| Age | Commit message (Collapse) | Author |
|---|
|
No change in the logic itself, just dropping "== true", replacing "==
false" with not and moving lines around to make branches more obvious.
Suggested-By: Julian Andres Klode
Gbp-Dch: Ignore
|
|
We support dash-encoding even if we don't really work with files who
would need it as implementations are free to encode every line, but
otherwise a line starting with a dash must either be a header we parse
explicitly or the file is refused. This is against the RFC which says
clients should warn on such files, but given that we aren't expecting
any files with dash-started lines to begin with this looks a lot like a
we should not continue to touch the file as it smells like an attempt to
confuse different parsers by "hiding" headers in-between others.
The other slightly more reasonable explanation would be an armor header
key starting with a dash, but no existing key does that and it seems
unlikely that this could ever happen. Also, it is recommended that
clients warn about unknown keys, so new appearance is limited.
|
|
This is C++, so we can use a bit more abstraction to let the code
look a tiny bit nicer hopefully improving readability a bit.
Gbp-Dch: Ignore
|
|
RFC 4880 section 7.1 "Dash-Escaped Text" at the end defines that only
space and tab are allowed, so we should remove only these even if due to
use complaining (or now failing) you can't really make use of it.
Note that strrstrip was removing '\r\n\t ', not other whitespaces like
\v or \f and another big reason to do it explicitly here now is to avoid
that a future change adding those could have unintended consequences.
|
|
Having many rather similar implementations especially if one is exported
while others aren't (and the rest of it not factored out at all) seems
suboptimal.
|
|
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.
|
|
The warnings were introduced 2 years ago without any reports from the
wild about them actually appearing for anyone, so now seems to be an as
good time as any to switch them to errors.
This allows rewritting the code by failing earlier instead of trying to
keep going which makes the diff a bit hard to follow but should help
simplifying reasoning about it.
References: 6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3
|
|
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.
|
|
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
|
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.
Gbp-Dch: Ignore
Reported-By: spellintian
|
|
Nothing in user visible strings.
Gbp-Dch: Ignore
Reported-By: codespell
|
|
Clearsigned files like InRelease, .dsc, .changes and co can potentially
include unsigned or additional messages blocks ignored by gpg in
verification, but a potential source of trouble in our own parsing
attempts – and an unneeded risk as the usecases for the clearsigned
files we deal with do not reasonably include unsigned parts (like emails
or some such).
This commit changes the silent ignoring to warnings for now to get an
impression on how widespread unintended unsigned parts are, but
eventually we want to turn these into hard errors.
|
|
This is a follow up to the previous issue where we did not check
if getline() returned -1 due to an end of file or due to an error
like memory allocation, treating both as end of file.
Here we ensure that we also handle buffered writes correctly by
flushing the files before checking for any errors in our error
stack.
Buffered writes themselves were introduced in 1.1.9, but the
function was never called with a buffered file from inside
apt until commit 46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c
which was first released with apt 1.2.10. The function is
public, though, so fixing this is a good idea anyway.
Affected: >= 1.1.9
|
|
This fixes a security issue where signatures of the
InRelease files could be circumvented in a man-in-the-middle
attack, giving attackers the ability to serve any packages
they want to a system, in turn giving them root access.
It turns out that getline() may not only return EINVAL
as stated in the documentation - it might also return
in case of an error when allocating memory.
This fix not only adds a check that reading worked
correctly, it also implicitly checks that all writes
worked by reporting any other error that occurred inside
the loop and was logged by apt.
Affected: >= 0.9.8
Reported-By: Jann Horn <jannh@google.com>
Thanks: Jann Horn, Google Project Zero for reporting the issue
LP: #1647467
|
|
We report warnings from apt-key this way already since
29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like
a good addition. Most of those errors aren't really from apt-key
through, but from the code setting up and actually calling it which used
to just print to stderr which might or might not intermix them with
(other) progress lines in update calls. Having them as proper error
messages in the system means that the errors are actually collected
later on for the list instead of ending up with our relatively generic
but in those cases bogus hint regarding "is gpgv installed?".
The effective difference is minimal as the errors apply mostly to
systems which have far worse problems than a not as nice looking error
message, which makes this pretty hard to test – but at least now the
hint that your system is broken can be read in proper order (= there
aren't many valid cases in which the permissions of /tmp are messed up…).
LP: #1522988
|
|
This allows other vendors to use different paths, or to build
your own APT in /opt for testing. Note that this uses + 1 in
some places, as the paths we receive are absolute, but we need
to strip of the initial /.
|
|
Create a temporary configuration file with a dump of our
configuration and pass that to apt-key.
LP: #1607283
|
|
|
|
Create a local exiter object which cleans up files on exit.
|
|
Previously, when data could be created and sig not, we would unlink
sig, not data (and vice versa).
|
|
We usually use absolute paths to specific the location of dpkg, apt-key
and the like, but there is nothing wrong with using just the command
name and instead let exec(3) make the lookup in PATH.
We had a wild mixture before, so opting for the more accepting option
out of the two seems about right especially as it makes no difference in
the default case as apt uses absolute paths.
|
|
Hardly noticeable, but given that we have the option to easily enable
it, lets enable it as every newline in the message is written
individually by the code.
|
|
Limits which key(s) can be used to sign a repository. Not immensely useful
from a security perspective all by itself, but if the user has
additional measures in place to confine a repository (like pinning) an
attacker who gets the key for such a repository is limited to its
potential and can't use the key to sign its attacks for an other (maybe
less limited) repository… (yes, this is as weak as it sounds, but having
the capability might come in handy for implementing other stuff later).
|
|
Various small leaks here and there. Nothing particularily big, but still
good to fix. Found by the sanitizers while running our testcases.
Reported-By: gcc -fsanitize
Git-Dch: Ignore
|
|
gnupg/gnupg2 can do verify just fine of course, so we don't need to use
gpgv here, but it is what we always used in the past, so there might be
scripts expecting a certain output and more importantly the output of
apt-cdrom contains messages from gpg and even with all the settings we
activate to prevent it, it still shows (in some versions) a quiet scary:
"gpg: WARNING: Using untrusted key!" message. Keeping the use of gpgv is
the simplest way to prevent it.
We are increasing also the "Breaks: apt" version from libapt as it
requires a newer apt-key than might be installed in partial upgrades.
|
|
Some advanced commands can be executed without the keyring being
modified like --verify, so this adds an option to disable the mergeback
and uses it for our gpg calling code.
Git-Dch: Ignore
|
|
apt-key does the keyring merge as we need it, so we just call it instead
of reimplementing it to do the merging before gpgv. This means we don't
use gpgv anymore (we never depended on it explicitly - bad style), but
it also means that the message in apt-cdrom add is a bit less friendly
as it says loudly "untrusted key", but for a one-time command its okay.
|
|
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
|
|
The most "visible" change is from utime to utimensat/futimens
as the first one isn't part of POSIX anymore.
Reported-By: cppcheck
Git-Dch: Ignore
|
|
No visible functional changes, just code moved around and additional
checks to eliminate impossible branches
Reported-By: scan-build
Git-Dch: Ignore
|
|
|
|
if the directory given by $TMPDIR is not available, use /tmp as fallback.
|
|
With the selfgrown splitting we got the problem of not recovering
from networks which just reply with invalid data like those sending
us login pages to authenticate with the network (e.g. hotels) back.
The good thing about the InRelease file is that we know that it must
be clearsigned (a Release file might or might not have a detached sig)
so if we get a file but are unable to split it something is seriously
wrong, so there is not much point in trying further.
The Acquire system already looks out for a NODATA error from gpgv,
so this adds a new error message sent to the acquire system in case
the splitting we do now ourselves failed including this magic word.
Closes: #712486
|
|
|
|
free to escape all lines (we have no lines in our files which need
to be escaped as these would be invalid fieldnames) and while ExecGPGV
would detect dash-escaped text as invalid (as its not expected in
messages with detached signatures) it would be possible to "comment"
lines in (signed) dsc files which are only parsed but not verified
|
|
|
|
apt-pkg/deb/deblistparser.cc:
- use OpenMaybeClearSignedFile to be free from detecting and
skipping clearsigning metadata in dsc and Release files
We can't write a "clean" file to disk as not all acquire methods copy
Release files before checking them (e.g. cdrom), so this reverts recombining,
but uses the method we use for dsc files also in the two places we
deal with Release files
|
|
* ftparchive/writer.cc:
- use OpenMaybeClearSignedFile to be free from detecting and
skipping clearsigning metadata in dsc files
|
|
|
|
into data and signatures, pass it to gpgv for verification and
recombines it after that in a known-good way without unsigned blocks
and whitespaces resulting usually in more or less the same file as
before, but later code can be sure about the format
* apt-pkg/deb/debmetaindex.cc:
- reenable InRelease by default
|
|
|
|
- ExecGPGV is a method which should never return, so mark it as such
and fix the inconsistency of returning in error cases
|
|
- rename RunGPGV to ExecGPGV and move it to apt-pkg/contrib/gpgv.cc
|
