summaryrefslogtreecommitdiff
path: root/test/integration/test-uri-encode-filename-field
Commit message (Collapse)AuthorAgeFilesLines
* No URL decode and quoting support for Files in SourcesDavid Kalnischkies2021-06-041-0/+10
| | | | | | | | 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.
* Do not use filename of local sources in 'apt download'David Kalnischkies2021-06-041-6/+1
| | | | | | | | | | 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.
* URI encode Filename field of Packages files (again)David Kalnischkies2021-06-041-0/+42
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