<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/deb, branch 1.3_pre2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_pre2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_pre2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-07-01T11:36:40Z</updated>
<entry>
<title>reinstalling local deb file is no downgrade</title>
<updated>2016-07-01T11:36:40Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-01T11:17:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e7edb2fef8370d54a4b8e5a01266e6eda81ef84e'/>
<id>urn:sha1:e7edb2fef8370d54a4b8e5a01266e6eda81ef84e</id>
<content type='text'>
If we have a (e.g. locally built) deb file installed and do try to
install it again apt complained about this being a downgrade, but it
wasn't as it is the very same version… it was just confused into not
merging the versions together which looks like a downgrade then.

The same size assumption is usually good, but given that volatile files
are parsed last (even after the status file) the base assumption no
longer holds, but is easy to adept without actually changing anything in
practice.
</content>
</entry>
<entry>
<title>write auto-bits before calling dpkg &amp; again after if needed</title>
<updated>2016-06-29T14:10:12Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-29T14:10:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=309f497b7280a45e3626493318adb6d39ba5c69b'/>
<id>urn:sha1:309f497b7280a45e3626493318adb6d39ba5c69b</id>
<content type='text'>
Writing first means that even in the event of a power-failure the
autobit is saved for future processing instead of "forgotten" so that
the package is treated as manually installed.

In some cases we have to re-run the writing after dpkg is done through
as dpkg can let packages disappear and in such cases apt will move
autobits around (or in that case non-autobits) which we need to store.
</content>
</entry>
<entry>
<title>Revert "travis: use gcc-5 instead of gcc(-4.8)"</title>
<updated>2016-06-29T10:23:02Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-29T09:00:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cfc6566d5097ef5518e12f5c1e5f15a8f5b182cf'/>
<id>urn:sha1:cfc6566d5097ef5518e12f5c1e5f15a8f5b182cf</id>
<content type='text'>
This reverts commit 2b8221d66a8284042fc53c7bbb14bb9750e9137f.

Avoiding the use of GCC &gt;= 5 stuff lets use go back to 4.8 simplifying
the travis setup again as well as reducing the backport requirements in
general.

This is possible because the std::get_time use requiring GCC &gt;= 5 in
9febc2b238e1e322dce1f94ecbed46d595893b52 was replaced by handrolling it
in 1d742e01470bba27715a8191c50adde4b39c2f19, so the remaining uses are
just small conviniences we can do without.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Fix buffer overflow in debListParser::VersionHash()</title>
<updated>2016-06-28T20:15:50Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-06-28T08:24:11Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b6e9756ca03ec887ef1d0bc8e38f63c29db7a365'/>
<id>urn:sha1:b6e9756ca03ec887ef1d0bc8e38f63c29db7a365</id>
<content type='text'>
If a package file is formatted in a way that that no space
follows a deprecated "&lt;", we would reformat it to "&lt;=" and
increase the length of the output by 1, which can break.

Under normal circumstances with "&lt;=" this should not be an
issue.

Closes: #828812
</content>
</entry>
<entry>
<title>add insecure (and weak) allow-options for sources.list</title>
<updated>2016-06-22T12:05:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-20T18:50:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a'/>
<id>urn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a</id>
<content type='text'>
Weak had no dedicated option before and Insecure and Downgrade were both
global options, which given the effect they all have on security is
rather bad. Setting them for individual repositories only isn't great
but at least slightly better and also more consistent with other
settings for repositories.
</content>
</entry>
<entry>
<title>ensure filesize of deb is included in the hashes list</title>
<updated>2016-06-22T12:05:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-18T14:27:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5da51e0e2da3f055306562d38103b06a23d81719'/>
<id>urn:sha1:5da51e0e2da3f055306562d38103b06a23d81719</id>
<content type='text'>
Filesize is a silly hash all by itself, but in combination with others
it can be a strong opponent, so ensuring that it is in the list of
hashes and hence checked by the normal course of action the acquire
process takes is a good thing.
</content>
</entry>
<entry>
<title>handle weak-security repositories as unauthenticated</title>
<updated>2016-06-22T12:05:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-03-17T15:36:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ab94dcece2465f824bea80fc9158bf9a028b2e87'/>
<id>urn:sha1:ab94dcece2465f824bea80fc9158bf9a028b2e87</id>
<content type='text'>
APT can be forced to deal with repositories which have no security
features whatsoever, so just giving up on repositories which "just" fail
our current criteria of good security features is the wrong incentive.

Of course, repositories are better of fixing their setup to provide the
minimum of security features, but sometimes this isn't possible:
Historic repositories for example which do not change (anymore).

That also fixes problem with repositories which are marked as trusted,
but are providing only weak security features which would fail the
parsing of the Release file.

Closes: 827364
</content>
</entry>
<entry>
<title>merge sources.list lines based on Release filename</title>
<updated>2016-06-17T16:09:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-17T11:27:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b90faf2486b977aef0183e38a7f9c535a8a61a34'/>
<id>urn:sha1:b90faf2486b977aef0183e38a7f9c535a8a61a34</id>
<content type='text'>
Merging by URI means that having sources lines with different URI
methods results in 'strange' warning and error messages, which aren't
very friendly from a user point of view as not encoding the method in
the filename is effectivly an implementation detail.

Merging by filename removes these messages and makes everything "work"
even if it isn't working the way it is configured as the indexes aren't
acquired over the method given, but over the first method for this
release file (which argueably is an implementation detail stemming from
the filename encoding, too).

So either direction isn't perfectly "right", but personally I prefer
"magic" over strange error messages (and doing a full-circle detection
of this with its own messages which would need to be translated feels
like way too much effort for dubious gain).

Closes: 826944
</content>
</entry>
<entry>
<title>don't use FindFile for external Dir::Bin commands</title>
<updated>2016-06-14T12:32:14Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-14T12:32:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=90f2a7a0f66cfc259883490a5fcf40f7d0696cfe'/>
<id>urn:sha1:90f2a7a0f66cfc259883490a5fcf40f7d0696cfe</id>
<content type='text'>
We usually use absolute paths to specific the location of dpkg, apt-key
and the like, but there is nothing wrong with using just the command
name and instead let exec(3) make the lookup in PATH.

We had a wild mixture before, so opting for the more accepting option
out of the two seems about right especially as it makes no difference in
the default case as apt uses absolute paths.
</content>
</entry>
<entry>
<title>don't leak dpkg statusfd pipe in debugging</title>
<updated>2016-06-10T08:49:41Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-09T21:18:10Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7977ed047f967b3e4b4091181acce3eaf7bd8176'/>
<id>urn:sha1:7977ed047f967b3e4b4091181acce3eaf7bd8176</id>
<content type='text'>
Not a big deal to leak fds in debugging mode, but for completeness.

Git-Dch: Ignore
</content>
</entry>
</feed>
