apt/apt-pkg/contrib/hashes.cc, branch 1.4.2

try not to call memcpy with length 0 in hash calculations

2016-09-01T14:13:14Z

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

Allow lowering trust level of a hash via config

2016-03-28T12:59:33Z

Introduces APT::Hashes:: with entries Untrusted and Weak which can be set to true to cause the hash to be treated as untrusted and/or weak.

Do not consider SHA1 usable

2016-03-13T12:01:14Z

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 checks

2015-09-01T12:19:44Z

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.

Consider md5sum no longer a usable hash

2015-09-01T09:29:49Z

The md5sum hash is broken since some time and we should no longer consider it a usable hash. Also update the tests to reflect this.

make all d-pointer * const pointers

2015-08-10T15:25:25Z

Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore

apply various style suggestions by cppcheck

2015-08-10T15:24:01Z

Some of them modify the ABI, but given that we prepare a big one already, these few hardly count for much. Git-Dch: Ignore

support hashes for compressed pdiff files

2015-06-09T10:57:36Z

At the moment we only have hashes for the uncompressed pdiff files, but via the new '$HASH-Download' field in the .diff/Index hashes can be provided for the .gz compressed pdiff file, which apt will pick up now and use to verify the download. Now, we "just" need a buy in from the creators of repositories…

rework hashsum verification in the acquire system

2015-06-09T10:57:35Z

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().

implement VerifyFile as all-hashes check

2015-05-12T11:29:54Z

It isn't used much compared to what the methodname suggests, but in the remaining uses it can't hurt to check more than strictly necessary by calculating and verifying with all hashes we can compare with rather than "just" the best known hash.