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):
"...we are compliant with the General Data Protection Regulation (GDPR)"
(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:
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).
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:
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].
On Wed, May 1, 2019 at 8:45 AM Bruce Lowenthal <[hidden email]> wrote:
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.
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:
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.
Lewis A. Loren, Ph.D.
T856 Co-Department Head
People like to say that the conflict is between good and evil.
The real conflict is between truth and lies – Don Miguel Ruiz
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.
PSIRT, Security Research and Operations
Cisco Systems, Inc.
Email: [hidden email]
Phone: <a href="tel:+1%20919%20392%208635">+1 919 392 8635
PGP Key: 0x3AF27EDC
|Free forum by Nabble||Edit this page|