| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Fail if InRelease or Release.gpg contain unsigned lines
See merge request apt-team/apt!45
|
| |
| |
| |
| |
| |
| | |
Having many rather similar implementations especially if one is exported
while others aren't (and the rest of it not factored out at all) seems
suboptimal.
|
|/
|
|
| |
aptitude has a similar "reinstall" command for precedent.
|
|\ |
|
| |
| |
| |
| | |
Muscle memory is acquired from querying package
info with tools like snap, dnf etc.
|
| |
| |
| |
| |
| |
| |
| | |
This visits dependencies of all manually installed metapackages,
as determined by APT::Never-MarkAuto-Sections, and marks them as
automatically installed. It can be used to clean up autoflags after
a d-i install, for example.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This used to be "apt-cache stats does not take any arguments", but
replace "apt-cache stats" with "%s" so we can reuse it for other
commands.
Gbp-Dch: ignore
|
|\ \
| | |
| | |
| | |
| | | |
Use quoted tagnames in config dumps
See merge request apt-team/apt!32
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tagnames in configuration can include spaces (and other nasties) e.g. in
repository-specific configuration options due to Origin/Label
potentially containing a space. The configuration file format supports
parsing quoted as well as encoded spaces, but the output generated by
apt-config and other places which might be feedback into apt via
parsing (e.g. before calling apt-key in our gpgv method) do not quote
and hence produce invalid configuration files.
Changing the default to be an encoded tagname ensures that the output of
dump can be used as a config file, but other users might not expect
this so that is technically a backward-breaking change.
|
|/
|
|
|
|
|
| |
This adds a new "autopurge" command that will is a shortcut for
"autoremove --purge"
Thanks: Michael Vogt for the initial work
|
|\
| |
| |
| |
| | |
Support subkeys and multiple keyrings in Signed-By options
See merge request apt-team/apt!27
|
| |
| |
| |
| |
| |
| |
| | |
A user can specify multiple fingerprints for a while now, so its seems
counter-intuitive to support only one keyring, especially if this isn't
really checked or enforced and while unlikely mixtures of both should
work properly, too, instead of a kinda random behaviour.
|
|/
|
|
|
|
| |
See merge request apt-team/apt!29
[jak@d.o: Also adjust translations, provide better subject]
|
|
|
|
|
|
|
|
| |
No user-visible change as it effects mostly code comments and
not a single error message, manpage or similar.
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
|
|
|
|
| |
We want to kill everything using our temporary directory.
LP: #1773992
|
| |
|
|
|
|
| |
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
|
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
|
| |
The casts are useless, but the reports show some where we can actually
improve the code by replacing them with better alternatives like
converting whatever int type into a string instead of casting to a
specific one which might in the future be too small.
Reported-By: gcc -Wuseless-cast
|
|
|
|
|
| |
Reported-By: gcc -Wunused-parameter
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpg2 generates keyboxes by default and users end up putting either those
or armored files into the trusted.gpg.d directory which apt tools
neither expect nor can really work with without fortifying backward
compatibility (at least under the ".gpg" extension).
A (short) discussion about how to deal with keyboxes happened in
https://lists.debian.org/deity/2017/07/msg00083.html
As the last message in that thread is this changeset lets go ahead
with it and see how it turns out.
The idea is here simply that we check the first octal of a gpg file to
have one of three accepted values. Testing on my machines has always
produced just one of these, but running into those values on invalid
files is reasonabily unlikely to not worry too much.
Closes: #876508
|
|
|
|
|
|
|
|
|
| |
We now wait for being online ourselves, so all we need to wait
on is for services we are using to be online first. This avoids
severe boot slowdowns by other services having specified an
After=network-online.target without a Wants=.
Gbp-Dch: Full
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new helper, apt-helper wait-online that uses
NetworkManager and/or systemd-networkd to wait for them
reporting online, with a time out of 30 seconds; and run
that helper before running the daily update script.
LP: #1699850
Gbp-Dch: Full
|
|
|
|
|
| |
As a follow up to the last commit, let's replace APT_CONST
with APT_PURE everywhere to clean stuff up.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our test-external-dependency-solver-protocol test sometimes fails on the
immediately 'crashing' solver exit1withoutmsg with the message that it
got SIGPIPE from the solver. That isn't really possible as the solver
produces no output, but on inspection its not this solver getting the
signal but the wrapping provided by the dump-solver as the wrapped
solver instantly exits. Simply ignoring the signal helps in perhaps
extracting the last words of another solver (as this one has none), but
at the very least we get the exit code of the wrapped solver we
interested in as output.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
|
|
|
|
| |
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
|
|
|
|
|
|
|
|
|
| |
Changes nothing on the program front and as the datatypes are
sufficently comparable fixes no bug either, but problems later on if we
ever change the types of those and prevent us using types which are too
large for the values we want to store waste (a tiny bit of) resources.
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Travis and co the default gpg implementation is gpg1 which for some
reason fails if a secret key which was already imported is imported
again. We would prefer it to be a NOP like gpg2 handles it so we crudely
check the error message. apt-key usually doesn't deal with secret keys –
it only learned to do it for manual testing and the integration
framework usage, so no public interface is effected.
Triggered-By: 4ce2f35248123ff2366c8c365ad6a94945578d66
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
| |
Importing a new secret key into gpg(2) can be increadibly slow which
prolongs the test runs significantly – by caching the homedir we gain a
significant speedbonus as reimporting already present keys seems like a
far less costly operation.
Git-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having binary files in /etc is kinda annoying – not that the armored
files are much better – but it is hard to keep tabs on which format the
file has ("simple" or "keybox") and different gnupg versions have
different default binary formats which can be confusing for users to
work with (beside that it is binary).
Adding support for this now will enable us in some distant future to
move to armored later on, much like we added trusted.gpg.d years before
the world picked it up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| | |
On FreeBSD, readlink -f requires the last component
to exist.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several modules use std::array without including the
array header. Bad modules.
Some modules use STDOUT_FILENO and friends, or close()
without including unistd.h, where they are defined.
One module also uses WIFEXITED() without including
sys/wait.h.
Finally, environ is not specified to be defined in unistd.h. We
are required to define it ourselves according to POSIX, so let's
do that.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented
for unreadable files which greatly improves the behavior of apt update
already as everything will work as long as we don't need the keys
included in these files. The behavior if they are needed is still
strange through as update will fail claiming missing keys and a manual
test (which the user will likely perform as root) will be successful.
Passing the new warning generated by apt-key through to apt is a bit
strange from an interface point of view, but basically duplicating the
warning code in multiple places doesn't feel right either. That means we
have no translation for the message through as apt-key has no i18n yet.
It also means that if the user has a bunch of sources each of them will
generate a warning for each unreadable file which could result in quite
a few duplicated warnings, but "too many" is better than none.
Closes: 834973
|
|/
|
|
|
|
|
|
|
|
|
| |
apt-key has inconsistent behaviour if it can't read a keyring file:
Commands like 'list' skipped silently over such keyrings while 'verify'
failed hard resulting in apt to report cconfusing gpg errors (#834973).
As a first step we teach apt-key to be more consistent here skipping in
all commands over unreadable keyrings, but issuing a warning in the
process, which is as usual for apt commands displayed at the end of the
run.
|
|
|
|
|
|
| |
Fingerprints tend to be displayed in space-separated octet pairs so be
nice and allow delete to remove a key based on such a string rather than
requiring that the user is deleting all the spaces manually.
|
|
|
|
|
|
| |
We need to support partial upgrades anyhow, so we have to deal with the
different versions and your tests try to ensure that we do, so we
shouldn't make any explicit higher requirements.
|
|
|
|
| |
Bye, bye, old friend.
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce an initial CMake buildsystem. This build system can build
a fully working apt system without translation or documentation.
The FindBerkelyDB module is from kdelibs, with some small adjustements
to also look in db5 directories.
Initial work on this CMake build system started in 2009, and was
resumed in August 2016.
|
|
|
|
|
|
|
|
|
|
|
| |
gpgconf wasn't always equipped with a --kill option as highlighted by
our testcases failing on Travis and co as these use a much older version
of gpg2. As this is just for cleaning up slightly faster we ignore any
error a call might produce and carry on. Use a recent enough gpg2
version if you need the immediate killing…
Gbp-Dch: Ignore
Reported-By: Travis CI
|
|
|
|
|
|
|
|
|
|
|
| |
apt-key has (usually) no secret key material so it doesn't really need
the agent at all, but newer gpgs insist on starting it anyhow. The
agents die off rather quickly after the underlying home-directory is
cleaned up, but that is still not fast enough for tools like sbuild
which want to unmount but can't as the agent is still hanging onto a
non-existent homedir.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generated dump output is incorrect in sofar as it uses the name as
the key for this compressor, but they don't need to be equal as is the
case if you force some of the inbuilt ones to be disabled as our testing
framework does it at times.
This is hidden from changelog as nobody will actually notice while
describing it in a few words make it sound like an important change…
Git-Dch: Ignore
|
|
|
|
|
|
| |
This caused a crash because the cache was a nullptr.
Closes: #829651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All apt versions support numeric as well as 3-character timezones just
fine and its actually hard to write code which doesn't "accidently"
accepts it. So why change? Documenting the Date/Valid-Until fields in
the Release file is easy to do in terms of referencing the
datetime format used e.g. in the Debian changelogs (policy §4.4). This
format specifies only the numeric timezones through, not the nowadays
obsolete 3-character ones, so in the interest of least surprise we should
use the same format even through it carries a small risk of regression
in other clients (which encounter repositories created with
apt-ftparchive).
In case it is really regressing in practice, the hidden option
-o APT::FTPArchive::Release::NumericTimezone=0
can be used to go back to good old UTC as timezone.
The EDSP and EIPP protocols use this 'new' format, the text interface
used to communicate with the acquire methods does not for compatibility
reasons even if none of our methods would be effected and I doubt any
other would (in these instances the timezone is 'GMT' as that is what
HTTP/1.1 requires). Note that this is only true for apt talking to
methods, (libapt-based) methods talking to apt will respond with the
'new' format. It is therefore strongly adviced to support both also in
method input.
|
|
|
|
|
|
| |
Debian isn't using 'update' anymore for years and the command is in
direct conflict with our goal of not requiring gnupg anymore, so it
is high time to officially declare this command as deprecated.
|
|
|
|
|
|
|
|
|
| |
apt-key needs gnupg for most of its operations, but depending on it
isn't very efficient as apt-key is hardly used by users – and scripts
shouldn't use it to begin with as it is just a silly wrapper. To draw
more attention on the fact that e.g. 'apt-key add' should not be used in
favor of "just" dropping a keyring file into the trusted.gpg.d
directory this commit implements the display of warnings.
|