Project

Profile

Help

Task #8435

closed

Task #7960: FIPS and support for ALLOWED_CONTENT_CHECKSUMS

Remove checksum filtering in Remote.get_downloader and add checksum type enforcement to downloaders itself

Added by bmbouter about 3 years ago. Updated about 3 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Sprint:
Sprint 93
Quarter:

Description

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.

  2. The Remote.get_downloader will filter out the checksums on an Artifact to only those that are allowed. That happens here.

  3. The DeclarativeArtifact.download also filters checksums. That occurs here.

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) 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 have it pass all original checksums unmodified to the downloader.

Also available in: Atom PDF