bobheadxi
commented
7 years ago Why build on that commit? It is several commits behind, have you tried building 6996d5e?
Closed mimi89999 closed 7 years ago
bobheadxi
commented
7 years ago Why build on that commit? It is several commits behind, have you tried building 6996d5e?
mimi89999
commented
7 years ago It is what is tagged as v0.7.0 and for F-Droid we are building on tags...
bobheadxi
commented
7 years ago Oh my bad, I misunderstood - might have to wait for a comment from @d4rken
d4rken
commented
7 years ago We are building against glide:4.0.0-SNAPSHOT, something likely changed in the library.
Someone either has to to hardcode an older snapshot in the gradle file, or fix the issue.
mimi89999
commented
7 years ago @bobheadxi Can you make a new release and add a new tag or move the existing one to that commit?
bobheadxi
commented
7 years ago Best if @d4rken does it when he has time, not sure what the process is, might be better if release as v0.7.1?
d4rken
commented
7 years ago Only the last step is something I need to do because I have the signing key used for the previous github versions, for F-Droid that's not necessary though.
bobheadxi
commented
7 years ago d4rken
commented
7 years ago Thinking about it, it might have been better to first merge then tag as the appstore app uses the tags to determine whether an update is available. That way we don't signal a new update before noticing an issue with the final build (i.e. travis is still testing the PR atm).
Hm actually we can do the tag, just not create a release for it on github, because that's what the app checks, right? Not sure what the app does when there is a new release, but no .apk attached yet...
Anyways, for F-Droid it should suffice.
bobheadxi
commented
7 years ago I believe the app waits for a release, and since v0.7.0 is still the "Latest Release" the tag in its current state shouldn't do anything
Without an apk attached, the app might just attempt to download the source code - should probably add a check to the app to check for that before indicating a release
I've put up a draft with an apk build attached, will that do or does it have to be done by you? Also unsure if I'm the only one who can see my drafts
d4rken
commented
7 years ago I believe the app waits for a release, and since v0.7.0 is still the "Latest Release" the tag in its current state shouldn't do anything
Yeah I think that's the way it's implemented, at least I hope so 😁 .
Without an apk attached, the app might just attempt to download the source code - should probably add a check to the app to check for that before indicating a release.
Yeah though the draft approach seems sufficient.
I've put up a draft with an apk build attached, will that do or does it have to be done by you? Also unsure if I'm the only one who can see my drafts.
Everyone can see the drafts, but the attached APK won't work because it's not signed with the same signature key as the version everyone has installed, so they can't update it. They will get an error. To install it the previous version has to be uninstalled. That's Androids security mechanism so to prevent malicious updates. It guarantees that the APK someone installs is generated from a trusted source, i.e. the same source that build the previous version (or at least had access to the same key). Unless you created your own signing key the current apk is signed with a debug key, but in either case users won't be able to update with it.
I'll build an APK later and attach it to your draft.
d4rken
commented
7 years ago F-Droid has it's own signing key which is why our APKs are not compatible with APKs build by F-Droid. Compatible meaning they can't update over each other.
bobheadxi
commented
7 years ago Ah I see
I'll build an APK later and attach it to your draft.
Thanks!
F-Droid has it's own signing key which is why our APKs are not compatible with APKs build by F-Droid. Compatible meaning they can't update over each other.
Does this mean when people using the FDroid build attempt to download an update via the "Update Available" dialogue built into the app they will run into problems?
d4rken
commented
7 years ago Does this mean when people using the FDroid build attempt to download an update via the "Update Available" dialogue built into the app they will run into problems?
Yes, the Android installer will throw an error during the update attempt. If someone wants to do a PR 😉 : This can be solved by comparing the signature of the apk that is installed (which can be accessed through the packagemanager) and comparing it with the signature of the github build apks (which doesn't change and could be hardcoded). If it doesn't match, don't show an update dialog or show some other kind of information.
bobheadxi
commented
7 years ago Seems fairly important usability wise, opened up an issue (#109) for it and will get around to it :) thanks!
d4rken
commented
7 years ago Yeah could be quite annoying, though I would guess that regular F-Droid users are fairly familiar with the issue as it also affects apps that are available from GPlay+FDroid.
bobheadxi
commented
7 years ago @d4rken How exactly does this work?
the signature of the github build apks (which doesn't change and could be hardcoded)
d4rken
commented
7 years ago By using something like
getPackageManager().getPackageInfo(pkgname, PackageManager.GET_SIGNATURES).signaturesYou could detect whether the apk is from github or froid by checking it for a specific signature.
The apk from github will have my signature (from the certificate file on my hdd), while the apk from fdroid will have their signature.
d4rken
commented
7 years ago @bobheadxi
keytool -list -v -keystore keystore_rAndroidAppStore.jksReturns
Creation date: 03.09.2016
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: OU=App Store, O=/r/Android
Issuer: OU=App Store, O=/r/Android
Serial number: 7e74e0e6
Valid from: Sat Sep 03 23:10:18 CEST 2016 until: Thu Jan 05 22:10:18 CET 3015
Certificate fingerprints:
MD5: 36:54:AD:AB:ED:1F:24:58:9E:9D:27:23:D3:1A:B4:AC
SHA1: FC:4E:25:23:E3:50:9B:A5:6E:6A:FD:C3:60:04:95:8E:2E:94:EA:B2
SHA256: 6F:95:6E:1A:9E:89:EA:8F:9B:E4:44:B3:EB:31:DA:9C:7B:4C:C6:34:A1:E1:18:90:15:A7:16:A0:90:A9:77:4C
Signature algorithm name: SHA256withRSA
Version: 3So our SHA1 certificate fingerprint is
FC4E2523E3509BA56E6AFDC36004958E2E94EAB2
This code reads the fingerprint for an any installed package and also returns the SHA finger print:
public static List<String> getSignatures(Context context, String packageName) {
List<String> foundSignatures = new ArrayList<>();
try {
final Signature[] signatures = context.getPackageManager().getPackageInfo(packageName, PackageManager.GET_SIGNATURES).signatures;
for (final Signature sig : signatures) {
final byte[] rawCert = sig.toByteArray();
InputStream certStream = new ByteArrayInputStream(rawCert);
CertificateFactory certFactory = CertificateFactory.getInstance("X509");
X509Certificate x509Cert = (X509Certificate) certFactory.generateCertificate(certStream);
MessageDigest md = MessageDigest.getInstance("SHA1");
byte[] publicKey = md.digest(x509Cert.getEncoded());
foundSignatures.add(bytesToHex(publicKey).toUpperCase());
}
} catch (Exception e) { e.printStackTrace(); }
return foundSignatures;
}
public static String bytesToHex(byte[] in) {
final StringBuilder out = new StringBuilder();
for (byte b : in) out.append(String.format("%02x", b));
return out.toString();
}For the release apk of this app it would return a list with a single entry, namely the above SHA1 fingerprint.
For the F-Droid APK it would be a different fingerprint.
Building on commit c70a58d24af5ddb3a430376bf483f314b08a6590