In April 2017, Oracle's jarsigner and Google's apksigner both switched to
considering any APK signature that uses MD5 as unsigned. Any old build
is likely to have a MD5 signature. This sets up the archive as the only
place where these "disabled algorithms" are allowed in the repo, and
marks any APK signed by a "disabled algorithm" as having a "known
vulnerability"
This also now automatically moves APKs with invalid signatures to the
archive section.
#323
The original logic was checking keepversions against the len() of ALL the
APKs in the repo/archive. The correct thing is to check against the
number of APKs available for the given packageName/appid.
closes#166
This exploit is old, and was fixed in 4.4. But it was easy to exploit,
so it is still worth scanning for it. It is also easy to scan for, since
valid APKs should not have files with duplicate names. In theory, this
could look for duplicate file names for any file, but this limits the
false positives by only checking names of files related to executing code.
fdroidclient#40
`fdroid update` crashed for apps that only had screenshots but no graphics
or localized texts because destdir was not being set in that case. This
fixes that and adds a test case.
closes#320!286
Since the Summary: and Description: in the metadata file has the highest
priority of all the localized texts, adding blank versions means that
apps would always have blank Summary and Description even if the app has
those fields in the localized sections of fdroiddata and/or in the app's
source repo itself.
fdroiddata!2262
Since the Summary/Description can now be set in the app's source code, or
in fdroiddata/metadata/<packageName>/<locale>/*.txt, this lint check is
no longer valid. It is important to check whether these texts are empty,
but it'll require some thinking about how and where to best to that.
`fdroid update` will have access to all that data, but perhaps at that
point it is too late.
Also, the current text prioritization puts Summary/Description in the
.txt/.yml file at the highest priority, overriding every other copy,
including in fdroiddata/metadata/<packageName>/<locale> and in the app's
source code.
This will allow us to put these up on Weblate and have people start
translating them. Then we can figure out how to actually include and
deploy the translations later. It is unfortunately non-trivial, since
we have to manually figure out the install paths.
If working with a random grabbag of APKs, there can be all sorts of
issues like corrupt entries in the ZIP, bad signatures, signatures that
are invalid since they use MD5, etc. Moving these two checks later means
that the APKs can be renamed still.
This does change how common.getsig() works. For years, it returned
None if the signature check failed. Now that I've started working
with giant APK collections gathered from the wild, I can see that
`fdroid update` needs to be able to first index what's there, then
make decisions based on that information. So that means separating
the getsig() fingerprint fetching from the APK signature verification.
This is not hugely security sensitive, since the APKs still have to
get past the Android checks, e.g. update signature checks. Plus the
APK hash is already included in the signed index.
With a generic file, the file name is the only guaranteed name metadata
field. So if the name is not specified in the metadata, then the name
is set to the filename. This changes that so that the file extension is
stripped from that generated name.
This is useful for parsing APK files, which can include packageName,
versionCode, and optionally 7 char signing key ID (i.e. <sig>).
This also can set the packageName and versionCoe for non APK files, so
that it is easy to assign them to metadata files, and to allow for
upgrades by setting the versionCode in the filename.
Really, it is the fdroidclient parser of index.xml that fails, due to the
hardcoded expectation that there will only ever be a single APK for any
given versionCode. We keep index.xml backwards compatible for old
clients, and use index-v1.json to support new things. Having multiple
APKs that have the same packageName and versionCode will break the client
v0.103.* since that version uses index-v1.json, but still has the hard-
coded database parsing stuff.
#153
uses the standard package.name_123.apk. If that exists, it appends the
shasum. If that exists, then its a duplicate, so its deleted. This should
help @SergeWinters with his 12,000 APKs.
There are many APKs out in the wild that claim to be the same app and
version and each other, but they are signed by different keys. fdroid
should be able to index these, and work with them. This supports having
the developer's signature via reproducible builds, random collections of
APKs like repomaker, etc.
