Python PIL is not so tolerant, so bad EXIF causes crashes:
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 2088, in main
insert_localized_app_metadata(apps)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 978, in insert_localized_app_metadata
_strip_and_copy_image(os.path.join(root, f), destdir)
File "/var/lib/jenkins/userContent/reproducible/reproducible_fdroid_build_apps/fdroidserver/update.py", line 754, in _strip_and_copy_image
in_image = Image.open(fp)
File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2687, in open
% (filename if filename else fp))
OSError: cannot identify image file <_io.BufferedReader name='build/org.sw24softwares.starkeverben/fastlane/metadata/android/en-US/images/featureGraphic.png'>
Using a filename based on the hash of the contents means that the caching
algorithms for fdroidclient and browsers can safely cache the file forever
using the filename, since this guarantees that the contents will never
change for a given filename.
This does not cover screenshots, only icon.png, featureGraphic.png,
tvBanner.png, and promoGraphic.png.
fdroidserver#689
fdroid-website!453
Ignoreversions were checked also if version did not match which raised the exception
The 'version check' runs in some unexpected situations like just
to find directories where to find the AutoName.
Match only whole words when looking for versionCode, versionName, etc. in
manifests. A real build.gradle example:
flutterVersionCode = '1'
flutterVersionName = '1.0'
...
defaultConfig {
versionCode 53
versionName "2.0.3"
}
Before this change checkupdates was erroneously getting version code and
version name from the first two lines and failing to find a new release.
git mirrors are meant to be an easy way to host a repo that is zero
maintenance. They are not meant to be the canonical repo with full,
preserved archive. This option provides the zero maintenance mode.
It is now possible to build an app using only things in Debian. Since the
buildserver will always control the contents of file:///usr/share/maven-repo,
it is the most safe repo there is.
When downloading a repo index, the downloaded index got written to a
file with `.write()` in a `with` clause. Before the file got actually
written to the disk, it got already passed into the next function,
resulting in a `VerificationException`:
```
JAR signature failed to verify: /tmp/tmppq2r51r0
jarsigner: java.util.zip.ZipException: zip file is empty
```
This behavior got introduced in
869cc114a3.
I've found this bug with help of Repomaker's tests: https://gitlab.com/fdroid/repomaker/merge_requests/215#note_148994053
Otherwise, this was posting mystery JSON parsing errors because it was
trying to parse the HTTP error page as JSON. This also moves the
virustotal API key to post data so it is not printed out in the stacktrace.
