You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Mark Cox <mj...@apache.org> on 2019/08/07 08:05:34 UTC
CVE helper tool
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
Re: CVE helper tool
Posted by Mark Cox <mj...@apache.org>.
Thanks for pointing out the license issue; there is a willingness to change
this (it's currently this way because Mitre's own draft tools are the same
license). I'll work on that. For the demo/show&tell i'll just host it on
my local machine.
thanks, Mark
On Wed, Aug 21, 2019 at 3:59 PM sebb <se...@gmail.com> wrote:
> On Wed, 21 Aug 2019 at 11:55, Mark J. Cox <mj...@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.
> >
> > > 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.
>
> AFAICT the license is CC BY 3.0, which is only allowed in binary form:
>
> http://apache.org/legal/resolved.html#cc-by
>
> I'm not sure we can use the code in that case.
>
> > > 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.
> >
> > Mark
> >
> > > > Thanks, Mark
> > > >
> > > > On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <mj...@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
> > > > >
> > >
>
Re: CVE helper tool
Posted by sebb <se...@gmail.com>.
On Wed, 21 Aug 2019 at 11:55, Mark J. Cox <mj...@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.
>
> > 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.
AFAICT the license is CC BY 3.0, which is only allowed in binary form:
http://apache.org/legal/resolved.html#cc-by
I'm not sure we can use the code in that case.
> > 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.
>
> Mark
>
> > > Thanks, Mark
> > >
> > > On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <mj...@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
> > > >
> >
Re: CVE helper tool
Posted by Mark Cox <mj...@apache.org>.
On Wed, Aug 21, 2019 at 1:29 PM Sam Ruby <ru...@intertwingly.net> wrote:
> On Wed, Aug 21, 2019 at 6:55 AM Mark J. Cox <mj...@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.
>
However I don't really expect much change to this tool once it's stable --
perhaps when the CVE automation WG get JSON submission of CVE requests
working we'd update it.
> 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.
>
Medium term I was expecting to checkin the scripts that could build the
static pages too (even if whimsy doesn't actually run them), but I'm
working with the Vulnogram author so we can try to separate out the ASF
specific changes into something that means we're running clean upstream
Vulnogram with just a custom configuration.
We did used to have a VM, but It just seems like a bit of overkill for
hosting a few static files that we really want to be used as a committers
tool.
Note that everything is done 'in browser', the tool is not intended to
store anything and any projects using it in advance with embargoed security
info nothing gets transmitted (except eventually to Mitre once the
submission stuff is written)
Mark
Re: CVE helper tool
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Sam Ruby wrote on 2019-8-21 8:29AM EDT:
> On Wed, Aug 21, 2019 at 6:55 AM Mark J. Cox <mj...@apache.org> wrote:
...snip...
> 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.
As a demo tool - to ensure it's ready for showing people what it would
do - Whimsy would be fine. But I'd be uncomfortable hosting a live
security tool (i.e. one that is handling pre-disclosure security data)
on Whimsy in the current environment, especially since it uses different
technologies than most applications.
--
- Shane
Whimsy PMC
The Apache Software Foundation
Re: CVE helper tool
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Aug 21, 2019 at 6:55 AM Mark J. Cox <mj...@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 <mj...@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
> > > >
> >
Re: CVE helper tool
Posted by "Mark J. Cox" <mj...@apache.org>.
> 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.
> 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.
Mark
> > Thanks, Mark
> >
> > On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <mj...@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
> > >
>
Re: CVE helper tool
Posted by sebb <se...@gmail.com>.
On Wed, 21 Aug 2019 at 09:31, Mark Cox <mj...@apache.org> wrote:
>
> Okay, I created a PR for it! https://github.com/apache/whimsy/pull/73 and
Thanks.
Had a quick look.
Many of the files have very long lines, so will be difficult to maintain.
Also there is no indication of the source of the code and its license.
Given that the tool requires a login, it could pre-populate the email
address(es).
> hope we can integrate it in time for the ApacheCon security BoF
When is that?
> Thanks, Mark
>
> On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <mj...@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
> >
Re: CVE helper tool
Posted by Mark Cox <mj...@apache.org>.
Okay, I created a PR for it! https://github.com/apache/whimsy/pull/73 and
hope we can integrate it in time for the ApacheCon security BoF
Thanks, Mark
On Wed, Aug 7, 2019 at 9:05 AM Mark Cox <mj...@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
>
Re: CVE helper tool
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Aug 7, 2019 at 5:23 AM Mark Cox <mj...@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?
Access control is whimsy is controlled by the following:
https://github.com/apache/infrastructure-puppet/blob/c78e76b9ec292a7e5c3634d632ce396eb346d139/data/nodes/whimsy-vm4.apache.org.yaml#L135
What this means is that anything in the /committers/ directory can
only be accessed by someone who is an ASF committer.
For completeness, another possible home for this tool would be comdev.
There is no precise division of labor between the two groups, so
wherever you think is the best fit could be made to work. If you
chose Whimsy, start with a pull request, and commit access is likely
to follow shortly thereafter.
The place in the source tree where artifacts that are served under the
/committers/ directory can be found here:
https://github.com/apache/whimsy/tree/master/www/committers
> Mark
- Sam Ruby