[EXT] The Github Decision (was Re: CVE Automation Group)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[EXT] The Github Decision (was Re: CVE Automation Group)

Art Manion
On 4/30/19 2:44 PM, Loren, Lewis A. wrote:
> All – The email below is incorrect, the board has made a final decision to move away from Github.  Chris Levendis misremembered the status when I inquired earlier and I wanted to send out a clarification at the earliest opportunity.  Chris had hoped to send the email himself, but is at the dentist and unable to do so, so in the interest of time, he asked me to send the update on his behalf.  I will leave this topic on the agenda for the next AWG meeting.

> All – during the meeting on April 29^th , there were questions about whether Github would continue to be used and the role of the AWG; I agreed to look into the issue and respond with my findings.  Currently, The SPWG is working on a position paper exploring the pros and cons of continuing to use Github in light of the EU’s General Data Protection Regulation (GDPR) and other factors.  Once complete, that paper will be provided to the Board so that they can make a decision.  Once the decision is made, the AWG will need to factor that decision into the “Entry Submission Service” which has yet to begin.
>
> Bottom line, it appears that a final decision has not yet been made and that AWG will be responsible for implementing the Entry Submission Service, which could be affected by the decision to continue using Github, or to implement an alternative service.

I've got a list of concerns about this decision, I'm going to list them here.  This isn't something I plan to argue further about, but we've reviewed what information we've been able to collect on this decision and I'll at least leave it on the record.

TLDR:  I don't see a compelling reason to move away from git, or Github.  No correspondingly strong reason to stay, but it's mostly(?) working so why fix it?

1. The decision.  I may have missed it, which is on me, but when exactly was the decision made?  I don't think there was a vote, was there a deadline, or a date when the discussion was scheduled?  I've heard bits from a board call and we got much more information from Kent.  I had a general sense that the SP WG was still preparing a proposal/documenting discussion from the Feb 26-27 meeting.

2. GDPR.  Github and every other code repository protocol and service have to sort this out, CVE is not special.  I'm betting that name and email address are required for functional reasons, like 17.3.(d):

   https://gdpr-info.eu/art-17-gdpr/

"...we are compliant with the General Data Protection Regulation (GDPR)"

   https://help.github.com/en/articles/github-privacy-statement

(I'm admittedly neither a lawyer nor privacy expert, but we shouldn't be jumping to premature fear/conclusions.)

3. Countries blocking Github (like China).  I'm 100% in favor of growing CVE and specifically trying to get CN-based vendors and researchers engaged.  But I don't think we should be working too hard to stay ahead of geopolitical issues, not our area.  CN might block a quasi-USG organization like MITRE for some reason.  Or the NGO/Foundation successor to the CVE Project.  Plus, just run a self-hosted git service.

Also, github is (currently) not blocked by China according to this:

   https://viewdns.info/chinesefirewall/?domain=github.com

4. Microsoft.  First, I doubt Microsoft is going to trash the world's biggest(?) public code repository.  If they do, self-hosted git service.

5. MITRE has dev resources available.  I think Microsoft has pitched in too.  This is great, thanks.  This enables change/new development, but shouldn't be the driver for it.

6. Transition to a new parent organization.  Which do you want to inherit, custom code or a git repo with some nice CI (OK, also some custom code, but based on common practices and the git framework).

All this said, I don't plan to argue further.  APIs in AWS sounds nice, I just don't see compelling reasons to change.  It's also entirely possible that allocation and other services end up pushing changes to a git repo (i.e., git/Github is still the authoritative, public, freely available, transparent, distributed, well-understood canonical record of CVE data).

Regards,

  - Art
 







Reply | Threaded
Open this post in threaded view
|

Re: [EXT] The Github Decision (was Re: CVE Automation Group)

Tod Beardsley
What Art said. +1. Thanks for articulating this, Art.

On Tue, Apr 30, 2019 at 4:23 PM Art Manion <[hidden email]> wrote:
On 4/30/19 2:44 PM, Loren, Lewis A. wrote:
> All – The email below is incorrect, the board has made a final decision to move away from Github.  Chris Levendis misremembered the status when I inquired earlier and I wanted to send out a clarification at the earliest opportunity.  Chris had hoped to send the email himself, but is at the dentist and unable to do so, so in the interest of time, he asked me to send the update on his behalf.  I will leave this topic on the agenda for the next AWG meeting.

