Re: [PATCH] embargoed releases: also describe the git-security list and the process

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2022, 17:12 UTC
Message-ID: <xmqqtu4rv2wb.fsf@gitster.g>
In-Reply-To: <CADq8SzUUoi6=6ggxkeTUf2y0WmeAMMjuq8_OCej0smF7OabPiQ@mail.gmail.com>

[moving git-security@ to BCC; those who have been following the thread, please switch to the main list]

> All of Junio's edits and call-outs are reasonable and I'll incorporate
> them into the next version.

Thanks.

Show 7 quoted lines

>> > +- Once the review has settled and everyone involved in the review agrees that
>> > +  the patches are ready, the Git maintainer determines a release date as well
>>
>> s/maintainer determines/& and others determine/ or "stakeholders
>> discuss and agree on".  You might want to mention that the schedule
>> for disclosure and release tend to be constrained by so called patch
>> Tuesday, which is the least flexible among various binary packagers.

By the way, this "we account for patch Tuesday" is not "the only 800 pound gorilla in the room inherently has rights to dictate their terms". It is merely that "other packagers are being nice and extra accomodating", and when another even less flexible packager requests a prolonged schedule, we might accomodate their needs, depending on the nature of the issue.

On the other hand, the git users community may not be able to wait for the next month to apply an unusually urgent fix, and a binary packager with a coarse release granularity may have to be creative on such an occasion.

In this hypothetical timeline:

    A---B-B-B-B-B-B-B-B---C

              D0----E0           D1----E1 (next month)

where

    A: problem reported
    B: solution proposed, discussed, and finalized
    C: public coordinated disclosure and release date

    Dn: cut-off date for "monthly security updates" for a packager
    En: date "monthly security updates" is issued by a packager

the wider Git user community may not be able to afford to wait until date E1 of the next month by delaying C, even if date D0 for this month's "security updates" for a particular packager comes before the solution gets finalized.

If the coordinated release C falls after the deadline D0 for the upcoming "monthly security updates" (not singling out Microsoft by mentioning "patch Tuesdays" anymore, as this applies generally to anybody whose release granularity is more coarse than other distros find comfortahble for security fixes) for a packager, but if an early round of proposed fix is seen, they can independently make their own judgement to include the non-final fix in their binary release at their cut-off date D0, while withholding the source at least to the agreed upon coordinate disclosure date C, for example.

They may later want to update to the final fix by date D1 to be included in their next "monthly security updates" on date E1, which would be an extra work, but that is the cost of running a coarse release schedule.

I do not know how to concisely phrase the above to fit in the framework of your document, but some of the above issues were brought up elsewhere, so I thought I'd better share it here.

Thanks.