For androguard, @thezero already developed a way to get all the icons after
only extracting the icon name. So this uses that for the aapt-based scans
also, to make them less brittle.
This should fix the problem where `fdroid update` was choosing the XML icon
for apps that include one, like NewPipe.
closesfdroid/fdroid-website#192
In order to test that aapt defaults minSdkVersion to 3, I ran this script
then compared the output with meld:
cd $ANDROID_HOME/build-tools
for d in *.*; do echo $d; $ANDROID_HOME/build-tools/$d/aapt dump badging /home/hans/code/fdroid/server/tests/repo/com.politedroid_3.apk > /tmp/${d}.txt; done
meld /tmp/17.0.0.txt /tmp/26.0.2.txt /tmp/27.0.3.txt
Apps can now use an XML icon, but if the app supports older Android
versions, it'll also contain PNG versions of the same icon. This finds
those PNGs and uses them instead.
#344closes#392
fdroiddata#913
This strips metadata and optimizes the compression of all PNGs copied
from the app's source repo as well as all the icons extracted from the
APKs. There have been exploits delivered via image metadata, and
F-Droid isn't using it all, so its best to just remove it.
This unfortunately uncompresses and recompresses the files. Luckily,
that's a lossless procedure with PNGs, and we might end up with
smaller files. The only tool I could find that strips without
changing the image data is exiftool, but that is written in Perl.
EXIF data can be abused to exploit systems a lot easier than the JPEG image
data can. The F-Droid ecosystem does not use the EXIF data, so keep things
safe and strip it all away. There is a chance that some images might rely
on the rotation to be set by EXIF, but I think having a safe system is more
important.
If needed, only the rotation data could be saved. But that then makes it
hard to tell which images have been stripped. This way, if there is no
EXIF, it has been stripped. And if there is EXIF data, then it is suspect.
https://securityaffairs.co/wordpress/51043/mobile-2/android-cve-2016-3862-flaw.htmlhttps://threatpost.com/google-shuts-down-potentially-massive-android-bug/120393/https://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html
The big downside of this is that it decompresses and recompresses the
image data. That should be replaced by a technique from jhead,
exiftool, ObscuraCam, etc. that only strips the metadata.
This fixes all the bugs I could find that prevented fdroid from
handling files with spaces in them. This is more important now that
fdroid supports random media files, and Repomaker
This allows all the text to be localized via Weblate. This is a quick
overview of all the strings, but there are certainly some that were left
out.
closes#342
There is a hardcoded template in update.py, and there is also the
possibility for the user to create a template.yml. This tests both of them
and cleans up the related code a bit.
#352!310
Hans-Christoph Steiner