Cwa-app-android: Origin of "play-services-nearby-18.0.2-eap.aar"

[egandro]

Please use a Maven based repository for the location of this file.

Just putting a file here - without proper tools of verifying it's checksum can look shady.

[Magoli1]

Hey @egandro ,

we also noticed this and could relate it to the missing update to 18.0.2 in the maven repository (see here and google). We suspect that this is also the reason why the example app from Google does it the way, the cwa-app does it. Nevertheless - does somebody from the project team know, if there are plans from google on releasing this to eg. maven?

Best Regards 🚀
Robert Jakobs & Tim Brüggenthies (@timbrueggenthies)

[ironjan]

FYI: I added an issue "upstream" in Google's reference app. (https://github.com/google/exposure-notifications-android/issues/23)

[pwoessner]

I can confirm that your assumptions are correct @Magoli1 . We have included the library this way because currently this is the only option. As soon as there is an official release from Google we will switch. But we don't know if and when Google will do this.
Thanks @ironjan for taking the question directly to Google and creating the issue 👍

We will keep this issue open and share updates as soon as we know.

[egandro]

I can confirm that your assumptions are correct @Magoli1 . We have included the library this way because currently this is the only option

However - to increase trust this is not your only option.

You can add a build task to verify the checksum of this file. Maven will do this for literally any other library you include during the build process.

If you avoid this by "we don't know how" the SAP / Telekom team loses trust!

There is a lot of build in stuff in Gradle on how to do very easy dependency verification:

https://docs.gradle.org/current/userguide/dependency_verification.html

[mh-]

@egandro I don't understand how a checksum would add trust. The corona-warn-app project is already vendoring this library here within the Github project. So everybody can verify that it is the same version as before, or not the same version, for whatever reason that might be interesting.
If you could explain why an additional checksum might be important, please go ahead.

[egandro]

@egandro I don't understand how a checksum would add trust.

Let me explain (with sarcasm).

"Maven does a sha256 for every library file we use during the app build, while the only aar file we added we don't check - because we don't know how. Checks of libraries are overrated - you have the source."

Does this look trustworthy for cracks like the CCC nerds or the "Gesellschaft für Informatik"? I doubt that.

[mh-]

I still don't see your point.
If your fear is that somebody manipulates the tool that SAP uses to build this app (which isn't Maven BTW), and then these tools don't include the published .aar but a modified version, this attacker could certainly also manipulate the build script you proposed. Allowing for Reproducible Builds would be a better solution.

[marcmuschko]

Dear @egandro,

your concerns are understandable and it is certainly part of our main interests to ensure a high level of trust for the application. However, as this library is not officially available yet, what is your suggestion on verification of the checksum? Where could we get the library including its checksum from a trusted source for users to compare to for file integrity?

This blocker aside, please keep in mind that, while SAP is one of the parties involved in the development of the Corona Warn app, we do not have control over the underlying API provided by Apple and Google and therefore cannot influence the (public) release cycle of the library.
As stated by @pwoessner we will include the verification as soon as this option becomes available.

Best,
Marc

[egandro]

However, as this library is not officially available yet, what is your suggestion on verification of the checksum?

Already answered! A few lines of code to a gradle file are required!

https://docs.gradle.org/current/userguide/dependency_verification.html

Just copy&paste the official sha256/512 from google.

If they do not provide one - please asked them to do so!

Then you add the origin of this sha checksum to the gradle file..

[ironjan]

Adding the SHA256 sum does not really add any more trust because it would still be some file from the internet with no official release.

However, it would be good to add some note that currently play-service-nearby:18.0.2-eap of commit https://github.com/google/exposure-notifications-android/commit/174cf0dab62d0c7c5d2c5d1abe5bef595d0d4942 is used. That way, interested users can verify the integrity of the file in this repository by comparing it to the one within the reference implementation repository. Unfortunately, there are three "releases" of 18.0.2-eap in their repository…

[egandro]

Adding the SHA256 sum does not really add any more trust because it would still be some file from the internet with no official release.

Sure! so we call this a "Snapshot".

One can simple put a checksum to a file example.

Downloaded "play-services-nearby-18.0.2-eap.aar" - at 2020-06-03-23-41-49:042

Problem solved :) Everybody can reproduce the origin and the checksum.

[SebastianWolf-SAP]

Well, it seems that the discussion is somehow going in circles. It has been stated repeatedly in this forum that we are hosting this dependency ourselves and - by that - assuming responsibility for it. Also the trust aspect has been discussed repeatedly and it was stated with concrete reasons by several users independently that there is no benefit by adding a checksum to this particular file. The origin of this file has also been clarified.

As a consequence, we will close this issue. Thanks for the discussion and additional insights!

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team