package-trust
package-trust copied to clipboard
more of a question
First off - I like that someone is looking at the problem and trying to find issues.
Once a package version has been signed - what is to say that the contents of a package are the same as the contents that were analysed? - for example what if a something managed to get in the middle of the auditor and package? (excuse crude ascii art)
+-------------------+
| |
| |
+-------------+ | Package Server |
+-----------+ | | | |
| | | | +--+------+ |
| Auditor | <----------------------+ | Interceptor | <--------------------+ | Package | |
| | | | +--+------+ |
+-----------+ | | | |
+-------------+ | |
| |
| |
+-------------------+
+----------------------------------------------------------------------------------------------------------+
Auditors would create pull requests for this repository with a signature. But what happens if the Interceptor now serves malevolent content after approval?
+-------------------+
| |
| |
+-------------+ | Package Server |
+-----------+ | | | |
| | | | +--+------+ |
| Auditor | <----------------------+ | Interceptor | <--------------------+ | Package | |
| | +----------+-+ | +--+------+ |
+-----------+ |Package With| | | |
|Malware +-------------+ | |
| | | |
+------------+ | |
+-------------------+
+----------------------------------------------------------------------------------------------------------+
maybe the signature should contain information about the content - some form of signature that can be checked to ensure that the content hasn't changed.
This might be something that you already thought about - I only looked at the readme file so this might be a more concrete implementation thing that has already be thought about.
I can see in the signature that there's an SHA hash for the ~victim~ volunteer does have a sha hash.
That's correct - the audit signature will contain a sha-512 hash of the .tgz of the package that was audited.
This is a sub-problem of reproducible builds. This is probably easier with source-code tarballs then with compiled code. But the checked .tgz
files should be reproducible before any attempts at attesting them would occur.
https://reproducible-builds.org/docs/sharing-certifications/
Fortunately, most npm packages aren't really built, theyre simply bundled - so the contents of the tarballs are mostly just the source code itself. For minified/transpiled code etc., it would make sense to audit the original source code, run a build, and verify that the hash of that build matches the published package.