F-Droid release and reproducible builds

[rugk]

Avoid duplicates

• This enhancement request has not already been raised before (it has, but the situation has changed, see below)
• Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
• If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation

App can only be downloaded from the Google Play Store.

Suggested Enhancement

Either:

• publish the app on the official F-Droid store (and/or)
• self-host a F-Droid repo and publish it there (like e.g. Tagessschau did)

Then:

• Do built that (your APK) reproducibly.
• Optionally, attach the APK to your GitHub releases. (And/Or upload them elsewhere.)

What has changed?

I saw #477 and corona-warn-app/cwa-documentation#5, however, these were asked months ago.
The main reason for declining it was that the api is from Google and requires Google Play Services anyway. However, this is not the case anymore.
Since September 2020, the Exposure Notification API can be used without Google Play Services on Android, if you use microG, which is a 100% FLOSS replacement for these Google Play Services. The reason is microG added support for the API in v0.2.12.203315.

Expected Benefits

F-Droid is an Android app store specifically for free/libre open-source apps. It would be great if your app could be released there, as it is the number one for getting FLOSS Android apps for many people.
F-Droid also builds all apps from source (optionally even reproducible), so downloads from there can be trusted.
This possibility then allows people to update the app both from Google Play and F-Droid as the signature is the same.

The app developer FAQ or the quick start guide may help you to get started.
If you want to self-host your repo, you can use Repomaker by F-Droid.

Anyway, now the advantages:

• it improves trust to have reproducible builds, see this website on reproducible builds. This is often overlooked when providing the source code of applications. You can then assure (i.e. verify) the binary also belongs to the source code you publish.
• it is good to have an alternative way of distribution (via F-Droid), and again this is a factor of trust (many people that do not use Google on Android trust F-Droid much more than the Google Play Store)
• Building reproducibly via F-Droid would then use a third-party to verify that the binary you get (from Google Play or elsewhere) is genuine (i.e. really built from the source code you publish).
  Note for this to be effective you should use the official F-Droid repository, because then you do have an neutral third-party building the source code (instead of youself doing it and just publishing the APK).
• Reproducible builds allow users to choose and switch the download channel at any time, i.e. you can download from Google Play, but later update via F-Droid.
• it is then possible to use it with a 100% FLOSS Android CustomROM. You can e.g. use it with CalyxOS, which is a ROM aimed at providing enhanced privacy even for non-experts. So all arguments against the F-Droid release that you "have to trust your OS anyway" are not applicable anymore, because in such a ROM you do not even have to use Google services at all on your Android device and starting from the group up (in the extend that it is technically possible today, i.e. the OS) it is 100% open-source. Some ROMs go beyond that like Replicant OS and I guess even on them you can install microG and thus use this app.
• You provide anyone who does not use Google Play a method for easily retrieving and updating(!) the app. Currently, this can only be done by apps like Aurora Store or so, which access the Google Play Store, but where updates is a bit harder (no auto-updates unless you manually flash another package etc. and IMHO it is slower than F-Droid). For F-Droid auto-updates many ROMs do have the privileged extension preinstalled like LineageOS4microG.
  Thus, in summary, you would allow more users to (easily) use the app, extend the user base and - which would be a legal argument one may even bake with constitutional law (Grundgesetz) - allow all people (in Germany) to easily use the app. Currently you do force them to use the Google Play Store, which is not resonable anymore given the app is easily deployable on F-Droid (or as an APK in general) and people can use it without Google Play (Services).
  I know of course you can self-compile the app from source, but then the official Google Play Services do not accept it anymore (I'm not sure whether microG also enforces this) and of course you cannot expect people to do that, not everyone is tech-savvy enough to compile an app and even if you are, it takes time and makes updates a pain. And before you now argue that only tech-savvy people could use an Android phone without Google (and microG), that is fundamentally wrong, as e.g. you can buy a Fairphone 3 with /e/ (eOS) or other partially re-flashed devices with eOS, which do have microG preinstalled - and do not have any Google Play Store nor Google Play Services - just to name one example.
  Furthermore, issue Availability in F-Droid cwa-documentation#5 shows there is a quite high demand for this on GitHub at least.

Again, I'd like to stress that the situation has changed fundamentally since this has last been proposed, so please don't close this as a duplicate. I understand why the issue was closed when the app development was started and never imagined microG would implement the exposure notification API, but as they did, I see no reason anymore to not publish the app on F-Droid. As I elaborated, actually I see many advantages in doing so.

/cc @IzzySoft @henrykrumb @jugendhacker @Bubu

---

Internal Tracking ID: EXPOSUREAPP-3447

[IzzySoft]

Let me emphasize the 3rd bullet point of the "expected benefits" once more – before you bring your argument of the RKI not having given its "green light": As it stands now, sceptics could claim the app you deploy via Google Play is not (entirely) based on the code you publish – and rightfully say your word alone does not prove otherwise but, as you continue refusing to have a reproducible build, you might do so because there's something you need to hide.

I urge you to prove otherwise – for the reasons @rugk pointed out already: improve trust, improve availability to a larger audience (doesn't the RKI want as many people as possible running the app? My device now supports it, thanks to microG, but I will NOT connect it to any Google service to do so; many other people I know think the same way), thus gaining more coverage.

If you want so, tell the RKI users are pressing you. It is not clear to us whether the RKI is aware of that – or if it was asked for this at all (they might not have agreed because no one asked them to).

[chris42]

I think this issue is less about the "not needing google play services anymore", as introduced above, but about access to the App by non google play store means.
The app still needs google play services or a fake of it. As a fake, like microg can't be bundled with the app, RKI will not be able to provide a "google play services free" version.

However where @rugk is right, it would be great for the no-google community, if there would be access to the app via means not being the google play store. Like a download on the RKI website or a F-Droid repository.

[Schyrsivochter]

Based on how I understand it, it is unlikely that the official F-Droid repo will include CWA, because it depends on a Google Play Services API – no matter whether that is implemented by proprietary or free software. A release channel with automatic updates independent from the Play Store would have to be a dedicated CWA F-Droid repo. Regardless of whether that may be feasible or not, I also think that GitHub releases should have APK builds attached for anyone to manually download who may need it.

[kbobrowski]

I think reproducible builds and attaching APKs to github releases is a great idea, but the problem may be keeping microG up-to-date with Play Services implementation, especially in case Google won't be promptly releasing code for the next versions of ENF (as it was not doing so far). CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported

[chris42]

I think reproducible builds and attaching APKs to github releases is a great idea, but the problem may be keeping microG up-to-date with Play Services implementation, especially in case Google won't be promptly releasing code for the next versions of ENF (as it was not doing so far). CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported

That is not connected to an alternative download. CWA should not and is not waiting for microg right now. Microg users know that and it should not be an issue for CWA, but more for microg. Having an alternative download option would just remove the hassle of forced app store registrations and apps to fake the store itself, promoting a free way of software distribution.

[kbobrowski]

That is not connected to an alternative download. CWA should not and is not waiting for microg right now. Microg users know that and it should not be an issue for CWA, but more for microg. Having an alternative download option would just remove the hassle of forced app store registrations and apps to fake the store itself, promoting a free way of software distribution.

I know, but "F-droid as alternative download option" could be provided already at the launch of CWA, but it was refused. Not sure how microG changes anything here, but let's see what would be SAP / RKI response

[IzzySoft]

As a fake, like microg can't be bundled with the app

That's also not needed. Just ship the very same APK that is deployed to Google Play. If microG is installed on a device, it takes care for the rest – as would Google Mobile Services on a device that ships with the entire Google framework.

Again, to make it clear: No changes to the APK are required. We're just asking to make the very same APK you deploy to Play Store available outside of Play Store. Ideally using reproducible builds, to increase trust etc. as pointed out in the initial post.

CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported

So it's better to leave the entire "privacy community" entirely outside? I cannot follow that reasoning. No offense meant, but sometimes it looks like a search for excuses not to provide the app outside Google Play. That's pretty much frustrating, and makes us privacy folks think to abandon the idea of contribution altogether – because we're getting tired of begging. Looks like we're not wanted to "join forces fighting Covid".

but let's see what would be SAP / RKI response

Yes, please! And it would be great to have that transparent as well – what ever the answer might be, make it a "headline". And hopefully that headline isn't "RKI refuses…" – as that would feeding the "the APK they ship does not correspond to the code they show" idea, and we want to avoid that, right? 😉

Thanks!

[rugk]

I know, but "F-droid as alternative download option" could be provided already at the launch of CWA, but it was refused.

Well, the stated reason (as linked above) was, that it just made no sense at that time: Without Google Play Services you literally had no way at all to use the app. This changed and using the app from F-Droid is now possible (if you have microG). That is the main point.

[rugk]

@svengabr Oh, great to see progress here! 🎉 😃
Is there any statement/idea what you plan to do?

---

IMHO, as explained above, I would of course prefer an reproducible build and release in the official F-Droid repository.

[chris42]

As a fake, like microg can't be bundled with the app

That's also not needed. Just ship the very same APK that is deployed to Google Play. If microG is installed on a device, it takes care for the rest – as would Google Mobile Services on a device that ships with the entire Google framework.

That was more aimed on if RKI could advertise/promote it, that no GSF is needed. If they would do so, you really would need to be able to install it into a fresh AOSP without anything else.

I am a microg user myself and would be happy to not go through the google play store. However I guess the reason for RKI to deny it in the first place was a cost/benefit analysis: The software itself depends on GSF, hence the google play store gives you a good filter that only people download it that have it.

I think for RKI, SAP, Telekom, etc. it would be important to know, that the microg users and privacy hardcore friends do not expect anything big here. It would already help tremendously if you could offer a non play store download. It can even include the "for this you get no support" tag if it helps.

[rugk]

No one said, they should/have to promote that exact feature. Even if you don't advertise it, for everyone who uses microG (and judging from the upvotes here, these are not so few people that would like this) this would help a lot.

[kbobrowski]

So it's better to leave the entire "privacy community" entirely outside? I cannot follow that reasoning. No offense meant, but sometimes it looks like a search for excuses not to provide the app outside Google Play.

I'm all for releasing it outside Play Store, it's just that to officially support microG mode CWA team would need to work closely with microG developer to ensure that microG implements properly v1.5 / v1.6 and future iterations of ENF. Of course it's possible to release CWA as APK on github / to F-droid, without any official reference to microG, and this would be already beneficial for privacy whether microG exists or not, but so far has been refused. Curious to see the official statement of SAP / RKI on this, maybe circumstances has changed indeed

[kbobrowski]

Yes, please! And it would be great to have that transparent as well – what ever the answer might be, make it a "headline". And hopefully that headline isn't "RKI refuses…" – as that would feeding the "the APK they ship does not correspond to the code they show" idea, and we want to avoid that, right?

Well this is trivial to verify as there is no obfuscation ;)

[kbobrowski]

CWA includes this binary, would it even make it eligible for F-droid?

https://github.com/corona-warn-app/cwa-app-android/blob/master/Corona-Warn-App/libs/play-services-nearby-exposurenotification-1.6.1-eap.aar

[Ein-Tim]

Just to reference it:
Related Issue: corona-warn-app/cwa-wishlist#57

[qoheniac]

If at least official checksums could be provided. Is that really too much to ask? I don't see what stands against that.

[heinezen]

Hello community members and @rugk,

Thank you for the renewed feedback on the F-Droid support. Since the situation regading Google Play Services seems to have changed, we have forwarded this feature request along with the new information to the development team and the contracting entities. They will now evaluate whether (and how) it would be possible to implement F-Droid support and reproducible builds under the changed circumstances.

This thread can be used for further community discussions on the feature request. If we get any news or updates from the development team regarding this request, we will also post them here.

Best Regards,
CH

---

Corona-Warn-App Open Source Team

[IzzySoft]

I guess the reason for RKI to deny it in the first place was a cost/benefit analysis

I see no extra cost not worth the benefit in simply providing the very same APK e.g. attached to Github releases. So:

I think for RKI, SAP, Telekom, etc. it would be important to know, that the microg users and privacy hardcore friends do not expect anything big here. It would already help tremendously if you could offer a non play store download. It can even include the "for this you get no support" tag if it helps.

This I'd sign!

@kbobrowski

I'm all for releasing it outside Play Store, it's just that to officially support microG mode CWA team would need to work closely with microG developer to ensure that microG implements properly v1.5 / v1.6 and future iterations of ENF.

I just read that Marvin is working on a FOSS library to replace the proprietary parts required in the app itself. While that would certainly be very, very welcome (don't let me stop you!) – let's focus on the "easy part" first: to provide the APK as-is outside Google Play. Without any "support promises" for "non-standard installations", fully understood. It's reported to work fine with microG.

Of course it's possible to release CWA as APK on github / to F-droid, without any official reference to microG, and this would be already beneficial for privacy whether microG exists or not, but so far has been refused. Curious to see the official statement of SAP / RKI on this, maybe circumstances has changed indeed

Full ack: please urge them to make their decision public. They're speaking so much about transparency, let them live it 😉

Well this is trivial to verify as there is no obfuscation ;)

I cannot tell, I'm not an Android dev (or security researcher). But I believe you (otherwise, why should I press so much for that APK? 😄). Whether conspiration folks do is another matter 😉

CWA includes this binary, would it even make it eligible for F-droid?

Nope, that's what's considered a "blob"; F-Droid insists on being able to build every component from sources.

For clarification, as some things got a little "mixed up" here: F-Droid currently can NOT build the app itself. THAT will change when Marvin's FLOSS replacements for the GMS libs are used. So the "reproducible builds" by F-Droid have to wait for that (other parties might be able to do the "reproducible builds", though).

Thanks for your commitment!

[kbobrowski]

@IzzySoft interesting, so CWA would need to depend on FLOSS lib instead of Google-provided binary, in order to be eligible for F-droid. I guess this would need to be another flavor. In the meantime APK attached to github release would be very welcome ;)

[chris42]

No one said, they should/have to promote that exact feature. Even if you don't advertise it, for everyone who uses microG (and judging from the upvotes here, these are not so few people that would like this) this would help a lot.

That was why I tried to clarify. The app is GSF dependent and nothing can be done about it. You can now argue for an easy access channel for users that use alternative GSF implementations and that is good.

My view on this: Having worked for Telekom and with SAP, a simple download or release on github will be the easiest and hence most palatable for RKI. No one there will discuss right now sinking a few days work into a fdroid reproducable release repository to reach a few tens of thousand of users. Developing the app and improving will always have priority.

So if you wish to have alternative access, ask for the simplest solution, that does involve a minimum of work.

[realpixelcode]

I just want to briefly state that I also urgently demand a release in the F-Droid Store!

[fynngodau]

CWA includes this binary, would it even make it eligible for F-droid?

Nope, that's what's considered a "blob"; F-Droid insists on being able to build every component from sources.

Of course @IzzySoft is right here that this would make it ineligable for the official F-Droid repo as-is, and I would like to add that CWA additionally depends on these proprietary google librares (per build.gradle):

    // Play Services
    implementation 'com.google.android.play:core:1.7.3'
    implementation 'com.google.android.gms:play-services-base:17.3.0'
    implementation 'com.google.android.gms:play-services-basement:17.3.0'
    implementation 'com.google.android.gms:play-services-safetynet:17.0.0'
    implementation 'com.google.android.gms:play-services-tasks:17.1.0'

I'm not sure what precisely is the purpose of these; specifically, I'm not sure why there is a dependency on safteynet, as cwa does not require SafteyNet to pass.

[rugk]

Yeah, I also was made aware of that proprietary dependency, though, as people have noted, they can certainly get rid of many – which would be very useful in general, because only then the app is 100% FLOSS and can thus be trusted.
I like how F-Droid always makes such issues transparent. So let's think of it: We want CWA to be free/open-source, not only 99%, all of it. Regardless of where users download the app. Ideally, at least…
Also I don't know why Google decided that the exposure notification API needs a proprietary client-side lib in your app – especially as they published many other internals of the API as FLOSS, just why?
Actually, as far as I see, in their reference implementation they do not include any of these libs. Oh, actually they do, but not the SafetyNet one.
But if the API is really easy maybe this part can indeed be re-implemented as FLOSS, but I'm no expert in these technical issues, so I'll let others comment here.

Anyway, it seems this overlaps with #75, the now second most-upvoted issue in this repository, which has the same aim of de-googlefying the app.

[heinezen]

While I can't say anything about the F-Droid feature request, I can tell you about the general process oof how feature requests are handled. Maybe that clears some of the things up. However, please keep in mind that the process can differ slightly for every feature request, and especially for features that require a lot of development attention.

The way features are proposed internally usually goes like this:

Community Team-->Dev Team-->RKI-->BMG

The more advanced features and decisions always have to be approved by the higher-ups in the chain. RKI and BMG decide where the strategic development priorities are. We (the community team and the devs) are constantly providing input based on community feedback, so there is a degree of influence from our side. However, the BMG has the final say on what is done and what should be communicated.

We have regular feedback talks for community topics, so the RKI and above are aware of community input, but we often have to wait for an official answer before we can communicate progress back to Github.

Then I would try to submit a request to the BMG, else we will stuck waiting for the JIRA-label, which may be obsolete, don't we?
Cause i guess that waiting for the internal process and hoping for activity, will not lead us anywhere.

We (the community) also only know what has been discussed here. We know that this request has been mirrored to the internal ticket system JIRA (see the label mirrored-to-jira) and is tracked there with the Internal Tracking ID: EXPOSUREAPP-3447 (see bottom of the OP).

For Github Issues, the content in the Jira ticket is pretty much the same as the content on Github. It's mainly used by the development team to track issues from all feedback sources (Github, App Store, Play Store, Internal Testing). Most of the stuff in there already gets mirrored back to Github.

---

Corona-Warn-App Open Source Team

[1Maxnet1]

While I can't say anything about the F-Droid feature request, I can tell you about the general process oof how feature requests are handled. Maybe that clears some of the things up. However, please keep in mind that the process can differ slightly for every feature request, and especially for features that require a lot of development attention.

The way features are proposed internally usually goes like this:

Community Team-->Dev Team-->RKI-->BMG

The more advanced features and decisions always have to be approved by the higher-ups in the chain. RKI and BMG decide where the strategic development priorities are. We (the community team and the devs) are constantly providing input based on community feedback, so there is a degree of influence from our side. However, the BMG has the final say on what is done and what we should be communicated.

We have regular feedback talks for community topics, so the RKI and above are aware of community input, but we often have to wait for an official answer before we can communicate progress back to Github.

Then I would try to submit a request to the BMG, else we will stuck waiting for the JIRA-label, which may be obsolete, don't we?
Cause i guess that waiting for the internal process and hoping for activity, will not lead us anywhere.

We (the community) also only know what has been discussed here. We know that this request has been mirrored to the internal ticket system JIRA (see the label mirrored-to-jira) and is tracked there with the Internal Tracking ID: EXPOSUREAPP-3447 (see bottom of the OP).

For Github Issues, the content in the Jira ticket is pretty much the same as the content on Github. It's mainly used by the development team to track issues from all feedback sources (Github, App Store, Play Store, Internal Testing). Most of the stuff in there already gets mirrored back to Github.

Corona-Warn-App Open Source Team

Thank you very much for your information. Then it is fine to me, if the request goes the internal way you described and I would not contact BMG additionally.

Of course, it would be very cool to have some insight into what point a request is currently at and when you can expect feedback (for example: F-Droid Realease has already been agreed with the development team and the request will be communicated to the RKI at the next consultation in mid-March or something like that)
Thanks for your work, really appreciate how Corona-Warn-App Open Source Team interacts with the community.

[JokerGermany]

Just a little reminder:
https://themarkup.org/privacy/2021/04/27/google-promised-its-contact-tracing-app-was-completely-private-but-it-wasnt
;)
Pls use the Free Implementation!

[fynngodau]

As documented there, the only thing we needed to change was that we pre-generated all XML assets as PNGs, because those were non-deterministic for some reason. Then it built reproducibly in the F-Droid environment.

Since #2800 was merged into the Android app, this workaround is now no longer necessary and the app should build reproducibly as-is.

(Besides that this is only of limited use due to the proprietary closed-source components from Google.)

[fynngodau]

The current status regarding reproducible builds is that it is not a far way, but some adaptions are necessary due to:

• the problem discussed in Remove top-level action elements from nav graph (COMMUNITY) #3325 (comment)
• the desugaring library working in a non-reproducible way. https://codeberg.org/corona-contact-tracing-germany/dgc-certlogic-android and https://codeberg.org/corona-contact-tracing-germany/dgc-business-rules can help with that.

[Ein-Tim]

@dsarkar @larswmh @svengabr

Could we have an update on this topic? Reproducible builds are, as described by @rugk in the OP a central element for being trustworthy. What exactly is the current status here?

@fynngodau What is your current take on RBs? Would they be achievable in the near future (from a technical perspective)?

[rugk]

@fynngodau What is your current take on RBs? Would they be achievable in the near future (from a technical perspective)?

Huh? You know @fynngodau et al are doing reporducible builds with the CWA code base in CCTG today already? See their guide for details.

Note from what I've heard they regularly have problems with updates as they break this process. I guess if reproducible builds were a feature/priority for the upstream SAP team here, which have much more manpower that would likely help (a lot), but I don't know the details here, so I'll let someone from the CCTG team comment…

[Ein-Tim]

@rugk

I'm aware of RBs @ CCTG, however, @fynngodau posted some kind of assessment in #1483 (comment) so I wanted to see if there is any news on this, e.g. because something changed.

[Anke]

I don't understand, why our government decides to spend tax payers' money to have apps (CWA just being one of them) developed that depend on big data companies.

As an /e/OS-user I was able to install CWA from the built-in App Lounge. I would have preferred APK or F-Droid installation. While the installation went smoothly, the app tells me that I cannot use it, because the "Covid-19 notification service" isn't part of my OS. There are apps using independent, built-in push services, like Threema Libre e.g. There are other projects developing independent notification/push services. Why isn't there an APK including the notification service?

I am very much aware of current market shares. But the number of independent Android users seems to be growing. And I think it's high time to prove that we can do without the two non-European monopolists.

[Ein-Tim]

@Anke As an alternative for your exact case: Use CCTG from F-Droid. You can get it here: https://f-droid.org/de/packages/de.corona.tracing/

[Anke]

@Ein-Tim Thank you for that tip, although I wasn't addressed. Really great! The State should have developed this version.

[mtwalli]

Not planned