<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/methods, branch 1.2.11</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.2.11</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.2.11'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-04-14T14:55:35Z</updated>
<entry>
<title>allow uncompressed files to be empty in store again</title>
<updated>2016-04-14T14:55:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-04-14T14:16:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=479f6fa454cd6ee9e1bc4d9ecda856d34584092e'/>
<id>urn:sha1:479f6fa454cd6ee9e1bc4d9ecda856d34584092e</id>
<content type='text'>
With the previous fix for file applied we can again hit repositories
which contain uncompressed empty files, which since the introduction of
the central store: method wasn't accounted for anymore as we forbid
empty compressed files.
</content>
</entry>
<entry>
<title>fix Alt-Filename handling of file method</title>
<updated>2016-04-14T14:15:39Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-04-14T14:01:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e169fa4a85e03b2b03bb1bdba716b96654ae6050'/>
<id>urn:sha1:e169fa4a85e03b2b03bb1bdba716b96654ae6050</id>
<content type='text'>
A silly of-by-one error in the stripping of the extension to check for
the uncompressed filename broken in an attempt to support all
compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5.

Fixing this highlights also mistakes in the handling of the Alt-Filename
in libapt which would cause apt to remove the file from the repository
(if root has the needed rights – aka the disk isn't readonly or similar)
</content>
</entry>
<entry>
<title>Allow lowering trust level of a hash via config</title>
<updated>2016-03-28T12:59:33Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-28T01:34:54Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6a4958d3134a3a61c036bc9ccaccc393c2bb99f2'/>
<id>urn:sha1:6a4958d3134a3a61c036bc9ccaccc393c2bb99f2</id>
<content type='text'>
Introduces APT::Hashes::&lt;NAME&gt; with entries Untrusted and Weak
which can be set to true to cause the hash to be treated as
untrusted and/or weak.
</content>
</entry>
<entry>
<title>handle gpgv's weak-digests ERRSIG</title>
<updated>2016-03-22T00:58:45Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-03-22T00:26:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=08b7761a251a36fa65cbe022a86c51d7f091a88d'/>
<id>urn:sha1:08b7761a251a36fa65cbe022a86c51d7f091a88d</id>
<content type='text'>
Our own gpgv method can declare a digest algorithm as untrusted and
handles these as worthless signatures. If gpgv comes with inbuilt
untrusted (which is called weak in official terminology) which it e.g.
does for MD5 in recent versions we should handle it in the same way.

To check this we use the most uncommon still fully trusted hash as a
configureable one via a hidden config option to toggle through all of
the three states a hash can be in.
</content>
</entry>
<entry>
<title>properly check for "all good sigs are weak"</title>
<updated>2016-03-21T21:47:17Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-03-21T17:47:10Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8fa99570816d3a644a9c4386c6a8f2ca21480329'/>
<id>urn:sha1:8fa99570816d3a644a9c4386c6a8f2ca21480329</id>
<content type='text'>
Using erase(pos) is invalid in our case here as pos must be a valid and
derefenceable iterator, which isn't the case for an end-iterator (like
if we had no good signature).
The problem runs deeper still through as VALIDSIG is a keyid while
GOODSIG is just a longid so comparing them will always fail.

Closes: 818910
</content>
</entry>
<entry>
<title>Make the weak signature message less ambigious</title>
<updated>2016-03-16T19:37:42Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-16T19:02:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5f060c2776606f3166bd6c64119c31be8ba5d857'/>
<id>urn:sha1:5f060c2776606f3166bd6c64119c31be8ba5d857</id>
<content type='text'>
There was a complaint that, in the previous message,
the key fingerprint could be mistaken for a SHA1 digest
due to the (SHA1) after it.

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>methods/gpgv: Rewrite error handling and message</title>
<updated>2016-03-16T16:56:50Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-16T15:54:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=349c5c89454ff344e4cf693492e7cb62ff549886'/>
<id>urn:sha1:349c5c89454ff344e4cf693492e7cb62ff549886</id>
<content type='text'>
This should be easy to extend in the future and allow us to simplify
the error handling cases somewhat.

Thanks: Ron Lee for wording suggestions
</content>
</entry>
<entry>
<title>methods/gpgv: Warn about SHA1 (and RIPEMD-160)</title>
<updated>2016-03-15T11:33:21Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-15T11:30:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=07ea3af0fe55fdfe976ab847c5c88efd703d1282'/>
<id>urn:sha1:07ea3af0fe55fdfe976ab847c5c88efd703d1282</id>
<content type='text'>
We will drop support for those in the future.

Also adjust the std::array to be a std::vector, as that's easier to
maintain.
</content>
</entry>
<entry>
<title>apt-pkg/acquire-worker.cc: Introduce 104 Warning message</title>
<updated>2016-03-15T11:33:21Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-15T10:40:10Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8c9b7725c3d89461e78061aff4bc644cdb237fe7'/>
<id>urn:sha1:8c9b7725c3d89461e78061aff4bc644cdb237fe7</id>
<content type='text'>
This can be used by workers to send warnings to the main
program. The messages will be passed to _error-&gt;Warning()
by APT with the URI prepended.

We are not going to make that really public now, as the
interface might change a bit.
</content>
</entry>
<entry>
<title>methods/gpgv: Correctly handle weak signatures with multiple keys</title>
<updated>2016-03-15T11:33:21Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-15T09:56:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=08fd77e83528fd03795524adf76e359ae2b56e06'/>
<id>urn:sha1:08fd77e83528fd03795524adf76e359ae2b56e06</id>
<content type='text'>
We added weak signatures to BadSigners, meaning that a Release file
signed by both a weak signature and a strong signature would be
rejected; preventing people from migrating from DSA to RSA keys
in a sane way.

Instead of using BadSigners, treat weak signatures like expired
keys: They are no good signatures, and they are worthless.

Gbp-Dch: ignore
</content>
</entry>
</feed>
