.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 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.
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
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
Followup to fdroid/fdroidserver!779.
We need to add smartcardoptions to every call to keytool and jarsigner
as well as handle when keypass not being required and not allowed for
pkcs11 keystores.
import is a strict keyword in Python, so it is not possible to import a
module called 'import', even with things like:
* import fdroidserver.import
* from fdroidserver import import
