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