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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide WebDownload Checksum algorithms consistent with shasum algorithms #96
Comments
According to David Cuthbert on my Re:Post question, it appears that WebDownload is also unzipping the gz file before checking the checksum. The value I found in the logs was consistent with the checksum of the unzipped Tar file. |
The second thing that I downloaded with |
Thank you for reporting this! Confirming this is definitely a bug. I've cut a ticket internally to the team and will keep you posted on the fix. |
Ugh. @jrstarke, if they're sending a From the MDN docs on Content-Encoding:
Image builder is acting correctly here. The original site needs to drop the |
@dacut - whether Image Builder is acting correctly due to the content encoding of the source, or not, we've treated this as a bug. It's painful and customers shouldn't have to deal with this. @jrstarke - This is now resolved. The following component YAML will now run with success with the latest versions of the AWSTOE binary (published within Image Builder and to the S3 Buckets outlined in the AWSTOE Downloads section of the service documentation). schemaVersion: 1.0
phases:
- name: build
steps:
- name: download
action: WebDownload
inputs:
- source: https://www.pdflib.com/binaries/PDFlib/1001/PDFlib-10.0.1-Linux-x64-php.tar.gz
destination: /tmp/PDFlib-10.0.1-Linux-x64-php.tar.gz
algorithm: SHA256
checksum: 31c589c76d96965ddeec3e3d89c0bf5322513dbe3f523dcc8d2352c6167cdc71 |
@austoonz - The edge case you may have to deal with is potentially accepting multiple checksums (for the While raw |
@dacut - definitely good to know for sure, thank you. I'll note this to the team for awareness for now. I'd imagine the use-cases for WebDownload are far more likely to download At least there is still the workaround to use curl or wget directly for any scenario where WebDownload isn't working as intended. |
Community Note
Tell us about your request
What do you want us to build?
WebDownload checksum algorithms that are consistent with those of shasum.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
I'm trying to ensure that the artifacts that I'm downloading as part of my build are consistent with those I expect and haven't been tampered with. The SHA256 algorithm consistently yields different results than
sha256sum
does for the same artifact.Are you currently working around this issue?
How are you currently solving this problem?
Run the image recipe once, wait for it to fail, get the checksum that it has for the same resource and feed it back in. This doesn't inspire trust in the resources though, as I can't verify that it's actually getting the same thing I'm getting.
Additional context
Anything else we should know?
Wrote this up on Re:Post
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
The text was updated successfully, but these errors were encountered: