| Age | Commit message (Collapse) | Author |
|---|
|
This avoids running the Proxy-Auto-Detect script inside the
untrusted (well, less trusted for now) sandbox. This will allow
us to restrict the http method from fork()ing or exec()ing via
seccomp.
|
|
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
|
|
This isn't really used by the acquire system at all at the moment and
the only method potentially sending this information is file://, but
that used to be working correctly before broken in 2013, so better fix
it now and worry about maybe using the data some day later.
Regression-Of: b3501edb7091ca3aa6c2d6d96dc667b8161dd2b9
|
|
Using hardcoded array-indexes in the build-dependency parsing is
efficient, but less discoverable and easier to break. We can avoid
this by making it even more efficient (not that it would be noticeable)
allowing us to do explicitly named comparisons instead.
Gbp-Dch: Ignore
|
|
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
|
|
In commit Do not warn about duplicate "legacy" targets, we
we added an if, that changed the .po files...
|
|
When udev is not available, the variables for libraries and
include paths are set to NOTFOUND rather than an empty string
and CMake exits with an error. Use a generator expression to
only use these variables when UDEV_FOUND is true.
|
|
We previously dlopen()ed it, but it seems painful to do that
without any real gain, except for possibly not having libudev
in the address space and not having code #ifdefed for Linux.
The latter means that we are a bit more likely to break stuff
for non-Linux systems now if we play with udev, but at least
we don't end up with it silently breaking because of a libudev
ABI break.
The existing function pointers in the struct were renamed and
kept for compat purposes.
Fixes Debian/apt#48
Also adjust prepare-release to strip [linux-any] from build-depends
for travis.
|
|
This fails if no Files field exists anymore, for example, because
the Sources index only contains SHA256 hashes. Instead check all
hashes.
|
|
If a source has a legacy Contents file, and two lines mention
the same archive but different components, a warning would be
issued that is confusing. So, as the field is named Contents-deb-legacy,
let's just not print warnings for fields containing "legacy".
LP: #1697120
Closes: #839259
|
|
The relevant calling code as well as the implementation for the deb
system was removed 2 years ago with the refactoring of release
information storage (b07aeb1a6e24825e534167a737043441e871de9f).
This commit removes the the unused remains of this change with no
practical effect on anybody (expect codesize) as the methods were
declared as hidden and hence only libapt could have called it.
Gbp-Dch: Ignore
|
|
A libapt user who hasn't initialized _system likely has a reason, so we
shouldn't greet back with a segfault usually deep down in the callstack
for no reason. If the user had intended to pick up information from the
system, _system wouldn't be uninitialized after all.
LP: #1613184
SRU: 1.4.y
|
|
APT by default logs terminal (term.log) and actions (history.log), but
if either or Dir::Log directly is set to /dev/null it continues to do
so, which isn't too bad – just wasted effort – but term.log is
chmodded to protect it from the general public (as it may contain
otherwise private data the admin entired in the terminal) which
shouldn't happen for /dev/null.
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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/]
|
|
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
|
|
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.
|
|
This makes it possible to write sensible auto detect scripts.
|
|
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.
|
|
Having messages being printed on the error stack and confirm them by
commandline flags is an okayish first step, but some frontends will
probably want to have a more interactive feeling here with a proper
question the user can just press yes/no for as for some frontends a
commandline flag makes no sense…
|
|
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 error cases are just as unlikely as the memory leaks to ever cause
real problems, but lets play it safe for correctness.
Reported-By: scan-build & clang
Gbp-Dch: Ignore
|
|
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).
|
|
Adopting this change in other frontends will require source changes as
well similar to our own changes in apt-private/.
|
|
|
|
POSIX.1-2008 gives us a range of *at calls to deal with files
including the unlinkat so we can remove a file from a directory
based on a path to the file relative to the directory.
(In our case here the path we have is just the filename)
We avoid changing directories in this way which e.g. fails if the
directory we started in no longer exists or is otherwise inaccessible.
Closes: 860738
|
|
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
|
|
Changes nothing on the program front and as the datatypes are
sufficently comparable fixes no bug either, but problems later on if we
ever change the types of those and prevent us using types which are too
large for the values we want to store waste (a tiny bit of) resources.
Gbp-Dch: Ignore
|
|
In complex situations in which we want to unpack a package which has a
conflict/breaks on another package which must be removed due this
conflict apt can decide to perform this remove earlier than initially
planned.
Problem: For three years apt wouldn't remove that package, but the
package which has the conflict… The situation isn't very common and
easily hidden as the package which is removed is unpacked a few actions
later – it becomes visible for packages which protect themselves from
removal through like systemd as the running init resulting in upgrade
failures (#854041).
Note that the package isn't purged, so data shouldn't be lost even if a
user runs into a "hidden" case of it as long as the package sticks to
the policy of removing data only on purge.
Reaching this situation artificially is hard, which is why no testcase
is included, as the situation is highly state dependent. Testing with
"real" systems indicate that slight modifications in the installed
packages set can make the bug not trigger.
Regression-Of: 0eb4af9d3d0c524c7afdc684238aa263ac287449
Thanks: Michael Biebl for helping find this with countless tests
|
|
We need to be able to update 1.4.y in different ways than later
apt versions, and thus need to bump the major version so there
is no collision in the minor version at some point.
|
