migrate to secure keystore alias scheme
It has been known since the very first audit that a malicious applicationId/packageName could theoretically be generated which would trigger an app to be signed by the key of another app.
A package could be crafted, such that it would use the same signing key as an existing app. While it may be theoretically possible for such a colliding package ID to be generated, it seems virtually impossible that the colliding ID would be something that would be a) a valid package ID, and b) a sane-looking ID that would make its way into the repo. Nonetheless, to be sure, before publishing we check that there are no collisions, and refuse to do any publishing if that's the case...
A check was added then to prevent key alias collisions. The latest audit also again proposed this as a problem, albeit as a DoS:
4.1.12 OTF-012 — Key Alias Collisions Can Lead to DoS of Publishing in Fdroidserver
Description: By submitting an app to fdroid with a crafted appid it is possible to deny the publishing of new apps to fdroid.
Technical description: The function key_alias() calculates the key_alias from the appid by hashing it with MD5 and taking the first 8 digits of the hex representation of this hash: md5.hexlify()[:8] . This is 32bits, but due to the birthday paradox collisions are reasonably cheap to calculate. In the main() function there is a check for collisions of key aliases, if there is any, the publish script aborts. There is a comment refering to a previous audit stating that chances are neglible of encountering a collision. We produced two PoC scripts, both use as input an english wordlist (taken from debian /usr/share/dict/words) removing all lines that end in "'s", resulting in a list with 73333 english words. In PoC-1 (collidemd5-4.py) we generate random english words into appids as long as there is no collision. After approximately 9000 samples we find that it takes about 113.930 random appids until there is a collision. In PoC-2 we adjust our sampling by taking into account that there are currently about 1500 apps in fdroid, and we try to create a collision with one of these 1500 items. After 1355 samples it takes an average 2.925.625 attempts to collide with one of the 1500 target hashes. This shows it is feasible to create a collision and create a DoS against the publishing process. Notable also is that the key_alias() function does allow for overriding the key alias, but the check in the main() function does not take that into account.
Recommendation: Either use longer ids, or don't make the ids depending on user input.