This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ehuss
Recipients alanmcintyre, ehuss, gvanrossum
Date 2008-01-07.00:49:25
SpamBayes Score 0.008977481
Marked as misclassified No
Message-id <Pine.BSF.4.58.0801061648400.94086@wintermute.sponsor.net>
In-reply-to <1199652941.5.0.655082587351.issue1622@psf.upfronthosting.co.za>
Content
Some of this work has already been done, see issue 1189216.

You'll obviously need to keep the CRC unpack as signed because the
binascii module uses signed values.

Some header values are stored as 0xffffffff to denote the value is stored
in the 64-bit extended fields.  There are a few places in the zipfile
module that use -1 to achieve this.  This will cause a deprecation warning
when passed into the struct module:
DeprecationWarning: struct integer overflow masking is deprecated

The places that check for this appear to always check for both -1 and
0xfffffff, so that should be safe.  Could potentially even remove the -1
check, not sure why it's checking for both.  In general, you should
probably review the 64-bit support with a fine-toothed comb.

There are some other signed fields in the spec, but I don't think any of
them apply to the zipfile module.  Some of them are timestamps in the
extra fields (Extended Timestamp and Info-ZIP Mac Extra fields).

I'd also keep an eye on other zipfile bugs that appear to be sign-related
(which you appear to have already looked at), such as issues 1189216,
1060, 1760357, 1526.
History
Date User Action Args
2008-01-07 00:49:27ehusssetspambayes_score: 0.00897748 -> 0.008977481
recipients: + ehuss, gvanrossum, alanmcintyre
2008-01-07 00:49:26ehusslinkissue1622 messages
2008-01-07 00:49:25ehusscreate