Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.4 2015-09-01T12:19:44Z 2015-09-01T12:19:44Z David Kalnischkies david@kalnischkies.de 2015-09-01T11:58:00Z urn: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. 2015-09-01T09:29:49Z Michael Vogt mvo@ubuntu.com 2015-09-01T09:13:48Z urn:sha1:55ae7a516126f9f064d8353bf962256b7307590a 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. 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T07:29:00Z urn:sha1:6c55f07a5fa3612a5d59c61a17da5fe640eadc8b 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 2015-08-10T15:24:01Z David Kalnischkies david@kalnischkies.de 2015-06-16T22:14:10Z urn:sha1:e8afd16892e87a6e2f17c1019ee455f5583387c2 Some of them modify the ABI, but given that we prepare a big one already, these few hardly count for much. Git-Dch: Ignore 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-07T22:06:41Z urn:sha1:4f51fd8636592a96aecf17c8bf4cfdb3ea2207cc 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… 2015-06-09T10:57:35Z David Kalnischkies david@kalnischkies.de 2015-06-06T10:28:00Z urn: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(). 2015-05-12T11:29:54Z David Kalnischkies david@kalnischkies.de 2015-05-12T09:18:17Z urn:sha1:495b7a615a2d8f485beadf88c6ed298f5bbe50c2 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. 2015-04-18T23:13:09Z David Kalnischkies david@kalnischkies.de 2015-03-30T18:47:13Z urn: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. 2014-11-08T13:26:00Z David Kalnischkies david@kalnischkies.de 2014-10-26T22:17:03Z urn:sha1:586d8704716a10e0f8b9c400cab500f5353eebe6 For compatibility we use/provide and fill quiet some deprecated methods and fields, which subsequently earns us a warning for using them. These warnings therefore have to be disabled for these codeparts and that is what this change does now in a slightly more elegant way. Git-Dch: Ignore 2014-10-24T21:54:59Z David Kalnischkies david@kalnischkies.de 2014-10-23T14:54:00Z urn: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.