[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/110
  
@jonenst 
Next week on Friday it should be already in Maven Central.
See the raod map [1]. We have last issue in good progress with 100% 
coverage of stream encoder and the only decoder is missing. I can push a new 
pull request to see the progress or commit directly.
[1] 
https://issues.apache.org/jira/browse/SUREFIRE/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Taking Security Seriously

[Martin Gainty]

From: Bernd Eckenfels 
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" 
 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
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
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
maven.apache.org
We suggest the following mirror site for your download: 
http://apache.mirrors.lucidnetworks.net/ Other mirror sites are suggested 

Re: Taking Security Seriously

[Bernd Eckenfels]

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" 
 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 

Re: Taking Security Seriously

[Alexander Kjäll]

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 

Re: [VOTE] Release Apache Maven Resources Plugin version 3.0.2

[Robert Scholte]

+1

On Mon, 05 Dec 2016 13:20:25 +0100, Christian Schulte   
wrote:



Hi,

We solved 3 issues:


There are still a couple of issues left in JIRA:


Staging repo:



Source release checksum(s):
maven-resources-plugin-3.0.2-source-release.zip sha1:
4b77d70fce42dbdc6382f57dff5635abe9c55cb1

Staging site:


Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.
[ ] +1
[ ] +0
[ ] -1


-
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

Re: POM 5: The problems with mixins

[Mark Derricutt]

On 6 Dec 2016, at 4:17, Jochen Wiedmann wrote:

> You have personal experience with a feature, that doesn't even exist?
> I am impressed...

I need to read thru this thread fully and write up a longer response - but 
we've been using the tiles plugin ( which myself and Richard Vowles took over ) 
to provide mixin like behaviour to Maven and despite a few minor teething 
issues, it works wonderfully.

The win - composition and reuse. The simple static inheritance chain doesn't 
really provide that.

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

[jonenst]

Github user jonenst commented on the issue:

https://github.com/apache/maven-surefire/pull/110
  
@Tibor17 Hi, thanks for the releases. Any idea of the release date ? Cheers.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Taking Security Seriously

[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-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

Re: POM 5: The problems with mixins

[Victor Nazarov]

Stephen,

One more slightly more abstract comment.

Your design document seems like a survey of current maven design.
I think it should be better to present several 3-4 current main pain points
and/or
much desired features at first and then show how each and every design
alteration provides for
achieving specified goals...

--
Victor Nazarov

On Mon, Dec 5, 2016 at 7:22 PM, Victor Nazarov 
wrote:

> I haven't been following your proposals. I have schemed through just now.
> I can say that I generally like some aspects of your proposal:
>
>  * build/artifact description split is a good thing.
>  * custom lifecycle declaration is great.
>  * building and reporting rejoin seems right
>
> I've fails to fully comprehend the idea behind inline template
> declarations.
> As I understand you what to provide a way to replace parant's or mixin's
> template
> with another. But I fail to see any motivation behind this decision.
>
> Another aspect that seems questionable is custom scopes...
> I've been using ivy-based build system recently and I think custom
> scopes don't pull their weight. I think there are very few use-cases
> for scopes other than maven's current scopes...
>
> What I'd like to contribute is that in my opinion templates should be
> defined
> by mojo's or plexus-components the same way plugins are defined and
> templates should have custom configuration.
> That way a company can define a FAMILY of lifecycles
> and a choice of one particular lifecycle depends
> on a specially crafted human readable configuration.
>
> Having configurable templates in place I think we don't need mixin's
> anymore...
>
> --
> Victor Nazarov
>
> On Mon, Dec 5, 2016 at 6:38 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Victor, have you been following my designs?
>> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>> https://cwiki.apache.org/confluence/display/MAVEN/Project+
>> Dependency+Trees+schema
>> and
>> https://cwiki.apache.org/confluence/display/MAVEN/Remote+
>> repository+layout ?
>>
>> On 5 December 2016 at 15:28, Victor Nazarov 
>> wrote:
>>
>> > I've been experimenting with profile-based system that is close to
>> mixins
>> > [1].
>> > Another existing maven extension for this is maven-tiles [2].
>> > I think your design is close to maven-tiles, so you can try to survey
>> it's
>> > developers to
>> > get feedback based on actual usage...
>> >
>> > Personally after my experiments with these systems I've come to a
>> > conclusion
>> > that mixins is wrong direction.
>> > I envision that the best solution to all my use-cases is configurable
>> > lifecycle/lifecycle-mapping [3].
>> > Configurable lifecycle should be like a collection of mixins defined in
>> > single module and thus guaranteed
>> > to work seamlessly with each-other. Mixin selection/activation mechanism
>> > should also be defined in
>> > configurable-lifecycle component and can be made as ergonomic as needed
>> > using custom configuration
>> > same way configuration is used by mojos.
>> >
>> > [1]
>> > https://github.com/sviperll/ozymandias/tree/master/maven-
>> > profiledep-extension
>> > [2] https://github.com/repaint-io/maven-tiles
>> > [3] https://issues.apache.org/jira/browse/MNG-6129
>> >
>> > --
>> > Victor Nazarov
>> >
>> > On Mon, Dec 5, 2016 at 1:56 AM, Stephen Connolly <
>> > stephen.alan.conno...@gmail.com> wrote:
>> >
>> > > I'm currently trying to figure out how to make mixins possible in POM
>> 5.
>> > >
>> > > Mixins basically bring a form of multiple inheritance to the POM...
>> which
>> > > leads to the problems of how to solve conflicts.
>> > >
>> > > Inheritance Style
>> > > =
>> > >
>> > > The first problem I hit was how to actually deal with a parent that
>> > > declares some mixins and a child that declares other mixins where
>> those
>> > > mixins declare some of the same mixins from the parent but different
>> > > versions... yes a some what esoteric edge case... but we can rest
>> assured
>> > > that users will hit this.
>> > >
>> > > I see two solutions to that problem:
>> > >
>> > > Option A: each project is consumed as its effective-pom (i.e. the
>> mixins
>> > > are merged before we consider application)
>> > > Option B: each project is treated as a graph of its mixins, then to
>> apply
>> > > inheritance we do conflict resolution on the versions, pick the
>> "nearest"
>> > > version, prune out the subtrees of the "loser" versions and away we
>> go.
>> > >
>> > > Option B feels like the more "correct" option... but heck I cannot
>> even
>> > > describe it well so how on earth are users to understand it.
>> > >
>> > > Thus, in the interests of simplifying life for users I am proceeding
>> with
>> > > the Option A approach... if that means that your parent has declared
>> the
>> > > myfaces-app:2.3 mixin and the child declares a tomee-web:3.0 mixin and
>> > that
>> > > mixin happens to include 

Re: POM 5: The problems with mixins

[Victor Nazarov]

I haven't been following your proposals. I have schemed through just now.
I can say that I generally like some aspects of your proposal:

 * build/artifact description split is a good thing.
 * custom lifecycle declaration is great.
 * building and reporting rejoin seems right

I've fails to fully comprehend the idea behind inline template declarations.
As I understand you what to provide a way to replace parant's or mixin's
template
with another. But I fail to see any motivation behind this decision.

Another aspect that seems questionable is custom scopes...
I've been using ivy-based build system recently and I think custom
scopes don't pull their weight. I think there are very few use-cases
for scopes other than maven's current scopes...

What I'd like to contribute is that in my opinion templates should be
defined
by mojo's or plexus-components the same way plugins are defined and
templates should have custom configuration.
That way a company can define a FAMILY of lifecycles
and a choice of one particular lifecycle depends
on a specially crafted human readable configuration.

Having configurable templates in place I think we don't need mixin's
anymore...

--
Victor Nazarov

On Mon, Dec 5, 2016 at 6:38 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Victor, have you been following my designs?
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
> https://cwiki.apache.org/confluence/display/MAVEN/
> Project+Dependency+Trees+schema
> and
> https://cwiki.apache.org/confluence/display/MAVEN/Remote+repository+layout
> ?
>
> On 5 December 2016 at 15:28, Victor Nazarov 
> wrote:
>
> > I've been experimenting with profile-based system that is close to mixins
> > [1].
> > Another existing maven extension for this is maven-tiles [2].
> > I think your design is close to maven-tiles, so you can try to survey
> it's
> > developers to
> > get feedback based on actual usage...
> >
> > Personally after my experiments with these systems I've come to a
> > conclusion
> > that mixins is wrong direction.
> > I envision that the best solution to all my use-cases is configurable
> > lifecycle/lifecycle-mapping [3].
> > Configurable lifecycle should be like a collection of mixins defined in
> > single module and thus guaranteed
> > to work seamlessly with each-other. Mixin selection/activation mechanism
> > should also be defined in
> > configurable-lifecycle component and can be made as ergonomic as needed
> > using custom configuration
> > same way configuration is used by mojos.
> >
> > [1]
> > https://github.com/sviperll/ozymandias/tree/master/maven-
> > profiledep-extension
> > [2] https://github.com/repaint-io/maven-tiles
> > [3] https://issues.apache.org/jira/browse/MNG-6129
> >
> > --
> > Victor Nazarov
> >
> > On Mon, Dec 5, 2016 at 1:56 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > I'm currently trying to figure out how to make mixins possible in POM
> 5.
> > >
> > > Mixins basically bring a form of multiple inheritance to the POM...
> which
> > > leads to the problems of how to solve conflicts.
> > >
> > > Inheritance Style
> > > =
> > >
> > > The first problem I hit was how to actually deal with a parent that
> > > declares some mixins and a child that declares other mixins where those
> > > mixins declare some of the same mixins from the parent but different
> > > versions... yes a some what esoteric edge case... but we can rest
> assured
> > > that users will hit this.
> > >
> > > I see two solutions to that problem:
> > >
> > > Option A: each project is consumed as its effective-pom (i.e. the
> mixins
> > > are merged before we consider application)
> > > Option B: each project is treated as a graph of its mixins, then to
> apply
> > > inheritance we do conflict resolution on the versions, pick the
> "nearest"
> > > version, prune out the subtrees of the "loser" versions and away we go.
> > >
> > > Option B feels like the more "correct" option... but heck I cannot even
> > > describe it well so how on earth are users to understand it.
> > >
> > > Thus, in the interests of simplifying life for users I am proceeding
> with
> > > the Option A approach... if that means that your parent has declared
> the
> > > myfaces-app:2.3 mixin and the child declares a tomee-web:3.0 mixin and
> > that
> > > mixin happens to include myfaces-app:2.5 then the child pom will have
> > both
> > > the myfaces-app:2.3 and myfaces-app:2.5 mixins applied... which may
> leave
> > > some "junk" that was in the myfaces-app:2.3 but removed from
> > > myfaces-app:2.5 present in the child pom... at least they can figure
> out
> > > where that "junk" is coming from and remove it from their own effective
> > pom
> > > or bump the parent.
> > >
> > > Thoughts?
> > >
> > > Inheritance Priority
> > > ==
> > >
> > > Mixins on their own are fine. Parents on their own are also fine...
> when
> > we
> > > have the two, how do we 

Re: POM 5: The problems with mixins

[Stephen Connolly]

Victor, have you been following my designs?
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
and
https://cwiki.apache.org/confluence/display/MAVEN/Remote+repository+layout ?

On 5 December 2016 at 15:28, Victor Nazarov 
wrote:

> I've been experimenting with profile-based system that is close to mixins
> [1].
> Another existing maven extension for this is maven-tiles [2].
> I think your design is close to maven-tiles, so you can try to survey it's
> developers to
> get feedback based on actual usage...
>
> Personally after my experiments with these systems I've come to a
> conclusion
> that mixins is wrong direction.
> I envision that the best solution to all my use-cases is configurable
> lifecycle/lifecycle-mapping [3].
> Configurable lifecycle should be like a collection of mixins defined in
> single module and thus guaranteed
> to work seamlessly with each-other. Mixin selection/activation mechanism
> should also be defined in
> configurable-lifecycle component and can be made as ergonomic as needed
> using custom configuration
> same way configuration is used by mojos.
>
> [1]
> https://github.com/sviperll/ozymandias/tree/master/maven-
> profiledep-extension
> [2] https://github.com/repaint-io/maven-tiles
> [3] https://issues.apache.org/jira/browse/MNG-6129
>
> --
> Victor Nazarov
>
> On Mon, Dec 5, 2016 at 1:56 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I'm currently trying to figure out how to make mixins possible in POM 5.
> >
> > Mixins basically bring a form of multiple inheritance to the POM... which
> > leads to the problems of how to solve conflicts.
> >
> > Inheritance Style
> > =
> >
> > The first problem I hit was how to actually deal with a parent that
> > declares some mixins and a child that declares other mixins where those
> > mixins declare some of the same mixins from the parent but different
> > versions... yes a some what esoteric edge case... but we can rest assured
> > that users will hit this.
> >
> > I see two solutions to that problem:
> >
> > Option A: each project is consumed as its effective-pom (i.e. the mixins
> > are merged before we consider application)
> > Option B: each project is treated as a graph of its mixins, then to apply
> > inheritance we do conflict resolution on the versions, pick the "nearest"
> > version, prune out the subtrees of the "loser" versions and away we go.
> >
> > Option B feels like the more "correct" option... but heck I cannot even
> > describe it well so how on earth are users to understand it.
> >
> > Thus, in the interests of simplifying life for users I am proceeding with
> > the Option A approach... if that means that your parent has declared the
> > myfaces-app:2.3 mixin and the child declares a tomee-web:3.0 mixin and
> that
> > mixin happens to include myfaces-app:2.5 then the child pom will have
> both
> > the myfaces-app:2.3 and myfaces-app:2.5 mixins applied... which may leave
> > some "junk" that was in the myfaces-app:2.3 but removed from
> > myfaces-app:2.5 present in the child pom... at least they can figure out
> > where that "junk" is coming from and remove it from their own effective
> pom
> > or bump the parent.
> >
> > Thoughts?
> >
> > Inheritance Priority
> > ==
> >
> > Mixins on their own are fine. Parents on their own are also fine... when
> we
> > have the two, how do we decide who wins.
> >
> > My current thinking is that there would be some parts of the model that
> can
> > only come from the parent: informational stuff, deployment stuff.
> >
> > But that should be a very small part of the model. We want mixins to be
> > able to contribute to the rest of the model.
> >
> > And here's the rub, in my parent I define some default conventions for
> > plugins, dependencies, etc... we then want the mixins to be able to bring
> > their best practices with them, so mixins need to be higher priority than
> > the parent... but we also want the parent to be able to enforce some
> > things.
> >
> > So say I want my parent to enforce that we only use myfaces for JSF. I
> may
> > have dependency management for various other jars... then the child
> brings
> > in some mixin and that mixin is directing all the JSF jars to the RI (not
> > because the mixin is focused on the RI, but because they wanted to align
> on
> > one thing)
> >
> > If mixins happen before parent, then some of the key rules of the mixin
> > will be defeated.
> > If mixins happen after parent, then the parent cannot enforce policy.
> >
> > I believe the enforcement of organizational policies is an important use
> > case for parent projects, but the quest for mixins that I have seen from
> > the JIRA is about being able to pull in configuration that has been
> tested
> > and should supercede the organizational *defaults*.
> >
> > I think the solution to this is to give the 

Re: POM 5: The problems with mixins

[Victor Nazarov]

I've been experimenting with profile-based system that is close to mixins
[1].
Another existing maven extension for this is maven-tiles [2].
I think your design is close to maven-tiles, so you can try to survey it's
developers to
get feedback based on actual usage...

Personally after my experiments with these systems I've come to a conclusion
that mixins is wrong direction.
I envision that the best solution to all my use-cases is configurable
lifecycle/lifecycle-mapping [3].
Configurable lifecycle should be like a collection of mixins defined in
single module and thus guaranteed
to work seamlessly with each-other. Mixin selection/activation mechanism
should also be defined in
configurable-lifecycle component and can be made as ergonomic as needed
using custom configuration
same way configuration is used by mojos.

[1]
https://github.com/sviperll/ozymandias/tree/master/maven-profiledep-extension
[2] https://github.com/repaint-io/maven-tiles
[3] https://issues.apache.org/jira/browse/MNG-6129

--
Victor Nazarov

On Mon, Dec 5, 2016 at 1:56 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I'm currently trying to figure out how to make mixins possible in POM 5.
>
> Mixins basically bring a form of multiple inheritance to the POM... which
> leads to the problems of how to solve conflicts.
>
> Inheritance Style
> =
>
> The first problem I hit was how to actually deal with a parent that
> declares some mixins and a child that declares other mixins where those
> mixins declare some of the same mixins from the parent but different
> versions... yes a some what esoteric edge case... but we can rest assured
> that users will hit this.
>
> I see two solutions to that problem:
>
> Option A: each project is consumed as its effective-pom (i.e. the mixins
> are merged before we consider application)
> Option B: each project is treated as a graph of its mixins, then to apply
> inheritance we do conflict resolution on the versions, pick the "nearest"
> version, prune out the subtrees of the "loser" versions and away we go.
>
> Option B feels like the more "correct" option... but heck I cannot even
> describe it well so how on earth are users to understand it.
>
> Thus, in the interests of simplifying life for users I am proceeding with
> the Option A approach... if that means that your parent has declared the
> myfaces-app:2.3 mixin and the child declares a tomee-web:3.0 mixin and that
> mixin happens to include myfaces-app:2.5 then the child pom will have both
> the myfaces-app:2.3 and myfaces-app:2.5 mixins applied... which may leave
> some "junk" that was in the myfaces-app:2.3 but removed from
> myfaces-app:2.5 present in the child pom... at least they can figure out
> where that "junk" is coming from and remove it from their own effective pom
> or bump the parent.
>
> Thoughts?
>
> Inheritance Priority
> ==
>
> Mixins on their own are fine. Parents on their own are also fine... when we
> have the two, how do we decide who wins.
>
> My current thinking is that there would be some parts of the model that can
> only come from the parent: informational stuff, deployment stuff.
>
> But that should be a very small part of the model. We want mixins to be
> able to contribute to the rest of the model.
>
> And here's the rub, in my parent I define some default conventions for
> plugins, dependencies, etc... we then want the mixins to be able to bring
> their best practices with them, so mixins need to be higher priority than
> the parent... but we also want the parent to be able to enforce some
> things.
>
> So say I want my parent to enforce that we only use myfaces for JSF. I may
> have dependency management for various other jars... then the child brings
> in some mixin and that mixin is directing all the JSF jars to the RI (not
> because the mixin is focused on the RI, but because they wanted to align on
> one thing)
>
> If mixins happen before parent, then some of the key rules of the mixin
> will be defeated.
> If mixins happen after parent, then the parent cannot enforce policy.
>
> I believe the enforcement of organizational policies is an important use
> case for parent projects, but the quest for mixins that I have seen from
> the JIRA is about being able to pull in configuration that has been tested
> and should supercede the organizational *defaults*.
>
> I think the solution to this is to give the parent a  section
> (which could only contain the elements permitted in a mixin) and have the
> inheritance priority be:
>
> 1. Start with the defaults for the current template (a.k.a packaging in
> 4.0.0 speak)
> 2. Apply the defaults from the parent pom
> 3. Apply the template specific defaults from the parent pom
> 4. Apply each mixin in turn (global first, then template specific)
> 5. Apply the project itself configuration
> 6. Apply the parent policy.
>
> I think that the parent policy should be inherited from its parents but
> whatever is said in the parent policy can 

Re: POM 5: The problems with mixins

[Jochen Wiedmann]

On Mon, Dec 5, 2016 at 3:31 PM, Chas Honton  wrote:

> My personal experience is that mixins lead to jar hell rather fast.

You have personal experience with a feature, that doesn't even exist?
I am impressed...

Jochen



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM 5: The problems with mixins

[Christian Schulte]

Am 05.12.2016 um 16:03 schrieb Christian Schulte:
> checkout the project for you automatically. You only need the "master"
> POM and the first invocation of "mvn" will checkout the aggregator
> automatically in some way. Just thoughts, though.)

With this I am referring to what is called "build plan" in maven core.
We could add a "" (or "" or something like that)
directly into POM 5 and automate SCM related things that way. Things
like that...


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM 5: The problems with mixins

[Christian Schulte]

Am 05.12.2016 um 15:31 schrieb Chas Honton:
> What problems are you trying to solve with mixins?  What is missing from the 
> current inheritance scheme?
> 
> It appears to me that you are putting the "how before the "what". 
> 
> My personal experience is that mixins lead to jar hell rather fast. 

In my understanding, there are no jar files involved. It's just a more
flexible way to compose an effective model and allows far more re-use.
The "what" becomes a matter of what user's are going to do with those
possibilities. The mixins are not about aggregating projects to build in
one go, as I understand it. They are about composition of an effective
model. As has already been said in this thread, maybe the parent/child
hierarchy is not needed anymore - aggregation can be expressed in other
ways more easily (a  element instead of , for
example. Maybe in a way decoupling from any kind of directory layout.
Where we have some-directory today, we may have
 in POM 5. By this I mean the first  build will
checkout the project for you automatically. You only need the "master"
POM and the first invocation of "mvn" will checkout the aggregator
automatically in some way. Just thoughts, though.)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM 5: The problems with mixins

[Chas Honton]

What problems are you trying to solve with mixins?  What is missing from the 
current inheritance scheme?

It appears to me that you are putting the "how before the "what". 

My personal experience is that mixins lead to jar hell rather fast. 

Chas

> On Dec 5, 2016, at 4:28 AM, Christian Schulte  wrote:
> 
> Not having read all of this for now, but that's what I was referring to
> with "relaxing a constraint is easier than enforcing a new one". When in
> doubt how to process conflicting elements or something like that, just
> error out and fail the build with a descriptive error message. If we
> later find out about such a constraint making a valid use-case
> impossible, we can relax that easily.
> 
> 
>> Am 05.12.2016 um 01:31 schrieb Hilco Wijbenga:
>> On 4 December 2016 at 14:56, Stephen Connolly
>>  wrote:
>>> I'm currently trying to figure out how to make mixins possible in POM 5.
>> 
>> This is wonderful news!
>> 
>>> Mixins basically bring a form of multiple inheritance to the POM... which
>>> leads to the problems of how to solve conflicts.
>> 
>> Why allow both inheritance and mixins? Why not simply allow only one
>> or the other? Or rather, allow inheritance only until mixins enter the
>> picture. So you could have a grandparent POM (without mixins), a
>> parent POM (without mixins), and then a child POM (potentially with
>> mixins). I don't really see the value in inheritance if mixins are
>> available. (But I can see why it would be nice to try and re-use an
>> existing company POM or similar.)
>> 
>> That still leaves the problem of including contradicting mixins. I
>> would simply disallow any contradictions. Keep it as simple as
>> possible, you can always make it more complex later. It is already
>> going to be quite difficult to clearly explain any encountered
>> problems to the user without any additional complexity.
>> 
>> Some more thoughts:
>> 
>> 1. Mixin A says A but Mixin B says
>> B. Maven should disallow that. The solution for
>> this would be to reference a property. Then both A and B could simply
>> state ${element.value}. Obviously, this may clash
>> (there may have been a very good reason for requiring "A" or "B") but
>> it is now up to the user to set ${element.value} appropriately or
>> change the combination of mixins. I don't see how Maven would be able
>> to resolve this.
>> 
>> 2. Mixin A says  but Mixin B says
>> . Again, this should not be allowed.
>> Maven can't possibly tell whether the order is relevant.
>> 
>> I have been thinking of a tool to do exactly this. It would use mixins
>> to generate the entire POM. With the above restrictions it seems
>> possible to achieve a real "define it once" type of build. Obviously,
>> it would be much nicer if Maven simply supported this natively. :-)
>> 
>> -
>> 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

