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