Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

utils/gzip: set mtime = 1 when mtime == 0. #14723

Merged
merged 1 commit into from Feb 21, 2023

Conversation

carlocab
Copy link
Member

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew style with your changes locally?
  • Have you successfully run brew typecheck with your changes locally?
  • Have you successfully run brew tests with your changes locally?

This allows us to bottle formulae whose source modified time is indeed
0.

Needed for Homebrew/homebrew-core#123724.

This allows us to bottle formulae whose source modified time is indeed
`0`.

Needed for Homebrew/homebrew-core#123724.
@BrewTestBot
Copy link
Member

Review period will end on 2023-02-21 at 14:06:16 UTC.

@BrewTestBot BrewTestBot added the waiting for feedback Merging is blocked until sufficient time has passed for review label Feb 20, 2023
Comment on lines 28 to +32
# Zlib::GzipWriter does not properly handle the case of setting mtime = 0:
# https://bugs.ruby-lang.org/issues/16285
#
# This was fixed in https://github.com/ruby/zlib/pull/10. Set mtime to 0 instead
# of raising exception once we are using zlib gem version 1.1.0 or newer.
# This was fixed in https://github.com/ruby/zlib/pull/10. Remove workaround
# once we are using zlib gem version 1.1.0 or newer.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing worth considering here: making this change might mean that this is a workaround we'll have to carry around forever, since changing this will change the checksum of some bottles (and hence bottling would not be reproducible).

However, this might be a property of any workaround we try, so I'm not sure what the right thing to do is.

If the above is correct, then the comment will need to be amended accordingly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How many bottles does this affect in practice? If it's just one or two that's getting (semi-)frequent bottle updates anyway then it's probably ok.

I hope we're not stuck with Ruby 2.6 for that long (Ruby 2.7 has the bugfix) but I guess we'll see come June.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far that I know of? Only one at Homebrew/homebrew-core#123724. But throwing an error here is relatively new, so there could be more. Presumably @alebcay spotted some others which is what prompted throwing an error here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlocab Does this change the checksum of any existing bottles?

I hope we're not stuck with Ruby 2.6 for that long (Ruby 2.7 has the bugfix) but I guess we'll see come June.

I think we could bump the requirement for CI/dev-cmd before that but probably want to assume end-users may be running it for a while longer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far that I know of? Only one at Homebrew/homebrew-core#123724. But throwing an error here is relatively new, so there could be more. Presumably @alebcay spotted some others which is what prompted throwing an error here.

I noticed this because my initial sanity testing with GzipWriter (in brew irb) was with mtime of 0. That's how I discovered the corner case.

I actually didn't know of any actual need we had for setting mtime of 0, this is the first I'm hearing of it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlocab Does this change the checksum of any existing bottles?

If it does, it would be because their checksums were not reproducible. @alebcay also points this out. Making this change will make their checksums reproducible (as long as we never remove the bit that does mtime = 1 if mtime.zero?).

@alebcay
Copy link
Member

alebcay commented Feb 20, 2023

I'll mention that prior to #14316, the logic for setting mtime on the gz file is the same as in this current implementation. The bug would have caused the explicitly requested zero mtime to be ignored and the resulting bottles would not be reproducible as a result. In this case we are just catching and throwing an error about this previously silent failure.

@MikeMcQuaid MikeMcQuaid added the critical Critical change which should be shipped as soon as possible. label Feb 21, 2023
@MikeMcQuaid
Copy link
Member

Thanks again @carlocab!

@BrewTestBot BrewTestBot removed the waiting for feedback Merging is blocked until sufficient time has passed for review label Feb 21, 2023
@BrewTestBot
Copy link
Member

Review period skipped due to critical label.

@MikeMcQuaid MikeMcQuaid merged commit f0fbeba into Homebrew:master Feb 21, 2023
@carlocab carlocab deleted the zlib-mtime branch February 21, 2023 09:27
@github-actions github-actions bot added the outdated PR was locked due to age label Mar 24, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
critical Critical change which should be shipped as soon as possible. outdated PR was locked due to age
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants