Generating a keystore is quite slow since it means a new RSA key is created.
That only needs to happen in the tests that check that it actually happened,
otherwise the test can just reuse the stored test keystore.
closes#432
Fixes bb758d3f, spotted by @bubu:
DEBUG: buildserver > DEBUG: > sudo apt-get -y purge sudo
DEBUG: buildserver > Reading package lists...
DEBUG: buildserver > Building dependency tree...
DEBUG: buildserver > Reading state information...
DEBUG: buildserver > The following packages will be REMOVED:
DEBUG: buildserver > sudo*
DEBUG: buildserver > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
DEBUG: buildserver > After this operation, 2,391 kB disk space will be freed.
(Reading database ... 68491 files and directories currently installed.)
DEBUG: buildserver > Removing sudo (1.8.10p3-1+deb8u4) ...
DEBUG: buildserver > You have asked that the sudo package be removed,
DEBUG: buildserver > but no root password has been set.
DEBUG: buildserver > Without sudo, you may not be able to gain administrative privileges.
DEBUG: buildserver >
DEBUG: buildserver > If you would prefer to access the root account with su(1)
DEBUG: buildserver > or by logging in directly,
DEBUG: buildserver > you must set a root password with "sudo passwd".
DEBUG: buildserver >
DEBUG: buildserver > If you have arranged other means to access the root account,
DEBUG: buildserver > and you are sure this is what you want,
DEBUG: buildserver > you may bypass this check by setting an environment variable
DEBUG: buildserver > (export SUDO_FORCE_REMOVE=yes).
DEBUG: buildserver >
DEBUG: buildserver > Refusing to remove sudo.
DEBUG: buildserver > dpkg: error processing package sudo (--purge):
DEBUG: buildserver > subprocess installed pre-removal script returned error exit status 1
DEBUG: buildserver > Errors were encountered while processing:
DEBUG: buildserver > sudo
DEBUG: buildserver > E: Sub-process /usr/bin/dpkg returned an error code (1)
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.
If I manually run some steps of the process, not all of the normal cruft
might be left behind. I'm not really sure which of the multiple copies of
the images are actually required, but these both seem to work when present.
Once `sudo` has been used to execute the commands in sudo=, then it should
be removed from the build VM. That prevents any other part of the build
from using sudo. That means that all commands run with `sudo` must be
committed to fdroiddata.git, making them very visible.
closes#424
