-
A potential vulnerability is reported to the git-security mailing list.
-
The members of the git-security list start a discussion to give an initial
assessment of the severity of the reported potential vulnerability.
We aspire to do so within a few days.
-
After discussion, if consensus is reached that it is not critical enough
to warrant any embargo, the reporter is redirected to the public Git mailing
list. This ends the reporter’s interaction with the git-security list.
-
If it is deemed critical enough for an embargo, ideas are presented on how to
address the vulnerability.
-
Usually around that time, the Git maintainer or their delegate(s) open a draft
security advisory in the git/git repository on GitHub (see below for more
details).
-
Code review can take place in a variety of different locations,
depending on context. These are: patches sent inline on the git-security list,
a private fork on GitHub associated with the draft security advisory, or the
git/cabal repository.
-
Contributors working on a fix should consider beginning by sending
patches to the git-security list (inline with the original thread), since they
are accessible to all subscribers, along with the original reporter.
-
Once the review has settled and everyone involved in the review agrees that
the patches are nearing the finish line, 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. Operators of hosting sites who may want to analyze whether the
given issue is exploited via any of the repositories they host, and binary
packagers who want to make sure their product gets patched adequately against
the vulnerability, for example, may want to give their input at this stage.
-
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.
-
Subsequently, branches with the fixes are pushed to the git/cabal repository.
-
The tags are created by the Git maintainer and pushed to the same repository.
-
The Git for Windows, Git for macOS, BSD, Debian, etc. maintainers prepare the
corresponding release artifacts, based on the tags created that have been
prepared by the Git maintainer.
-
The release artifacts prepared by various binary packagers can be
made available to stakeholders under embargo via a mail to the
git-security list.
-
Less than a week before the release, a mail with the relevant information is
sent to <distros@vs.openwall.org> (see below), a list used to pre-announce
embargoed releases of open source projects to the stakeholders of all major
distributions of Linux as well as other OSes.
-
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.
-
On the day of the release, at around 10am Pacific Time, the Git maintainer
pushes the tag and the master branch to the public repository, then sends
out an announcement mail.
-
Once the tag is pushed, the Git for Windows maintainer publishes the
corresponding tag and creates a GitHub Release with the associated release
artifacts (Git for Windows installer, Portable Git, MinGit, etc).
-
Git for Windows release is then announced via a mail to the public Git and
Git for Windows mailing lists as well as via a tweet.
-
Ditto for distribution packagers for Linux and other platforms:
their releases are announced via their preferred channels.
-
A mail to <oss-security@lists.openwall.org> (see below for details) is sent
as a follow-up to the <distros@vs.openwall.org> one, describing the
vulnerability in detail, often including a proof of concept of an exploit.