Fix issue 20287 - std.zip: Wrong compressed data

[ghost]

While working on issue 20027 I noticed this bug. It's there because someone assumed, that the namelength and extralength are the same in the central directory and the local file header. This is not necessarily the case, even in correct files (assuming, that my local zip utility produces correct files).

[dlang-bot]

Thanks for your pull request and interest in making D better, @berni44! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20287	normal	std.zip: Wrong compressed data

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#7221"

[CyberShadow]

It's there because someone assumed, that the namelength and extralength are the same in the central directory and the local file header

When would these values be different in the directory and the local header in a valid zip file? What values does your zip utility produce?

[ghost]

When would these values be different in the directory and the local header in a valid zip file?

The name fields should not differ, but can. It's one of the next issues I'll address to reject such files. The extra field contains 3rd party stuff, that's not completely covered in the specs. In this file, there are two entries: Extended time stamp (0x5455) and something, that I did not manage to find out yet (0x7875) which is the same in both places. The two entries differ in the time stamp where I don't know the exact format neither. But I guess it's more accurate at one place (9 bytes), than at the other (5 bytes). Or one is localised, one not, or such stuff.

What values does your zip utility produce?

The unittest is directly taken from that utility. You can find the two entries at position 0x22 and 0x75.

[CyberShadow]

If these values may differ, then it would probably make sense to expose both occurrences to the application.