Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.1 2021-06-04T14:45:06Z 2021-06-04T14:45:06Z David Kalnischkies david@kalnischkies.de 2021-06-04T14:15:45Z urn:sha1:a2406cda4dd0aca523183ed6a8b651f06e0e63f9 The code exists since ever, but no other client supports this and the specification like debian-policy isn't asking for this either. What it does do is breaking than all others continue working through: If the filename includes in fact URI encoded bits (hopefully no quotes) which is rather unlikely, but none the less possible. 2021-06-04T14:45:02Z David Kalnischkies david@kalnischkies.de 2021-06-04T12:15:46Z urn:sha1:ba18c4323ecbc66e6a1e3fedae60721f9c5701b1 If a source is not copying files to the destination the download code forces the copy – which in practice are local repositories accessed via file:/ – but in that process takes the filename the local repo used rather than the filename it e.g. advertised via --print-uris. A local repository could hence override a file in the current directory if you use 'apt download', which is a rather weak ability, but still. 2021-06-04T14:43:41Z David Kalnischkies david@kalnischkies.de 2021-06-04T11:06:34Z urn:sha1:149b23c2b9697bc262c0af1934c7a3f6114d903f Keeping URIs encoded in the acquire system depends on having them encoded in the first place. While many other places got the encoding 2 out of 3 ArchiveURI implementations were missed which are in practice responsible for nearly all of the URI building, just that index filename do not contain characters to escape and the Filename fields in Packages files usually aren't. Usually. Except if you happen to have e.g. an epoch featuring package with the colon encoded in the filename. On the upside, in most repositories the epoch isn't part of the filename. Reported-By: Johannes 'josch' Schauer on IRC References: e6c55283d235aa9404395d30f2db891f36995c49