<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test, branch 1.8.0_rc4</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.8.0_rc4</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.8.0_rc4'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2019-02-10T12:16:27Z</updated>
<entry>
<title>Fix various typos in the documentation</title>
<updated>2019-02-10T12:16:27Z</updated>
<author>
<name>Jakub Wilk</name>
<email>jwilk@jwilk.net</email>
</author>
<published>2019-02-10T11:51:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9a702b150c8ddeafa8c10c9f120dafdeb08ef93b'/>
<id>urn:sha1:9a702b150c8ddeafa8c10c9f120dafdeb08ef93b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Merge branch 'pu/dead-pin' into 'master'</title>
<updated>2019-02-04T12:44:08Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2019-02-04T12:44:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3a015964dd56edf897ee062b2eafa2cfc0584380'/>
<id>urn:sha1:3a015964dd56edf897ee062b2eafa2cfc0584380</id>
<content type='text'>
A pin of -32768 overrides any other, disables repo

See merge request apt-team/apt!40</content>
</entry>
<entry>
<title>Add a Packages-Require-Authorization Release file field</title>
<updated>2019-02-01T16:52:03Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2019-02-01T13:43:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c2b9b0489538fed4770515bd8853a960b13a2618'/>
<id>urn:sha1:c2b9b0489538fed4770515bd8853a960b13a2618</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Introduce experimental 'never' pinning for sources</title>
<updated>2019-02-01T16:51:35Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-12-18T13:50:25Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8bb2a91a070170d7d8e71206d1c66a26809bdbc3'/>
<id>urn:sha1:8bb2a91a070170d7d8e71206d1c66a26809bdbc3</id>
<content type='text'>
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: &lt;min&gt;. 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.
</content>
</entry>
<entry>
<title>Merge branch 'pu/refuseunsignedlines' into 'master'</title>
<updated>2019-02-01T14:40:06Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2019-02-01T14:40:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d5dcc2e9d3008b57c3fae0bcb5b1c2a197f5430c'/>
<id>urn:sha1:d5dcc2e9d3008b57c3fae0bcb5b1c2a197f5430c</id>
<content type='text'>
Fail if InRelease or Release.gpg contain unsigned lines

See merge request apt-team/apt!45</content>
</entry>
<entry>
<title>Step over empty sections in TagFiles with comments</title>
<updated>2019-02-01T13:51:56Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-02-01T13:51:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5caa8cac3bc0ffa8b5360f3e5d5c84e710eb394b'/>
<id>urn:sha1:5caa8cac3bc0ffa8b5360f3e5d5c84e710eb394b</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Refuse files with lines unexpectedly starting with a dash</title>
<updated>2019-01-28T19:45:02Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-01-28T19:45:02Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9b840b59cc80a072e14b8adc9d76669a7a50ab87'/>
<id>urn:sha1:9b840b59cc80a072e14b8adc9d76669a7a50ab87</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Merge and reuse tmp file handling across the board</title>
<updated>2019-01-23T23:33:16Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-01-23T21:50:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=73e3459689c05cd62f15c29d2faddb0fc215ef5e'/>
<id>urn:sha1:73e3459689c05cd62f15c29d2faddb0fc215ef5e</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Fail on non-signature lines in Release.gpg</title>
<updated>2019-01-23T21:48:16Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-01-23T19:50:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e2965b0b6bdd68ffcad0e06d11755412a7e16e50'/>
<id>urn:sha1:e2965b0b6bdd68ffcad0e06d11755412a7e16e50</id>
<content type='text'>
The exploit for CVE-2019-3462 uses the fact that a Release.gpg file can
contain additional content beside the expected detached signature(s).
We were passing the file unchecked to gpgv which ignores these extras
without complains, so we reuse the same line-reading implementation we
use for InRelease splitting to detect if a Release.gpg file contains
unexpected data and fail in this case given that we in the previous
commit we established that we fail in the similar InRelease case now.
</content>
</entry>
<entry>
<title>Fail instead of warn for unsigned lines in InRelease</title>
<updated>2019-01-23T18:10:47Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2019-01-23T16:47:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3734cceb44b02ca4d5ee3c6f5cbfe1e12f17cffb'/>
<id>urn:sha1:3734cceb44b02ca4d5ee3c6f5cbfe1e12f17cffb</id>
<content type='text'>
The warnings were introduced 2 years ago without any reports from the
wild about them actually appearing for anyone, so now seems to be an as
good time as any to switch them to errors.

This allows rewritting the code by failing earlier instead of trying to
keep going which makes the diff a bit hard to follow but should help
simplifying reasoning about it.

References: 6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3
</content>
</entry>
</feed>
