Comments on: Comments on the Maven Repository Security Proposal http://hiramchirino.com/blog/2008/07/comments-on-the-maven-repository-security-proposal/ My Ramblings on Hawt Tech Sat, 04 Feb 2012 07:19:34 +0000 hourly 1 http://wordpress.org/?v=3.1 By: brettporter http://hiramchirino.com/blog/2008/07/comments-on-the-maven-repository-security-proposal/comment-page-1/#comment-24 brettporter Tue, 29 Jul 2008 05:01:00 +0000 http://hiramchirino.com/wordpress/2008/07/comments-on-the-maven-repository-security-proposal/#comment-24 Thanks for the comments Hiram! I certainly agree. Here a few responses:<br/>* 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.<br/>* 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.<br/>* An enforcer rule would be a good way to ensure checksums are specified for all dependencies, like versions are today.<br/>* 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.<br/>* 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)<br/><br/>I'll update the proposal :) 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: robilad http://hiramchirino.com/blog/2008/07/comments-on-the-maven-repository-security-proposal/comment-page-1/#comment-23 robilad Mon, 28 Jul 2008 23:10:00 +0000 http://hiramchirino.com/wordpress/2008/07/comments-on-the-maven-repository-security-proposal/#comment-23 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.<br/><br/>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. 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.

]]>