-
Notifications
You must be signed in to change notification settings - Fork 116
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
content-app will fully stream a file to the user before doing any checksum verification #5012
Comments
Try closing the connection before sending the last chunk on the digest error. |
We discussed this more on this on the last week's rpm meeting. Some key notes: Close connection
Stream Design vs More Consistent Error responses
The client may have to wait very long (and possibly close the conn on their side) if we try every remote before starting a response (on a bad case where we have to try a bunch). Also, as stated above, we can't really provide a reasonably good error message in http standards, and we can't even tell if it's a transient problem or not. Avoid resource wastingWe may still conder trying something to address
Better Error on Logs for admins/supportPost meeting though: if we close the conn, the admins or support will probably look at pulp logs.
|
Assuming we want to keep our stream-redirect approach on the content-app, We cant recover from wrong data already sent if the Remote happens to be corrupted (contains wrong binaries). In order to not give a 200 reponse to client, we decided to close the connection as soon as the request handler realizes the checksum is wrong. That only happens after we already sent the whole blob minus EOF, so we close the connection before sending the EOF. fixes pulp#5012
Version
Any
Describe the bug
In the event that a file pointed to by a remote artifact is changed but left in place (i.e. doesn't 404) and no longer represents the original file (different checksums), the content app will still stream the file in its entirety back to the client before pulp verifies the checksum, which it does when saving the file to artifact storage.
An error message will be printed when this fails, but at this point, the wrong file has already been delivered.
Correct behavior in this situation is actually a bit ambiguous because the chance to download the original copy of the file is probably gone now that it has been replaced at the upstream source. And there's no HTTP status code for "checksum validation failed", so the best we could do might be HTTP status code 404 or 410.
To Reproduce
Example of a small repository, easy to create on localhost:
create a repository that will sync from http://localhost/pub/repo/ and sync it:
Change the content of the rpmfile bear-4.1-1.noarch.rpm from the upstream (on localhost) repository. Ensure the checksum of the file changed!!
Actual results:
Client receives a bad file and no errors.
Pulpcore-content logs errors when saving the artifact:
Expected behavior
Well, presumably if the upstream file has changed out from under us, then the chance to download the original is gone, so probably an HTTP status code 404 or 410?
Additional context
https://bugzilla.redhat.com/show_bug.cgi?id=2262110
The text was updated successfully, but these errors were encountered: