You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Patrick <nh...@gmail.com> on 2016/12/05 00:56:22 UTC
Taking Security Seriously
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Alexander Kjäll <al...@gmail.com>.
Hi
The attack scenario that I'm trying to guard against is the following:
Stopping an attacker that manages to exploit the our nexus server from
being able to run arbitrary code on all the build servers and developer
machines in our organization.
best regards
Alexander Kj�ll
On 06. des. 2016 13:25, Tibor Digana wrote:
> What real problem is behind your question?
> Are you running any tool which has a problem with signatures in Nexus or
> the development process in your company has a problem?
>
> The MD5 is not security nothing but verification of deployed artifact is
> identical binary you have downloaded from Nexus, and however GnuPG *.asc is
> the real signature of deployer and the KEYS can be found in Apache projects
> if really necessary.
>
> You should be always able to verify gpg signatures via (gpg --verify
> your-artifact-file.sig your-artifact-file) without adding (<signed-by
> algoritm="sha256">XXX</signed-by>) in POM.
>
>
> On Mon, Dec 5, 2016 at 1:56 AM, John Patrick <nh...@gmail.com> wrote:
>
>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Tibor Digana <ti...@apache.org>.
What real problem is behind your question?
Are you running any tool which has a problem with signatures in Nexus or
the development process in your company has a problem?
The MD5 is not security nothing but verification of deployed artifact is
identical binary you have downloaded from Nexus, and however GnuPG *.asc is
the real signature of deployer and the KEYS can be found in Apache projects
if really necessary.
You should be always able to verify gpg signatures via (gpg --verify
your-artifact-file.sig your-artifact-file) without adding (<signed-by
algoritm="sha256">XXX</signed-by>) in POM.
On Mon, Dec 5, 2016 at 1:56 AM, John Patrick <nh...@gmail.com> wrote:
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Taking Security Seriously
Posted by Martin Gainty <mg...@hotmail.com>.
________________________________
From: Bernd Eckenfels <ec...@zusammenkunft.net>
Sent: Monday, December 5, 2016 5:10 PM
To: Maven Developers List
Subject: Re: Taking Security Seriously
Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is not what .md5 or .asc is used for.
Gruss
Bernd
--
http://bernd.eckenfels.net
On Mon, Dec 5, 2016 at 10:45 PM +0100, "Alexander Kjäll" <al...@gmail.com> wrote:
Maybe we are talking about different attack scenarios?
The vector I would like to protect against is that someone is able to
inject false binaries in a caching nexus server (or over the network
if https is not used).
The way I envision the trust to be established is:
The developer goes either to maven central or the projects homepage
and copies the block needed to add the dependency to
pom.xml. The dependency block includes information that can be used to
cryptographically guarantee that the binary that ends up in the build
is the same one that the original developer published.
I think it would be possible to simplify the verification of gpg
signatures and make it be possible to automate it in a resonable
manner.
MG>Sign project artifact, the POM, and attached artifacts with GnuPG for deployment is implemented via maven-gpg-plugin:sign (where default binding for maven-gpg-plugin is verify phase)
http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html
Apache Maven GPG Plugin – gpg:sign<http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html>
maven.apache.org
gpg:sign. Full name: org.apache.maven.plugins:maven-gpg-plugin:1.6:sign. Description:
best regards
Alexander Kjäll
2016-12-05 18:29 GMT+01:00 Hervé BOUTEMY :
> 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 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
Signing Releases - Apache Software Foundation<https://www.apache.org/dev/release-signing.html>
www.apache.org
Abstract¶ This document gives a basic primer on the wide subject of release signing. See under Further reading for links to authoritative sources of deeper information.
>> > 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
Apache Download Mirrors - Apache Maven<http://maven.apache.org/download.cgi>
maven.apache.org
We suggest the following mirror site for your download: http://apache.mirrors.lucidnetworks.net/ Other mirror sites are suggested below. Please use the backup mirrors ...
>> >
>> > [2] https://www.apache.org/mirrors/
the status of all apache mirrors<https://www.apache.org/mirrors/>
www.apache.org
each unit represents 2.0 mirror sites. legend project site -- home project site is an url. The href is the href for the site in the list of mirrors, usually the root ...
>> >
>> > 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
Signing Releases - Apache Software Foundation<https://www.apache.org/dev/release-signing.html>
www.apache.org
Abstract¶ This document gives a basic primer on the wide subject of release signing. See under Further reading for links to authoritative sources of deeper information.
>> >> 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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Alexander Kjäll <al...@gmail.com>.
This is a a good idea, and a hash it would serve roughly as good as
specifying the key i think, it would maybe even be better since it's
easier to generate a hash.
It might be wise to plan for the future, as what ever hash algorithm
that is considered best practice today will be broken and useless at
some point in the future.
maybe something like this:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<signed-by algoritm="sha256">XXX</signed-by>
</dependency>
And having the signed-by element be legal to specify 0-N times, so that
it's possible to add multiple versions of it but not required.
I understand that .md5 files isn't used to verify that the downloaded
artifact isn't controlled by an attacker, but at least I use the .asc
files for that. Do you mean that they also have some other purpose?
best regards
Alexander Kj�ll
On 05. des. 2016 23:10, Bernd Eckenfels wrote:
> Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is not what .md5 or .asc is used for.
>
> Gruss
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is not what .md5 or .asc is used for.
Gruss
Bernd
--
http://bernd.eckenfels.net
On Mon, Dec 5, 2016 at 10:45 PM +0100, "Alexander Kjäll" <al...@gmail.com> wrote:
Maybe we are talking about different attack scenarios?
The vector I would like to protect against is that someone is able to
inject false binaries in a caching nexus server (or over the network
if https is not used).
The way I envision the trust to be established is:
The developer goes either to maven central or the projects homepage
and copies the block needed to add the dependency to
pom.xml. The dependency block includes information that can be used to
cryptographically guarantee that the binary that ends up in the build
is the same one that the original developer published.
I think it would be possible to simplify the verification of gpg
signatures and make it be possible to automate it in a resonable
manner.
best regards
Alexander Kjäll
2016-12-05 18:29 GMT+01:00 Hervé BOUTEMY :
> 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 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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Alexander Kjäll <al...@gmail.com>.
Maybe we are talking about different attack scenarios?
The vector I would like to protect against is that someone is able to
inject false binaries in a caching nexus server (or over the network
if https is not used).
The way I envision the trust to be established is:
The developer goes either to maven central or the projects homepage
and copies the <dependency> block needed to add the dependency to
pom.xml. The dependency block includes information that can be used to
cryptographically guarantee that the binary that ends up in the build
is the same one that the original developer published.
I think it would be possible to simplify the verification of gpg
signatures and make it be possible to automate it in a resonable
manner.
best regards
Alexander Kjäll
2016-12-05 18:29 GMT+01:00 Hervé BOUTEMY <he...@free.fr>:
> 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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Alexander Kjäll <al...@gmail.com>.
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 Kjll
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 dcembre 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Taking Security Seriously
Posted by Anders Hammar <an...@hammar.net>.
My view is that the artifact checksums deployed have nothing to do with
security, but just a way for Maven to verify that the download was ok. It's
not verifying that it's the *correct* (valid) artifact that was downloaded.
The apache link you're refering to talks about release signatures, not
artifact checksum files. md5 or sha1 should be suifficient for artifact
checksums.
/Anders
On Mon, Dec 5, 2016 at 1:56 AM, John Patrick <nh...@gmail.com> wrote:
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>