Clarify distribution security requirements#440
Conversation
funnelfiasco
force-pushed
the
fix-artifact-download
branch
from
69e5c09 to
abcef0c
Compare
| that channel MUST be protected from adversary-in-the-middle | ||
| attacks. |
There was a problem hiding this comment.
- What is the functional difference between the old and new text?
- If there is value added by this, why isn't
BR-03.01also changed to get the same value?
There was a problem hiding this comment.
(Sorry, put this in a box for a while since we didn't have a meeting.)
-
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.
-
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>
Co-authored-by: Ben Cotton <bcotton@funnelfiasco.com> Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
funnelfiasco
force-pushed
the
fix-artifact-download
branch
from
18cf17b to
22fddb7
Compare
5 participants
As discussed in the 2025-11-25 meeting, correct the recommendation for OSPS-BR-03.02.