<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt, branch 1.7.0_alpha3</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.7.0_alpha3</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.7.0_alpha3'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2018-08-20T16:29:16Z</updated>
<entry>
<title>Release 1.7.0~alpha3</title>
<updated>2018-08-20T16:29:16Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-08-20T15:44:39Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f7b58ce01124c48407b4310a523104af7107578f'/>
<id>urn:sha1:f7b58ce01124c48407b4310a523104af7107578f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>clear alternative URIs for mirror:// between steps (CVE-2018-0501)</title>
<updated>2018-08-20T16:29:16Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-18T15:32:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=29658a3a74af49e2a24e17bdebb20e1612aac3ec'/>
<id>urn:sha1:29658a3a74af49e2a24e17bdebb20e1612aac3ec</id>
<content type='text'>
APT in 1.6 saw me rewriting the mirror:// transport method, which works
comparable to the decommissioned httpredir.d.o "just" that apt requests
a mirror list and performs all the redirections internally with all the
bells like parallel download and automatic fallback (more details in the
apt-transport-mirror manpage included in the 1.6 release).

The automatic fallback is the problem here: The intend is that if a file
fails to be downloaded (e.g. because the mirror is offline, broken,
out-of-sync, …) instead of erroring out the next mirror in the list is
contacted for a retry of the download.

Internally the acquire process of an InRelease file (works with the
Release/Release.gpg pair, too) happens in steps: 1) download file and 2)
verify file, both handled as URL requests passed around. Due to an
oversight the fallbacks for the first step are still active for the
second step, so that the successful download from another mirror stands
in for the failed verification… *facepalm*

Note that the attacker can not judge by the request arriving for the
InRelease file if the user is using the mirror method or not. If entire
traffic is observed Eve might be able to observe the request for
a mirror list, but that might or might not be telling if following
requests for InRelease files will be based on that list or for another
sources.list entry not using mirror (Users have also the option to have
the mirror list locally (via e.g. mirror+file://) instead of on a remote
host). If the user isn't using mirror:// for this InRelease file apt
will fail very visibly as intended.

(The mirror list needs to include at least two mirrors and to work
reliably the attacker needs to be able to MITM all mirrors in the list.
For remotely accessed mirror lists this is no limitation as the attacker
is in full control of the file in that case)

Fixed by clearing the alternatives after a step completes (and moving a pimpl
class further to the top to make that valid compilable code). mirror://
is at the moment the only method using this code infrastructure (for all
others this set is already empty) and the only method-independent user
so far is the download of deb files, but those are downloaded and
verified in a single step; so there shouldn't be much opportunity for
regression here even through a central code area is changed.

Upgrade instructions: Given all apt-based frontends are affected, even
additional restrictions like signed-by are bypassed and the attack in
progress is hardly visible in the progress reporting of an update
operation (the InRelease file is marked "Ign", but no fallback to
"Release/Release.gpg" is happening) and leaves no trace (expect files
downloaded from the attackers repository of course) the best course of
action might be to change the sources.list to not use the mirror family
of transports ({tor+,…}mirror{,+{http{,s},file,…}}) until a fixed
version of the src:apt packages are installed.

Regression-Of: 355e1aceac1dd05c4c7daf3420b09bd860fd169d,
 57fa854e4cdb060e87ca265abd5a83364f9fa681
LP: #1787752
</content>
</entry>
<entry>
<title>Update symbols</title>
<updated>2018-08-20T16:29:16Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-08-20T16:29:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e946d82865e1231c2cc21249eb8690ce7311b39d'/>
<id>urn:sha1:e946d82865e1231c2cc21249eb8690ce7311b39d</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Report (soon) worthless keys if gpg uses fpr for GOODSIG</title>
<updated>2018-08-19T15:30:31Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-16T21:36:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b934870c4f893be28eb1537910c0aadce6dd6e09'/>
<id>urn:sha1:b934870c4f893be28eb1537910c0aadce6dd6e09</id>
<content type='text'>
gpgs DETAILS documentation file declares that GOODSIG could report keyid
or fingerprint since gpg2, but for the time being it is still keyid
only. Who knows if that will ever change as that feels like an interface
break with dangerous security implications, but lets be better safe than
sorry especially as the code dealing with signed-by keyids is prepared
for this already. This code is rewritten still to have them all use the
same code for this type of problem.
</content>
</entry>
<entry>
<title>test: Supports records larger than 32kb in 'apt show'</title>
<updated>2018-08-19T15:25:43Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-08-14T22:23:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6df0d31d60d6ad0b706b15d57bd433d036cce82f'/>
<id>urn:sha1:6df0d31d60d6ad0b706b15d57bd433d036cce82f</id>
<content type='text'>
The 1.7 series rework of show started in
bf53f39c9a0221b670ffff74053ed36fc502d5a0 resolved the issue already,
but its always a good idea to at least bring the tests along so
that we hopeful do not regress in the future with another rewrite.

Tests: #905527
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Simplified Chinese program translation update</title>
<updated>2018-08-19T15:25:43Z</updated>
<author>
<name>Boyuan Yang</name>
<email>073plan@gmail.com</email>
</author>
<published>2018-08-14T18:37:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b172d6afb88296d7794e6a8f28d379d969d18521'/>
<id>urn:sha1:b172d6afb88296d7794e6a8f28d379d969d18521</id>
<content type='text'>
Reviewed-by: Mo Zhou &lt;cdluminate@gmail.com&gt;
Closes: #903695
</content>
</entry>
<entry>
<title>aptwebserver: Prefetch compressors to avoid thread crashes</title>
<updated>2018-08-19T15:25:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-07-09T14:12:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d298701bd765357905705aa133c3fdb2d1a4835c'/>
<id>urn:sha1:d298701bd765357905705aa133c3fdb2d1a4835c</id>
<content type='text'>
If multiple threads act on requests (like if connection comes from a
webbrowser) a thread might request the supported compressors while
another thread is still working on creating the list to be stored in the
static cache variable.

As the price to pay for atomic and co seems to high for the fringe
usecase of manual usage of aptwebserver the patch just makes a call to
generate the list while still single threaded.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>CMake: Use ${PROJECT_NAME} instead of hardcoding apt</title>
<updated>2018-08-14T17:44:28Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-06-28T16:23:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9a521ed76019fc7bdad1bf09c063bd3550536ef0'/>
<id>urn:sha1:9a521ed76019fc7bdad1bf09c063bd3550536ef0</id>
<content type='text'>
Completely pointless as it makes no difference for apt,
but copying the file to other projects becomes a lot easier.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Set DPKG_FRONTEND_LOCKED as needed when doing selection changes</title>
<updated>2018-08-08T13:20:44Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-08-08T13:19:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=55489885b51b02b7f74e601a393ecaefd1f71f9c'/>
<id>urn:sha1:55489885b51b02b7f74e601a393ecaefd1f71f9c</id>
<content type='text'>
We forgot to set the variable for the selection changes. Let's
set it for that and some other dpkg calls.

Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a
</content>
</entry>
<entry>
<title>Merge branch 'bugfix/big-lock' into 'master'</title>
<updated>2018-08-07T13:51:13Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2018-08-07T13:51:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e165588b0b9bc7c484c91e324b6b9418b0a29457'/>
<id>urn:sha1:e165588b0b9bc7c484c91e324b6b9418b0a29457</id>
<content type='text'>
Add support for dpkg frontend lock

See merge request apt-team/apt!11</content>
</entry>
</feed>
