monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Patch to compile against Botan 2.x


From: Jack Lloyd
Subject: Re: [Monotone-devel] Patch to compile against Botan 2.x
Date: Wed, 13 Dec 2017 18:58:12 -0500
User-agent: Mutt/1.9.1 (2017-09-22)

Hi Markus,

Sorry for the long delayed reply, this ended up going into a mail folder I don't
usually look in.

On Wed, Nov 08, 2017 at 10:39:55PM +0100, Markus Wanner wrote:

> Second, our custom gzip filter sets the timestamp in the gzip header to
> all all zeroes. More importantly, the parser *requires* it to be all
> zeroes. This does not work with more standard gzip behaviour (like the
> one implemented with Botan's (De)Compression_Filter that's available
> since 2.0 and newer).
> 
> I already made the parser more tolerant (in nvm.botan). However, we
> cannot simply start writing non-zero timestamps without breaking
> backwards-compatibility. Therefore, I left the custom gzip code in place
> and in use, even when compiled against newer Botan versions.

Thanks for pointing this out. For 2.4 I'm going to change the code so that by
default the time field is zeros, and then the user can optionally supply a time
if they want it set in the header. (Ironically I just recently opened a bug in
Python because the tarfile module has the same behavior of always using the
system clock in the gzip header with no way to override it, oops.)

One (albeit hackish) fix would be to just zero out the timestamp field in the
header before writing. (Oh but this might break the CRC? Not sure.) However in
practice you're probably better of just continuing to use your custom filter, as
not all distributions that package Botan include the compression code.

> All of the unit tests now pass with the following Botan versions I'm
> currently testing against: 1.8.15, 1.10.17, 2.0.1, 2.1.0, 2.2.0, and
> 2.3.0. However, I'm still facing Botan-version dependent failures on
> various functional tests. I'll investigate on those, next.

From the NEWS file it looks like this has landed on nvm now, thank you!

The good news is, Botan 2.x should remain API stable and is supported through at
least 2021. And even in future major releases, API changes will be limited to
features that are actively marked as deprecated. So if you do notice any problem
caused by using a future version of Botan it's almost certainly a bug in Botan,
so just mail me or open a Github issue and we'll take care of it.

Jack



reply via email to

[Prev in Thread] Current Thread [Next in Thread]