Skip to content

Clarify distribution security requirements#440

Open
evankanderson wants to merge 3 commits intoossf:mainfrom
evankanderson:fix-artifact-download
Open

Clarify distribution security requirements#440
evankanderson wants to merge 3 commits intoossf:mainfrom
evankanderson:fix-artifact-download

Conversation

@evankanderson
Copy link
Contributor

As discussed in the 2025-11-25 meeting, correct the recommendation for OSPS-BR-03.02.

puerco
puerco previously approved these changes Nov 25, 2025
funnelfiasco
funnelfiasco previously approved these changes Nov 25, 2025
evankanderson and others added 2 commits December 12, 2025 14:50
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Co-authored-by: Ben Cotton <bcotton@funnelfiasco.com>
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Comment on lines 224 to 225
that channel MUST be protected from adversary-in-the-middle
attacks.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. What is the functional difference between the old and new text?
  2. If there is value added by this, why isn't BR-03.01 also changed to get the same value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Sorry, put this in a box for a while since we didn't have a meeting.)

  1. The old text required that the content was delivered using an encrypted channel, but the actual intent was that the content was delivered in a signed or otherwise authenticated manner. This could include delivery via HTTP or FTP with e.g. a PGP signature which was checked against an existing (local) key, as many Linux distributions were originally designed to do.

  2. BR-03.01's "official project channels" doesn't have existing prior art (RPM / DEB / etc ecosystems) which was designed for secure distribution prior to the widespread adoption of TLS. While HTTPS is a simple way to meet BR-03.02's requirements, there are existing systems which meet the requirements without the use of HTTPS which we're not looking to exclude. BR-03.01 does not have a comparable existing ecosystem that I'm aware of.

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants