Fixes the following crash:
```
$ fdroid update --create-metadata --rename-apks
WARNING: Using Java's jarsigner, not recommended for verifying APKs! Use apksigner
CRITICAL: Unknown exception found!
Traceback (most recent call last):
File "/home/jonas/miniconda3/bin/fdroid", line 164, in <module>
main()
File "/home/jonas/miniconda3/bin/fdroid", line 138, in main
mod.main()
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1927, in main
apks, cachechanged = process_apks(apkcache, repodirs[0], knownapks, options.use_date_from_apk)
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1454, in process_apks
use_date_from_apk, ada, True)
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1327, in process_apk
apk = scan_apk(apkfile)
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1056, in scan_apk
scan_apk_aapt(apk, apk_file)
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1184, in scan_apk_aapt
apk['icons_src'] = _get_apk_icons_src(apkfile, icon_name)
File "/home/jonas/miniconda/lib/python3.6/site-packages/fdroidserver/update.py", line 1089, in _get_apk_icons_src
density_re = re.compile('^res/(.*)/' + icon_name + '\.(png|xml)$')
TypeError: must be str, not NoneType
```
aapt --rename-manifest-package changes the applicationId for an app without
changing the packageName listed in AndroidManifest.xml under
<application android:package="">
repo/ch.swift.willi_417101.apk had a C/Java comment in the
AndroidManifest.xml rather than an XML comment:
<uses-sdk android:minSdkVersion="16" android:targetSdkVersion="26">
</uses-sdk>
// Remove permissions introduced by the appsflyer library
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION">
</uses-permission>
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.
