On travis-ci connect.cc detects a rotation, triggering it store the IP
which is later appended to the error message, which is all nice and
great if we deal with a real server, but in the testcases it just
triggers failures as strings do not match.
Changing user and co works only as root, but can do some things for
methods run as normal user as well to protect them from being able to
call setuid binaries like sudo to elevate their privileges.
Also uses a cheap trick now to build with old unsupporting kernels.
Some distributions (or repositories) do not have as much
"Ign-discipline" as I would like to, so that could be pretty distracting
for our users if enabled by default. It is handy for testcases though.
Michael Vogt [Tue, 7 Oct 2014 11:34:28 +0000 (13:34 +0200)]
Ignore EINVAL from prctl(PR_SET_NO_NEW_PRIVS)
Ignore a EINVAL error here as it means that the kernel is too old
to understand this option. We should not fail hard in this case
but just ignore the error.
consistently using Item::Failed in all specializec classes helps setting
up some information bits otherwise unset, so some errors had an empty
reason as an error. Ign is upgraded to display the error message we
ignored to further help in understanding what happens.
Using a different user for calling methods is intended to protect us
from methods running amok (via remotely exploited bugs) by limiting what
can be done by them. By using root:root for the final directories and
just have the files in partial writeable by the methods we enhance this
in sofar as a method can't modify already verified data in its parent
directory anymore.
As a side effect, this also clears most of the problems you could have
if the final directories are shared without user-sharing or if these
directories disappear as they are now again root owned and only the
partial directories contain _apt owned files (usually none if apt isn't
running) and the directory itself is autocreated with the right
permissions.
ensure partial dirs are 0700 and owned by _apt:root
Reworks the API involved in creating and setting up the fetcher to be a
bit more pleasent to look at and work with as e.g. an empty string for
no lock isn't very nice. With the lock we can also stop creating all our
partial directories "just in case". This way we can also be a bit more
aggressive with the partial directory itself as with a lock, we know we
will gone need it.
Guillem Jover [Thu, 2 Oct 2014 15:48:13 +0000 (17:48 +0200)]
apt-get: Create the temporary downloaded changelog inside tmpdir
The code is creating a secure temporary directory, but then creates
the changelog alongside the tmpdir in the same base directory. This
defeats the secure tmpdir creation, making the filename predictable.
Inject a '/' between the tmpdir and the changelog filename.
Having it in the header exposes some implementation details, namely
private methods and will cause problems for us if we ever want to change
the actions.
ensure world-readability for trusted.gpg in postinst
apt-key creates trusted.gpg if it needs it with 644 nowadays, but before
it ensured this, it was gpg creating it, which gives it by default 600.
Not a problem as long as our gpgv is run as root, but now that we drop
privileges we have to ensure that we can also read trusted.gpg files
created by earlier apt-key versions.
Michael Vogt [Wed, 1 Oct 2014 10:21:55 +0000 (12:21 +0200)]
Use Acquire::Allow{InsecureRepositories,DowngradeToInsecureRepositories}
The configuration key Acquire::AllowInsecureRepositories controls if
apt allows loading of unsigned repositories at all.
The configuration Acquire::AllowDowngradeToInsecureRepositories
controls if a signed repository can ever become unsigned. This
should really never be needed but we provide it to avoid having
to mess around in /var/lib/apt/lists if there is a use-case for
this (which I can't think of right now).
The fileformat of a pdiff index stores currently only SHA1 hashes. With
this change, we look for all other hashes we support as well and take
what we get, so that we can work after the release of jessie to get
right of SHA1 if we want to.
Note that the completely patched file is and was checked against the
hashes collected from the Release file, so this transition isn't mission
critical.
We are the only possible users of private methods, so we are also the
only users who can potentially export them via using them in inline
methods. The point is: We don't need these symbols exported if we don't
do this, so marking them as hidden removes some methods from the API
without breaking anything as nobody could have used them.
replace c-string Mode with c++-string ActiveSubprocess
A long-lasting FIXME in the acquire code points out the problem that we
e.g. for decompressors assign c-string representations of c++-strings to
the Mode variable, which e.g. cppcheck points out as very bad.
In practice, nothing major happens as the c++-strings do not run out of
scope until Mode would do, but that is bad style and fragile, so the
obvious proper fix is to use a c++ string for storage to begin with.
The slight complications stems from the fact that progress reporting
code in frontends potentially uses Mode and compares it with NULL, which
can't be done with std::string, so instead of just changing the type we
introduce a new variable and deprecate the old one.
cleanup partial directory of lists in apt-get clean
Not really the intended usecase for apt-get clean, but users expect it
to help them in recovery and it can't really hurt as this directory
should be empty if everything was fine and proper anyway.
apt-get download and changelog as well as apt-helper reuse the acquire
system for their own proposes without requiring the directories the
fetcher wants to create, which is a problem if you run them as non-root
and the directories do not exist as it greets you with:
E: Archives directory /var/cache/apt/archives/partial is missing. -
Acquire (13: Permission denied)
Accessing the package records to acquire this information is pretty
costly, so that information wasn't used so far in many places. The most
noticeable user by far is EDSP at the moment, but there are ideas to
change that which this commit tries to enable.
Adding and deleting many repositories could cause (empty) keyring files
to pill up in older apt-key versions, which in the end might cause gnupg
to run into its internal limit of at most 40 keyrings
add and use 'apt-key verify' which prefers gpgv over gpg
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.
We were down to at most two keyrings before, but gnupg upstream plans
dropping support for multiple keyrings in the longrun, so with a
single keyring we hope to be future proof – and 'apt-key adv' isn't a
problem anymore as every change to the keys is merged back, so we have
now the same behavior as before, but support an unlimited amount of
trusted.gpg.d keyrings.
For some advanced usecases it might be handy to specify the secret
keyring to be used (e.g. as it is used in the testcases), but specifying
it via a normal option for gnupg might not be available forever:
http://lists.gnupg.org/pipermail/gnupg-users/2013-August/047180.html
If both are available APT will still prefer gpg over gpg2 as it is a bit
more lightweight, but it shouldn't be a problem to use one or the other
(at least at the moment, who knows what will happen in the future).
'apt-key help' and incorrect usage do not need a functioning gnupg
setup, as well as we shouldn't try to setup gnupg before we actually
test if it is available (and print a message if it is not).
use apt-key adv (+ gnupg) instead of gpgv for verify
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.
merge fragment keyrings in apt-key to avoid hitting gpg limits
gnupg has a hardlimit of 40 (at the moment) keyrings per invocation,
which can be exceeded with (many) repositories. That is rather
misfortune as the longrun goal was to drop gnupg dependency at some
point in the future, but this can now be considered missed and dropped.
It also means that 'apt-key adv' commands might not have the behaviour
one would expect it to have as it mainly operates on a big temporary
keyring, so commands modifying keys will break. Doing this was never a
good idea anyway through, so lets just hope nothing break too badly.
It helps in identifying its affiliation.
Also removes the old postinst which was hidden by apt.postinst for a
long time now and would just install a sources.list in edgecases which
is probably not a good idea (e.g. on my system /etc/apt/sources.list
does not exist). It is better done by the installer of the distro.
projects / apt.git / log
