| Age | Commit message (Collapse) | Author |
|---|
|
The exploit for CVE-2019-3462 uses the fact that a Release.gpg file can
contain additional content beside the expected detached signature(s).
We were passing the file unchecked to gpgv which ignores these extras
without complains, so we reuse the same line-reading implementation we
use for InRelease splitting to detect if a Release.gpg file contains
unexpected data and fail in this case given that we in the previous
commit we established that we fail in the similar InRelease case now.
|
|
Telling the acquire system which keys caused the gpgv method to
succeed allows us for now just a casual check if the gpgv method
really executed catching bugs like CVE-2018-0501, but we will make use
of the information for better features in the following commits.
|
|
Having a method take a bunch of string vectors is bad style, so we
change this to a wrapping struct and adapt the rest of the code brushing
it up slightly in the process, which results even in a slightly "better"
debug output, no practical change otherwise.
Gbp-Dch: Ignore
|
|
A user can specify multiple fingerprints for a while now, so its seems
counter-intuitive to support only one keyring, especially if this isn't
really checked or enforced and while unlikely mixtures of both should
work properly, too, instead of a kinda random behaviour.
|
|
If we limit a file to be signed by a certain key it should usually
accept also being signed by any of this keys subkeys instead of
requiring each subkey to be listed explicitly. If the later is really
wanted we support now also the same syntax as gpg does with appending an
exclamation mark at the end of the fingerprint to force no mapping.
|
|
gpgs DETAILS documentation file declares that GOODSIG could report keyid
or fingerprint since gpg2, but for the time being it is still keyid
only. Who knows if that will ever change as that feels like an interface
break with dangerous security implications, but lets be better safe than
sorry especially as the code dealing with signed-by keyids is prepared
for this already. This code is rewritten still to have them all use the
same code for this type of problem.
|
|
In gpgv1 GOODSIG (and the other messages of status-fd) are documented as
sending the long keyid. In gpgv2 it is documented to be either long
keyid or the fingerprint. At the moment it is still the long keyid, but
the documentation hints at the possibility of changing this.
We care about this for Signed-By support as we detect this way if the
right fingerprint has signed this file (or not). The check itself is
done via VALIDSIG which always is a fingerprint, but there must also be
a GOODSIG (as expired sigs are valid, too) found to be accepted which
wouldn't be found in the fingerprint-case and the signature hence
refused.
|
