apt/test/libapt/hashsums_test.cc, branch 1.7.0_rc1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.7.0_rc12018-05-04T16:42:37ZPrevent GTest from flooding us with compiler warnings2018-05-04T16:42:37ZDavid Kalnischkiesdavid@kalnischkies.de2018-05-04T16:24:57Zurn:sha1:1d77c915005f7630949e2ce706055ee3235009b6
GTest has a bunch of undefined macros which causes the compiler to spit
out warnings for each one on each test file. There isn't much we can do,
so we just disable the warning for the testcases. Other warnings like
sign-promo and sign-compare we can avoid by being more explicit about
our expected integer constants being unsigned.
As we are just changing testcases, there is no user visible change which
would deserve to be noted in the changelog.
Gbp-Dch: Ignore
Reported-By: gcc-8
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.
CMake: Add unit tests2016-08-10T14:11:43ZJulian Andres Klodejak@debian.org2016-08-07T16:22:14Zurn:sha1:06c2b40b9b9094f4f6391bd1d17cfc3725313070
Add support for our GTest based unit tests. By default, CMake will
look in /usr/src/gtest for the external GTest project, but this can
be overriden by defining GTEST_ROOT when invoking cmake.
Gbp-Dch: ignore
Do not consider SHA1 usable2016-03-13T12:01:14ZJulian Andres Klodejak@debian.org2016-03-13T11:21:09Zurn:sha1:51c04562559d0924aa52cc8c9b69901bc8a5c945
SHA1 is not reasonably secure anymore, so we should not consider it
usable anymore. The test suite is adjusted to account for this.
use unusable-for-security hashes for integrity checks2015-09-01T12:19:44ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-01T11:58:00Zurn:sha1:63d609985eb7eefa5f2332bfe4fab96f017760a1
We want to declare some hashes as not enough for security, so that a
user will need --allow-unauthenticated or similar to get data secured
only by those hashes, but we can still us these hashes for integrity
checks if we got them.
rework hashsum verification in the acquire system2015-06-09T10:57:35ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-06T10:28:00Zurn:sha1:448c38bdcd72b52f11ec5f326f822cf57653f81c
Having every item having its own code to verify the file(s) it handles
is an errorprune process and easy to break, especially if items move
through various stages (download, uncompress, patching, …). With a giant
rework we centralize (most of) the verification to have a better
enforcement rate and (hopefully) less chance for bugs, but it breaks the
ABI bigtime in exchange – and as we break it anyway, it is broken even
harder.
It shouldn't effect most frontends as they don't deal with the acquire
system at all or implement their own items, but some do and will need to
be patched (might be an opportunity to use apt on-board material).
The theory is simple: Items implement methods to decide if hashes need to
be checked (in this stage) and to return the expected hashes for this
item (in this stage). The verification itself is done in worker message
passing which has the benefit that a hashsum error is now a proper error
for the acquire system rather than a Done() which is later revised to a
Failed().
calculate only expected hashes in methods2015-04-18T23:13:09ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-30T18:47:13Zurn:sha1:9224ce3d4d1ea0428a70e75134998e08aa45b1e6
Methods get told which hashes are expected by the acquire system, which
means we can use this list to restrict what we calculate in the methods
as any extra we are calculating is wasted effort as we can't compare it
with anything anyway.
Adding support for a new hash algorithm is therefore 'free' now and if a
algorithm is no longer provided in a repository for a file, we
automatically stop calculating it.
In practice this results in a speed-up in Debian as we don't have SHA512
here (so far), so we practically stop calculating it.
promote filesize to a hashstring2014-10-24T21:54:59ZDavid Kalnischkiesdavid@kalnischkies.de2014-10-23T14:54:00Zurn:sha1:23397c9d7d4d455461176600bb45c81185493504
It is a very simple hashstring, which is why it isn't contributing to
the usability of a list of them, but it is also trivial to check and
calculate, so it doesn't hurt checking it either as it can combined even
with the simplest other hashes greatly complicate attacks on them as you
suddenly need a same-size hash collision, which is usually a lot harder
to achieve.
use HashStringList in the acquire system2014-05-09T11:06:27ZDavid Kalnischkieskalnischkies@gmail.com2013-08-18T22:00:23Zurn:sha1:b3501edb7091ca3aa6c2d6d96dc667b8161dd2b9
It is not very extensible to have the supported Hashes hardcoded
everywhere and especially if it is part of virtual method names.
It is also possible that a method does not support the 'best' hash
(yet), so we might end up not being able to verify a file even though we
have a common subset of supported hashes. And those are just two of the
cases in which it is handy to have a more dynamic selection.
The downside is that this is a MAJOR API break, but the HashStringList
has a string constructor for compatibility, so with a bit of luck the
few frontends playing with the acquire system directly are okay.
add a simple container for HashStrings2014-05-08T23:25:55ZDavid Kalnischkieskalnischkies@gmail.com2013-08-18T21:17:05Zurn:sha1:f4c3850ea335545e297504941dc8c7a8f1c83358
APT supports more than just one HashString and even allows to enforce
the usage of a specific hash. This class is intended to help with
storage and passing around of the HashStrings.
Git-Dch: Ignore