I fear the proposed change would not improve security but lower it: if the pom contains the reference to a key "to be used to sign the artifact", anybody wanting to change the content will just change the key reference to a value it owns
yes, knowing which keys you should trust to sign which artifact is not easy, but I fear there is no automagic way to automate trust What I'd want to do is to improve the dependencies report to show the key used to sign the artifact: that would improve people knowledge of who they are trusting: but that would not mean that they can trust them... Regards, Hervé Le lundi 5 décembre 2016, 09:31:20 CET Alexander Kjäll a écrit : > Regarding verifying the gpg signature, as a contributor to the gpg > verify plugin here: > > http://www.simplify4u.org/pgpverify-maven-plugin/index.html > > I have some thoughts on why the current infrastructure doesn't really > help us to verify the signatures in practice: > > 1) Very hard to know what key are the correct one, as it's not specified > anywhere in the pom, you need to contact the developer of the jar that > you want to verify and ask them to publish what key they used to sign > the project with. It would be nice to have a <signed-by> tag in the pom > in order to resolve this. > > 2) Verifying the signature can't really be done with a maven plugin, as > those are downloaded over the same channels that the jar's are > downloaded over, and there is no method for maven to verify that it > downloaded the correct plugin. > > I opened a bug about this problem a couple of years ago, but since it's > not really possible to fix this without changing the structure of the > pom i didn't even bother to write a patch for it. > > If there is a chance that a fix for this problem would be included, then > I would be happy to try to write a patch for it. > > best regards > Alexander Kjäll > > On 05. des. 2016 08:23, Hervé BOUTEMY wrote: > > AFAIK, checksums are there only to avoid stupid download/upload > > distorsion. > > What gives real security is *signature* done by developers, ie .asc files, > > that use other hash algorithms than these little .md5 and .sha1 files. > > That's why we recommend to verify *the signature* [1]. > > > > Another topic: https://www.apache.org/dev/release-signing.html is not > > about > > Maven repository but is about Apache releases that are distributed as part > > of Apache official (source) releases, distributed by Apache mirrors [2] > > > > AFAIK, security is taken seriously: checksums are just not really part of > > that security, they are only checksums. > > > > Regards, > > > > Hervé > > > > [1] http://maven.apache.org/download.cgi > > > > [2] https://www.apache.org/mirrors/ > > > > Le lundi 5 décembre 2016, 00:56:22 CET John Patrick a écrit : > >> Hiya, > >> > >> So currently checksum's are not generated by default... I've submitted > >> a ticket which switched the install plugin to generate them by > >> default. > >> > >> Next step stop using md5 which most have considered dead for several > >> years, and checking apache > >> (https://www.apache.org/dev/release-signing.html) sha512 should be > >> being used. > >> > >> So either; > >> 1) add support so md5, sha1, sha256 and sha512 are all generated > >> 2) plugin defines which is generated > >> 3) plugin defines a list which are generated > >> 4) settings.xml defines which is generated > >> 5) settings.xml defines a list which are generated? > >> > >> Thoughts??? > >> > >> Next; > >> Currently when downloading we have ignore, warn or error if checksum's > >> don't match. I propose adding a checksum min level options? i.e. allow > >> MD5 > SHA1, SHA256 > SHA512 > >> > >> So; > >> 1) Default to MD5 > >> 2) Wait till all maven plugins deploy a sha512 to central > >> 3) Switch default to SHA512 > >> > >> What are developers thoughts? > >> What staged steps should this be merged as? > >> > >> I would like to start helping getting the core maven and all of it's > >> dependencies more secure so people can start trusting maven is secure > >> by default as I get the feeling isn't at the moment. > >> > >> Cheers, > >> John > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
