| Age | Commit message (Collapse) | Author |
|---|
|
Since we append a concrete kernel version to each pattern, and then
anchor the pattern, let's just pick any package starting with a
kernel name (linux-, kfreebsd-, gnumach-), and not worry about
linux-headers, linux-tools, etc specifically, as they'll be caught
by the generic pattern.
LP: #1607845
|
|
APT 1.9.6 introduced empty groups by making use of groups to
deduplicate package names. This is not normally a problem, but
here we assumed that every group has at least one package.
This caused a problem because automake was providing automake-1.16
while having the source package automake-1.16. So we found the
automake-1.16 group, iterated over its empty package list, trying
to store the provides (which hence never happened).
LP: #1859952
|
|
apt(8): Disable regular expressions and fnmatch
See merge request apt-team/apt!95
|
|
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
|
Commit 93f33052de84e9aeaf19c92291d043dad2665bbd restricted auth.conf
entries to only apply to https by default, but this was silent - there
was no information why http sources with auth.conf entries suddenly
started failing. Add such information, and extend test case to cover
it.
|
|
apt satisfy "" caused a segmentation fault because we were iterating
over the characters, checking if the next character was the end of
the string; when it could also be the current character.
Instead, check whether the next character is before the end of
the string, rather than identical to the end.
|
|
Pu/patterns phase2
See merge request apt-team/apt!85
|
|
This avoids downgrade attacks where an attacker could inject
Location: http://private.example/
and then (having access to raw data to private.example, for example,
by opening a port there, or sniffing network traffic) read the credentials
for the private repository.
Closes: #945911
|
|
While passing the combi Release and Release.gpg to the gpgv method for
verification the filename of Release is placed where usually Release.gpg
is assumed in the rest of the code. The "usual" cases like passing
verification and failing verification ending in an error are taking care
of this, but the code path dealing with a failed verification, but
ignoring said failure (e.g. due to trusted=yes) was not which results in
the wrong file being removed later on (in case the index happens to be
unmodified since the last update call) leading us into the abyss of
strange failures (fixed in the previous commit) were nothing should have
changed.
This is not a security issue in this form as the repository needs to fail
verification & the user forcing apt to ignore the failure and carry on
anyhow. It does show however how complicated the code and its various
interconnected paths can become.
Reported-By: Val "pinkieval" Lorentz on IRC
|
|
If we have no old Release file, but old indices we can't compare
hashsums with the new Release file and hence must request the indices
again and have to react to IMS hits if they didn't change.
We used to symlink the old index file to the partial directory, but that
usually meant that we linked an uncompressed file to a compressed file,
which not all uncompressors can deal with transparently resulting in
strange failures.
We could do without the symlink, but that would require changes in the
codepaths dealing with failure as they would rename the file to FAILED.
|
|
Skipped tests do not age very well as changes to the infrastructure go
by unnoticied. In this case we are fetching Translation files now
differently meaning only if mentioned in Release file, which broke this
test. As it makes use of LC_ALL and utf8 locales it can't really be
reenabled, but it might be able to serve as an example for others and
hence at least deserves being fixed.
Gbp-Dch: Ignore
|
|
|
|
|
|
This is pure syntactic sugar - ?narrow does not exist in the
abstract syntax.
|
|
|
|
|
|
|
|
|
|
|
|
When multiple translations of package descriptions are available,
perform search in all of them. It allows using search patterns in
any of the configured languages.
Previously, only the first available translation was searched. As
the result, patterns in e.g. English never matched packages which
had their descriptions translated into local language.
Closes: #490000
|
|
We recently made info an alias for show, but we did not change the
command-line parser to work around it.
LP: #1843812
|
|
Using --force-depends causes dpkg to continue removing packages
a package depends upon even if that package fails to be removed,
because dpkg turns off all sanity checks. So we gotta tell dpkg
to stop immediately if there's an error removing stuff.
Closes: #935910
LP: #1844634
|
|
This matches any package that does not have versions.
|
|
The ?exact-name pattern matches the name exactly, there is
no substring matching going on, or any regular expression
or fnmatch magic.
|
|
This matches all packages where at least one of the versions
is marked essential; or well, whenver apt considers a package
essential.
|
|
This matches all packages that have broken dependencies in the
installed version or the version selected for install.
|
|
These two are mutually exclusive states of installed-ness. And
?installed package is fully unpacked and configured; a ?config-files
package only has config files left.
|
|
These match packages that have no version in a repository, or
where an upgrade is available. Notably,
?and(?obsolete,?upgradable) == ?false
because an upgradable package is by definition not obsolete.
|
|
These patterns allow you to identify automatically installed
packages, as well as automatically installed packages that are
no longer reachable from the manually installed ones.
|
|
This implements the basic logic patterns:
?and ?false ?not ?or ?true
and the basic package patterns:
?architecture ?name ?x-name-fnmatch
|
|
This adds a transformation from parse tree into a CacheFilter and
connects it with cachesets and the apt list command.
|
|
Unfortunately for us, apt update with Acquire::Queue-Mode=access
does not always crash on a real system, so run the whole thing
in valgrind.
|
|
In commit 79b1a8298, QueueName() was changed, amongst other things,
to exit early when the queue mode was single access, as single
access does not need any fancy queue name. The exit became too
early though, as Config was not initialized anymore, but the
caller was relying on it.
Fix QueueName() to always initialize Config and in Enqueue()
initialize Config with a nullptr, so if this regresses it's
guaranteed to fail harder. Also add a test case - this is
very simple, but the first and only test case for access
queue mode.
Regression-Of: 79b1a82983e737e74359bc306d9edb357c5bdd46
LP: #1839714
|
|
Also in old changelogs, but nothing really user visible
like error messages or alike so barely noteworthy.
Reported-By: codespell
Gbp-Dch: Ignore
|
|
Currently CONNECT requests use the name of the proxy as Host value, instead of
the origin server's name.
According to RFC 2616 "The Host field value MUST represent the naming authority
of the origin server or gateway given by the original URL."
The current implementation causes problems with some proxy vendors. This
commit fixes this.
[jak: Adding a test case]
See merge request apt-team/apt!66
|
|
Allow to satisfy dependency strings supplied on
the command line, optionally prefixed with
"Conflicts:" to satisfy them like Conflicts.
Build profiles and architecture restriction lists,
as used in build dependencies, are supported as
well.
Compared to build-dep, build-essential is not
installed automatically, and installing of recommended
packages follows the global default, which defaults
to yes.
Closes: #275379
See merge request apt-team/apt!63
|
|
|
|
Test from the fix for the regression in trusty for LP #1821308.
|
|
Verifying the content of Release.gpg made us fail on binary signatures
which were never officially supported (apt-secure manpage only documents
only the generation of ASCII armored), but silently accepted by gpgv as
we passed it on unchecked before.
The binary format is complex and is itself split into old and new
formats so adding support for this would not only add lots of code but
also a good opportunity for bugs and dubious benefit.
Reporting this issue explicitly should help repository creators figure
out the problem faster than the default NODATA message hinting at
captive portals.
Given that the binary format has no file magic or any other clear and
simple indication that this is a detached signature we guess based on
the first two bits only – and by that only supporting the "old" binary
format which seems to be the only one generated by gnupg in this case.
References: e2965b0b6bdd68ffcad0e06d11755412a7e16e50
Closes: #921685
|
|
|
|
A pin of -32768 overrides any other, disables repo
See merge request apt-team/apt!40
|
|
This new field allows a repository to declare that access to
packages requires authorization. The current implementation will
set the pin to -32768 if no authorization has been provided in
the auth.conf(.d) files.
This implementation is suboptimal in two aspects:
(1) A repository should behave more like NotSource repositories
(2) We only have the host name for the repository, we cannot use
paths yet.
- We can fix those after an ABI break.
The code also adds a check to acquire-item.cc to not use the
specified repository as a download source, mimicking NotSource.
|
|
This allows disabling a repository by pinning it to 'never',
which is internally translated to a value of -32768 (or whatever
the minimum of short is).
This overrides any other pin for that repository. It can be used
to make sure certain sources are never used; for example, in
unattended-upgrades.
To prevent semantic changes to existing files, we substitute
min + 1 for every pin-priority: <min>. This is a temporary
solution, as we are waiting for an ABI break.
To add pins with that value, the special Pin-Priority
"never" may be used for now. It's unclear if that will
persist, or if the interface will change eventually.
|
|
Fail if InRelease or Release.gpg contain unsigned lines
See merge request apt-team/apt!45
|
|
Implementing a parser with recursion isn't the best idea, but in
practice we should get away with it for the time being to avoid
needless codechurn.
Closes: #920317 #921037
|
|
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.
|
|
The exploit for CVE-2019-3462 uses the fact that a Release.gpg file can
contain additional content beside the expected detached signature(s).
We were passing the file unchecked to gpgv which ignores these extras
without complains, so we reuse the same line-reading implementation we
use for InRelease splitting to detect if a Release.gpg file contains
unexpected data and fail in this case given that we in the previous
commit we established that we fail in the similar InRelease case now.
|
|
The warnings were introduced 2 years ago without any reports from the
wild about them actually appearing for anyone, so now seems to be an as
good time as any to switch them to errors.
This allows rewritting the code by failing earlier instead of trying to
keep going which makes the diff a bit hard to follow but should help
simplifying reasoning about it.
References: 6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3
|
|
Report keys used to sign file from gpgv method to acquire system
See merge request apt-team/apt!44
|
|
This fixes a security issue that can be exploited to inject arbritrary debs
or other files into a signed repository as followed:
(1) Server sends a redirect to somewhere%0a<headers for the apt method> (where %0a is
\n encoded)
(2) apt method decodes the redirect (because the method encodes the URLs before
sending them out), writting something like
somewhere\n
<headers>
into its output
(3) apt then uses the headers injected for validation purposes.
Regression-Of: c34ea12ad509cb34c954ed574a301c3cbede55ec
LP: #1812353
|
