F-Droid release and reproducible builds

rugk commented 3 years ago

Avoid duplicates

[x] This enhancement request has not already been raised before (it has, but the situation has changed, see below)
[x] Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
[x] 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 https://github.com/corona-warn-app/cwa-app-android/issues/477 and https://github.com/corona-warn-app/cwa-documentation/issues/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 https://github.com/corona-warn-app/cwa-documentation/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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? :wink:

Thanks!

rugk commented 3 years ago

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 commented 3 years ago

@svengabr Oh, great to see progress here! :tada: :smiley: 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Just to reference it: Related Issue: https://github.com/corona-warn-app/cwa-wishlist/issues/57

qoheniac commented 3 years ago

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

heinezen commented 3 years ago

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 commented 3 years ago

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 :wink:

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? :smile:). Whether conspiration folks do is another matter :wink:

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

fynngodau commented 3 years ago

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 commented 3 years ago

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 https://github.com/corona-warn-app/cwa-app-android/issues/75, the now second most-upvoted issue in this repository, which has the same aim of de-googlefying the app.

rugk commented 3 years ago

BTW another cross-link. Reproducible builds were previously discussed in https://github.com/corona-warn-app/cwa-backlog/issues/21 and https://github.com/corona-warn-app/cwa-backlog/issues/21. The community (namely @gutjuri, credits to them) even already did some initial work in form of a Docker file: https://github.com/corona-warn-app/cwa-app-android/pull/468

ljl-covid commented 3 years ago

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.

