Re: Security related metadata

[Bernd Eckenfels]

There is the problem of missing CPE/maven-coordinates mappings. 
owasp,dependency check can work around that only with crude heuristics. 
Therefore it would be at least nice if we can add a CPE to the POM (or define 
an official mapping to CPEs, but last time I tried to address that on different 
lists nobody really agreed)

Having a standard way to attach annotations might do the whole eco system a 
favor.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Hervé BOUTEMY 
Sent: Wednesday, March 14, 2018 11:48:35 PM
To: Maven Developers List
Subject: Re: Security related metadata

using a plugin like OWASP Dependency-Check (or any other tool like it), and
its dedicated security issues storage and update workflow, avoid adding a new
management nightmare at every level of Maven

Regards,

Hervé

Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :
> Hi,
>
> recently I had an issue, where a security problem was claimed, because
> a published POM was using a jar version, for which a CVE exists. The
> reporter requested to upgrade to a current version, and publish an
> updated POM.
>
> As you know, we cannot update the POM. We only publish new POM's, so
> the case resulted in publication of a new version. However, this case
> got me thinking:
>
> 1.) Whether we like it, or not, the published POM is an artifact, that we
> have to maintain. (And, in the case of the ASF: For which we might be
> legally responsible.)
> 2.) Knowing, that one can exclude the jar file in question in a
> downstream POM, is not sufficient. You've got to know, that there is a
> problem.
>
> Point one is a simple statement of fact. Nothing much to do
> here.Regarding point two, however: Here's something, that the Maven
> world could do better.
>
> My suggestion would be:
>
>   a) Introduce a new artifact (say --issues.xml).
>
>   The idea would be, to publish such an artifact, if an issue with the
> jar, war, or whatever file (the original artifact, without
> classifier) has been
>detected.
>
>   b) On occasion, Maven would check, whether there is an issues file
> for a dependency. If so, it would issue a warning, break the build, or
> do whatever seems appropriate.
>   Of course, this action would be done in a plugin, which might be
>   skipped.
>
> Leaving out questions like update of an issues file (There might be
> other issues, later on, or more serious issues.), I think this should
> be doable with moderate efforts.
>
> Jochen
>
> -
> 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: Security related metadata

[Hervé BOUTEMY]

using a plugin like OWASP Dependency-Check (or any other tool like it), and 
its dedicated security issues storage and update workflow, avoid adding a new 
management nightmare at every level of Maven

Regards,

Hervé

Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :
> Hi,
> 
> recently I had an issue, where a security problem was claimed, because
> a published POM was using a jar version, for which a CVE exists. The
> reporter requested to upgrade to a current version, and publish an
> updated POM.
> 
> As you know, we cannot update the POM. We only publish new POM's, so
> the case resulted in publication of a new version. However, this case
> got me thinking:
> 
> 1.) Whether we like it, or not, the published POM is an artifact, that we
> have to maintain. (And, in the case of the ASF: For which we might be
> legally responsible.)
> 2.) Knowing, that one can exclude the jar file in question in a
> downstream POM, is not sufficient. You've got to know, that there is a
> problem.
> 
> Point one is a simple statement of fact. Nothing much to do
> here.Regarding point two, however: Here's something, that the Maven
> world could do better.
> 
> My suggestion would be:
> 
>   a) Introduce a new artifact (say --issues.xml).
> 
>   The idea would be, to publish such an artifact, if an issue with the
> jar, war, or whatever file (the original artifact, without
> classifier) has been
>detected.
> 
>   b) On occasion, Maven would check, whether there is an issues file
> for a dependency. If so, it would issue a warning, break the build, or
> do whatever seems appropriate.
>   Of course, this action would be done in a plugin, which might be
>   skipped.
> 
> Leaving out questions like update of an issues file (There might be
> other issues, later on, or more serious issues.), I think this should
> be doable with moderate efforts.
> 
> Jochen
> 
> -
> 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: Build vs Consumer POM study

[Hervé BOUTEMY]

IMHO, in this case, the dependency should be defined in the profile in the 
consumer POM, with resolved property of the profile.

I don't know if flatten-maven-plugin currently detects such a situation and is 
able to move the parametrized dependency in main section to non-parametrized 
dependency in profile. Or at least detect that the situation is complex and 
require some tricks.

This situation won't happen often, but sure, this will happen and we need to 
define what to do.

Currently, the study in Git did not try to dig into implementation of the 
transformation: but this edge case will be a good one to test.

Regards,

Hervé

Le mercredi 14 mars 2018, 13:21:21 CET Jörg Schaible a écrit :
> Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY:
> 
> [snip]
> 
> >> > Why is  required for consumers? I'm not aware how profiles
> >> > of a dependency ever play(ed) a role in my "dependent" project?
> >> 
> >> I can remember we had a discussion about that..my first reaction would
> >> be saying no profiles needed in a consumer pom...but I'm not 100%
> >> sure...we need to think that more in detail with different scenarios..
> > 
> > Robert has a strong opinion on this, for profiles activated by OS or JDK
> > version, like flatten-maven-plugin
> 
> How would you solve this case then:
> 
> Somewhere in a parent pom:
> == %< =
>   
> linux-amd64
> 
>   
>   linux
>   amd64
>   
> 
> 
>   org.eclipse.swt.gtk.linux.x86_64
> 
>   
>   
> windows-amd64
> 
>   
> windows
> amd64
>   
> 
> 
>   org.eclipse.swt.win32.win32.x86_64
> 
>   
>   
> == %< =
> 
> Somewhere in a child project X:
> 
> == %< =
>   
> 
>   org.eclipse.swt
>   ${swt.artifactId}
>   3.106.0.v20170608-0516
> 
>   
> == %< =
> 
> What would a consumer-pom.xml of X look like and how can a client of X
> still depend on the proper dependency for its target platform?
> 
> Cheers,
> Jörg
> 
> 
> -
> 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: Build vs Consumer POM study

[Hervé BOUTEMY]

Le mercredi 14 mars 2018, 09:10:20 CET Robert Scholte a écrit :
> The more I think about this, the more I believe we should approach this a
> little bit different.
> 
> There are discussions which parts should be part and which shouldn't. But
> is this up to us/Maven?
I don't get the intend here

> How about removing those bits that are useless, i.e build and reporting
> and I tend to agree on distributionmanagement. These are all instructions
> specifically for building, reporting and its distribution and does not add
> value once deployed.
> If there are additional elements that users want to remove, they can
> decide to use the flatten-maven-plugin.
what is hard here is to really define the consumer features, for example on 
profiles or dependencyManagement or repositories. But for the few pure 
descriptive fields that are discussed (like ciManagement), there is no long 
discussion: we'll keep them in the consumer POM, they don't really hurt common 
understanding

> 
> There is another proposal, the pdt-  or project dependency trees-file[1],
> which will the ultimate and optimized consumer-file.
yes, in the future, when consumer poms are a reality and we get all the 
implications, we can eventually create a completely new format, why not.
IMHO, this first step of consumer vs build POM as consumer = subset of POMv4 
and build POM is full POMV4 and newer is a crucial step before discussing more 
disruptive evolution

Regards,

Hervé

> 
> I also have demands about the implementation, but I'll put that in a
> separate mail. It requires a detailed story and maybe some drawings to
> fully understyand it.
> 
> thanks,
> Robert
> 
> [1]
> https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+s
> chema
> 
> 
> On Sun, 11 Mar 2018 18:03:07 +0100, Hervé BOUTEMY 
> 
> wrote:
> > Hi,
> > 
> > I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded
> > a
> > simplified model for the Consumer POM [2]
> > As written in the proposal, this would permit us to create new POM
> > versions
> > that change everything but not the Consumer POM part without breaking any
> > compatibility with existing Central repository users: build element is
> > the
> > main element that could be changed, adding new build
> > features/configuration
> > without affecting consumers.
> > 
> > In addition to reviewing choices proposed for majority of POM elements,
> > there
> > are 4 elements that require more discussion:
> > - contributors
> > - mailingLists
> > - repositories
> > - profiles/activation
> > 
> > Any thoughts?
> > 
> > On the code, IMHO, the only missing part is a test of
> > flatten-maven-plugin to
> > check that everything works as expected in any situation.
> > And I suppose a discussion on what we do for the xsd
> > 
> > Then we should be able to use this strategy for our own artifacts, before
> > updating POM model version in any newer Maven version starting with 3.6
> > (yay!)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > [1]
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> > 
> > [2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html
> > 
> > -
> > 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

Security related metadata

[Jochen Wiedmann]

Hi,

recently I had an issue, where a security problem was claimed, because
a published POM was using a jar version, for which a CVE exists. The
reporter requested to upgrade to a current version, and publish an
updated POM.

As you know, we cannot update the POM. We only publish new POM's, so
the case resulted in publication of a new version. However, this case
got me thinking:

1.) Whether we like it, or not, the published POM is an artifact, that we have
 to maintain. (And, in the case of the ASF: For which we might be legally
 responsible.)
2.) Knowing, that one can exclude the jar file in question in a
downstream POM, is not sufficient. You've got to know, that there is a
problem.

Point one is a simple statement of fact. Nothing much to do
here.Regarding point two, however: Here's something, that the Maven
world could do better.

My suggestion would be:

  a) Introduce a new artifact (say --issues.xml).

  The idea would be, to publish such an artifact, if an issue with the jar,
   war, or whatever file (the original artifact, without
classifier) has been
   detected.

  b) On occasion, Maven would check, whether there is an issues file
for a dependency. If so, it would issue a warning, break the build, or
do whatever seems appropriate.
  Of course, this action would be done in a plugin, which might be
  skipped.

Leaving out questions like update of an issues file (There might be
other issues, later on, or more serious issues.), I think this should
be doable with moderate efforts.

Jochen

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

Re: Build vs Consumer POM study

[Jörg Schaible]

Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY:

[snip]

>> > Why is  required for consumers? I'm not aware how profiles
>> > of a dependency ever play(ed) a role in my "dependent" project?
>> I can remember we had a discussion about that..my first reaction would
>> be saying no profiles needed in a consumer pom...but I'm not 100%
>> sure...we need to think that more in detail with different scenarios..
> Robert has a strong opinion on this, for profiles activated by OS or JDK
> version, like flatten-maven-plugin

How would you solve this case then:

Somewhere in a parent pom:
== %< =
  
linux-amd64

  
linux
amd64
  


  org.eclipse.swt.gtk.linux.x86_64

  
  
windows-amd64

  
windows
amd64
  


  org.eclipse.swt.win32.win32.x86_64

  
  
== %< =

Somewhere in a child project X:

== %< =
  

  org.eclipse.swt
  ${swt.artifactId}
  3.106.0.v20170608-0516

  
== %< =

What would a consumer-pom.xml of X look like and how can a client of X 
still depend on the proper dependency for its target platform?

Cheers,
Jörg


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

Re: Build vs Consumer POM study

[Robert Scholte]

The more I think about this, the more I believe we should approach this a  
little bit different.


There are discussions which parts should be part and which shouldn't. But  
is this up to us/Maven?
How about removing those bits that are useless, i.e build and reporting  
and I tend to agree on distributionmanagement. These are all instructions  
specifically for building, reporting and its distribution and does not add  
value once deployed.
If there are additional elements that users want to remove, they can  
decide to use the flatten-maven-plugin.


There is another proposal, the pdt-  or project dependency trees-file[1],  
which will the ultimate and optimized consumer-file.


I also have demands about the implementation, but I'll put that in a  
separate mail. It requires a detailed story and maybe some drawings to  
fully understyand it.


thanks,
Robert

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema



On Sun, 11 Mar 2018 18:03:07 +0100, Hervé BOUTEMY   
wrote:



Hi,

I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded  
a

simplified model for the Consumer POM [2]
As written in the proposal, this would permit us to create new POM  
versions

that change everything but not the Consumer POM part without breaking any
compatibility with existing Central repository users: build element is  
the
main element that could be changed, adding new build  
features/configuration

without affecting consumers.

In addition to reviewing choices proposed for majority of POM elements,  
there

are 4 elements that require more discussion:
- contributors
- mailingLists
- repositories
- profiles/activation

Any thoughts?

On the code, IMHO, the only missing part is a test of  
flatten-maven-plugin to

check that everything works as expected in any situation.
And I suppose a discussion on what we do for the xsd

Then we should be able to use this strategy for our own artifacts, before
updating POM model version in any newer Maven version starting with 3.6  
(yay!)


Regards,

Hervé


[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM


[2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html

-
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: Build vs Consumer POM study

[Hervé BOUTEMY]

Le mercredi 14 mars 2018, 01:37:38 CET Laird Nelson a écrit :
> On Tue, Mar 13, 2018 at 5:34 PM Hervé BOUTEMY  wrote:
> > I don't see any issues with content provided:
> > org.springframework.boot:spring-
> > boot-dependencies has a "pom" packaging, then would be deployed directly
> > as
> > build POM, containing dependencyManagement
> 
> I'm not sure, but I think the question is: when you use this Spring Boot
> pom.xml not just in import scope (as a BOM) but in compile scope as well
> (so you "use" its transitive dependencies in compile scope), are its
> dependencies present in your project's consumer pom.xml under this proposal?
the answer has 2 parts:
1. no, what is flattened is parent configuration, not transitive dependencies
2. AFAIK, using these coordinates as compile dependency does not have any 
interest: the pom only contains dependencyManagement but no dependency, then 
it won't change anything on transitive resolution

> 
> My apologies if I've misunderstood the issue.
it's not so easy to understand each other: and this discussion proves we mix 
build features with resolution features for too much time
it's time to better define everything

Regards,

Hervé

> 
> Best,
> Laird



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