On Wed, Aug 21, 2019 at 6:55 AM Mark J. Cox <m...@apache.org> wrote: > > > Many of the files have very long lines, so will be difficult to maintain. > > The Vulnogram tool is a nodejs app and the standalone files are generated > using a nodejs script. I was intending to just check in the compiled files > for now.
Long term, I don't think checking in the compiled files the right solution. > > Also there is no indication of the source of the code and its license. > > https://github.com/Vulnogram/Vulnogram at the moment with a number of > customisations and patches I hope to fold many of these back into the > upstream project. > > > Given that the tool requires a login, it could pre-populate the email > > address(es). > > Yes. > > > > hope we can integrate it in time for the ApacheCon security BoF > > > > When is that? > > https://www.apachecon.com/acna19/s/#/scheduledEvent/1337 although I'm away in > 6 days time until then. So if we don't want to pop the compiled stuff into > the tree I can always host it elsewhere for the BoF demo. Perhaps we can discuss the right long term solution, then work backwards from there? One possibility is for the security team to request a VM (perhaps security.apache.org or perhaps cve.apache.org?). I believe that it could be spun up within an hour. > Mark - Sam Ruby > > > Thanks, Mark > > > > > > On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <m...@apache.org> wrote: > > > > > > > Hi all! > > > > > > > > Many of our projects struggle with the format of creating Mitre CVEs and > > > > various text representations of vulnerabilities needed for public > > > > mailing > > > > lists as per our security policy. > > > > > > > > But, one of the CVE automation working group members has been working > > > > on a > > > > nice javascript tool that simplifies all this ( > > > > https://vulnogram.github.io/), and I'm working with it and him on making > > > > it so we can do an easy customisation to guide ASF projects through the > > > > process. > > > > > > > > The tool runs standalone just static content once built (it may pull > > > > from > > > > /public jsons too) so I'd really just need somewhere I can commit to > > > > that > > > > appears under whimsy. In the future the tool may even be able to submit > > > > direct to Mitre so it'd make sense to start it with requiring > > > > /committer/ > > > > access to run it. > > > > > > > > So this could be as simple as agreeing a location and allowing me to > > > > update things there? > > > > > > > > Mark > > > > > >
