<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/contrib, branch 1.4_beta1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.4_beta1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.4_beta1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-11-23T23:21:35Z</updated>
<entry>
<title>report apt-key errors via status-fd messages</title>
<updated>2016-11-23T23:21:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-12T22:22:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8e438ede2f179f2f66268308c24d62952ac06fa4'/>
<id>urn:sha1:8e438ede2f179f2f66268308c24d62952ac06fa4</id>
<content type='text'>
We report warnings from apt-key this way already since
29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like
a good addition. Most of those errors aren't really from apt-key
through, but from the code setting up and actually calling it which used
to just print to stderr which might or might not intermix them with
(other) progress lines in update calls. Having them as proper error
messages in the system means that the errors are actually collected
later on for the list instead of ending up with our relatively generic
but in those cases bogus hint regarding "is gpgv installed?".

The effective difference is minimal as the errors apply mostly to
systems which have far worse problems than a not as nice looking error
message, which makes this pretty hard to test – but at least now the
hint that your system is broken can be read in proper order (= there
aren't many valid cases in which the permissions of /tmp are messed up…).

LP: #1522988
</content>
</entry>
<entry>
<title>Compare size before data when ordering cache bucket entries</title>
<updated>2016-11-22T21:58:19Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-09-27T16:59:11Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f378b41f9ab2493bcbc5892d482b18826b0b84c0'/>
<id>urn:sha1:f378b41f9ab2493bcbc5892d482b18826b0b84c0</id>
<content type='text'>
This has the effect of significantly reducing actual string
comparisons, and should improve the performance of FindGrp
a bit, although it's hardly measureable (callgrind says it
uses 10% instructions less now).
</content>
</entry>
<entry>
<title>Optimize VersionHash() to not need temporary copy of input</title>
<updated>2016-11-22T21:58:18Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-09-27T16:28:55Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f903069c139df58d1ba855f7cf02c4a2d4e51dc3'/>
<id>urn:sha1:f903069c139df58d1ba855f7cf02c4a2d4e51dc3</id>
<content type='text'>
Stop copying stuff, and just parse the bytes one by-one to the
newly created AddCRC16Byte. This improves the instruction count
for an update run from 720,850,121 to 455,801,749 according to
callgrind.
</content>
</entry>
<entry>
<title>Introduce tolower_ascii_unsafe() and use it for hashing</title>
<updated>2016-11-22T21:58:18Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-09-27T16:20:02Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7a3b00b10b6a5a740e07fc1b68a4f3fb3bcdac23'/>
<id>urn:sha1:7a3b00b10b6a5a740e07fc1b68a4f3fb3bcdac23</id>
<content type='text'>
This one has some obvious collisions for non-alphabetical characters,
like some control characters also hashing to numbers, but we don't
really have those, and these are hash functions which are not
collision free to begin with.
</content>
</entry>
<entry>
<title>add TMP/TEMP/TEMPDIR to the TMPDIR DropPrivileges dance</title>
<updated>2016-11-11T22:38:47Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-11T08:18:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e2c8c825a5470e33c25d00e07de188d0e03922c8'/>
<id>urn:sha1:e2c8c825a5470e33c25d00e07de188d0e03922c8</id>
<content type='text'>
apt tools do not really support these other variables, but tools apt
calls might, so lets play save and clean those up as needed.

Reported-By: Paul Wise (pabs) on IRC
</content>
</entry>
<entry>
<title>reset HOME, USER(NAME), TMPDIR &amp; SHELL in DropPrivileges</title>
<updated>2016-11-09T18:33:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-09T18:15:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=34b491e735ad47c4805e63f3b83a659b8d10262b'/>
<id>urn:sha1:34b491e735ad47c4805e63f3b83a659b8d10262b</id>
<content type='text'>
We can't cleanup the environment like e.g. sudo would do as you usually
want the environment to "leak" into these helpers, but some variables
like HOME should really not have still the value of the root user – it
could confuse the helpers (USER) and HOME isn't accessible anyhow.

Closes: 842877
</content>
</entry>
<entry>
<title>add support for Build-Depends/Conflicts-Arch</title>
<updated>2016-11-09T15:18:54Z</updated>
<author>
<name>Johannes Schauer</name>
<email>josch@debian.org</email>
</author>
<published>2016-11-09T14:28:15Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c5f22e483cc0f31f2938874370ac776e40792069'/>
<id>urn:sha1:c5f22e483cc0f31f2938874370ac776e40792069</id>
<content type='text'>
These new enum values might cause "interesting" behaviour in tools not
expecting them – like an old apt would think a Build-Conflicts-Arch is
some sort of Build-Depends – but that can't reasonably be avoided and
effects only packages using B-D/C-A so if there is any breakage the
tools can easily be adapted.

The APT_PKG_RELEASE number is increased so that libapt users can detect
the availability of these new enum fields via:
 #if APT_PKG_ABI &gt; 500 || (APT_PKG_ABI == 500 &amp;&amp; APT_PKG_RELEASE &gt;= 1)

Closes: #837395
</content>
</entry>
<entry>
<title>Do not read stderr from proxy autodetection scripts</title>
<updated>2016-10-04T17:30:30Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-10-02T15:20:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0ecceb5bb9cc8727c117195945b7116aceb984fe'/>
<id>urn:sha1:0ecceb5bb9cc8727c117195945b7116aceb984fe</id>
<content type='text'>
This fixes a regression introduced in
  commit 8f858d560e3b7b475c623c4e242d1edce246025a

  don't leak FD in AutoProxyDetect command return parsing

which accidentally made the proxy autodetection code also read
the scripts output on stderr, not only on stdout when it switched
the code from popen() to Popen().

Reported-By: Tim Small &lt;tim@seoss.co.uk&gt;
</content>
</entry>
<entry>
<title>try not to call memcpy with length 0 in hash calculations</title>
<updated>2016-09-01T14:13:14Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-31T08:11:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=644478e8db56f305601c3628a74e53de048b28c8'/>
<id>urn:sha1:644478e8db56f305601c3628a74e53de048b28c8</id>
<content type='text'>
memcpy is marked as nonnull for its input, but ignores the input anyhow
if the declared length is zero. Our SHA2 implementations do this as
well, it was "just" MD5 and SHA1 missing, so we add the length check
here as well as along the callstack as it is really pointless to do all
these method calls for "nothing".

Reported-By: gcc -fsanitize=undefined
</content>
</entry>
<entry>
<title>Base256ToNum: Fix uninitialized value</title>
<updated>2016-08-31T15:40:15Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-31T15:18:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cf7503d8a09ebce695423fdeb2402c456c18f3d8'/>
<id>urn:sha1:cf7503d8a09ebce695423fdeb2402c456c18f3d8</id>
<content type='text'>
If the inner Base256ToNum() returned false, it did not set
Num to a new value, causing it to be uninitialized, and thus
might have caused the function to exit despite a good result.

Also document why the Res = Num, if (Res != Num) magic is done.

Reported-By: valgrind
</content>
</entry>
</feed>
