apt/methods/rred.cc, branch 2.1.13Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.132020-11-07T21:52:20ZSupport compressed output from rred similar to apt-helper cat-file2020-11-07T21:52:20ZDavid Kalnischkiesdavid@kalnischkies.de2020-11-07T21:52:20Zurn:sha1:e5bb443cf58cec23503ad0deeeb06a080053da8aSupport reading compressed patches in rred direct call modes2020-11-07T20:48:21ZDavid Kalnischkiesdavid@kalnischkies.de2020-11-07T20:39:00Zurn:sha1:418f9272606857e312f485778a1ef1b263236463
The acquire system mode does this for a long time already and as it is
easy to implement and handy for manual testing as well we can support
it in the other modes, too.
Prepare rred binary for external usage2020-11-07T20:48:21ZDavid Kalnischkiesdavid@kalnischkies.de2020-11-07T20:23:57Zurn:sha1:9e1398b164f55238990907f63dfdef60588d9b24
Merging patches is a bit of non-trivial code we have for client-side
work, but as we support also server-side merging we can export this
functionality so that server software can reuse it.
Note that this just cleans up and makes rred behave a bit more like all
our other binaries by supporting setting configuration at runtime and
supporting --help and --version. If you can make due without this, the
now advertised functionality is provided already in earlier versions.
apt-pkg: URI: Add 'explicit' to single argument constructor2019-04-30T15:43:56ZJulian Andres Klodejulian.klode@canonical.com2019-04-30T10:32:54Zurn:sha1:af74a9e2d55d6a9532eb3fbb9b96c65b7ddc1e4d
This needs a fair amount of changes elsewhere in the code,
hence this is separate from the previous commits.
Sandbox methods with seccomp-BPF; except cdrom, gpgv, rsh2017-10-22T21:38:31ZJulian Andres Klodejak@debian.org2017-10-22T21:34:03Zurn:sha1:32bcbd73e0988d2d2237690ffae33b4f5cc5ff81
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.
Reformat and sort all includes with clang-format2017-07-12T11:57:51ZJulian Andres Klodejak@debian.org2017-07-12T11:40:41Zurn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3
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.
stop rred from leaking debug messages on recovered errors2017-01-19T03:14:08ZDavid Kalnischkiesdavid@kalnischkies.de2017-01-19T03:14:08Zurn:sha1:2984d7aec37e09b473c7b99f43d20622c25dc99d
rred can fail for a plentory of reasons, but its failure is usually
recoverable (Ign lines) so it shouldn't leak unrequested debug messages
to an observing user.
Closes: #850759
try not to call memcpy with length 0 in hash calculations2016-09-01T14:13:14ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-31T08:11:07Zurn:sha1:644478e8db56f305601c3628a74e53de048b28c8
memcpy is marked as nonnull for its input, but ignores the input anyhow
if the declared length is zero. Our SHA2 implementations do this as
well, it was "just" MD5 and SHA1 missing, so we add the length check
here as well as along the callstack as it is really pointless to do all
these method calls for "nothing".
Reported-By: gcc -fsanitize=undefined
implement generic config fallback for methods2016-08-10T21:19:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-31T16:05:56Zurn:sha1:30060442025824c491f58887ca7369f3c572fa57
The https method implemented for a long while now a hardcoded fallback
to the same options in http, which, while it works, is rather inflexible
if we want to allow the methods to use another name to change their
behavior slightly, like apt-transport-tor does to https – most of the
diff being s#https#tor#g which then fails to do the full circle
fallthrough tor -> https -> http for https sources. With this config
infrastructure this could be implemented now.
rred: truncate result file before writing to it2016-07-27T13:52:22ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-27T13:52:22Zurn:sha1:0e071dfe205ad21d8b929b4bb8164b008dc7c474
If another file in the transaction fails and hence dooms the transaction
we can end in a situation in which a -patched file (= rred writes the
result of the patching to it) remains in the partial/ directory.
The next apt call will perform the rred patching again and write its
result again to the -patched file, but instead of starting with an empty
file as intended it will override the content previously in the file
which has the same result if the new content happens to be longer than
the old content, but if it isn't parts of the old content remain in the
file which will pass verification as the new content written to it
matches the hashes and if the entire transaction passes the file will be
moved the lists/ directory where it might or might not trigger errors
depending on if the old content which remained forms a valid file
together with the new content.
This has no real security implications as no untrusted data is involved:
The old content consists of a base file which passed verification and a
bunch of patches which all passed multiple verifications as well, so the
old content isn't controllable by an attacker and the new one isn't
either (as the new content alone passes verification). So the best an
attacker can do is letting the user run into the same issue as in the
report.
Closes: #831762