[guardian-dev] Complete, reproducible app distribution achieved!

Mon Feb 16 04:28:00 EST 2015

str4d:
> Hans-Christoph Steiner wrote:
>> str4d:
>>> Nathan of Guardian wrote:
>>>
>>>
>>>> On Wed, Feb 11, 2015, at 02:53 PM, Hans-Christoph Steiner 
>>>> wrote:
>>>>> new blog post: 
>>>>> https://guardianproject.info/2015/02/11/complete-reproducible-app-distribution-achieved/
>>>>> With F-Droid, we have been working towards getting a complete app
>>>>> distribution channel that is able to reproducibly build each 
>>>>> Android app from source.
>>>
>>>> This is really fantastic. I can't wait to get Orbot moved 
>>>> over.
>>>
>>> +1
>>>
>>> I am interested in doing this for I2P Android and Bote, neither 
>>> of which require the NDK to build. If you want another 
>>> vict^H^H^H^Hperson to test the reproducible build process, let
>>> me know.
>>>
>>> str4d
> 
>> Excellent!  If these apps are already in FDroid, then switching to 
>> this build process should be trivial.  Just post the APK releases 
>> on a publicly available website,
> 
> We recently started operating our own F-Droid repository [0] to enable
> F-Droid users to use APKs with our signature that would be
> interoperable with our other distribution mechanisms (Google Play and
> direct website download), so we will probably use this as the binary
> source for the main F-Droid repo.

Yes, this makes sense since the APKs are already there.  The tricky part is
how to handle the reproducibility long term.  For example, with fdroid repos,
older APKs are usually automatically rotated out of the main repo and put into
the archive repo.  That would break the link to the APK given in `Binaries:`.
 I think we'll have to move towards actually including the APK signature files
in the build recipe so that people can reproduce builds even if the `Binaries`
link is broken.

>> then add a `Binaries:` tag to the fdroid build recipe.  The build 
>> recipes for f-droid.org are all here:
> 
>> https://gitlab.com/fdroid/fdroiddata
> 
>> The tricky part there is that the signing key of the APK will then 
>> change from the FDroid key to yours.  For any app that saves
>> state, like message history, etc. the only way to switch to an APK
>> with a new key means deleting all the saved state.
> 
> I2P Android is already in mainline F-Droid (although it has missed
> several updates because we switched to Gradle and our maintainer is
> MIA). I will think about whether we want to make this change or not.
> It's not a huge issue if we do, as there are only a few places where
> saved state might be an issue (which I expect are only used by
> advanced users).

We are planning on switching as many as our apps in the f-droid.org as
possible to use this process and ultimately only our signing key.  For apps
like Orbot and Orweb, where there is very little saved state, that shouldn't
be too hard.  We just need to figure out a good process to walk users through
upgrading to the new signing key without opening them up to malware using the
same process.  Ideas, patches, testing all needed here.

>> If these apps are not already in f-droid.org, then the key
>> question does not matter, but it means you'll have to create a
>> build recipe and submit a merge request on gitlab.  Here's the
>> manual:
> 
>> https://f-droid.org/manual/fdroid.html
> 
> I had decided to hold off adding Bote to the main F-Droid repository;
> I am glad that I did :) (it *would* have state issues)
> 
> 
>> The people on irc://irc.freenode.net/fdroid are also very helpful 
>> (sometimes that even includes me ;).
> 
> I will probably be in there at some point trying to get fdroidserver
> working with Gradle and our esoteric dependency structure :-P

There are lots of apps in f-droid.org that are built using gradle.  That
shouldn't be too hard.  Try asking mvdan or krt in #fdroid about it.

.hc

> 
> str4d
> 
> [0] https://geti2p.net/en/blog/post/2014/12/01/Android-app-releases

> 
>> .hc
> 
>>>>> while this may sound like a mundane detail, it does provide 
>>>>> lots of tangible benefits. First, it means that anyone can 
>>>>> verify that the app that they are using is 100% built from 
>>>>> the source code, with nothing else added. That verifies that 
>>>>> the app is indeed 100% free, open source software.
>>>>>
>>>>> It also verifies that there have not been any malicious bits 
>>>>> of code added into the app during the build process. As has 
>>>>> been demonstrated in the 31c3 Reproducible Builds talk, just 
>>>>> flipping a single bit is enough to create a usable exploit
>>>>> in an app.
>>>>>
>>>>> The F-Droid project is leading the way with its system for 
>>>>> publishing verified builds. We know have our first full 
>>>>> example, building upon our previous work with making Lil’ 
>>>>> Debi build reproducibly. We started with our simple little 
>>>>> utility app Checkey since it has few moving parts (first get 
>>>>> one working, then the rest).
>>>>>
>>>>> When you download Checkey from f-droid.org, you will get an 
>>>>> APK that was signed using the official Guardian Project 
>>>>> offline signing key that was built by f-droid.org. No, we
>>>>> did not give them a copy of our key, instead, the fdroid
>>>>> publish process now looks for the Binaries: tag in the build
>>>>> recipe. If it sees that, it downloads that APK, then builds
>>>>> the app from source, then checks to make sure that they match
>>>>> using a simple diff of the APK contents and by checking that
>>>>> the signature on the official APK also validates on the APK
>>>>> that f-droid.org built.
>>>>>
>>>>> Now that we have our little Checkey working, we can work 
>>>>> towards getting all of our apps verifying in the same way, 
>>>>> eliminating a whole field of exploits that we have to worry 
>>>>> about. You can follow the progress of this work on the 
>>>>> F-Droid wiki Reproducible Builds page, and learn about a 
>>>>> future application of it on the Verification Server page.
>>>>>
>>>>> The next two apps that are in the reproducible pipeline are 
>>>>> LEAP‘s Bitmask and our LocationPrivacy.
>>>>>
>>>>> .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F 
>>>>> E587 374B BE81 
>>>>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>>>
>>>>>
> _______________________________________________
>>>>> List info: 
>>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To 
>>>>> unsubscribe, email: 
>>>>> guardian-dev-unsubscribe at lists.mayfirst.org
>>>
>>>
>>> _______________________________________________ List info: 
>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To 
>>> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>>>
> 
> 
> 
>> _______________________________________________ List info: 
>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To 
>> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150216/4b37286e/attachment.sig>