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
Conversation
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. |
Nice catch! I found the culprit - this hasn't been updated since 1.2.6 in #82 . |
Fix SHA256 checksum for nginx 1.4.4
@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? |
@irontoby I suspect that the $ 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 |
When the fixes for the issue is going to be released? |
@miketheman @irontoby Isn't it also possible that the file changed? (which is obviously problematic) I'm going to check your theory about |
@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 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! |
Of course, now that I type that out, I realize it dispels the theory that |
I just did a little bit more testing - it must be a change in
I'm going to take a look at |
I've run out of time to look at this today, but I suspect (FWIW, I also checksum'd my old and new copies of |
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. |
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 is7c989a5
, rather than the0510af7
insource.rb
: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?