Re: POM 5: The problems with mixins

[Christian Schulte]

Not having read all of this for now, but that's what I was referring to
with "relaxing a constraint is easier than enforcing a new one". When in
doubt how to process conflicting elements or something like that, just
error out and fail the build with a descriptive error message. If we
later find out about such a constraint making a valid use-case
impossible, we can relax that easily.


Am 05.12.2016 um 01:31 schrieb Hilco Wijbenga:
> On 4 December 2016 at 14:56, Stephen Connolly
>  wrote:
>> I'm currently trying to figure out how to make mixins possible in POM 5.
> 
> This is wonderful news!
> 
>> Mixins basically bring a form of multiple inheritance to the POM... which
>> leads to the problems of how to solve conflicts.
> 
> Why allow both inheritance and mixins? Why not simply allow only one
> or the other? Or rather, allow inheritance only until mixins enter the
> picture. So you could have a grandparent POM (without mixins), a
> parent POM (without mixins), and then a child POM (potentially with
> mixins). I don't really see the value in inheritance if mixins are
> available. (But I can see why it would be nice to try and re-use an
> existing company POM or similar.)
> 
> That still leaves the problem of including contradicting mixins. I
> would simply disallow any contradictions. Keep it as simple as
> possible, you can always make it more complex later. It is already
> going to be quite difficult to clearly explain any encountered
> problems to the user without any additional complexity.
> 
> Some more thoughts:
> 
> 1. Mixin A says A but Mixin B says
> B. Maven should disallow that. The solution for
> this would be to reference a property. Then both A and B could simply
> state ${element.value}. Obviously, this may clash
> (there may have been a very good reason for requiring "A" or "B") but
> it is now up to the user to set ${element.value} appropriately or
> change the combination of mixins. I don't see how Maven would be able
> to resolve this.
> 
> 2. Mixin A says  but Mixin B says
> . Again, this should not be allowed.
> Maven can't possibly tell whether the order is relevant.
> 
> I have been thinking of a tool to do exactly this. It would use mixins
> to generate the entire POM. With the above restrictions it seems
> possible to achieve a real "define it once" type of build. Obviously,
> it would be much nicer if Maven simply supported this natively. :-)
> 
> -
> 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

[VOTE] Release Apache Maven Resources Plugin version 3.0.2

[Christian Schulte]

Hi,

We solved 3 issues:


There are still a couple of issues left in JIRA:


Staging repo:



Source release checksum(s):
maven-resources-plugin-3.0.2-source-release.zip sha1:
4b77d70fce42dbdc6382f57dff5635abe9c55cb1

Staging site:


Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.
 
[ ] +1
[ ] +0
[ ] -1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Taking Security Seriously

[Alexander Kjäll]

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-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