| Age | Commit message (Collapse) | Author |
|---|
|
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
|
