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

Fix SHA256 checksum for nginx 1.4.4 #305

Merged
merged 1 commit into from Dec 9, 2014
Merged

Conversation

irontoby
Copy link
Contributor

@irontoby irontoby commented Dec 9, 2014

I'm not sure what's going on here, but the SHA-256 checksum I calculate for http://nginx.org/download/nginx-1.4.4.tar.gz using sha256sum on Ubuntu 14.04.1 is 7c989a5, rather than the 0510af7 in source.rb:

$ wget http://nginx.org/download/nginx-1.4.4.tar.gz
$ sha256sum ./nginx-1.4.4.tar.gz
7c989a58e5408c9593da0bebcd0e4ffc3d892d1316ba5042ddb0be5b0b4102b9  ./nginx-1.4.4.tar.gz

$ ls -l /var/chef/cache/nginx-1.4.4.tar.gz
... Jun  4  2014 /var/chef/cache/nginx-1.4.4.tar.gz
$ sha256sum /var/chef/cache/nginx-1.4.4.tar.gz 
7c989a58e5408c9593da0bebcd0e4ffc3d892d1316ba5042ddb0be5b0b4102b9  /var/chef/cache/nginx-1.4.4.tar.gz

Recently a chef-client run threw a fatal error that the checksum was incorrect. However I still have the cached downloaded resource from June 2014 and the file is the same, 7c989a5. So did this only recently begin being checked, or is it some other issue on my end? How was the checksum "wrong" this whole time but only recently threw the error?

@ToMoCoop
Copy link

ToMoCoop commented Dec 9, 2014

I'm not sure what's happened either, but this definitely has only just occurred, as i've got boxes where this worked successfully for months and then caused an issue after a re-provision.

+1 for this being merged, looks fine to me.

@miketheman miketheman added this to the 2.7.5 milestone Dec 9, 2014
@miketheman miketheman self-assigned this Dec 9, 2014
@miketheman
Copy link
Contributor

Nice catch! I found the culprit - this hasn't been updated since 1.2.6 in #82 .

miketheman added a commit that referenced this pull request Dec 9, 2014
Fix SHA256 checksum for nginx 1.4.4
@miketheman miketheman merged commit 7a8f3dc into sous-chefs:master Dec 9, 2014
@irontoby
Copy link
Contributor Author

irontoby commented Dec 9, 2014

@miketheman well I'm glad I'm not crazy, but for my own peace of mind, any idea why it worked with the wrong hash for so long? Was the checksum just being ignored or could it be a bad config on my side?

@miketheman
Copy link
Contributor

@irontoby I suspect that the remote_file resource was using some of the other mechanisms to prevent redownload like the Last-Modified or ETag fields.

$ curl -I http://nginx.org/download/nginx-1.4.4.tar.gz
HTTP/1.1 200 OK
Server: nginx/1.7.7
Date: Tue, 09 Dec 2014 15:53:31 GMT
Content-Type: application/octet-stream
Content-Length: 768217
Last-Modified: Tue, 19 Nov 2013 14:59:58 GMT
Connection: keep-alive
Keep-Alive: timeout=15
ETag: "528b7cee-bb8d9"
Accept-Ranges: bytes

@tapasmishra
Copy link

When the fixes for the issue is going to be released?

@davidgiesberg
Copy link

@miketheman @irontoby Isn't it also possible that the file changed? (which is obviously problematic) I'm going to check your theory about remote_file, but that seems a bit fishy.

@irontoby
Copy link
Contributor Author

@davidgiesberg I tried to explain that in my original report but don't think I did a good job. That was my initial concern as well, and I was worried that I was dealing with a file that had been tampered with (either previously or recently), or they simply updated e.g. a README or license file inside the tarball. After all that's pretty much the whole reason why we use checksums! :)

I first provisioned this system on June 4, 2014, and at that time the file was first downloaded, and it was cached on my system at /var/chef/cache/nginx-1.4.4.tar.gz ever since. I have run chef-client many times since then, but only in the past month or so did the checksum mismatch occur. It sounds like this was the same experience @ToMoCoop had also.

I manually verified that the file, which hadn't changed in half a year, had the same checksum as the one I freshly downloaded from nginx.org. Both of them had the "wrong" checksum of 7c989a5. That's why I was so confused that it was silently wrong the whole time, yet I'm fairly confident that it wasn't recently changed.

As an aside, it would be really nice if nginx.org at least provided downloads over https!

@irontoby
Copy link
Contributor Author

Of course, now that I type that out, I realize it dispels the theory that remote_file was comparing Last-Modified or ETag, since the checksum was wrong even on the initial download...

@davidgiesberg
Copy link

I just did a little bit more testing - it must be a change in remote_file. I switched my chef-client version from 12.0.3-1 to 11.16.4-1 and I got the 7c989a checksum, but chef-client went right past it:

[2014-12-18T21:31:08+00:00] INFO: remote_file[http://nginx.org/download/nginx-1.4.4.tar.gz] created file /tmp/kitchen/cache/nginx-1.4.4.tar.gz

    - create new file /tmp/kitchen/cache/nginx-1.4.4.tar.gz

[2014-12-18T21:31:12+00:00] INFO: remote_file[http://nginx.org/download/nginx-1.4.4.tar.gz] updated file contents /tmp/kitchen/cache/nginx-1.4.4.tar.gz

    - update content in file /tmp/kitchen/cache/nginx-1.4.4.tar.gz from none to 7c989a
    (new content is binary, diff output suppressed)

I'm going to take a look at remote_file and see if anything jumps out.

@davidgiesberg
Copy link

I've run out of time to look at this today, but I suspect remote_file changed somehow and the current behavior is more "correct". The old version was not raising an exception on the checksum mismatch, which I believe it should have been.

(FWIW, I also checksum'd my old and new copies of nginx-1.4.4.tar.gz and got the same results as you)

@lock
Copy link

lock bot commented Apr 25, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants