You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2018/03/14 12:27:53 UTC
Security related metadata
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 <ARTIFACTID>-<VERSION>-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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Security related metadata
Posted by Hervé BOUTEMY <he...@free.fr>.
Hi Jochen,
I'll try to rephrase and summarize previous ideas on this.
The issue is two sided:
1. from the artifact provider point of view
2. from the artifact consumer point of view
For the provider: the provider of an artifact owns its groupId in Central.
Then if we do something, the data will have to be provided by the project:
we'll need to provide tooling to add the new file to already published gavs,
and eventually updating, with publication, sync and so on, available from
every source repository, ie named "public forge" in the documentation [1]
Not that easy: I don't have personally energy to even try
For the consumer:
What will be the quality of data? What will we provide to deal with false
positives, or issues that the consumer deal with by implementing workarounds?
Who will manage requests from users when then get a warning they did not ask
for and don't understand (and we, the Maven team don't understand either)?
Currently, there is NIST and OWASP to provide data and tooling: implementing
at Maven level would be competing with this whole established eco-system,
hoping we'll be more accurate. But I don't hope so.
And we have already so much to do with so much plugins, core evolutions on
build features
IMHO, the most we can do is helping awareness of the consequences of consuming
public artifacts = not only consume, but manage security issues from the
dependencies
Then ok to write some documentation, spread the word about CVE/CPE, about
OWASP Dependency Check Maven plugin and alternative (both Open Source or
commercial, like listed by OWASP): everything is already available.
But reimplement the whole ecosystem ourselves (data + tooling) will be without
me :)
Regards,
Hervé
[1] https://maven.apache.org/repository/
Le jeudi 15 mars 2018, 09:43:06 CET Jochen Wiedmann a écrit :
> Hi, Hervé
>
> could you describe to me, what in my proposal makes you expect a "management
> nightmare"? My impression was, that I am describing something reasonable.
>
> Jochen
>
> On 2018/03/14 22:48:35, Hervé BOUTEMY <he...@free.fr> wrote:
> > 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 <ARTIFACTID>-<VERSION>-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-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: Security related metadata
Posted by Jochen Wiedmann <jo...@apache.org>.
Hi, Hervé
could you describe to me, what in my proposal makes you expect a "management nightmare"? My impression was, that I am describing something reasonable.
Jochen
On 2018/03/14 22:48:35, Hervé BOUTEMY <he...@free.fr> wrote:
> 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 <ARTIFACTID>-<VERSION>-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-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: Security related metadata
Posted by Hervé BOUTEMY <he...@free.fr>.
I like this idea: seems reasonable, even if I don't really see yet the full
implications
I had a look at the 2 CVEs for Maven and could not find any CPE
Is it really something used for every CVE?
Regards,
Hervé
Le jeudi 15 mars 2018, 00:14:34 CET Bernd Eckenfels a écrit :
> 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 <he...@free.fr>
> 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 <ARTIFACTID>-<VERSION>-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-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: Security related metadata
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <he...@free.fr>
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 <ARTIFACTID>-<VERSION>-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-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: Security related metadata
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <ARTIFACTID>-<VERSION>-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-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