Comments on the Maven Repository Security Proposal
For those of you who don't know, Maven is an awesome build tool. It uses centralized repositories to share build artifacts. Right now there is a problem, where if a repository is hacked, malicious code could be injected into those artifacts and distributed by other builds. Lots of folks object to using maven solely due to this possibility. It's a good thing that the maven teams seems to be working on fix those problems.
First off, I love the Maven Repository Security Proposal. I think that the 'Specified Checksums' idea is awesome. I think it needs to be made so easy to use that folks always use it. Right now it's a little ugly because it makes the dependency declaration much more verbose. Plus it does not seem to cover transitive dependencies that are being used during the build, and I think that those checksums NEED to be included too.
I think that what would be better is if maven provided the tools to update the checksum information in the pom.
Lets say that a build for a module is setup in some strict mode where only artifacts with known checksums are allowed. If the pom is updated to add a new dependency, I think there should be some maven command which automatically adds the checksum for the new dependency (and transitive dependencies). Artifacts that are signed with a trusted key get added without prompting, and a confirmation prompt would be given for artifacts that are not GPG trusted.
So the question is why go through all that trouble? So that folks get a trusted source distribution (out of SCM or a signed tar ball), can do a build and have a high level of guarantee that the dependencies that are being used in the source build match what was intended by the developers of the source distribution. Furthermore, it will not matter if the transitive dependencies are signed and have keys in the end user's keyring since all the checksums are include in the build.
Now, since there could be lots of dependencies in a build, due to the use of build plugins and transitive dependencies, it might be worth storing the checksum data in a file external to pom.xml, or at least in a different xml section from the dependencies declaration.
Things to think about: Having SNAPSHOT dependencies in the build could complicate things, as the build would be tied to a particular SNAPSHOT/checksum, but maybe that's a good thing.
First off, I love the Maven Repository Security Proposal. I think that the 'Specified Checksums' idea is awesome. I think it needs to be made so easy to use that folks always use it. Right now it's a little ugly because it makes the dependency declaration much more verbose. Plus it does not seem to cover transitive dependencies that are being used during the build, and I think that those checksums NEED to be included too.
I think that what would be better is if maven provided the tools to update the checksum information in the pom.
Lets say that a build for a module is setup in some strict mode where only artifacts with known checksums are allowed. If the pom is updated to add a new dependency, I think there should be some maven command which automatically adds the checksum for the new dependency (and transitive dependencies). Artifacts that are signed with a trusted key get added without prompting, and a confirmation prompt would be given for artifacts that are not GPG trusted.
So the question is why go through all that trouble? So that folks get a trusted source distribution (out of SCM or a signed tar ball), can do a build and have a high level of guarantee that the dependencies that are being used in the source build match what was intended by the developers of the source distribution. Furthermore, it will not matter if the transitive dependencies are signed and have keys in the end user's keyring since all the checksums are include in the build.
Now, since there could be lots of dependencies in a build, due to the use of build plugins and transitive dependencies, it might be worth storing the checksum data in a file external to pom.xml, or at least in a different xml section from the dependencies declaration.
Things to think about: Having SNAPSHOT dependencies in the build could complicate things, as the build would be tied to a particular SNAPSHOT/checksum, but maybe that's a good thing.
posted by Hiram Chirino at
4:07 PM
2 Comments:
As long as Maven does not match the support of dpkg/apt to do clean builds from source code alone, it's all largely pointless - any binary dependency could be trojaned in its current state in the current maven repositories without anyone actually being able to detect it, since you can't just rebuild the maven artifacts from scratch to verify that what you get is what you think you're getting, as you can do with a useful system build on source code.
It's fundamentally broken from a security POV, as long as you decide to carry the current repository over into the future, and not start from scratch from source.
By
robilad, At
7:10 PM
Thanks for the comments Hiram! I certainly agree. Here a few responses:
* I agree tooling is the best way to populate the checksums. This may be a good operation to incorporate into the release plugin, though it would hopefully usable for those not using it as well.
* I think by having the GPG mechanism used when the checksum is not present, you already can achieve what you were suggesting about this without any explicit coupling.
* An enforcer rule would be a good way to ensure checksums are specified for all dependencies, like versions are today.
* I think keeping the syntax in the POM is ok (perhaps it needs to be less verbose though). Hopefully, your transitive dependencies would already have their checksums specified, and if not you can use dependencyManagement to apply it - much like versions today.
* I believe by default you can ignore the requirement to specify these for snapshots, as you expect them to be updated. But you can still use them if they are present (especially useful if you intend to pin to a particular version)
I'll update the proposal :)
By
brettporter, At
1:01 AM
Post a Comment
<$I18N$LinksToThisPost>:
Create a Link
<< Home