> All – during the meeting on April 29^th , there were questions about whether Github would continue to be used and the role of the AWG; I agreed to look into the issue and respond with my findings.  Currently, The SPWG is working on a position paper exploring the pros and cons of continuing to use Github in light of the EU’s General Data Protection Regulation (GDPR) and other factors.  Once complete, that paper will be provided to the Board so that they can make a decision.  Once the decision is made, the AWG will need to factor that decision into the “Entry Submission Service” which has yet to begin.
>
> Bottom line, it appears that a final decision has not yet been made and that AWG will be responsible for implementing the Entry Submission Service, which could be affected by the decision to continue using Github, or to implement an alternative service.

I've got a list of concerns about this decision, I'm going to list them here.  This isn't something I plan to argue further about, but we've reviewed what information we've been able to collect on this decision and I'll at least leave it on the record.

TLDR:  I don't see a compelling reason to move away from git, or Github.  No correspondingly strong reason to stay, but it's mostly(?) working so why fix it?

1. The decision.  I may have missed it, which is on me, but when exactly was the decision made?  I don't think there was a vote, was there a deadline, or a date when the discussion was scheduled?  I've heard bits from a board call and we got much more information from Kent.  I had a general sense that the SP WG was still preparing a proposal/documenting discussion from the Feb 26-27 meeting.

2. GDPR.  Github and every other code repository protocol and service have to sort this out, CVE is not special.  I'm betting that name and email address are required for functional reasons, like 17.3.(d):

   https://gdpr-info.eu/art-17-gdpr/

"...we are compliant with the General Data Protection Regulation (GDPR)"

   https://help.github.com/en/articles/github-privacy-statement

(I'm admittedly neither a lawyer nor privacy expert, but we shouldn't be jumping to premature fear/conclusions.)

3. Countries blocking Github (like China).  I'm 100% in favor of growing CVE and specifically trying to get CN-based vendors and researchers engaged.  But I don't think we should be working too hard to stay ahead of geopolitical issues, not our area.  CN might block a quasi-USG organization like MITRE for some reason.  Or the NGO/Foundation successor to the CVE Project.  Plus, just run a self-hosted git service.

Also, github is (currently) not blocked by China according to this:

   https://viewdns.info/chinesefirewall/?domain=github.com

4. Microsoft.  First, I doubt Microsoft is going to trash the world's biggest(?) public code repository.  If they do, self-hosted git service.

5. MITRE has dev resources available.  I think Microsoft has pitched in too.  This is great, thanks.  This enables change/new development, but shouldn't be the driver for it.

6. Transition to a new parent organization.  Which do you want to inherit, custom code or a git repo with some nice CI (OK, also some custom code, but based on common practices and the git framework).

All this said, I don't plan to argue further.  APIs in AWS sounds nice, I just don't see compelling reasons to change.  It's also entirely possible that allocation and other services end up pushing changes to a git repo (i.e., git/Github is still the authoritative, public, freely available, transparent, distributed, well-understood canonical record of CVE data).

Regards,

  - Art










--
"Tod Beardsley"
Director of Research
+1-512-438-9165 | https://keybase.io/todb

NOTICE OF CONFIDENTIALITY: At Rapid7, the privacy of our customers, partners, and employees is paramount. If you received this email in error, please notify the sender and delete it from your inbox right away. Learn how Rapid7 handles privacy at rapid7.com/privacy-policy. To opt-out of Rapid7 marketing emails, please click here or email [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] The Github Decision (was Re: CVE Automation Group)

Kurt Seifried-2


On Wed, May 1, 2019 at 8:45 AM Bruce Lowenthal <[hidden email]> wrote:

I strongly support the decision to move off of GitHub.    There are fundamental issues especially when widely used third party CVEs are announced.   In such case, hundreds, perhaps thousands of Suppliers (Vendors) should be expected to update the CVE record to indicate their product versions that are vulnerable.   The GitHub infrastructure really cannot handle a thousand independent entities entering information in the same record that they are vulnerable in a reliable manner.    Especially in cases where a Supplier changes their mind and wishes to delete or modify their entry in the CVE record.  

Yes actually it can, especially if the JSON container format is used correctly and PR's are merged quickly (ideally automatically). But in the above scenario ANY solution will quickly fail unless there is heavy automation. 

Also I agree with Art's concerns but I too am done and not willing to argue about this. The decision was made (and it didn't involve a board vote...) so I don't even know if there's a mechanism to deal with this. 

 

I understand the reluctance to create custom code but creating the simple facilities for creating and updating records reliably is not difficult and competent programmers should be able to be found, if not on board already, to create and maintain this application. 

If assistance and/or review of a create/update facility for CVE records is needed, we would be happy to participate.

