Package: lzop Version: 1.03-4+b1 Severity: wishlist User: [email protected] Usertags: toolchain timestamps umask X-Debbugs-Cc: [email protected]
lzop embeds timestamp and filesystem mode: $ echo foo > foo # produces foo.lzo $ lzop foo $ lzop --info foo.lzo LZO1X-1 4 4 100.0% 2018-04-21 20:21 foo 1.030 2.080 0.940 Fl: 0x03000001 Mo: 000000100644 Me: 1/5 OS: 3 $ rm foo.lzo $ touch -d @1000000 foo $ chmod o-r foo $ lzop foo $ lzop --info foo.lzo LZO1X-1 4 4 100.0% 1970-01-12 05:46 foo 1.030 2.080 0.940 Fl: 0x03000001 Mo: 000000100640 Me: 1/5 OS: 3 This can lead to unreproducibility in other packages which may ship lzop compressed data, but are built at different times, or with a different umask. Interestingly enough, there are the --no-time and --no-mode options, but according to the manpage and my experimentation, they only work when decompressing files, not the creation of the archive. Making --no-time and --no-mode also apply to the creation of lzo archives would at least make it possible to call lzop in a deterministic way. Patching to support SOURCE_DATE_EPOCH would at least workaround the timestamp issue: https://reproducible-builds.org/specs/source-date-epoch/ I'm not positive, but lzop may also embed other metadata: $ echo foo | lzop - | sha256sum Consistantly produces a different checksum. But I don't always see changed output from lzop --info: $ echo foo | lzop - | lzop --info - LZO1X-1 4 4 100.0% 2018-04-21 20:19 <stdout> 1.030 2.080 0.940 Fl: 0x0300000d Mo: 000000000000 Me: 1/5 OS: 3 This might be because the lzo archive contains time information at a higher resolution than displayed(e.g. seconds), or possibly other metadata. live well, vagrant
signature.asc
Description: PGP signature
