Age | Commit message (Collapse) | Author |
|
Closes: 738103
|
|
|
|
Conflicts:
apt-private/private-list.cc
doc/po/de.po
test/integration/framework
|
|
|
|
There is a new "apt full-upgrade" that performs a apt-get dist-upgrade.
"apt dist-upgrade" is still supported as a alias. The "apt upgrade" code
is changed so that it mirrors the behavior of
"apt-get upgrade --with-new-pkgs" and also honors
"apt uprade --no-new-pkgs".
|
|
|
|
|
|
|
|
|
|
|
|
Avoids that gpg gets the idea it could use files from the user which
weren't overridden specifically like secret keyring and trustdb as
before.
|
|
|
|
|
|
|
|
|
|
|
|
message instead of "ignoring"
|
|
|
|
|
|
|
|
pkg=version requests
|
|
|
|
|
|
|
|
The apt-key script uses quiet a few keyring files for operation which
are specific to the distribution it is build on and is hence one of the
most patched parts – even if it is not that often used anymore now that
a fragment directory for trusted.gpg exists.
|
|
With the net-update command a special keyring can be downloaded and
imported into apt, which must be signed by a master key. Its is
currently disabled because of security problems with it – and the only
known user before that was Ubuntu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The upgrade releated code is moved into upgrade.{cc,h} and
all pkg*Upgrade* prototypes are included in algorihms.h to
avoid breaking API (unless build with APT_9_CLEANER_HEADERS).
|
|
|
|
With a bit of trickery we can reuse the usual infrastructure we have in
place to acquire deb files for the 'download' operation as well, which
gains us authentification check & display, error messages, correct
filenames and "downloads" from the root-owned archives.
|
|
refactor the fetching process so that it looks more like the
others we have in the hope that we can reuse code in the future.
This is a soft interface change as 'source' previously printed
errors directly on stderr, while it will now push it onto our usual
error stack.
|
|
Git-Dch: Ignore
|
|
|
|
|
|
dist-upgrade 2vcard- 4g8+
|
|
|
|
Conflicts:
cmdline/apt-get.cc
|
|
is used with additional
arguments (closes: #705510)
|
|
experimental
|
|
Having fragement files means there is a good chance that there is one
key per keyring, so deal with that as well as with setups in which
keyrings are linked into trusted.gpg.d as we can't just modify those
files (they might be in /usr for example).
|
|
Might come in handy for more than just a simple testcase.
|
|
Closes: 665411
|
|
for some "interesting" reason gpg decides that it needs to update its
trustdb.gpg file in a --list-keys command even if right before gpg is
asked to --check-trustdb. That wouldn't be as bad if it wouldn't modify
the keyring being listed at that moment as well, which generates not
only warnings which are not a problem for us, but as the keyring
modified can be in /usr it modified files which aren't allowed to be
modified.
The suggested solution in the bugreport is running --check-trustdb
unconditionally in an 'apt-key update' call, but this command will not
be used in the future and this could still potentially bite us in
net-update or adv calls. All of this just to keep a file around, which
we do not need…
The commit therefore switches to the use of a temporary created
trusted.gpg file for everyone and asks gpg to not try to update the
trustdb after its intial creation, which seems to avoid the problem
altogether.
It is using your also faked secring btw as calling the check-trustdb
without a keyring is a lot slower …
Closes: #687611
Thanks: Andreas Beckmann for the initial patch!
|
|
APT doesn't care for the trustdb.gpg, but gnupg requires one even for
the simplest commands, so we either use the one root has available in
/etc or if we don't have access to it (as only root can read that file)
we create a temporary directory to store a trustdb.gpg in it.
We can't create just a temporary file as gpg requires the given
trustdb.gpg file to be valid (if it exists), so we would have to remove
the file before calling gnupg which would allow mktemp (and co) to hand
exactly this filename out to another program (unlikely, but still).
|