[issue1523] xdrlib fails to detect overflow (struct bug?)

[Jack Lloyd]

New submission from Jack Lloyd:

The XDR format requires integers to fit into 4 byte values. However (at
least on x86-64) xdrlib will silently accept (and truncate) values
larger than this (up to 2**64-1). Taking a (very brief) look at the
xdrlib code, it appears this is actually a problem in the struct module,
but I don't have the time (or interest) to trace through the _struct
module code.

An example on an x86-64 machine (Python 2.4.3) of encoding 2**32 (which
will not fit in an XDR field) being silently truncated:

$ ./xdr.py 
4294967296 ->  -> 0

An example of struct itself not detecting overflow:

>>> struct.pack("!I", 2**32)
'\x00\x00\x00\x00'

struct.pack will only throw an overflow error if a value >= 2**64 is
used, even if it is encoding into a field that is much smaller.

--
components: Extension Modules
files: xdr.py
messages: 57939
nosy: lloyd
severity: normal
status: open
title: xdrlib fails to detect overflow (struct bug?)
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file8825/xdr.py

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1523>
__

xdr.py
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31526] Allow setting timestamp in gzip-compressed tarfiles

[Jack Lloyd]

New submission from Jack Lloyd:

Context: I have a script which checks out a software release (tagged git 
revision) and builds an archive to distribute to end users. One goal of this 
script is that the archive is reproducible, ie if the script is run twice (at 
different times, on different machines, by different people) it produces 
bit-for-bit identical output, and thus also has the same SHA-256 hash.

Mostly this works great, using the TarInfo feature of tarfile.py to set the 
uid/gid/mtime to fixed values. Except I also want to compress the archive, and 
tarfile calls time.time() to find out the timestamp that will be embedded in 
the gzip header. This breaks my carefully deterministic output.

I would like it if tarfile accepted an additional keyword that allowed 
overriding the time value for the gzip header. As it is I just hack around it 
with

def null_time():
return 0
time.time = null_time

which does work but is also horrible.

Alternately, tarfile could just always set the timestamp header to 0 and avoid 
having its output depend on the current clock. I doubt anyone would notice.

The script in question is here 
https://github.com/randombit/botan/blob/master/src/scripts/dist.py

My script uses Python2 for various reasons, but it seems the same problem 
affects even the tarfile.py in latest Python3. I would be willing to try 
writing a patch for this, if anything along these lines might be accepted.

Thanks.

--
components: Library (Lib)
messages: 302590
nosy: randombit
priority: normal
severity: normal
status: open
title: Allow setting timestamp in gzip-compressed tarfiles
type: enhancement
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue31526>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com