| Age | Commit message (Collapse) | Author |
|---|
|
If a InRelease file fails to download with a non-404 error
we assumed there is some general problem with repository like
a webportal or your are blocked from access (wrong auth, Tor, …).
Turns out some server like S3 return 403 if a file doesn't exist.
Allowing this in general seems like a step backwards as 403 is a
reasonable response if auth failed, so failing here seems better
than letting those users run into problems.
What we can do is show our insecure warnings through and allow the
failures for insecure repos: If the repo is signed it is easy to add
an InRelease file and if not you are setup for trouble anyhow.
References: cbbf185c3c55effe47f218a07e7b1f324973a8a6
|
|
We did not strip away profiling messages when we were diffing
from stdin (-). Just always write temporary files and strip from
them.
We also had a problem when stripping ...profiling: from a line
and the next line starts with profiling. Split the sed into two
calls so we first remove complete profiling: lines before fixing
the ...profiling: cases.
|
|
apt usually gets the width of the window from the terminal or failing
that has a default value, but especially for testing it can be handy
to control the size as you can't be sure that variable sized content
will always be linebreaked as expected in the testcases.
|
|
The documentation said "spaces", but there is no real reason to be so
strict and only allow spaces to separate values as that only leads to
very long lines if e.g. multiple URIs are specified which are again hard
to deal with from a user PoV which the deb822 format is supposed to
avoid. It also deals with multiple consecutive spaces and strange things
like tabs users will surely end up using in the real world.
The old behviour on encountering folded lines is the generation of URIs
which end up containing all these whitespace characters which tends to
mess really bad with output and further processing.
Closes: 881875
|
|
Installed-Size for linux-image-4.13.0-1-amd64-dbg and friends
are larger than 4 GB, but read as a signed integer - that's
fine so far, as the value is in KB, but it's multiplied with
1024 which overflows. So let's read it as unsigned long long
instead.
While we're at it, also use unsigned long long for Size, in
case that is bigger than 2 GB.
|
|
tagfile-order.c: Add missing fields from dpkg 1.19
For binary packages, this is Build-Essential; for source packages,
it is Description.
test-bug-718329-...: Ignore control.tar.*, changes in dpkg 1.19
test-apt-extracttemplates: Fix for dpkg 1.19
|
|
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
|
|
APT used to parse only wellformed files produced by repository creation
tools which removed empty files as pointless before apt would see them.
Now that apt can be told to parse e.g. debian/control files directly, it
needs to be a little more accepting through: We had this with comments
already, now let it deal with the far more trivial empty fields.
Closes: #875363
|
|
APT connects just fine to any .onion address given, only if the connect
fails somehow it will perform checks on the sanity of which in this case
is checking the length as they are well defined and as the strings are
arbitrary a user typing them easily mistypes which apt should can be
slightly more helpful in figuring out by saying the onion hasn't the
required length.
|
|
This automatically removes any old apt-transport-https, as
apt now Breaks it unversioned.
|
|
When writing a Sources files hashes that were already present
in the .dsc were always copied through (or modified), even if
disabled. Remove them instead when they are disabled, otherwise
we end up with hashes for tarballs and stuff but not for dsc
files (as the dsc obviously does not hash itself).
Also adjust the tests: test-compressed-indexes relied on Files
being present in showsrc, and test-apt-update-weak-hashes expected
the tarball to be downloaded when an archive only has MD5 and we
are requiring SHA256 because that used to work because the tarball
was always included.
Closes: #872963
|
|
Commit e250a8d8d8ef2f8f8c5e2041f7645c49fba7aa36 implemented the fix and
should have included already this testcase for it.
Gbp-Dch: Ignore
|
|
gpgv: WARNING: This key is not suitable for signing in --compliance=gnupg mode
|
|
It was broken because apt.conf.d was not readable, but that's
where the architecture is defined...
|
|
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 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.
|
|
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.
|
|
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
|
|
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
|
|
This caused spurious test failures.
|
|
The old curl based method is still available as 'curl',
'curl+http', and 'curl+https'.
|
|
When APT was trying multiple addresses, any later error
somewhere else would be reported with ConnectionRefused
or ConnectionTimedOut as the FailReason because that
was set by early connect attempts. This causes APT to
handle the failures differently, leading to some weirdly
breaking test cases (like the changed one).
Add debugging to the previously failing test case so
we can find out when something goes wrong there again.
|
|
The apt-transport-tor package operates via simple symlinks which can
result in 'http' being called as 'tor+https', so it must pick up the
right configuration pieces and trigger https support also in plus names.
|
|
This should fix some issues with dpkg normalizing such
values. Suprisingly enough apt treats the Version: field
the same, even with epoch vs without, but not when searching,
and does not strip the 0: from the output.
|
|
This gives the repository owner a chance to explain why this change was
needed – e.g. explaining the organisational changes or simply detailing
the changes in the new release made. Note that this URI is also shown
if the change is accepted, so it also draws attention to release notes
of minor updates (if users watch apt output closely).
|
|
The value of Origin, Label, Codename and co can be used in user
configuration from apts own pinning to unattended upgrades.
A repository changing this values can therefore have serious effects on
the behaviour of apt and other tools using these values.
In a first step we will generate error messages for these changes now
explaining the need for explicit confirmation and provide config options
and commandline flags to accept them.
|
|
The exception was made to give (script) users a one-release grace period
to adapt their setup to deal with apt enforcing signing of repositories.
As we are now at the start of a new release cycle its as good a time as
any to lift it now.
Removes-Exception: 952ee63b0af14a534c0aca00c11d1a99be6b22b2
|
|
|
|
The test keeps failing continously on Ubuntu, so let's
fix it for now.
|
|
Gbp-Dch: ignore
|
|
Gbp-Dch: ignore
|
|
On Travis CI running tests with code coverage enabled sometimes
generates profiling lines, which we filter out for a while now,
but that misses lines generated showing progress still causing test
failures, so more sed logic is added in the hopes to ignore them.
Extends: 58608941e6b58a46109b7cd875716b3d8054c4bf
Gbp-Dch: Ignore
|
|
An unknown code should be handled the same as the x00 code of this
group, but for redirections we used to treat 300 (and a few others)
as an error while unknown codes were considered redirections.
Instead we check now explicitly for the redirection codes we support for
redirecting (and add the 308 defined in RFC 7538) to avoid future
problems if new 3xx codes are added expecting certain behaviours.
Potentially strange would have been e.g. "305 Use Proxy" sending a
Location for the proxy to use – which wouldn't have worked and resulted
in an error anyhow, but probably confused users in the process.
|
|
There are very many HTTP errorcodes which indicate that the repository
isn't available at the moment or the connection has some kind of
problem. Given that we do not require Release files the result was that
these errors were ignored and the user presented with a message like
"Repository is no longer signed" which sends the user in the wrong
direction.
Instead of trying to figure out which http errorcodes indicate a global
problem we accept only 404 for ignoring and consider all the rest as
hard errors now causing us to stop instantly after the InRelease file
and print the errorcode (with short description from server) received.
|
|
Moving the code responsible for parsing the Index file from ::Done into
the slightly earlier ::VerifyDone allows us to still "fail" the download
if we can't make use of the Index for whatever reason, so that the
progress log correctly displays "Ign" instead of "Get" for the file.
This also makes quiet a few debug messages proper error messages (but
those are still hidden by default for Ign lines).
|
|
If we couldn't find an entry for a Sources file we would generate an
error while for a Packages file we would silently skip it due to
assuming it is missing because it is empty. We can do better by checking
if the repository declares that it supports a component we want to get
the file from and if not say so and hint at the user making a typo.
An example were this helps is mozilla.debian.net which dropped the
firefox-aurora component (as upstream did) meaning no upgrades until the
user notices manually that the repository doesn't provide packages
anymore. With this commit warnings are raised hopefully causing the user
to investigate what is wrong (sooner).
|
|
Changes in the past to the buildsystem and the testing framework broke
this little helper script – lets fix those problems to restore
functionality.
Gbp-Dch: Ignore
|
|
As the proxy commands are not executed as root, a user can run into
permission errors (s)he isn't expecting – as our switching is an
implementation detail – so the error message in that case should really
be better than a generic "error code 100" sending the user in the wrong
direction as that implies the command was executed, but errored out.
Closes: 857885
|
|
We setup a "horrible" environment in the apt-key testcase to check all
kinds of things, but we really should be making also at least a simple
apt update call, as that in turn will call apt-key which is how apt-key
is used in the non-testcase world, so that calling should be able to
deal with such environments as well.
Gbp-Dch: Ignore
|
|
Gbp-Dch: Ignore
|
|
We want to kill the agent if its home directory exists at that location,
not if it isn't there (leaving an army of processes around).
Gbp-Dch: Ignore
|
|
If the last alternative(s) of an Or group is ignored, because it does
not match an architecture list, we would end up keeping the or flag,
effectively making the next AND an OR.
For example, when parsing (on amd64):
debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386]
=> debhelper (>= 9), libnacl-dev |
Which can cause python-apt to crash.
Even worse:
debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar
=> debhelper (>= 9), libnacl-dev [amd64] | foobar
By setting the previous alternatives Or flag to the current Or flag
if the current alternative is ignored, we solve the issue.
LP: #1694697
|
|
We are in a dilemma here: The regression of sorts was introduced in 2013
with commit d8a8f9d7f0 allowing pkg modifiers for the upgrade commands.
That calls the autoremover as a sideeffect through and with it comes the
option to remove the garbage packages in these commands (similar to aptitude).
Having the option on the commandline is no problem – people aren't going
to request what they don't want (or so I hope), but the documentation
explicitly states that this option only effects install/remove and
mentions a config knob users might use and expect to not suddenly apply
(especially without documentation) to more commands.
Just reverting the commit is out of question, completely ignoring the
option breaks the workflow of every user who happened to use
--autoremove on the commandline for upgrade and expects that to work
given that it was accepted and worked in a stable release. Changing the
documentation to reflect reality while perhaps the simplest and cleanest
option contradicts freeze and is a surprising change we tend to avoid
like the plague while just leaving it be confuses all users who end up
believing the documentation even if was different in the last 3 years.
So what we do is a tricky compromise: The configuration option if read
from a file does apply only for install/remove as documented, while if
the option is encountered on the commandline it is accepted and applies
to the upgrade which should make 99% of the users happy. The rest has to
wait for us to figure out for buster how to get that documented and
implemented in a saner way.
Closes: #855891
|
