Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2022-04-01T12:16:19Z 2022-04-01T12:16:19Z David Kalnischkies david@kalnischkies.de 2022-04-01T09:37:26Z urn:sha1:05fae6fae95d8ef6690f3d56863e3bb6a44d424c We abstract hashes a fair bit to be able to add new ones eventually, which lead us to building the field names on the fly. We can do better through by keeping a central place for these names, too, which even helps in reducing code as we don't need the MD5 → Files dance anymore. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-26T16:35:42Z urn:sha1:f2f8e89f08cdf01c83a0b8ab053c65329d85ca90 Failing on too much data is good, but we can do better by checking for exact filesizes as we know with hashsums how large a file should be, so if we get a file which has a size we do not expect we can drop it directly, regardless of if the file is larger or smaller than what we expect which should catch most cases which would end up as hashsum errors later now a lot sooner. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-24T12:30:41Z urn:sha1:d7518dba50e2285c41c7002a1d86f876401fd9ea We tend to operate on rather large static files, which means we usually get Content-Length information from the server. If we combine this information with the filesize we are expecting (factoring in pipelining) we can avoid reading a bunch of data we are ending up rejecting anyhow by just closing the connection saving bandwidth and time both for the server as well as the client. 2016-11-09T22:32:02Z David Kalnischkies david@kalnischkies.de 2016-11-09T22:32:02Z urn:sha1:28ee7f19b865c32ce1b03cc0afa26983a0208693 Some people do not recognize the field value with such an arcane name and/or expect it to refer to something different (e.g. #839257). We can't just rename it internally as its an avoidance strategy as such fieldname existed previously with less clear semantics, but we can spare the general public from this implementation detail. 2016-06-22T12:05:01Z David Kalnischkies david@kalnischkies.de 2016-06-18T13:15:27Z urn:sha1:d30036922c6963846db4ab633b13fb87c1b5b462 For "Hash Sum mismatch" that info doesn't make a whole lot of difference, but for the new insufficient info message an indicator that while this hashes are there and even match, they aren't enough from a security standpoint. 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-04-24T08:35:08Z urn:sha1:30979dd7616105302f06af82f419eb62d7b613f8 They are the small brothers of the hashsum mismatch, so they deserve a similar treatment even through we have for architectual reasons not a much to display as for hashsum mismatches for now. 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-03-12T19:29:04Z urn:sha1:0340069cc4709a18ba117090763d9f263de999a9 Users tend to report these errors with just this error message… not very actionable and hard to figure out if this is a temporary or 'permanent' mirror-sync issue or even the occasional apt bug. Showing the involved hashsums and modification times should help in triaging these kind of bugs – and eventually we will have less of them via by-hash. The subheaders aren't marked for translation for now as they are technical glibberish and probably easier to deal with if not translated. After all, our iconic "Hash Sum mismatch" is translated at least. These additions were proposed in #817240 by Peter Palfrader. 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-03-12T16:36:01Z urn:sha1:3f7604340855760289d7ed7e2dca70f99a9f4986 This is a duplicate of sorts of 0efb29eb36184bbe6de7b1013d1898796d94b171 which is the a lot more frequent case of this error – and also a duplicate of this error message, just without the \n at the end. Git-Dch: Ignore 2016-03-14T10:54:08Z David Kalnischkies david@kalnischkies.de 2016-03-13T21:44:37Z urn:sha1:d4c45145553781418c25343ac1478f62da645851 The structure we parse the data into has a dedicated size field, but it tends to be easier to handle it as a (very weak) checksum. 2016-03-13T12:01:14Z Julian Andres Klode jak@debian.org 2016-03-13T11:21:09Z urn: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.