Bruce
------

On 5/1/2019 6:30 AM, Tod Beardsley wrote:
What Art said. +1. Thanks for articulating this, Art.

On Tue, Apr 30, 2019 at 4:23 PM Art Manion <[hidden email]> wrote:
On 4/30/19 2:44 PM, Loren, Lewis A. wrote:
> All – The email below is incorrect, the board has made a final decision to move away from Github.  Chris Levendis misremembered the status when I inquired earlier and I wanted to send out a clarification at the earliest opportunity.  Chris had hoped to send the email himself, but is at the dentist and unable to do so, so in the interest of time, he asked me to send the update on his behalf.  I will leave this topic on the agenda for the next AWG meeting.

> All – during the meeting on April 29^th , there were questions about whether Github would continue to be used and the role of the AWG; I agreed to look into the issue and respond with my findings.  Currently, The SPWG is working on a position paper exploring the pros and cons of continuing to use Github in light of the EU’s General Data Protection Regulation (GDPR) and other factors.  Once complete, that paper will be provided to the Board so that they can make a decision.  Once the decision is made, the AWG will need to factor that decision into the “Entry Submission Service” which has yet to begin.
>
> Bottom line, it appears that a final decision has not yet been made and that AWG will be responsible for implementing the Entry Submission Service, which could be affected by the decision to continue using Github, or to implement an alternative service.

I've got a list of concerns about this decision, I'm going to list them here.  This isn't something I plan to argue further about, but we've reviewed what information we've been able to collect on this decision and I'll at least leave it on the record.

TLDR:  I don't see a compelling reason to move away from git, or Github.  No correspondingly strong reason to stay, but it's mostly(?) working so why fix it?

1. The decision.  I may have missed it, which is on me, but when exactly was the decision made?  I don't think there was a vote, was there a deadline, or a date when the discussion was scheduled?  I've heard bits from a board call and we got much more information from Kent.  I had a general sense that the SP WG was still preparing a proposal/documenting discussion from the Feb 26-27 meeting.

2. GDPR.  Github and every other code repository protocol and service have to sort this out, CVE is not special.  I'm betting that name and email address are required for functional reasons, like 17.3.(d):

   https://gdpr-info.eu/art-17-gdpr/

"...we are compliant with the General Data Protection Regulation (GDPR)"

   https://help.github.com/en/articles/github-privacy-statement

(I'm admittedly neither a lawyer nor privacy expert, but we shouldn't be jumping to premature fear/conclusions.)

3. Countries blocking Github (like China).  I'm 100% in favor of growing CVE and specifically trying to get CN-based vendors and researchers engaged.  But I don't think we should be working too hard to stay ahead of geopolitical issues, not our area.  CN might block a quasi-USG organization like MITRE for some reason.  Or the NGO/Foundation successor to the CVE Project.  Plus, just run a self-hosted git service.

Also, github is (currently) not blocked by China according to this:

   https://viewdns.info/chinesefirewall/?domain=github.com

4. Microsoft.  First, I doubt Microsoft is going to trash the world's biggest(?) public code repository.  If they do, self-hosted git service.

5. MITRE has dev resources available.  I think Microsoft has pitched in too.  This is great, thanks.  This enables change/new development, but shouldn't be the driver for it.

6. Transition to a new parent organization.  Which do you want to inherit, custom code or a git repo with some nice CI (OK, also some custom code, but based on common practices and the git framework).

All this said, I don't plan to argue further.  APIs in AWS sounds nice, I just don't see compelling reasons to change.  It's also entirely possible that allocation and other services end up pushing changes to a git repo (i.e., git/Github is still the authoritative, public, freely available, transparent, distributed, well-understood canonical record of CVE data).

Regards,

  - Art










--
"Tod Beardsley"
Director of Research
+1-512-438-9165 | https://keybase.io/todb

NOTICE OF CONFIDENTIALITY: At Rapid7, the privacy of our customers, partners, and employees is paramount. If you received this email in error, please notify the sender and delete it from your inbox right away. Learn how Rapid7 handles privacy at rapid7.com/privacy-policy. To opt-out of Rapid7 marketing emails, please click here or email [hidden email].


--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] The Github Decision (was Re: CVE Automation Group)

Loren, Lewis A.
In reply to this post by Art Manion

All – thank you for your input on this thread.  It appears likely that the AWG will need to solicit requirements in order to design a functional replacement and Eric and Omar’s inputs below are a good example of the information we’ll need to collect.  I have a couple goals for this effort:

  • Retain all of the benefits Github provides
  • Minimize the impact to users who have developed tooling around Github
  • Add any helpful features that Github doesn’t currently provide

