Michael Vogt [Wed, 8 Oct 2014 06:32:42 +0000 (08:32 +0200)]
Fix http pipeline messup detection
The Maximum-Size protection breaks the http pipeline reorder code
because it relies on that the object got fetched entirely so that
it can compare the hash of the downloaded data. So instead of
stopping when the Maximum-Size of the expected item is reached we
only stop when the maximum size of the biggest item in the queue
is reached. This way the pipeline reoder code keeps working.
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 18:40:37 +0000 (20:40 +0200)]
Add new Acquire::MaxReleaseFileSize=10*1000*1000 option
This option controls the maximum size of Release/Release.gpg/InRelease
files. The rational is that we do not know the size of these files in
advance and we want to protect against a denial of service attack
where someone sends us endless amounts of data until the disk is full
(we do know the size all other files (Packages/Sources/debs)).
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).
projects / apt.git / log
