3 ms·

Treating PGP signed commits as privileged and only pointing at them as opposed to mutable tags seems like it would help.

dathinab 5y ago
I'm not sure it's actually possible, for varying reasons. Even if we ignore that cargo can be used with other version control systems I see some problems: - Validation must be done server side as everything the client does can be manipulated. - So the server would need to be able to make sure that some signature is valid for some commit. - But you don't upload commits, you uploads a sub-set of the checkout produced by the combination of the current commit and previous commits. - Uploading all of the diff of the current (or previous) commit is a no-go for various reasons (size, leaking internal code etc.). - Similar even if it would work, the repository on GitHub could still contains different code, the signature might not match, but who is checking the signature? The reviewer manually? What you maybe could do is e.g. signing the uploaded archive which in combination with e.g. a Yubikey would make it harder for attackers to upload malicious packages (if the authors aren't the attackers). You also could include some version id (e.g. git hash) in the signature, then review tools could check that the uploaded code matches the GitHub repository. But really the most important thing is to review the code you actually use (e.g. what is uploaded to crates.io) and not what you belive you probably should be using.
- rectang 5y ago
  In the abstract, what I'm wishing for is definitely possible at least for some subset of packages. • Source code packages are cryptographically signed by at least one and ideally several identities which are verifiable via a web of trust. • Packages are associated with a public repository base URL known to the package manager and that base URL doesn't change without setting off alarm bells. • The source code of a package can be traced back and cryptographically connected to a public commit history at the public repository URL.

dathinab 5y ago

I'm not sure it's actually possible, for varying reasons. Even if we ignore that cargo can be used with other version control systems I see some problems: - Validation must be done server side as everything the client does can be manipulated. - So the server would need to be able to make sure that some signature is valid for some commit. - But you don't upload commits, you uploads a sub-set of the checkout produced by the combination of the current commit and previous commits. - Uploading all of the diff of the current (or previous) commit is a no-go for various reasons (size, leaking internal code etc.). - Similar even if it would work, the repository on GitHub could still contains different code, the signature might not match, but who is checking the signature? The reviewer manually? What you maybe could do is e.g. signing the uploaded archive which in combination with e.g. a Yubikey would make it harder for attackers to upload malicious packages (if the authors aren't the attackers). You also could include some version id (e.g. git hash) in the signature, then review tools could check that the uploaded code matches the GitHub repository. But really the most important thing is to review the code you actually use (e.g. what is uploaded to crates.io) and not what you belive you probably should be using.

rectang 5y ago
In the abstract, what I'm wishing for is definitely possible at least for some subset of packages. • Source code packages are cryptographically signed by at least one and ideally several identities which are verifiable via a web of trust. • Packages are associated with a public repository base URL known to the package manager and that base URL doesn't change without setting off alarm bells. • The source code of a package can be traced back and cryptographically connected to a public commit history at the public repository URL.