Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.20 2021-02-04T10:00:00Z 2021-02-04T10:00:00Z David Kalnischkies david@kalnischkies.de 2021-02-03T20:47:00Z urn:sha1:c31ba27ecf7e35e03af34c3d74d3c6c93976f89c APT tries to detect if applying patches is more costly than just downloading the complete index by combining the size of the patches. That is correct for client-side merging, but for server-side merging we actually don't know if we will jump directly from old to current or have still intermediate steps in between. With this commit we assume it will be a jump from old to current through as that is what dak implements and it seems reasonable if you go to the trouble of server side merging that the server does the entire merging in one file instead of leaving additional work for the client to do. Note that this just changes the heuristic to prevent apt from discarding patches as uneconomic in the now more common one merged-patch style, it still supports multiple merged patches as before. To resolve this cleanly we would need another field in the index file declaring which hash we will arrive at if a patch is applied (or a field differentiating between these merged-patch styles at least), but that seems like overkill for now. 2020-12-18T19:45:35Z David Kalnischkies david@kalnischkies.de 2020-07-10T18:19:31Z urn:sha1:a5859bafdaa6bcf12934d0fb1715a5940965e13a This commit potentially breaks code feeding apt an encoded URI using a method which does not get URIs send encoded. The webserverconfig requests in our tests are an example for this – but they only worked before if the server was expecting a double encoding as that was what was happening to an encoded URI: so unlikely to work as expected in practice. Now with the new methods we can drop this double encoding and rely on the URI being passed properly (and without modification) between the layers so that passing in encoded URIs should now work correctly. 2020-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T14:38:49Z urn:sha1:e6c55283d235aa9404395d30f2db891f36995c49 We do not deal a lot with URIs which need encoding, but then we do it is a pain that we store it decoded in the acquire system as it means we have to decode and reencode URIs eventually which is potentially giving us slightly different URIs. We see that in our own testing framework while setting up redirects as the config options are effectively double-encoded and decoded to pass them around successfully as otherwise %2f and / in an URI are treated the same. This commit adds the infrastructure for methods to opt into getting URIs send in encoded form (and returning them to us in encoded form, too) so that we eventually do not have to touch the URIs which is how it should be. This means though that we have to deal with methods who do not support this yet (aka: all at the moment) for which we decode and encode while communicating with them. 2020-08-10T13:39:33Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T13:39:33Z urn:sha1:64b45e294f0c6931a9b57ae6cc99ecded8f6a2d3 Closes: #931566 2020-02-26T13:10:47Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T13:04:51Z urn:sha1:da18eb10188a22fc1698a9b8466272f2826447db 2020-02-26T12:55:38Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T12:55:38Z urn:sha1:e4e9af454db78c287ca062ac7d75bdd63bd7f744 2020-02-16T11:46:09Z Julian Andres Klode julian.klode@canonical.com 2020-02-16T10:45:05Z urn:sha1:9cc0e2cab7c83ede99e21c70f248d884b8930983 This experiment did not turn out sensibly, as some servers do not accept credentials when none are expected and fail, so you cannot mirror such a repository. This reverts commit c2b9b0489538fed4770515bd8853a960b13a2618. 2019-11-27T21:00:43Z David Kalnischkies david@kalnischkies.de 2019-11-27T11:10:31Z urn:sha1:1690c3f87ae45a41e8d3e09bf0b1021c008460b9 While passing the combi Release and Release.gpg to the gpgv method for verification the filename of Release is placed where usually Release.gpg is assumed in the rest of the code. The "usual" cases like passing verification and failing verification ending in an error are taking care of this, but the code path dealing with a failed verification, but ignoring said failure (e.g. due to trusted=yes) was not which results in the wrong file being removed later on (in case the index happens to be unmodified since the last update call) leading us into the abyss of strange failures (fixed in the previous commit) were nothing should have changed. This is not a security issue in this form as the repository needs to fail verification & the user forcing apt to ignore the failure and carry on anyhow. It does show however how complicated the code and its various interconnected paths can become. Reported-By: Val "pinkieval" Lorentz on IRC 2019-11-27T20:56:33Z David Kalnischkies david@kalnischkies.de 2019-11-27T18:57:08Z urn:sha1:62bfe5b6ca3ccfba6313d3f9ab4cb75a24a5557a If we have no old Release file, but old indices we can't compare hashsums with the new Release file and hence must request the indices again and have to react to IMS hits if they didn't change. We used to symlink the old index file to the partial directory, but that usually meant that we linked an uncompressed file to a compressed file, which not all uncompressors can deal with transparently resulting in strange failures. We could do without the symlink, but that would require changes in the codepaths dealing with failure as they would rename the file to FAILED. 2019-11-26T11:36:46Z David Kalnischkies david@kalnischkies.de 2019-09-13T10:01:47Z urn:sha1:35012abf30ec1cfc9b5ee29647d4b1e25d98e99f Unused variable, std::algorithms instead of raw for-loops. There should be no observeable difference in behaviour. Reported-By: cppcheck Gbp-Dch: Ignore