F-Droid - WITHOUT their Official Repo or their Policies

[aphirst]

Note: I calm down later in the thread.

I brought this up in IRC today (and I think I've also brought it up before), and was recommended to bring it up here. I'll try to summarise this.

I'm aware that there's been some friction between the Palemoon development team and the maintainers over at F-Droid regarding their Official repository. As a result, Palemoon is not available therein, and this situation is not going to be changing any time soon.

However, there is still interest among many Android users (of which it seems I'm claiming to be somehow representative) to be able to install Palemoon from a source that can provide official, automatic updates (so, not just installing the raw .apk or self-building), but without having to marry themselves to the Google infrastructure.

It seems from the discussion in IRC that the Palemoon maintainers aren't aware of another option - it is indeed possible to have Palemoon installable through the F-Droid package-management software by non-GApps users, but without Palemoon having to have any ties with either the F-Droid maintainers or with their official server: it is possible to set up your own F-Droid repository: https://f-droid.org/wiki/page/Setup_an_FDroid_App_Repo

If you host your own F-Droid repo, then people can use F-Droid to install your own builds signed by your own signing key

After you set up such a repository (which from their guide, seems quite simple), all a prospective user would need to do is click your "F-Droid" link on your page, have your repo with its key added to their list of package-sources, and then simply install Palemoon from it using the F-Droid software.

So... could this be an option?

[Moonchild]

I'm aware. and I looked at it before. However, due to the friction about this in the past I can't support the way they do things in their main repo (and as such can't and won't support F-Droid, period), and having alternative repos like outlined is not as convenient or simple as you think (see "real world setup" in that wiki) and I don't want to jeopardize my keystore with my code signing key/cert. It also feels like a bad hack to their system.

In addition, f-droid repos created this way are not at all discoverable; it will be purely a client-side link made to the individual repos which is a lot of extra work for no added value for us.

[aphirst]

Edit: maybe I came off a bit strong, I'm pretty frustrated about this situation; lots of Android developers on a lot of fronts seem to absolutely utterly not care about Android users who wish to reject the Google Malware, or the tacit requirement to have Google accounts. Perhaps I should just state my basic point, since you are keen to state issue after issue, what would you expect of a hypothetical means to get updateable builds to non-GApps users that you would not automatically discard?

OK, let me break this down.

However, due to the friction about this in the past I can't support the way they do things in their main repo (and as such can't and won't support F-Droid, period)

This just sounds like you've had one bad experience and are now cutting off your nose to spite your face, to be perfectly honest.

and having alternative repos like outlined is not as convenient or simple as you think (see "real world setup" in that wiki) and I don't want to jeopardize my keystore with my code signing key/cert. It also feels like a bad hack to their system.

The "real world setup" part still doesn't seem inconvenient or complicated, and while I don't share your seemingly aesthetic judgement I confess that that's not something I feel capable of convincing you of. What do you even mean by "jeopardise" in this context? You seem to be complaining about the overcontrol of their central repos, but then complaining that being able to make an unassociated server is a "bad hack", so to be honest I don't even know what you're expecting (other, presumably, than non-Play-Store users to shut up and install GApps...)

In addition, f-droid repos created this way are not at all discoverable; it will be purely a client-side link made to the individual repos which is a lot of extra work for no added value for us.

Them being not discoverable isn't really an issue... How is this different from ANY other OS' mechanism for setting up user repositories to supplement deficiencies (for whatever reason) in main repos?

It just seems like you're inventing bullshit excuses to dismiss acknowledging the Android userbase who don't submit to the Google ecosystem. You've already set yourselves to "the only way I'll ever permit people to get automatic updates is via the Play Store and any and all options that differ from this in any way are automatically worse." Look, I get that you're pissed off with the F-Droid people, but I really cannot believe that you want to sit there and insist that the only distribution channel to non-Google users is manual download of .apks...

[Moonchild]

This just sounds like you've had one bad experience and are now cutting off your nose to spite your face, to be perfectly honest.

Let me break this down for you then with a direct analogy.
You don't like Google because of their overall practices; as a result you don't want to have anything to do with them, even if they offer convenient services. Would you, despite your dislike, still publish on the Google Play store? Probably not. Would someone asking you to publish on Google Play because it's more convenient for them change your mind? Probably not.

What do you even mean by "jeopardise" in this context?

I mean that Android Apps are cryptographically signed. Having the cryptographic keys on anything but a private system is a big risk, as even outlined on that wiki page. So, the issue would be that the APK is signed but the f-droid publishing setup still wants my keystore for... something^[1]. Because it needs the keystore, it needs me to set up a client machine JUST to push to my hosted repo. All of that is a lot of extra administrative work I don't want to do and (because it needs my truststore) I can't let anyone else do either. Not to mention that their client expects me to store my keystore password in cleartext in their config...

^[1] It's not even clear why I can't just do a binary distribution and why it needs my private key to publish on an f-droid type repo when the APK is already signed... Google Play sure as hell doesn't need this kind of info to distribute my App. So, before I can trust their framework with my private keys I'll have to do a sec audit on that. Not sure when I'll be able to fit that in, either.

non-Play-Store users to shut up and install GApps.

Or sideload like everyone else. No Google involved.

It just seems like you're inventing bullshit excuses to dismiss acknowledging the Android userbase who don't submit to the Google ecosystem.

And it seems to me like you're trying to get "your" F-droid delivery for Pale Moon in any way you can, even up to the point of insulting me by saying I make up bullshit. You'd better dial down a bit with your attitude, fast. -- Do you think this will make me any more amenable to listening to you or any other F-droid users now or in the future?
I'm not dismissing any Android users. If I wanted to limit y'all to the Google ecosystem I wouldn't offer 2 HTTP and an FTP mirror as well as an independent third party to get your damn APK from.

EDIT:

Look, I get that you're pissed off with the F-Droid people, but I really cannot believe that you want to sit there and insist that the only distribution channel to non-Google users is manual download of .apks...

Well, I haven't been pointed at any. You don't want Google, I don't want F-Droid. if there's a different publishing framework that you know of that does something in a sane way, then I'm certainly open to have a look at it.

[aphirst]

Alright, fine. I apologise. I'll try to be a bit more positive and a lot less accusatory - I'm sure that you can at least understand where I'm coming from though, even if you don't agree, and even if you don't want to publicly acknowledge it. I've been tearing my hair out recently also about how the "Signal" developers have ironically utterly tied at least their Calling feature to requiring the Google Push Notifications feature to even work. We do have someone maintaining a (rebranded) build, "LibreSignal", in his own F-Droid repo, where he also hosts packages of a fork that enables websockets for the text part. But for the Calling we're still up shit creek without a paddle.

If you yourself don't want to do it, would there be any hypothetical means to have Pale Moon regardless available in such a package-managed way to non-GApps users? Given that we do have package management now for Android that's free from Google and committed to FOSS ideals (at least ostensibly, and even if you don't see eye to eye with them), it just seems like a crying shame for non-GApps users to nonetheless be restricted to either sideloading or being jettisoned onto the proverbial highway.

I will point out that I'm not in a position to compare as I'm not involved in any FOSS projects that catch anyone's interests, never mind ones for Android, so while I would in fact like to say that I would submit builds to Google Play, albeit begrudgingly, I don't know what I would in fact do. If I were to dig my heels in, it'd probably be the other way round, but were the project to be something actually useful that would indeedbe the nose-cutting-face-spiting thing due to (at least in the sad current state of Google-centralised package management) hinder adoption.

And just to clarify where at least I stand, and where a few others I know do too, the issue with having GApps on the device is that the code to access the "Google Services" is nonFree, and that (at least to the very best of my knowledge) there is no way to access the Play Store builds of packages without having to also have a Google account.

[Moonchild]

would there be any hypothetical means to have Pale Moon regardless available in such a package-managed way to non-GApps users?

I repeat:
If there's a different publishing framework that you know of that does something in a sane way, then I'm certainly open to have a look at it.
And with "sane" I mean it doesn't try to do anything silly beyond actually publishing and providing updates to packages that are, for all intents and purposes, ready to be published as-is.

[aphirst]

Were there to be a feature to notify users of being out-of-date, and in such cases to at least direct the user to the PM4A homepage, that could be a stopgap for at least the short-term. Also were there the option to set home-page I would have already done this manually. As these features "sound simple", I assume there's some technical reason why neither are implemented.

I don't yet know of any other package distribution system for Android, at least not one that expresses any kind of interest of preference in FOSS, but of course if I find anything out (and if the thread stays open) I'll post something here. I'll also get myself in touch with the F-Droid guys, as I'd be interested to see what they have to say about the matter - if they happen to agree with or at least understand your objections to even setting up your own Server, never mind to use their Official one, perhaps they could be persuaded to change/improve something to accommodate for what would essentially be your suggestions. I'll see what I can learn myself.

[aphirst]

And with "sane" I mean it doesn't try to do anything silly beyond actually publishing and providing updates to packages that are, for all intents and purposes, ready to be published as-is.

Would this be the sort of thing you're after? Quote from that section of the page:
If you want to maintain a simple repository hosting only binary APKs obtained and compiled elsewhere, the process is quite simple:

[New Tobin Paradigm]

The script still for some reason insists on resigning the apk during repo generation. What we need to make this actually in the relm of possiblity is research into setting up a repo WITHOUT it affecting the apk .. period..

Maybe you can strip this process down and figure out exactly what is needed by the program to see a repo as valid.. If it can be done manually.. namely a metafile that can be edited and drop the already signed apk in to a directory on a server.. then maybe.. But right now it is too much hassle and still has some of the flaws hosting with them have.

[squarefractal]

Maybe you can strip this process down and figure out exactly what is needed by the program to see a repo as valid.. If it can be done manually.. namely a metafile that can be edited and drop the already signed apk in to a directory on a server..

It seems like things can be done manually.

F-Droid compatible repos contain an index.jar file, and the APKs to be served in a single directory (but named as {packagename}_{vercode}.apk; for more details, see below), and the icons of the APKs under icons/${packagename}.apk. The index.jar file has, containing an index.xml file, and the typical META-INF/*.{RSA,MF,SF}; where *.RSA has the signer's signature. An example would be the official repository: https://f-droid.org/repo, which has the organisation that I have described.

The index.xml file has the following structure:

Code: Select all

<?xml version="1.0"?>
<fdroid>
  <repo icon="<!-- icon for the repo -->" maxage="<!-- number of days the repo index is considered to be valid -->" name="<!-- name of the repository -->" pubkey="<!-- some kind of hex representation, not very sure what this is -->" timestamp="<!-- last update time -->" url="<!-- repository URL -->" version="14">
    <description><!-- description of the repository --></description>
  </repo>
  <application id="<!-- packagename -->">
    <id><!-- packagename --></id>
    <added><!-- date of addition in %Y-%m-%d format --></added>
    <lastupdated><!-- last updated time in %Y-%m-%d format --></lastupdated>
    <name><!-- Name of the application --></name>
    <summary><!-- short description of the application --></summary>
    <icon><!-- icon of the application --></icon>
    <desc><!-- description of the application --></desc>
    <license><!-- license of the application --></license>
    <categories><!-- application category, "Internet" for Pale Moon --></categories>
    <category><!-- application category, "Internet" for Pale Moon --></category>
    <web><!-- A web page further describing the application, can be left out by using <web/> --></web>
    <source><!-- link to source code --></source>
    <tracker><!-- link to bug tracker --></tracker>
    <marketversion><!-- highest version number --></marketversion>
    <marketvercode><!-- an unique incrementing number that represents unique versions --></marketvercode>
    <package>
      <version><!-- version number --></version>
      <versioncode><!-- see marketvercode --></versioncode>
      <apkname><!-- packagename -->.apk</apkname>
      <hash type="sha256"><!-- sha256 of the hash --></hash>
      <sig><!-- some kind of md5 sig, not sure what --></sig>
      <size><!-- size in bytes --></size>
      <sdkver>4</sdkver>
      <added><!-- date of upload in %Y-%m-%d format --></added>
      <permissions><!-- list of permissions, only containing the section after the last . for all permissions beginning with "com.android.", otherwise, name of the full permission seperated by commas --></permissions>
      <features>android.hardware.touchscreen,android.hardware.wifi</features> <!-- specific for Pale Moon -->
      <!-- <nativecode>armeabi-v7a</nativecode> --><!-- uncomment for native code applications meant for a single architecture; if there are different APKs for different architectures, they have to be listed seperately. -->
    </package>
    <!-- further package sections as necessary, to list all versions -->
  </application>
</fdroid>

I'm not going to do any further reverse engineering of the client and the server XML, so aphirst or someone else will have to confirm the usage of the pubkey attribute and the sig tag.

[New Tobin Paradigm]

Actually I know exactly what to do but not using the tools to generate a signature for the xml file is a tough one. But I am already exploring this front. Also your information on structure is completely wrong.

[squarefractal]

Also your information on structure is completely wrong.

I've looked into this quite a bit and there are indeed things that I'm not sure of (which I did mention in the reply above); but without some specifics as to what is wrong it is difficult to evaluate your statement.

Of course, reverse engineering has its limits, and I do not discount the possibility of something being wrong in the above information.