| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
pkgAcqIndexDiffs/pkgAcqMergeDiffs
|
|
|
|
|
|
|
|
This prevents a failure in mktemp -d - it will blindly trust
TMPDIR and not use something else if the dir is not there.
|
|
|
|
|
|
|
|
|
|
feature/acq-trans
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
methods/gpgv.cc
|
|
Closes: #763004
Thanks: Russ Allbery
|
|
Conflicts:
apt-pkg/acquire-item.cc
|
|
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
|
|
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.
Git-Dch: Ignore
|
|
This used to work before we implemented a stricter commandline parser
and e.g. the dd-schroot-cmd command constructs commandlines like this.
Reported-By: Helmut Grohne
|
|
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.
Closes: #762889
|
|
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)
Closes: 762898
|
|
Closes: 763033
|
|
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.
|
|
'unsigned int'
Git-Dch: Ignore
Reported-By: cppcheck
|
|
also defined in its parent class 'pkgSource'
Git-Dch: Ignore
Reported-By: cppcheck
|
|
Git-Dch: Ignore
Reported-By: cppcheck
|
|
unnecessary.
Git-Dch: Ignore
Reported-By: cppcheck
|
|
|
|
apt can work with both, so it has an or-dependency on them,
but the tests want to play with both of them.
Git-Dch: Ignore
|
|
The original patch does not apply against the rewritten apt-key,
but an additional test doesn't hurt.
Closes: 754436
|
|
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
|
|
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.
|
|
Git-Dch: Ignore
|
|
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
|
|
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
Git-Dch: Ignore
|
|
|
|
Git-Dch: Ignore
|
|
beside testing apt-key a bit it also avoids duplicating gpghome setup
code in apt-key and the test framework
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
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).
|
|
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.
|
|
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.
Closes: 733028
|
