-
Notifications
You must be signed in to change notification settings - Fork 15
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
Start v0.2 of Principles for Package Repository Security #38
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Zach Steindler <steiza@github.com>
Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim: Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..) Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time. Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust. |
The "Authorization" section says:
but I'm not sure that this section only applies to repositories that accept built packages, unless I'm misunderstanding something. Crates.io accepts source code, not built packages, but we definitely have API tokens for publishing that code, the tokens can have different permissions associated with them, and we integrate with GitHub's secret scanning. Perhaps this should say "Applies to: package repositories that have user accounts with associated API tokens, especially if the repository accepts built packages" or similar? |
General Capabilities Level 1 has this guideline:
which is for the security policy of the package registry itself. The registry could also be surfacing information in its UI about the security/vulnerability policy of each package. For example, this issue is where we're discussing possible improvements to crates.io's UI to display security information about each package. I think this would be a useful guideline to add, perhaps in Level 2 as it feels similar to "The package repository warns of known security vulnerabilities in dependencies in the package repository UI" to me? |
Thank you to the authors for putting this set of Principles out! An aspect of package security that I did not see, but may have missed, relates to containing, and protecting users from, malware or malicious/rogue code that makes it through. Here's how the FreeBSD package management system does it. (All of this is BSD licensed so, with porting, should be replicable by others.)
|
Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc? |
(Note that there is some discussion about this on #40 as well) |
I'm curious about specifying TOTP for authentication, which if I understand correctly is based on shared symmetric secrets. A very sophisticated adversary might make use of this to circumvent authentication (by obtaining and using the database of secrets to impersonate authorized users). Perhaps SMS is in this regard superior, even though it isn't cryptographic. Maybe FIDO2 is a better recommendation? OAUTH2 with TOTP is intended to support delegation, not authentication, per se. Please kindly correct me if I'm mistaken. |
@phatgeek The current version of the doc does recommend WebAuthn (part of FIDO2) as a Level 2 principle:
The primary motivator here is that TOTP is phishable and WebAuthn is not, but I think the fact that TOTP requires storing secrets, while WebAuthn only requires storing public keys, would be a valid thing to include here as well. |
You want both imo. They are related but different things. |
Yes. I see how what I said was ambiguous. I completely agree with you. But transparency in package management often whitewashes the opacity of identities and veracity of code contributions. So we need to create accountability and transparency in both the code contributions (think gitops) and package management. Getting a Red Hat package that is signed by Red Hat seems great until you think about whether they pulled in their Rust crates with cargo (or their Python with PIP, or their JS with NPM, base container from Docker Hub,...) I want to know exactly where my code came from, and who submitted it, who they are, where they live, who they work for, and what they think about Travis Kelsey. |
Signed-off-by: Zach Steindler <steiza@github.com>
This is where we can collect feedback from the v0.1 release, as well as pick up feedback we didn't get to in #37.