Re: Security related metadata
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é BOUTEMYwrote: > > 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 > > - > 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
Re: Security related metadata
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 <herve.bout...@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 --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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Security related metadata
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é BOUTEMYwrote: > 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 > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Security related metadata
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 <herve.bout...@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 --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
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
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 --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