.idsig files contain an apksig v4 (https://source.android.com/security/apksigning/v4)
new versions of apksigner make this signature by default and it ends up
in /repo. Without this patch it would be included into the index as a
file to be downloaded by users. F-Droid Client crashes when it
encounters such an apk entry.
It's fine to have these signature files in the repo though, maybe
fdroidclient can make use of them at some point in the future (they are
intended to support streaming app installations).
This makes it possible to use process_apks(), get_cache(), and anything
calling disabled_algorithms_allowed() as an API without having to set
options up beforehand.
This broke in 74af61f255.
Keytool has still a different opinion from both apksigner and jarsigner
about the providerName argument. apksigner doesn't support it at all,
jarsigner ignores it but keytool fails without it. :-/
So we add it back to the default argument list but filter it out before
calling apksigner.
The `force_build_tools` config option was added a long time ago to
brute force the _build-tools_ version by trying to replace the value
in `build.gradle` files. This is never something that should be used
in production, since the app's build metadata should specify this kind
of thing. And now that we're moving towards _androguard_ for
everything except fdroid build and fdroid publish, _build-tools_ will
no longer even be used in the other commands.
latestapps.dat was being used for the old-website, it's not used anymore
Fixes the following crash in production:
```
2020-09-13 19:26:59,000 CRITICAL: Unknown exception found!
Traceback (most recent call last):
File "/home/fbuild/fdroidserver/fdroid", line 22, in <module>
fdroidserver.__main__.main()
File "/home/fbuild/fdroidserver/fdroidserver/__main__.py", line 230,
in main
raise e
File "/home/fbuild/fdroidserver/fdroidserver/__main__.py", line 211,
in main
mod.main()
File "/home/fbuild/fdroidserver/fdroidserver/update.py", line 2451, in
main
app = apps[appid]
KeyError: '45b464b398a7d9fac5a186bd3d3d8dc1e6a25f7f9cd48c7462619b1e5fba87c2'
```
apksigner documents the options as --ks-provider-class and --ks-provider-arg
those seem to be accepted but fail when actually making a signature with
weird internal exceptions. The new options actually work.
From: https://geoffreymetais.github.io/code/key-signing/#scripting
This makes apksigner a hard requirement of the signing procedure.
We'll first try to find a globally installed version from PATH and if
that's not available fall back to using a version from build-tools.
Future TODO: always sign with apksigner, blocked on signature transplant
support for apksigv2/v3
Closesfdroid/fdroidserver#634Closesfdroid/fdroidserver#827
This was accidentally changed in !756 because the functionality was
hidden in `apply_info_from_latest_apk` which is a less than stellar name
for something that also applies infos from app->apk and in this case did
apply info from *oldest* apk->app.
So instead move that into a separate step.
Note: This restores the previous behaviour. There's discussion in #801
on further changes to make the added date also work for repos which
don't keep an archive at all.
There's valid use-cases for setups where set-head --auto fails. This
happens when building an app from a gitlab CI checkout where no remote
tracking branches are setup.
This isn't really a fatal error. When a remote HEAD exists we'll
continue setting it and if none exists and something requires this being
set up later on (either a build script or fdroid checkupdates) then
we'll fail later on with "origin/HEAD not being known to git".
By not failing early we allow the majority of use-cases that don't need
a remote HEAD to continue with just a warning.
The setup in which this can be reproduced is as follows:
(This is roughly what gitlab runner does when setting up a git checkout
for CI)
- mkdir test && cd test
- git init
- git remote add https://gitlab.com/Bubu/fdroidclassic.git
- git fetch --all
- git checkout db0d2a9a5d1d89101a344169013ac5d518185f31
- mkdir nested_repo && cd nested_repo
- git clone .. .
- git remote set-head origin --auto
> error: Cannot determine remote HEAD
A file can be flagged for multiple problems (i.e. multiple unknown maven
repos in one build.gradle file that is included in a scandelete path).
The scanner will try to delete it once for every problem detected, we
don't really care, as long as the file is gone.
fixesfdroid/fdroidserver#759
publish is currently not reusable from other modules as everything is
happening in main. It's also not testable from python unittests.
There's already a function for getting the key_alias, so we can use
that.
Introduce tests for the split out functions.
* newKeyAliases wasn't providing any useful information
* generatedKeys now contains the used keyalias as well
* signedApks now also records the used keyalias for each apk
