BobStore/project.properties

proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

target=android-19

android.library.reference.1=extern/UniversalImageLoader/library
android.library.reference.2=extern/MemorizingTrustManager
android.library.reference.3=extern/AndroidPinning
Add proguard to project.properties 2013-08-07 11:57:00 +02:00			`proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt`

Bump project target to android-19 2013-11-10 18:44:26 +01:00			`target=android-19`
Add project.properties (closes #323) 2013-08-06 16:26:08 +02:00
Whoops, forgot to also change the ant setup 2014-02-15 11:18:58 +01:00			`android.library.reference.1=extern/UniversalImageLoader/library`
Adding support for SPKI pins, trust-on-first-use of TLS certs. In order to support F-droid repositories hosted with HTTPS using a self-signed certificate the f-droid client should prompt the user to trust or 'memorize' the certificate presented by a repository. The MemorizingTrustManager[0] project enables easy integration of a prompting activity and corresponding trust manager implementation. This behaviour is useful to projects such as Kerplapp[1] that boostrap an F-droid repository on a user's device where it isn't possible to acquire a long lived CA vetted TLS certificate. In addition to Trust-on-First-Use (TOFU) behaviour, this patch integrates the PinningTrustManager [2] project by Moxie Marlinspike to allow the FDroid client to ship a hardcoded set of Subject Public Key Identifier pins [3] for the official FDroid repository TLS certificate, and the Guardian Project TLS certificate. Additional pins can be added to the FDroidPins.java class. The upstream release of AndroidPinning by moxie0 uses a minsdk value of 8. The Fdroid client has a minsdk of 5, presenting compatibility issues using the AndroidPinning lib as a submodule. Fortunately it seems there is no technical reason preventing using a minSDK of 5 with AndroidPinning. I have created a fork with this change and submitted a pull req upstream. Until this pull is merged we can use my fork of AndroidPinning as the submodule. The new 'flow' for deciding if a repositories presented TLS certificate should be trusted is as follows: 1) If the certificate was previously trusted by a TOFU action, then the certificate is accepted as trusted 2) If the certificate wasn't previously trusted by a TOFU action but there is a matching SPKI pin then the certificate is accepted as trusted 3) If the certificate wasn't previously trusted by a TOFU action and there is no SPKI pin but the certificate is signed by a trusted Certificate Authority it is accepted as trusted (This is the behaviour of the FDroid client prior to this patch with all other conditions being a hard-fail). 4) If the certificate wasn't previously trusted by a TOFU action and there is no SPKI pin and the certificate is not signed by a trusted CA (i.e. self signed or otherwise) then the user is prompted to TOFU the certificate. The user may choose to trust the certificate for the current connection or forever. If the user chooses an option other than "deny" the certificate is accepted as trusted for the specified duration. Users currently using a TLS protected repository will see no difference in user experience after this patch is merged as the only TLS protected repositories that would function prior to this patch were providing certificates that match condition #3. [0] https://github.com/ge0rg/MemorizingTrustManager/wiki/Integration [1] https://github.com/guardianproject/kerplapp [2] https://github.com/moxie0/AndroidPinning [3] https://www.imperialviolet.org/2011/05/04/pinning.html 2013-12-11 11:46:08 -05:00			`android.library.reference.2=extern/MemorizingTrustManager`
			`android.library.reference.3=extern/AndroidPinning`