| Age | Commit message (Collapse) | Author |
|---|
|
As a follow up to the last commit, let's replace APT_CONST
with APT_PURE everywhere to clean stuff up.
|
|
Functions marked with the const attribute may not inspect
any global memory. This includes targets of pointers or
references passed as arguments. A pure function however
is free to inspect memory, but may not have any side
effects.
The function StringSplit() was marked as const, but took
two references to strings. When the second one was passed
as a literal as in StringSplit(name, "::") the compiler
cleverly figured out that we only inspect the address of
"::" (since StringSplit is const) and thus optimized away
the "::" content.
While patching out individual broken uses of APT_CONST
would be possible, this is already the second case, and
there might be more, so let's redefine APT_CONST to use
the pure attribute, so we don't end up with the same
situation again in some time.
|
|
|
|
It contained raw text inside a refsect1
Gbp-Dch: ignore
|
|
The version is probably wrong for most, but oh well,
let's just pretend we are introducing them now.
|
|
We now require gcc 7 on the packaging side, and add an appropriate
symbol to our symbols file.
Also adjust prepare-release to ignore g++ version requirements
when setting up build dependencies on CI.
Closes: #871275
|
|
This caused a build failure in the test suite.
|
|
APT clients always noticed if a method isn't supported and nowadays
generate a message of the form:
E: The method driver …/foobar could not be found.
N: Is the package apt-transport-foobar installed?
This only worked if a single source was using such an unavailable method
through as we were registering the failed config the first round and
the second would try to send requests to the not started method, which
wouldn't work and hang instead (+ hiding the error messages as they would
be shown only at the end of the execution).
Closes: 870675
|
|
Regression-Of: 3317ad864c997f4897756c0a2989c4199e9cda62
|
|
If 'apt-ftparchive packages /path/to/files/' (or sources) is used the
files to include in the generated index (on stdout) were included in the
order in which they were discovered, which isn't a very stable order
which could lead to indexes changing without actually changing content
causing needless changes in the repository changing hashsums, pdiffs,
rsyncs, downloads, ….
This does not effect apt-ftparchive calls which already have an order
defined via a filelist (like generate) which will still print in the
order given by the filelist.
Note that a similar effect can be achieved by post-processing index
files with apt-sortpkgs.
Closes: 869557
Thanks: Chris Lamb for initial patch & Stefan Lippers-Hollmann for testing
|
|
The code only used to warn when it came into a situation where
something actually had to be forced. Warn directly after parsing
the command-line instead, that's more accurate.
|
|
|
|
|
|
The feature exists for a long while even if we get around to document
it properly only now, so we should push for its adoption a bit to avoid
the problems its supposed to solve like avoiding usage of non-world
readable configuration files as they can cause strange behaviour for the
unsuspecting user (like different solutions as root and non-root).
|
|
We detect the effected sources by matching Release info – that has
potential by-catch of repositories which have incorrect field values,
but those are better fixed now anyhow. The bigger incorrectness is that
this message will not only be printed for the Debian services itself but
also for all mirrors not under Debian control but serving Debian like more
local/private mirrors which will not (directly) shutdown. It is likely
through that many of them will follow suite with less visible
announcements or break downright if their upstream source disappears, so
having false-positives here seems benefitial for the user in the end.
|
|
|
|
Opening the file before we drop privileges in the methods allows us to
avoid chowning in the acquire main process which can apply to the wrong
file (imagine Binary scoped settings) and surprises users as their
permission setup is overridden.
There are no security benefits as the file is open, so an evil method
could as before read the contents of the file, but it isn't worse than
before and we avoid permission problems in this setup.
|
|
On HTTP Connect we since recently look into the auth.conf file for login
information, so we should really look for all proxies into the file as
the argument is the same as for sources entries and it is easier to
document (especially as the manpage already mentions it as supported).
|
|
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
|
|
We used to fail on unreadable config/preferences/sources files, but at
least for sources we didn't in the past and it seems harsh to refuse to
work because of a single file, especially as the error messages are
inconsistent and end up being silly (like suggesting to run apt update
to fix the problem…).
LP: #1701852
|
|
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.
|
|
Failing on too much data is good, but we can do better by checking for
exact filesizes as we know with hashsums how large a file should be, so
if we get a file which has a size we do not expect we can drop it
directly, regardless of if the file is larger or smaller than what we
expect which should catch most cases which would end up as hashsum
errors later now a lot sooner.
|
|
We tend to operate on rather large static files, which means we usually
get Content-Length information from the server. If we combine this
information with the filesize we are expecting (factoring in pipelining)
we can avoid reading a bunch of data we are ending up rejecting anyhow
by just closing the connection saving bandwidth and time both for the
server as well as the client.
|
|
Weak hashes like filesize can be used by methods for basic checks and
early refusals even if we can't use them for hard security proposes.
Normal apt operations are not affected by this as they fail if no strong
hash is available, but if apt is forced to work with weak-only files or
e.g. in apt-helper context it can have benefits as weak is better than
no hash for the methods.
|
|
It is highly unlikely to encounter fields which start with HTTP in
practice, but we should really be a bit more restrictive here.
|
|
The comment says this is intended, but looking at the history reveals
that the comment comes from a different era. Nowadays we don't really
need it anymore (and even back then it was disputeable) as we haven't
used that file for our update in the end and nothing really needs this
file after the update.
Triggered is this by 188f297a2af4c15cb1d502360d1e478644b5b810 which
moves various error conditions forward including this code expecting the
file to exist – but it doesn't need to as download could have failed.
We could fix that by simple checking if the file exists and only stage
it if it does, but instead we don't stage it and instead even rename it
out of the way with our conventional FAILED name (if it exists).
That restores support for partial mirrors (= in this case mirrors which
don't ship pdiff files). Note that apt heals itself even if only such a
mirror is used as the update is successful even if that error is shown.
Closes: 869425
|
|
RenameOnError does the rename already, so the check for existence will
always fail making this some completely harmles but also completely
pointless two lines of code we are better of removing.
Gbp-Dch: Ignore
|
|
This file isn't compressed by default, but it might be compressed by a
bugreporter and uncompressing it is extra work apt could do just as well
on the fly as needed just like it does for the dpkg/status file.
|
|
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.
|
|
debtorrent and its helper apt-transport-debtorrent were removed from
Debian in 2013 based on the bugreports #730459 and #731281. As they
aren't available, we shouldn't make references to them anymore. a-t-tor
is picked as replacement for the example.
|
|
The main process is guessed by systemd. This prevents killing dpkg
run by unattended-upgrades in the middle of installing packages
and ensures graceful shutdown.
The timeout of 900 seconds after which apt-daily-upgrade.service
is killed is in sync with unattended-upgrades's timer.
LP: #1690980
|
|
We can't allocate a pointer here, it would not get released - use
an object instead.
Gbp-Dch: ignore
|
|
This makes the code easier to read.
|
|
Minor grammar fix
[jak@d.o: Fixed up po/]
|
|
/org has been obsoleted by /srv for many years on debian.org hosts.
|
|
Gbp-Dch: ignore
|
|
|
|
[squashed:]
apt.systemd.daily: check_stamp: check for 'always' before numerical values
Prevents a crash when the configuration actually uses 'always':
apt.systemd.daily: 402: [: Illegal number: always
|
|
This should make it easier to read includes.
|
|
|
|
This adds a warning so existing working code will still
work (as it includes pkgcache.h first anyway), but it will
know that it's not right to include this file directly.
|
|
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.
|
|
Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 parses the Components
section of (In)Release and attempts to detect the distribution's
supported components. While doing so, it handles component names with
slashes in a special manner, assuming that the actual component is only
the part after the final slash. This is done to handle
security.debian.org, which usually appears in sources.list as follows:
deb http://s.d.o/debian-security stretch/updates main contrib non-free
while the actual release file has:
Codename: stretch
Components: updates/main updates/contrib updates/non-free
While this special handing on APTs part indeed works for
debian-security, it emits spurious warnings on repositories that
actually use slashes in the component names *and* appear so in
sources.list.
We fix this by adding both component versions (whole and final part) to
the SupportedComponents array.
Closes: #868127
|
|
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
Closes: 858877
|
|
Progress only shows if we have an idea of how much files we will
acquire, but if a transaction fails before we have got an idea we ended
up never showing progress even through we know that a failed transaction
will not download additional files.
|
|
|
|
|
