Re: Patch to compile against Botan 2.x
Jack Lloyd <[email protected]> Wed, 13 Dec 2017 18:58:12 -0500
| Newsgroups | gmane.comp.version-control.monotone.devel |
|---|---|
| Message-ID | <[email protected]> |
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