apt/test, branch 1.8.2

Add test case for local-only packages pinned to never

2019-04-02T15:04:25Z

Test from the fix for the regression in trusty for LP #1821308.

Add explicit message for unsupported binary signature

2019-03-03T20:52:40Z

Verifying the content of Release.gpg made us fail on binary signatures which were never officially supported (apt-secure manpage only documents only the generation of ASCII armored), but silently accepted by gpgv as we passed it on unchecked before. The binary format is complex and is itself split into old and new formats so adding support for this would not only add lots of code but also a good opportunity for bugs and dubious benefit. Reporting this issue explicitly should help repository creators figure out the problem faster than the default NODATA message hinting at captive portals. Given that the binary format has no file magic or any other clear and simple indication that this is a detached signature we guess based on the first two bits only – and by that only supporting the "old" binary format which seems to be the only one generated by gnupg in this case. References: e2965b0b6bdd68ffcad0e06d11755412a7e16e50 Closes: #921685

Fix various typos in the documentation

2019-02-10T12:16:27Z

Merge branch 'pu/dead-pin' into 'master'

2019-02-04T12:44:08Z

A pin of -32768 overrides any other, disables repo See merge request apt-team/apt!40

Add a Packages-Require-Authorization Release file field

2019-02-01T16:52:03Z

This new field allows a repository to declare that access to packages requires authorization. The current implementation will set the pin to -32768 if no authorization has been provided in the auth.conf(.d) files. This implementation is suboptimal in two aspects: (1) A repository should behave more like NotSource repositories (2) We only have the host name for the repository, we cannot use paths yet. - We can fix those after an ABI break. The code also adds a check to acquire-item.cc to not use the specified repository as a download source, mimicking NotSource.

Introduce experimental 'never' pinning for sources

2019-02-01T16:51:35Z

This allows disabling a repository by pinning it to 'never', which is internally translated to a value of -32768 (or whatever the minimum of short is). This overrides any other pin for that repository. It can be used to make sure certain sources are never used; for example, in unattended-upgrades. To prevent semantic changes to existing files, we substitute min + 1 for every pin-priority: . This is a temporary solution, as we are waiting for an ABI break. To add pins with that value, the special Pin-Priority "never" may be used for now. It's unclear if that will persist, or if the interface will change eventually.

Merge branch 'pu/refuseunsignedlines' into 'master'

2019-02-01T14:40:06Z

Fail if InRelease or Release.gpg contain unsigned lines See merge request apt-team/apt!45

Step over empty sections in TagFiles with comments

2019-02-01T13:51:56Z

Implementing a parser with recursion isn't the best idea, but in practice we should get away with it for the time being to avoid needless codechurn. Closes: #920317 #921037

Refuse files with lines unexpectedly starting with a dash

2019-01-28T19:45:02Z

We support dash-encoding even if we don't really work with files who would need it as implementations are free to encode every line, but otherwise a line starting with a dash must either be a header we parse explicitly or the file is refused. This is against the RFC which says clients should warn on such files, but given that we aren't expecting any files with dash-started lines to begin with this looks a lot like a we should not continue to touch the file as it smells like an attempt to confuse different parsers by "hiding" headers in-between others. The other slightly more reasonable explanation would be an armor header key starting with a dash, but no existing key does that and it seems unlikely that this could ever happen. Also, it is recommended that clients warn about unknown keys, so new appearance is limited.

Merge and reuse tmp file handling across the board

2019-01-23T23:33:16Z

Having many rather similar implementations especially if one is exported while others aren't (and the rest of it not factored out at all) seems suboptimal.