| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Run the test for kfreebsd-i386 and amd64 and pass "amd64" as
an additional argument to the function. This tests that the
argument is used and thus ParseDepends returns the amd64
results even on a different architecture like i386.
|
|
This is useful for e.g. Britney, where the Build-Depends would have to
be parsed for multiple architectures. With this change, the call can
choose the architecture without having to mess with the config.
Signed-off-by: Niels Thykier <niels@thykier.net>
Closes: #845969
(jak@d.o: made the code compile)
|
|
The idea is simple: Each¹ Find*( call starts with a call check if the
given option (with the requested type) exists in the whitelist. The
whitelist is specified via our configure-index file so that we have
a better chance at keeping it current. the whitelist is loaded via a
special (undocumented for now) configuration stanza and if none is
loaded the empty whitelist will make it so that no warnings are shown.
Much needs to be done still, but that is as good a time as any to take a
snapshot of the current state and release it into the wild given that it
found some bugs already and has no practical effect on users.
¹ not all in this iteration, but many
|
|
Interpreting a boolean as an int works just fine – it just hasn't the
intended result – it isn't a serious problem through as the disabling of
the usage of this dpkg calling style is just an "optimization"
|
|
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
|
|
Again no practical difference, but for consistency a boolean option
should really be accessed via a boolean method rather than an int
especially if you happen to try setting the option to "true" …
Gbp-Dch: Ignore
|
|
This can happen e.g. for file: repositories. There is no inherent
problem with setting such values internally, but its bad style,
forbidden in the manpage and could be annoying in the future.
Gbp-Dch: Ignore
|
|
Unlikely to have any practical effect, but its more consistent to use
the right methods instead of performing it slightly incorrect by hand.
Gbp-Dch: Ignore
|
|
This 'method' is the abstract base for http and https and should as such
be called out like this rather using an easily confused name.
Gbp-Dch: Ignore
|
|
Having a Reset(bool) method to partially reset certain variables like
the download size always were strange, so this commit splits the
ServerState into an additional RequestState living on the stack for as
long as we deal with this request causing an automatic "reset".
There is much to do still to make this code look better, but this is a
good first step which compiles cleanly and passes all tests, so keeping
it as history might be beneficial and due to avoiding explicit memory
allocations it ends up fixing a small memory leak in https, too.
Closes: #440057
|
|
Users end up believing that this is a --force mode as -f is common for
that, but apt doesn't have such a mode and --fix-broken is really not
about forcing something but actually trying to fix the breakage which
tends to be the result of a user forcing something on its system via
low-level forced dpkg calls.
Example: The "common" pattern of "dpkg -i ./foo.deb; apt install -f" is
nowadays far better dealt with via "apt install ./foo.deb".
And while at it the two places handing out this suggestion are changed
to use the same strings to avoid needless translation work in the future
and the suggestion uses 'apt' instead of 'apt-get' as this will be run
interactively by a user, so its a good opportunity to showcase what we
can do and will allow us to be more helpful to the user.
Closes: #709092
Thanks: Kristian Glass for initial patch!
|
|
The config list APT::Build-Essential gets a similar treatment to other
lists now by having the value of the option itself be an override for
the list allowing to disable build-essentials entirely as well as
adding/overriding as usual by now in other lists.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
The implementation is quite different compared to --arch-only due to ABI
reasons but functionality wise they are similar and usually both
available for symmetry at least.
Closes: #845775
|
|
The crude way of preparing a message to be a multiline value failed at
generation valid deb822 in case the error message ended with a new line
like the resolving errors from apt do. apt itself can parse these, but
other tools like grep-dctrl choke on it, so be nice and print valid.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
Closes: #849235
|
|
Any respective parser will do the right thing and grab the last value,
but its better for style to generate that field only once.
Gbp-Dch: Ignore
|
|
Clearsigned files like InRelease, .dsc, .changes and co can potentially
include unsigned or additional messages blocks ignored by gpg in
verification, but a potential source of trouble in our own parsing
attempts – and an unneeded risk as the usecases for the clearsigned
files we deal with do not reasonably include unsigned parts (like emails
or some such).
This commit changes the silent ignoring to warnings for now to get an
impression on how widespread unintended unsigned parts are, but
eventually we want to turn these into hard errors.
|
|
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
|
|
Closes: #846514
|
|
In bug #757534 the opposite direction was initially requested, but what
we did end up with was having a possibility to configure the options
passed to dpkg. The reasoning given their and in #724744 is specific why
apt doesn't need the checks to be performed by dpkg. In fact, what these
two reports show is that if those checks are run people end up being
confused about the requirement of them being run, so given the best case
those checks can do is do nothing (visibly) while the worst cases are
warnings and errors which are neither we are from a security point
better of with disabling them – as (as mentioned in the bugreports)
false positives for issues are really really bad in a security context.
Closes: 724744
|
|
We are calling system() in this code paths, so all we do here is having
a single child performing the action while the parent waits for it to
finish… with the added strangeness of not having our usual error message
collection and giving up after first failure even if told to act on
multiple packages.
|
|
That was the case already for tar-only and diff-only, but in a more
confusing way and without a message while dsc "worked" before resulting
in a dpkg-source error shortly after as tar/diff files aren't available…
|
|
Note: This is a warning about disabling a security feature. It is
supposed to be scary as we are disabling a security feature and we
can't just be silent about it! Downloads really shouldn't happen
any longer as root to decrease the attack surface – but if a warning
causes that much uproar, consider what an error would do…
The old WARNING message:
| W: Can't drop privileges for downloading as file 'foobar' couldn't be
| accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
is frequently (incorrectly) considered to be an error message indicating
that the download didn't happen which isn't the case, it was performed,
but without all the security features enabled we could have used if run
from some other place…
The word "unsandboxed" is chosen as the term 'sandbox(ed)' is a common
encounter in feature lists/changelogs and more people are hopefully able
to make the connection to 'security' than it is the case for 'privilege
dropping' which is more correct, but far less known.
Closes: #813786
LP: #1522675
|
|
Honour Acquire::ForceIPv4/6 in the https transport
|
|
|
|
|
|
This is a follow up to the previous issue where we did not check
if getline() returned -1 due to an end of file or due to an error
like memory allocation, treating both as end of file.
Here we ensure that we also handle buffered writes correctly by
flushing the files before checking for any errors in our error
stack.
Buffered writes themselves were introduced in 1.1.9, but the
function was never called with a buffered file from inside
apt until commit 46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c
which was first released with apt 1.2.10. The function is
public, though, so fixing this is a good idea anyway.
Affected: >= 1.1.9
|
|
This fixes a security issue where signatures of the
InRelease files could be circumvented in a man-in-the-middle
attack, giving attackers the ability to serve any packages
they want to a system, in turn giving them root access.
It turns out that getline() may not only return EINVAL
as stated in the documentation - it might also return
in case of an error when allocating memory.
This fix not only adds a check that reading worked
correctly, it also implicitly checks that all writes
worked by reporting any other error that occurred inside
the loop and was logged by apt.
Affected: >= 0.9.8
Reported-By: Jann Horn <jannh@google.com>
Thanks: Jann Horn, Google Project Zero for reporting the issue
LP: #1647467
|
|
|
|
Previouosly apt's bash completion was such that, given
$ mkdir xyzzz
$ touch xyzzy.deb xyzzx.two.deb
you'd get
$ apt install xyzz<tab>
xyzzx.two.deb xyzzz/
$ apt install /tmp/foo/xyzz<tab>
xyzzx.two.deb xyzzz/
this is inconsistent (xyzzx.two.deb is listed but not xyzzy.deb), but
worse than that it offered things that apt would not actually
recognise as candidates for install:
$ sudo apt install xyzzx.two.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package xyzzx.two.deb
E: Couldn't find any package by glob 'xyzzx.two.deb'
E: Couldn't find any package by regex 'xyzzx.two.deb'
With this small (trival, really) change, apt's bash completion will
only offer things apt understands, and won't recquire an aditional
period in the filename to offer it:
$ apt install xyzz<tab>^C
$ # (no completions!)
$ apt install ./xyzz<tab>
xyzzx.two.deb xyzzy.deb xyzzz/
$ apt install /tmp/foo/xyzz
xyzzx.two.deb xyzzy.deb xyzzz/
fixes #28
LP: #1645815
|
|
|
|
This is output of triehash.
Gbp-Dch: ignore
|
|
Change the trust level check to allow downgrading an Untrusted
option to weak (APT::Hashes::SHA1::Weak "yes";), so it prints
a warning instead of an error; and change the default values
for SHA1 and RIPE-MD/160 from Weak to Untrusted.
|
|
The documentation of APT::Periodic::Verbose doesn't match the code,
specifically level 2 should apply some things differently to level 1
but does not because it uses `-le 2` instead of `-lt 2` or `-le 1`.
Closes: 845599
|
|
The test test-handle-redirect-as-used-mirror-change serves multiple
clients at the same time, so the order of the output is undefined and
once in a while the two clients will intermix their lines causing the
grep we perform on it later to fail making our tests fail.
Solved by introducing client-specific logfiles which we all grep and
sort the result to have the results more stable.
Git-Dch: Ignore
|
|
|
|
In ad9416611ab83f7799f2dcb4bf7f3ef30e9fe6f8 we fall back to asking the
original mirror (e.g. a redirector) if we do not get the expected
result. This works for the indexes, but patches are a different beast
and much simpler. Adding this fallback code here seems like overkill as
they are usually right along their Index file, so actually forward the
relevant settings to the patch items which fixes pdiff support combined
with a redirector and partial mirrors as in such a situation the pdiff
patches would be 404 and the complete index would be downloaded.
|
|
* the good old 'simple' keyring format
* the ascii armored variant since 1.4
Not supported is the (new in gpg 2.1) keybox format.
Closes: 844724
|
|
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
|
|
|
|
We try to configure all packages at the end which need to be configured,
but that also applies to packages which weren't completely installed
(e.g. maintainerscript failed) we end up removing in this interaction
instead.
APT doesn't perform this explicit configure in the end as it is using
"dpkg --configure --pending", but it does confuse the progress report
and potentially also hook scripts.
Regression-Of: 9ffbac99e52c91182ed8ff8678a994626b194e69
|
|
dpkg stumbles over these (#844300) and we haven't dropped 'easier'
removes to be implicit and to be scheduled by dpkg by default so far
so we shouldn't push the decision in such cases to dpkg either.
|
|
Our old idea was to look for the first package which would be "touched"
and take this as the package dpkg is talking about, but that is
incorrect in complicated situations like a package upgraded to/from
multiple M-A:same siblings installed.
As we us the progress report to decide what is still needed we have to
be reasonabily right about the package dpkg is talking about, so we jump
to quite a few loops to get it.
|
|
Given that we use the progress information to skip over actions dpkg has
already done like not purging a package which was already removed and
had no config files or not acting on disappeared packages and such it is
important that apt and dpkg agree on which states the package has to
pass through.
To ensure that we keep tabs on this in the future a warning is added at
the end if apt hasn't seen all the action it was supposed to see. I
can't wait for the first bugreporters to wonder about this…
|
|
If a package is triggered dpkg frequently issues two messages about it
causing us to make a note about it both times which messes up our
planned dpkg actions view. Adding these actions if we have nothing else
planned fixes this and should still be correct as those planned actions
will deal with the triggering just fine and we avoid strange problems
like a package triggered before its removed…
|
|
Our profile says we spend about 5% of the time transforming the
hex digits into the binary format used by HashsumValue, all for
comparing them against the other strings. That makes no sense
at all.
According to callgrind, this reduces the overall instruction
count from 5,3 billion to 5 billion in my example, which
roughly matches the 5%.
|
|
Generating a string for each version we see is somewhat inefficient.
The problem here is that the Description tag names are longer than
15 byte, and thus require an allocation on the heap, which we should
avoid.
It seems reasonable that 20 characters works for all languages codes
used for archive descriptions, but if not, there's a warning, so
we'll catch that.
This should improve performance by about 2%.
|
|
This has the effect of significantly reducing actual string
comparisons, and should improve the performance of FindGrp
a bit, although it's hardly measureable (callgrind says it
uses 10% instructions less now).
|
