The settings used for unwrapping TLS connections depend on the access
and hostname we connect to more than what we eventually unwrap. The
bugreport mentions CaInfo, but all other https-settings should also
apply (regardless of generic or hostname specific) to an https proxy,
even if the connection we proxy through it is http-only.
Closes: #990555
varg API is a nightmare as the symbols seems different on ever other
arch, but more importantly SendMessage does a few checks on the content
of the message and it is all outputted via C++ iostreams and not mixed
in FILE* which is handy for overriding the streams.
Every method opts in to getting the encoded URI passed along while
keeping compat in case we are operated by an older acquire system.
Effectively this is just a change for the http-based methods as the
others just decode the URI as they work with files directly.
Went through the list of syscalls starting at 403 (and looked
one back) up to the next unknown syscalls, and added all those that
were present in their non-time64 variant.
Closes: #951012
Commit 93f33052de restricted auth.conf
entries to only apply to https by default, but this was silent - there
was no information why http sources with auth.conf entries suddenly
started failing. Add such information, and extend test case to cover
it.
This allows us to install matching auth files for sources.list.d
files, for example; very useful.
This converts aptmethod's authfd from one FileFd to a vector of
pointers to FileFd, as FileFd cannot be copied, and move operators
are hard.
Embedding an entire acquire stack and HTTP logic in the mirror method
made it rather heavy weight and fragile. This reimplement goes the other
way by doing only the bare minimum in the method itself and instead
redirect the actual download of files to their proper methods.
The reimplementation drops the (in the real world) unused query-string
feature as it isn't really implementable in the new architecture.
The Fail method for acquire methods has a boolean parameter indicating
the transient-nature of a reported error. The problem with this is that
Fail is called very late at a point where it is no longer easily
identifiable if an error is indeed transient or not, so some calls were
and some weren't and the acquire system would later mostly ignore the
transient flag and guess by using the FailReason instead.
Introducing a tri-state enum we can pass the information about fatal or
transient errors through the callstack to generate the correct fails.
qemu-user passes prctl()-based seccomp through to the kernel,
umodified. That's bad, as it blocks the wrong syscalls.
We ignored EFAULT which fixed the problem for targets with different
pointer sizes from the host, but was a bad hack. In order to identify
qemu we can rely on the fact that qemu-user prints its version and
exits with 0 if QEMU_VERSION is set to an unsupported value. If we
run a command that should fail in such an environment, and it exits
with 0, then we are running in qemu-user.
apt-helper is an obvious command to run. The tests ensure it exits
with 1, and it only prints usage information. We also could not use
/bin/false because apt might just as well be from a foreign arch
while /bin/false is not.
Closes: #881519
This should help debugging crashes. The signal handler is a C++11
lambda, yay! Special care has been taken to only use signal handler
-safe functions inside there.
If seccomp is disabled, we fallback to running without it. Qemu fails
in the seccomp() call, returning ENOSYS and libseccomp falls back to
prctl() without adjusting the pointer, causing the EFAULT. I hope
qemu gets fixed at some point to return EINVAL for seccomp via
prctl.
Bug-Qemu: https://bugs.launchpad.net/qemu/+bug/1726394
This reduces the number of syscalls to about 140 from about
350 or so, significantly reducing security risks.
Also change prepare-release to ignore the architecture lists
in the build dependencies when generating the build-depends
package for travis.
We might want to clean up things a bit more and/or move it
somewhere else.
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
