[-cc git-security]
On Wed, Oct 19, 2022 at 01:16:00AM +0000, Julia Ramer via GitGitGadget wrote:
> +Audience of the `git-security` mailing list
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Anybody may contact the `git-security` mailing list by sending an email
> +to <git-security@xxxxxxxxxxxxxxxx>, though the archive is closed to the
> +public and only accessible to subscribed members.
> +
> +There are a few dozen subscribed members: core Git developers who are trusted
> +with addressing vulnerabilities, and stakeholders (i.e. owners of products
> +affected by security vulnerabilities in Git).
Everything in this section looks good. Though I wonder whether readers
will wonder how one subscribes to the list. You sort of address this
earlier in the proposed document, but I think it's worth clarifying here
to indicate the differences between subscribing to a public list like
this one, and the invite-only git-security list.
Perhaps something like:
[...] the archive is closed to the public, and only accessible to
invited members.
There are a few dozen such members: [...]
which is basically just s/subscribed/invited, but I think it adds some
worthwhile clarity.
> +Most of the discussions revolve around assessing the severity of the reported
> +bugs (including the decision whether the report is security-relevant or can be
> +redirected to the public mailing list), how to remediate the bug, determining
> +the timeline of the disclosure as well as aligning priorities and
> +requirements.
Looks good, though I am unsure what "priorities and requirements" refers
to specifically. Could you elaborate?
> +A bug's life: Typical timeline
> +------------------------------
> +
> +- A bug is reported to the `git-security` mailing list.
> +
> +- Within a couple of days, someone from the core Git team responds with an
> + initial assessment of the bug’s severity.
A few nitpicks on this and the above bullet point:
- The git-security list isn't for bug reports, though there can be a
security component to something that looks like a bug report.
Perhaps to be clearer we should swap "bug" for "potential
vulnerability"?
- On "within a couple of days", I think that this is aspirationally
true, though not always the case. Perhaps, "as soon as possible"
instead? That's vague enough that I wouldn't worry about somebody
reading this document >2 days after submitting a potential
vulnerability wondering why nobody has gotten back to them ;-).
- Finally, consider replacing "core Git team" with "member of the
git-security list".
> +- Depending on the preferences of the involved contributors and reviewers, code
> + review then happens either on the `git-security` mailing list or in a private
> + fork associated with the draft security advisory.
There's a third option, too, which is using the private git/cabal
repository. Anybody who is a member of the @git/security team on GitHub
has access to this repository. And it is often a convenient option for
coordinating releases that contain fixes for more than one
vulnerability.
There aren't any hard and fast rules for which approach should be used
in a given circumstance, but I think it's worth mentioning it as another
option.
For my own $.02, I often find it useful to *start* by sending patches to
the git-security list inline with the thread so that the original
reporter (who is more often than not *not* a member of the @git/security
team) can participate in review (or at least look at the patches).
The private forks tied to a security advisory are often convenient
(assuming that the reporter has a GitHub account) since they provide a
shared workspace. But I think we usually avoid them when working on
preparing a release for more than one vulnerability.
> +- Once the review has settled and everyone involved in the review agrees that
> + the patches are ready, the Git maintainer, and others determine a release date
> + as well as the release trains that are serviced. The decision regarding which
> + versions need a backported fix is based on input from the reporter, the
> + contributor who worked on the patches, and from stakeholders (e.g. operators
> + of hosting sites who may want to analyze whether the given bug is exploited
> + via any of the repositories they host).
> +
> +- While the Git community does its best to accommodate the specific timeline
> + requests of the various binary packagers, the nature of the issue may preclude
> + a prolonged release schedule. For fixes deemed urgent, it may be in the best
> + interest of the Git users community to shorten the disclosure and release
> + timeline, and packagers may need to adapt accordingly.
I strongly agree with the above two points.
> +- Public communication is then prepared in advance of the release date. This
> + includes blog posts and mails to the Git and Git for Windows mailing lists.
For what it's worth, GitHub does usually prepare a public blog post, but
I don't think we've typically shared them with the git-security list
ahead of time. Not because there's anything sensitive in there (I
personally would have no problem sharing them with git-security ahead of
time if there was interest), but just because nobody has asked. It may
be worth clarifying which communications we expect to have reviewed by
the git-security list during this period and which we do not.
> +The first step is to https://github.com/git/git/security/advisories/new[open
> +an advisory]. Technically, this is not necessary. However, it is the most
> +convenient way to obtain the CVE number and it give us a private repository
> +associated with it that can be used to collaborate on a fix.
This is all good. I would add some of the things we need to figure out
before opening a security advisory, too. By the time we want to open a
security advisory, we need to have the following information decided
upon:
- Affected version(s)
- Patched version(s)
- Impact
- Potential workaround(s), if any
- Credit for finding and fixing the vulnerability
Determining which versions to patch is more-or-less up to the person
preparing those patches. Affected versions is usually "everything", or
"everything since xyz patch was merged". Impact is up for debate, though
usually whoever opens the security advisory writes this, and then
discussion occurs on the git-security as to its accuracy ;-).
Obtaining permission to give credit to the original reporter (and
anybody that they wish to include who was also involved in the
discovery) is important to do at this step, too.
Thanks,
Taylor
