Re: Taking Security Seriously

[Hervé BOUTEMY]

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

Re: Taking Security Seriously

[Anders Hammar]

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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Taking Security Seriously

[John Patrick]

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

Re: POM 5: The problems with mixins

[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

[GitHub] maven-plugins pull request #98: Correct jira.codehaus.org to issues.apache.o...

[nhojpatrick]

GitHub user nhojpatrick opened a pull request:

https://github.com/apache/maven-plugins/pull/98

Correct jira.codehaus.org to issues.apache.org/jira

Looking though several plugins 
(http://maven.apache.org/plugins/maven-install-plugin/issue-tracking.html) and 
discovered the currently published url for issue tracking is pointing to 
codehaus.

This pull requests corrects all the links to they point to valid end points.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nhojpatrick/maven-plugins 
bugfix/jira.codehaus.org

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/98.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #98


commit 49b62f35a7c286ae5c1748c229bdeeb4b6408906
Author: John Patrick 
Date:   2016-12-04T23:05:47Z

Correct jira.codehaus.org to issues.apache.org/jira




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

POM 5: The problems with mixins

[Stephen Connolly]

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 override what is said in the
grandparent.

Thoughts?

Thanks for your consideration

-Stephen

svn: E170013: Unable to connect to a repository

[Christian Schulte]

I cannot access the subversion repository since a few hours any more.
Anyone else experiencing this?

C:\Users\schulte>svn checkout
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-resources-plugin
svn: E170013: Unable to connect to a repository at URL
'https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-resources-plugin'
svn: E175012: Connection timed out

C:\Users\schulte>

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

[GitHub] maven-plugins pull request #97: MINSTALL-133 createChecksum default true

[nhojpatrick]

GitHub user nhojpatrick opened a pull request:

https://github.com/apache/maven-plugins/pull/97

MINSTALL-133 createChecksum default true

Patch for https://issues.apache.org/jira/browse/MINSTALL-133


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nhojpatrick/maven-plugins 
bugfix/MINSTALL-133-createChecksum-true

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/97.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #97


commit d5ea2a8b57a9b212ba35728448fc0a4e2321fb66
Author: John Patrick 
Date:   2016-12-04T17:23:42Z

MINSTALL-133 createChecksum default true




---
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: maven-gpg-plugin updates

[Christian Schulte]

Am 04.12.2016 um 16:11 schrieb Chas Honton:
> Already there. 

Seems I looked at the wrong patch file. Regarding the 'checksum-files'
goal, I think this does not belong to the 'maven-gpg-plugin' because it
is not related to GPG in any way. Looking at
, I am not sure if there already
is a plugin this goal could be added to. Maybe
 or maybe a whole
new plugin gathering goals to access standard JCA functionality in
general. Maybe a 'crypto-maven-plugin' with goals 'encrypt', 'decrypt',
'mac', 'digest', etc.

Regards,
-- 
Christian


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

Re: maven-gpg-plugin updates

[Chas Honton]

Already there. 

Chas

> On Dec 4, 2016, at 4:22 AM, Christian Schulte  wrote:
> 
>> Am 12/04/16 um 06:27 schrieb Charles Honton:
>> Who can work with me to get maven-gpg-plugin updated?  In particular, I’d 
>> like to add goals to sign and checksum files that are not artifacts.  See 
>> MGPG-43 .  
>> 
> 
> Could you add ITs to that patch as well, please?
> 
> 
> -
> 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: maven-gpg-plugin updates

[Christian Schulte]

Am 12/04/16 um 06:27 schrieb Charles Honton:
> Who can work with me to get maven-gpg-plugin updated?  In particular, I’d 
> like to add goals to sign and checksum files that are not artifacts.  See 
> MGPG-43 .  
> 

Could you add ITs to that patch as well, please?


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

Re: Question on Maven Dependencies

[Karl Heinz Marbaise]

Hi,

first this is development list for Maven...

Your question is intended for the users list:

To find dependencies is best to read the documentation of the 
appropriate framework in your case Spring...or you can check maven 
central search:


https://search.maven.org

There is a button "Advanced" where you can type a class name...


presumably this will give a large number of results...check the relation 
to your framework...


Kind regards
Karl Heinz Marbaise

On 04/12/16 06:00, Saritha.Mathai wrote:


Hello,

What is the best way to find the dependency jars to include in my POM xml.

I am trying to find the dependency jar to include for SpringJUnit4ClassRunner 
class for Junit testing

Thanks in advance
Saritha








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

Question on Maven Dependencies

[Saritha . Mathai]

Hello,

What is the best way to find the dependency jars to include in my POM xml.

I am trying to find the dependency jar to include for SpringJUnit4ClassRunner 
class for Junit testing

Thanks in advance
Saritha