| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APT is not the place this information should be stored at, but it is a
good place to experiment and see what will be (not) needed in the future
for a proper implementation higher up the stack.
This is why "BarbarianArchitectures" is chosen instead of a more neutral
and/or sensible "VeryForeign" and isn't readily exported in the API to
other clients for this PoC as a to be drawn up standard will likely
require potentially incompatible changes. Having a then outdated and
slightly different implementation block a "good" name would be bad.
The functionality itself mostly exists (ignoring bugs) since the
introduction of MultiArch as we always had the risk of encountering
packages of architectures not known to dpkg (forced onto the system,
potentially before MultiArch) we had to deal with somehow and other
edge cases.
All this commit really does is allowing what could previously only be
achieved with editing sources.list and some conf options via a single
config option: -o APT::BarbarianArchitectures=foo,bar
|
|
|
|
| |
This is the only nullable thing we have here.
|
|
|
|
|
|
|
|
|
|
|
| |
The JSON encoder only looked at the top state, but did not
pop it, so if we nested objects, we got stuck in whatever
the last state we pushed aside was, so in our example, we
wrongly get a comma inserted _after_ key "b":
{"a":[{}],
"b":,[{}]
}
|
|
|
|
|
|
|
|
| |
This allows us to correctly encode strings containing quotation
marks, escape characters and control characters.
The test case is a bit nasty because it embeds private-cachefile.cc
for linkage reasons.
|
|
|
|
|
|
|
|
|
| |
MaybeAddAuth() here tells us that it refused to use the credentials
for an http source; but that caused the test suite to fail at a later
stage because we checked if there were any errors/warning. Strangely,
this is only triggered with LTO enabled.
Actually check that the warning is being set and then reject it.
|
|
|
|
|
|
|
| |
Our configuration files are not security relevant, but having a parser
which avoids crashing on them even if they are seriously messed up is
not a bad idea anyway. It is also a good opportunity to brush up the
code a bit avoiding a few small string copies with our string_view.
|
|
|
|
|
|
|
| |
strtoul(l) surprises us with parsing negative values which should not
exist in the places we use to parse them, so we can just downright
refuse them rather than trying to work with them by having them promoted
to huge positive values.
|
|
|
|
|
|
| |
This has no attack surface though as the loop is to end very soon anyhow
and the method only used while reading CD-ROM mountpoints which seems
like a very unlikely attack vector…
|
|
|
|
|
|
|
| |
For \xff and friends with the highest bit set and hence being a negative
value on signed char systems the wrong encoding is produced as we run
into undefined behaviour accessing negative array indexes.
We can avoid this problem simply by using an unsigned data type.
|
|
|
|
|
| |
References: 2497198e9599a6a8d4d0ad08627bcfc7ea49c644
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
| |
This allows patterns like ~nalpha~nbeta and ~nalpha!~nbeta to
work like they do in APT.
Also add a comment to remind readers that everything in START
should be in short too.
Cc: stable >= 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No sensible file should include these, but even insensible files do not
gain unfair advantages with it as this parser does not deal with
security critical files before they haven't passed other checks like
signatures or hashsums.
The problem is that the parser accepts and parses empty tag names
correctly, but does not store the data parsed which will effect later
passes over the data resulting e.g. in the following tag containing
the name and value of the previous (empty) tag, its own tagname and its
own value or a crash due to an attempt to access invalid memory
depending on who passes over the data and what is done with it.
This commit fixes both, the incidient of the crash reported by
Anatoly Trosinenko who reproduced it via apt-sortpkgs:
| $ cat /tmp/Packages-null
| 0:
| PACKAGE:0
|
| :
| PACKAGE:
|
| PACKAGE::
| $ apt-sortpkgs /tmp/Packages-null
and the deeper parsing issue shown by the included testcase.
Reported-By: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
References: 8710a36a01c0cb1648926792c2ad05185535558e
|
|
|
|
|
|
| |
Remove all code scheduled to be removed after 5.90, and fix
files to include files they previously got from hashes.h
including more headers.
|
| |
|
|
|
|
|
|
|
|
|
| |
we have to stop parsing on space so that things like ~ramd64 | ~rall
work correctly.
aptitude does not stop parsing on ?, but we'll do as it gets very
confusing otherwise if you write stuff like ~ramd64?name(foo), and
it resolves to ?and(?architecture(amd64?name), (foo))...
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the syntax from approximately
expr = unary
unary = '!'? primary
primary = pattern | short-pattern | word | quoted-word
pattern = '?' name [ '(' expr [',' expr]* ')' ]
short-pattern = ~ name | ~name expr
to:
primary = pattern | short-pattern
argument = word | quoted-word | expr
pattern = '?' name [ '(' argument [',' argument]* ')' ]
short-pattern = ~ name | ~name argument
|
| |
|
|
|
|
|
|
| |
Also make pattern detector in cacheset and private's list accept
such patterns. We probably should just try to parse and see if it
is a (start of a) pattern.
|
| |
|
|
|
|
|
|
| |
We missed that because the CI never ran GTests, because it did
not find the GTest library and failed silently (until the previous
commit).
|
|
|
|
|
|
| |
Require passing -DWITH_TESTS=OFF to CMakeList to disable
unit tests, rather than ignoring them if GTest cannot be
found; which just happened on CI...
|
|
|
|
|
|
| |
GTest 1.9 uses a variable defined in the parent directory, thus
failing to configure. Configure the project in the parent directory
instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a parser for patterns that generates a parse tree. The
language understood by the parser is:
pattern = '?'TERM
| '?'TERM '(' pattern (',' pattern)* ','? ')'
| WORD
| QUOTED-WORD
TERM = [0-9a-zA-Z-]
WORD = [0-9a-ZA-Z-.*^$\[\]_\\]
QUOTED_WORD = "..." # you know what I mean
This language is context free, which is a massive simplification
from aptitude's language, where ?foo(bar) could have two different
meanings depending on whether ?foo takes an argument or not.
|
| |
|
| |
|
|
|
|
|
| |
This ensures that we do not accidentally stop overriding a
method because it's signature changed in an API break.
|
| |
|
|\
| |
| |
| |
| | |
Fail if InRelease or Release.gpg contain unsigned lines
See merge request apt-team/apt!45
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We support dash-encoding even if we don't really work with files who
would need it as implementations are free to encode every line, but
otherwise a line starting with a dash must either be a header we parse
explicitly or the file is refused. This is against the RFC which says
clients should warn on such files, but given that we aren't expecting
any files with dash-started lines to begin with this looks a lot like a
we should not continue to touch the file as it smells like an attempt to
confuse different parsers by "hiding" headers in-between others.
The other slightly more reasonable explanation would be an armor header
key starting with a dash, but no existing key does that and it seems
unlikely that this could ever happen. Also, it is recommended that
clients warn about unknown keys, so new appearance is limited.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Completely pointless as it makes no difference for apt,
but copying the file to other projects becomes a lot easier.
Gbp-Dch: Ignore
|
|
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GTest has a bunch of undefined macros which causes the compiler to spit
out warnings for each one on each test file. There isn't much we can do,
so we just disable the warning for the testcases. Other warnings like
sign-promo and sign-compare we can avoid by being more explicit about
our expected integer constants being unsigned.
As we are just changing testcases, there is no user visible change which
would deserve to be noted in the changelog.
Gbp-Dch: Ignore
Reported-By: gcc-8
|
|
|
|
|
|
| |
Still allow the older one to be used.
Closes: #897149
|
|
|
|
|
|
|
| |
zstd is a compression algorithm developed by facebook. At level 19,
it is about 6% worse in size than xz -6, but decompression is multiple
times faster, saving about 40% install time, especially with eatmydata
on cloud instances.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 89c4c588b275 ("fix from David Kalnischkies for the InRelease gpg
verification code (LP: #784473)") amended verification of cleartext
signatures by a check whether the file to be verified actually starts
with "-----BEGIN PGP SIGNATURE-----\n".
However cleartext signed InRelease files have been found in the wild
which use \r\n as line ending for this armor header line, presumably
generated by a Windows PGP client. Such files are incorrectly deemed
unsigned and result in the following (misleading) error:
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
RFC 4880 specifies in 6.2 Forming ASCII Armor:
That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same
line.
RFC 4880 does not seem to specify whether LF or CRLF is used as line
ending for armor headers, but CR is generally considered whitespace
(e.g. "man perlrecharclass"), hence using CRLF is legal even under
the assumption that LF must be used.
SplitClearSignedFile() is stripping whitespace (including CR) on lineend
already before matching the string, so StartsWithGPGClearTextSignature() is
adapted to use the same ignoring. As the earlier method is responsible
for what apt will end up actually parsing nowadays as signed/unsigned this
change has no implications for security.
Thanks: Lukas Wunner for detailed report & initial patch!
References: 89c4c588b275d098af33f36eeddea6fd75068342
Closes: 884922
|
|
|
|
|
|
|
|
|
|
| |
LookupTag is a little helper to deal with rfc822-style strings we use in
apt e.g. to pass acquire messages around for cases in which our usual
rfc822 parser is too heavy. All the fields it had to deal with so far
were single line, but if they aren't it should really produce the right
output and not just return the first line. Error messages are a prime
candidate for becoming multiline as at the moment they are stripped of
potential newlines due to the previous insufficiency of LookupTag.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
This caused a build failure in the test suite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have support for an netrc-like auth.conf file since 0.7.25 (closing
518473), but it was never documented in apt that it even exists and
netrc seems to have fallen out of usage as a manpage for it no longer
exists making the feature even more arcane.
On top of that the code was a bit of a mess (as it is written in c-style)
and as a result the matching of machine tokens to URIs also a bit
strange by checking for less specific matches (= without path) first.
We now do a single pass over the stanzas.
In practice early adopters of the undocumented implementation will not
really notice the differences and the 'new' behaviour is simpler to
document and more usual for an apt user.
Closes: #811181
|
|
|
|
|
|
| |
Using different ways of opening files means we have different behaviour
and error messages for them, so by the same for all we can have more
uniformity for users and apt developers alike.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the intended usecase where this serves as a hack there is no problem
with double/single quotes being present as we write it to a log file
only, but nowadays our calling of apt-key produces a temporary config
file containing this "setting" as well and suddently quoting is
important as the config file syntax is allergic to it.
So the fix is to ignore all quoting whatsoever in the input and just
quote (with singles) the option values with spaces. That gives us 99% of
the time the correct result and the 1% where the quote is an integral
element of the option … doesn't exist – or has bigger problems than a
log file not containing the quote. Same goes for newlines in values.
LP: #1672710
|