Task #8435
Updated by bmbouter over 3 years ago
## Current behavior 1) The downloaders don't have any capability to only use those checksums that are in `ALLOWED_CONTENT_CHECKSUMS`. This usage happens [here](https://github.com/pulp/pulpcore/blob/master/pulpcore/download/base.py#L97). 2) The `Remote.get_downloader` will filter out the checksums on an Artifact to only those that are allowed. That happens [here](https://github.com/pulp/pulpcore/blob/e7af85214c107e836bb42885b6f9d07958cb7629/pulpcore/app/models/repository.py#L352). 3) The `DeclarativeArtifact.download` also filters checksums. That occurs [here](https://github.com/pulp/pulpcore/blob/15e7e587ffe616797cb255a35087c4506a21662e/pulpcore/plugin/stages/models.py#L77-L86). ## The First Issue (1) is an issue because the downloaders can be used directly and as-is they won't respect the `ALLOWED_CONTENT_CHECKSUMS` feature. ## Solution to the first Issue The downloader code should be adjusted to only use those checksums in `ALLOWED_CONTENT_CHECKSUMS`. If any checksums are specified (trusted or not), at least one trusted hasher must be available or an exception should be raised. If no checksums are requested the downloader should be allowed to proceed because some content does not have checksums, e.g. the very first metadata file fetched, or ruby content. ## The second problem By (2)(3) (2) filtering out checksums, it could misrepresent the set of checksums to the downloader as being an empty set when really checksums exist but no trusted checksums exist. ## Solution to the second problem Remove the filtering done in `Remove.get_downloader` and `DeclarativeArtiface.download`. Instead instead have it pass all original checksums unmodified to the downloader.
.