@Schyrsivochter to the best of my knowledge, based on talking to F-Droid people before, this is not true. A version of CWA that only includes free software would be eligible for including in the main F-Droid repository, even if it makes use of the Play Services API (whether it be implemented by the "real thing", or microG). The problem is that in order to to be able to use the Play Services API, an app normally includes a proprietary client library that Google provides. That cannot be released in the main F-Droid repository. However, it would be possible to write a free replacement for such a wrapper, and microG has had an incomplete one for a long time (yes, that GitHub repo is archived now, and I'm not entirely sure if this is now available in the main GmsCore repo, but maybe @mar-v-in can clarify that). The thing is that no one, so far, has seemed to take an application, fork it, and actually make it use that client library and maintain it, and then propose it for inclusion in F-Droid. Until it happens, there won't be an application using microG in F-Droid, but it's not, per se, due to F-Droid policies! It basically boils down to nobody having done it.

Note that this is all relating to the main, official F-Droid repository, where things are built from source by the F-Droid team; much of this issue (the original issue) seems to have an underlying assumption that reproducible builds should be used, in which case, provided the proprietary client library is done away with, the app could be in both the official F-Droid repository and in a third-party F-Droid repository with the same signature, hence identical; but if that were not the case (and considering reproducible builds can be tricky), then I want to note that an app provided in binary form, and possibly included proprietary parts, in a third-party F-Droid repository provides no higher "factor of trust" for anyone, unless someone misunderstands the mechanisms: getting the app from a third-party F-Droid repository or getting it from Play Store, possibly using a third-party client to avoid the proprietary one (e.g. Aurora Store), would provide the same app with the same level of trust. Of course, it can simply be more convenient to have it in an F-Droid repository for people who don't have the Play Store or Aurora Store installed, but convenience and trust are different. I just wanted to clarify this, as this issue covers several combinations of possibilities that are not all equivalent.

IzzySoft commented 3 years ago

@rugk

But if the API is really easy maybe this part can indeed be re-implemented as FLOSS

Marvin is already on it, just scroll up a little.

And @ljl-covid is correct: if implemented fully FLOSS it would be acceptable to F-Droid (disclosure: I'm one of the maintainers there). Even if it would interact with some non-free API. For things like that F-Droid has AntiFeatures, so the app might be marked NonFreeDep then (depending on some non-free stuff that must be installed on the device for the app to work).

would provide the same app with the same level of trust

Disagreed, partly at least. Concerning the APK itself, yes. But fetching it from Play requires direct interaction with Google servers. Fetching it from a (3rd party) F-Droid repo does not. Again, let's focus on the availability of the APK first, as that's not too hard to achieve (technically) – and leave the rest for later. Step by step we're getting there. Don't ask for too much too soon (but ask it at the appropriate time :wink:).

spth commented 3 years ago

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

Even without microG the App is useful. Contact tracing won't work, but it can still be used to see test results. And for many, the App is the only way to see their test result: https://github.com/corona-warn-app/cwa-app-android/issues/1587

rugk commented 3 years ago

As it has also been said in a related issue, is there any information about the status of this – very popular – feature request? @svengabr, you are assigned and it is tagged with “in progress” and somewhere in the GitHub Kanban/project (in TODO, then "mirrored to Jira").

The last update was from @heinezen:

If we get any news or updates from the development team regarding this request, we will also post them here.

Well… it has been a month now. So what should "in progress" actually mean? Do you still have no reply from RKI or whoever needs to decide that or whatever input you still need?

rugk commented 3 years ago

Hu? :astonished: What does this bot do? Move everything to "ToDo" when someone comments? :sweat_smile:

IzzySoft commented 3 years ago

As the BfDI was just interviewed on this topic, I've asked them to "animate" the RKI in this direction. Maybe it helps a bit if the voice comes from "upstairs" instead just from us "peasants below" :roll_eyes:

To repeat what for sure already has been said: looks a bit schizophrenic to complain about not enough people participating – when you don't make it available to them. And yes, this goes in direction of the RKI or whoever is holding this back, not the dev team here.

rugk commented 3 years ago

Also awesome good news from the microG developer @mar-v-in the latest microG release has initial support for „microG EN as a library”, and @mar-v-in said „it should be a drop-in replacement”. So as far as I understand that, that should also remove the current blocker (for F-Droid inclusion) of proprietary Google libraries that were mentioned before. So F-Droid inclusion is even more realistic now.

IzzySoft commented 3 years ago

Besides, here are the replacement steps as listed by the microG dev:

remove all com.google.android.{play,gms} dependencies from build.gradle
remove all play-services-nearby*.aar as well
add new dependencies:
- org.microg.gms:play-services-nearby (client library)
- org.microg.gms:play-services-nearby-core-ui (implementation)
Profit.

Additional profit when run on a device with "microG core" installed, quoting the author:

wenn man die Implementierung direkt einbettet werden auch zusätzlich die Funktionen von microG die nicht über die Google API verfügbar sind erreichbar. Damit wäre es dann möglich im Falle einer Warnung Datum und Uhrzeit des Kontakts anzuzeigen.

Rawly translated:

if you embed the implementation directly, you will also be able to access additional microG features that are not available through the Google API. So it would be possible to show date and time of the contact in case of a warning.

dsarkar commented 3 years ago

Hi @IzzySoft, @rugk,

We will approach the developers with your suggestions regarding F-Droid/apk/reproducible builds, and will come back to you hopefully soon with some new information regarding these issues.

Best wishes, DS

Corona-Warn-App Open Source Team

rugk commented 3 years ago

For everyone following: good news again, the community is working on integrating the mentioned microG lib into the CWA app/a fork of it + releasing it on F-Droid. See https://gitlab.com/fdroid/rfp/-/issues/1387#note_455703679 and https://codeberg.org/corona-contact-tracing-germany/cwa-android Seems the community is faster than SAP here.

That said; this issue still stands, because e.g. reproducible builds could also be contributed back to the fork and would benefit everyone. Also an official release would also be glad, of course. Of course, CWA can also use the patches proposed in the fork/downstream (as long as the license is followed) – that's the spirit of open-source.

rugk commented 3 years ago

Backlink: heise news wrote about this.

Edit: Golem.de too.

JokerGermany commented 3 years ago

I will switch to corona-contact-tracing-germany as soon as i get informed that it's avaible on F-Droid. You can notify me here, when the corona-warn-app didn't need to use a proprietary api anymore...

IzzySoft commented 3 years ago

I'm already using it for about a day (now that it's available outside Play and I finally can), waiting for it to turn from gray to green (which seems to take between 1 and 7 days). Several others use it already as well, since it became available from its testing repo. Should show up in the "official one" this week, it's metadata are already merged (so it's running through the build-and-sign process currently). My guess would be between tomorrow and Friday.

Got a lot of feedback from users who weren't able to use the app before (no Play Store etc), eagerly waiting to install and use it. Looks like the FOSS variant will bring some additional benefits, again inviting more users – so it will probably also support those with older devices still sitting on e.g. Android 5 (the CWA requires Android 6), if the manufacturers/ROM-bakers had BLE implemented there already. Not initially with the first release, but it's being worked on.

So, as claimed in our requests, this sets the app on a broader user base. The team is open for cooperation – so maybe CWA team will one day pick up the FOSS implementation for its benefits: independency from "overseas", support for more devices, enhanced trust due to full auditability. Then, one day, the official app might show up at F-Droid – cross-signed by CWA team and F-Droid. That'd be great!

qoheniac commented 3 years ago

For me it turned green on the second day. I am running both at the moment until the FOSS version has 14 days of data and then will disable ENs in microG and remove the original app. Really great to finally see this working! BTW, you can support Marvin Wißfeld through Liberapay or here on GitHub.

Alfred-Franz commented 3 years ago

Thank you so much for solving this! Installation with F-Droid on my Huawei P7 Lite worked without any problems ... Before that I spent hours trying to get the original version with google play services running, which never succeeded. I'm a big fan of the open-source community!

rugk commented 3 years ago

BTW, SAP you can now also use a microG library to just replace the propriertary Google Play Services lib dependency in your app. See https://github.com/microg/GmsCore/issues/1166#issuecomment-742502212:

Technically it should be possible to use the client library with original Google Play Services for a single, fully FOSS codebase. However, this was never tested, mainly because the app that uses the play services needs to be signed by an authorized key (which is only provided to official government organizations or their partners). Additionally, I doubt Google will allow the official apps as distributed through Play Store to use an alternative implementations of play services client library, but should any official government app be interested in doing this nontheless, I'd be ready to help out should any issues occur.

Regarding documentation: The API of microG client library is exactly the same as Google, so all of the Google documentation can be used as is, except that a different library is to be used as I described on Mastodon.

fynngodau commented 3 years ago

I would like to point our that our fork CCTG builds reproducibly: https://codeberg.org/corona-contact-tracing-germany/cwa-android/src/branch/main/docs/rebuilding.md

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. The builds we publish are verified for correctness by the F-Droid build server, which then publishes our builds with our signature.

IzzySoft commented 3 years ago

@rugk I'm curious how long it will take RKI to decide on that. Based on past experience, I'm afraid they never decide unless getting pressure from "upper echelons". It's a bit schizophrenic: they want more people to use it but are obviously unwilling to permit them to (first with the APK, now with the EN API). So honestly, it would surprise me. But then, I like to be (positively) surprised…

rugk commented 3 years ago

Yeah, I also see no progress here on the SAP/RKI-side (that said, the community is doing great!).

Also, as there also seems to be no transparency about the current state or what is happening here, here we have a FOI request (freedom of information; IFG – Informationsfreiheitsanfrage) on FragDenStaat about this topic: https://fragdenstaat.de/anfrage/sap-cwa-jira-tickets-zu-den-themen-f-droid-vollkommen-quelloffener-software-und-reproduzierbare-builds-corona-warn-app/ Feel free to follow, it asks for some internal Jira tickets about this topic/reproducible builds/F-Droid etc.

IzzySoft commented 3 years ago

Somehow it's telling that they answer timely not being able to answer timely. Let's hope this is not just stonewalling. They should be able to at least partly answer in-time (eg. providing the requested details of at least one or two from the requested issues). From past process, they risk seeming "unwilling to answer" instead of "unable to do so in time". They had half a year to answer on providing the APK – and I guess I'm not the only one wondering what makes that decision so complicated if not unwillingness.

And yes, I'm chiming in to your thanks towards the community (including the SAP/DTAG team working on the app)!

Ein-Tim commented 3 years ago

Although the RKI seems to be unable to provide useful information about this (and the other issues), maybe one of the community managers here could provide some details. Is there any work going on reg. the above mentioned issues? In which phase are the issues (discussion, waiting for RKI feedback, etc)? (cc @svengabr, @dsarkar, @heinezen)

Thank you!

GisoSchroederSAP commented 3 years ago

All, please note that we are asked not comment at all any status or activities regarding the F-Doid topic including the above-mentioned "freedom of information enquiry" (Informationsfreiheitsanfrage). The reason is simple - we are not in charge here: Because of the technical, legal, support and politcal implications the only communication will come from the Federal Ministry of Health (BMG).

ndegendogo commented 3 years ago

@GisoSchroederSAP Thanks for clarifying this - it adds a big amount of transparency to understand the constraints and the procedure.

JokerGermany commented 3 years ago

Perhaps the IFG is should be directed to the Federal Ministry of Health, too? ;)

It would be a time waste if the RKI is answering: Ask the Federal Ministry of Health about it

rugk commented 3 years ago

To BMG: https://fragdenstaat.de/anfrage/sap-cwa-jira-tickets-zu-den-themen-f-droid-vollkommen-quelloffener-software-und-reproduzierbare-builds-corona-warn-app-1/

:smiley:

hrehfeld commented 3 years ago

To BMG: https://fragdenstaat.de/anfrage/sap-cwa-jira-tickets-zu-den-themen-f-droid-vollkommen-quelloffener-software-und-reproduzierbare-builds-corona-warn-app-1/

Answer:

zu Ihrer Anfrage vom 10. Januar 2021 teile ich Ihnen folgendes mit:

Die von Ihnen angefragte Informationen liegen im Bundesministerium für Gesundheit (BMG) nicht vor. Jira ist ein technisches System, das in der Softwareentwicklung zur Bearbeitung von Tickets eingesetzt wird. So ermöglicht das System etwa das Einstellen und die Bearbeitung von Fehlermeldungen, ggf. in einem Levelsystem. Bei dem Betrieb der Corona-Warn-App wird ein entsprechendes System zur Abstimmung zwischen SAP Deutschland SE und Co. KG sowie T-Systems International GmbH eingesetzt. Das BMG hat auf dieses System jedoch keinen Zugriff.

Mit freundlichen Grüßen

tldr: BMG can't access Jira, so can't answer the question.

corona-warn-app / cwa-app-android