Essentially, users of the Github process shouldn’t sacrifice any of the efficiencies they currently enjoy, only the implementation should change and those changes should be, to the extent possible, opaque to the user community.

 

Best regards,

Lew

 

 

 

Lewis A. Loren, Ph.D.

T856 Co-Department Head

MITRE Corporation

Office: 781-271-5969

Cell: 781-715-5125

People like to say that the conflict is between good and evil.

The real conflict is between truth and lies – Don Miguel Ruiz

id:image001.png@01D38615.9BCA7BD0id:image002.png@01D38615.9BCA7BD0id:image003.png@01D38615.9BCA7BD0id:image004.png@01D38615.9BCA7BD0id:image005.png@01D38615.9BCA7BD0

id:image006.png@01D38615.9BCA7BD0

 

 

From: "Omar Santos (osantos)" <[hidden email]>
Date: Tuesday, April 30, 2019 at 8:39 PM
To: "Johnson, Eric" <[hidden email]>
Cc: "Manion, Art" <[hidden email]>, CVE Board Automation Working Group <[hidden email]>, CVE Editorial Board Discussion <[hidden email]>, "Loren, Lewis A." <[hidden email]>, "Levendis, Chris" <[hidden email]>, "Landfield, Kent" <[hidden email]>
Subject: Re: [EXT] The Github Decision (was Re: CVE Automation Group)

 

What Eric said. In all seriousness, I share the same experience, as Eric. I will also support whatever system the community thinks that is best. I do like the Git experience. Familiar tool, identity verification / signed commits, etc. 

 

On the other hand, I do benefit from having all CVEs in the repository. In some cases, I have added additional reference URLs of security advisories and other content to open source CVEs that affect Cisco products. I also use and keep up with some of the data being submitted, even before that data makes it to NVD.

 

I suggest that the new system supports an open framework and that use common tools used by the industry, like git.

Regards,



Omar Santos

PSIRT, Security Research and Operations

Cisco Systems, Inc.

Email: [hidden email]

Phone: <a href="tel:&#43;1%20919%20392%208635">+1 919 392 8635

PGP Key: 0x3AF27EDC


On Apr 30, 2019, at 7:57 PM, Eric Johnson <[hidden email]> wrote:

For what it is worth, I've been using the GitHub submission process. I've not been a part of the automation WG, because I simply haven't been able to find the time. I sort of wish that the WG had done a survey (did they do one and I missed it?).

 

Off-the-top-of-my-head problems:

  • Pulling down all the CVEs in JSON form is potentially interesting, but mostly it is just overhead. If it came with ways to take advantage of all that data, such as an import into a DB, where I could learn from other's submissions (word choice analysis, etc, changes over time), that would be useful. As it is, at best I can use grep, and then try to make something of it. A lot of data, without a lot of value, unless I invest a lot of time (which I don't have).
  • Most of the commits to the github project are now "automated" synchronization. Presumably, these are CVEs that arrive not via the GitHub trial. Distracting.
  • Instead of posting a JSON file to the cveform, I have to (after forking, just once) bring my local copy current with the "upstream", bring my github fork current with upstream, create a branch, make my changes on the branch, commit the branch, push the branch, and then create the pull-request.
  • The changes I need to make for CVEs have to be put in specific files of the right names. These directories, with 1000 files in them, are a little slower to navigate in editor / IDE environments. Also resist tab-completion to the desired files at the command line. Since the CVE # is in the file I'm submitting, it is ever so slightly redundant to have to match up the file name.
  • When I submit CVE data via Git, the merge process has (at least in the past), triggered a merge with minor formatting changes, or other data normalization, not with my commit being accepted as-is. This is inconsistent with the typical Git experience, where one can submit a code change, and that change is typically accepted as is, or rejected with a note for necessary changes. When I've had to go back and make updates to my original post, I was surprised to find the JSON file modified.
  • The one time I made a mistake in my upload, the process for fixing that mistake was to modify my pull request. I didn't do it that way - I withdrew my pull request and resubmitted. Either way is confusing, and more steps.

What works well for me, as a submitter:

  • Collision detection
  • Familiar tooling
  • Automated validation of JSON
  • Strong assertion of identity (signed commits), using an identity mechanism independent of MITRE / CVE systems
  • More automated processing means fewer chances for errors.
  • A git commit can encompass multiple CVEs in a single submission
  • Better than what I ran into before, which involved submitting via the cveform, but not being able to submit the JSON to the cveform, because it exceeded the character limit. Which meant that I had to manually reply to the automated email reply that came from the MITRE systems, noting that the JSON was attached.

Some conclusions about improving the Git experience - if Git is still a desirable vehicle (even if not GitHub!):

  • Including all the CVEs ever in the github project is probably unnecessary - only include CVEs that people want to submit via that mechanism.
  • The structure of the repository is currently ordered around an arbitrary date-based taxonomy. A better taxonomy is probably CNA name, and then allow CNAs to structure submit as they wish underneath that, but including the CVE # at the beginning of a file name.
  • Avoid modifying submissions to the Git repository. Whatever a CNA submits is what ends up in the tree.
  • Document what to do if the pull request is rejected

I'm happy to work with whatever system MITRE ends up coming up with. My primary aim is to reduce the time it takes from me submitting information for publishing to having it actually published.

 

Eric.

 

 

On Tue, Apr 30, 2019 at 2:23 PM Art Manion <[hidden email]> wrote:

On 4/30/19 2:44 PM, Loren, Lewis A. wrote:
> All – The email below is incorrect, the board has made a final decision to move away from Github.  Chris Levendis misremembered the status when I inquired earlier and I wanted to send out a clarification at the earliest opportunity.  Chris had hoped to send the email himself, but is at the dentist and unable to do so, so in the interest of time, he asked me to send the update on his behalf.  I will leave this topic on the agenda for the next AWG meeting.

> All – during the meeting on April 29^th , there were questions about whether Github would continue to be used and the role of the AWG; I agreed to look into the issue and respond with my findings.  Currently, The SPWG is working on a position paper exploring the pros and cons of continuing to use Github in light of the EU’s General Data Protection Regulation (GDPR) and other factors.  Once complete, that paper will be provided to the Board so that they can make a decision.  Once the decision is made, the AWG will need to factor that decision into the “Entry Submission Service” which has yet to begin.
>
> Bottom line, it appears that a final decision has not yet been made and that AWG will be responsible for implementing the Entry Submission Service, which could be affected by the decision to continue using Github, or to implement an alternative service.

I've got a list of concerns about this decision, I'm going to list them here.  This isn't something I plan to argue further about, but we've reviewed what information we've been able to collect on this decision and I'll at least leave it on the record.

TLDR:  I don't see a compelling reason to move away from git, or Github.  No correspondingly strong reason to stay, but it's mostly(?) working so why fix it?

1. The decision.  I may have missed it, which is on me, but when exactly was the decision made?  I don't think there was a vote, was there a deadline, or a date when the discussion was scheduled?  I've heard bits from a board call and we got much more information from Kent.  I had a general sense that the SP WG was still preparing a proposal/documenting discussion from the Feb 26-27 meeting.

2. GDPR.  Github and every other code repository protocol and service have to sort this out, CVE is not special.  I'm betting that name and email address are required for functional reasons, like 17.3.(d):

   https://gdpr-info.eu/art-17-gdpr/

"...we are compliant with the General Data Protection Regulation (GDPR)"

   https://help.github.com/en/articles/github-privacy-statement

(I'm admittedly neither a lawyer nor privacy expert, but we shouldn't be jumping to premature fear/conclusions.)

3. Countries blocking Github (like China).  I'm 100% in favor of growing CVE and specifically trying to get CN-based vendors and researchers engaged.  But I don't think we should be working too hard to stay ahead of geopolitical issues, not our area.  CN might block a quasi-USG organization like MITRE for some reason.  Or the NGO/Foundation successor to the CVE Project.  Plus, just run a self-hosted git service.

Also, github is (currently) not blocked by China according to this:

   https://viewdns.info/chinesefirewall/?domain=github.com

4. Microsoft.  First, I doubt Microsoft is going to trash the world's biggest(?) public code repository.  If they do, self-hosted git service.

5. MITRE has dev resources available.  I think Microsoft has pitched in too.  This is great, thanks.  This enables change/new development, but shouldn't be the driver for it.

6. Transition to a new parent organization.  Which do you want to inherit, custom code or a git repo with some nice CI (OK, also some custom code, but based on common practices and the git framework).

All this said, I don't plan to argue further.  APIs in AWS sounds nice, I just don't see compelling reasons to change.  It's also entirely possible that allocation and other services end up pushing changes to a git repo (i.e., git/Github is still the authoritative, public, freely available, transparent, distributed, well-understood canonical record of CVE data).

Regards,

  - Art