[RFC] Publishing glibc advisories

[RFC] Publishing glibc advisories

[Siddhesh Poyarekar]

Hello folks,

I'm working on a way to publish glibc advisories and my first thought 
was to host all advisories in the repository in a `advisories` toplevel 
directory, but there's a bunch of information that is typically shared, 
that will be cumbersome to maintain within the repository.

As a result, I am thinking of requesting a separate repository, e.g. 
glibc-advisories.git to host the advisory files along with scripts to 
process them.  I'm thinking of using the OSV[1] format for the advisory 
files since that appears to be the growing standard for maintaining and 
sharing CVE information.

For formal announcements of CVEs (typically when they're fixed) I was 
thinking of sending out notifications to the openwall oss-security 
mailing list[2] since again, that seems to be where a bunch of FOSS 
projects that do their own security announcements send their notifications.

Any thoughts or comments on this?

Thanks,
Sid

[1] https://ossf.github.io/osv-schema/
[2] https://www.openwall.com/lists/oss-security/

Re: [RFC] Publishing glibc advisories

[Noah Goldstein]

On Thu, Oct 12, 2023 at 4:50 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> Hello folks,
>
> I'm working on a way to publish glibc advisories and my first thought
> was to host all advisories in the repository in a `advisories` toplevel
> directory, but there's a bunch of information that is typically shared,
> that will be cumbersome to maintain within the repository.
>
> As a result, I am thinking of requesting a separate repository, e.g.
> glibc-advisories.git to host the advisory files along with scripts to
> process them.  I'm thinking of using the OSV[1] format for the advisory
> files since that appears to be the growing standard for maintaining and
> sharing CVE information.
>
> For formal announcements of CVEs (typically when they're fixed) I was
> thinking of sending out notifications to the openwall oss-security
> mailing list[2] since again, that seems to be where a bunch of FOSS
> projects that do their own security announcements send their notifications.
>
> Any thoughts or comments on this?

Personally would think it makes more sense to keep in the current repo.
Not everyone checking out the code will know to look for glibc-advisories.git
so it just seems liable to cause people to miss them.
>
> Thanks,
> Sid
>
> [1] https://ossf.github.io/osv-schema/
> [2] https://www.openwall.com/lists/oss-security/

Re: [RFC] Publishing glibc advisories

[Siddhesh Poyarekar]

On 2023-10-12 18:09, Noah Goldstein wrote:
> Personally would think it makes more sense to keep in the current repo.
> Not everyone checking out the code will know to look for glibc-advisories.git
> so it just seems liable to cause people to miss them.

Oh so the code would continue to have the information it currently does, 
e.g. CVE numbers in the commits and in NEWS.  This is for additional 
information that gets announced as advisories, that refer to, e.g. 
commits in the repository that contributed to fixing the CVE, branches 
the fixes were backported to, etc.  Here are some example announcements:

https://www.openwall.com/lists/oss-security/2023/10/11/1
https://mail.python.org/archives/list/security-announce@python.org/thread/TRTM4UVSANUWNHC2QY2X73E5IBQLQU76/
https://www.openwall.com/lists/oss-security/2023/10/10/9

All of them admittedly share different amounts of information, but I was 
hoping for us to be as informative as possible.

Thanks,
Sid

Re: [RFC] Publishing glibc advisories

[Noah Goldstein]

On Thu, Oct 12, 2023 at 5:25 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2023-10-12 18:09, Noah Goldstein wrote:
> > Personally would think it makes more sense to keep in the current repo.
> > Not everyone checking out the code will know to look for glibc-advisories.git
> > so it just seems liable to cause people to miss them.
>
> Oh so the code would continue to have the information it currently does,
> e.g. CVE numbers in the commits and in NEWS.  This is for additional
> information that gets announced as advisories, that refer to, e.g.
> commits in the repository that contributed to fixing the CVE, branches
> the fixes were backported to, etc.  Here are some example announcements:
>
> https://www.openwall.com/lists/oss-security/2023/10/11/1
> https://mail.python.org/archives/list/security-announce@python.org/thread/TRTM4UVSANUWNHC2QY2X73E5IBQLQU76/
> https://www.openwall.com/lists/oss-security/2023/10/10/9
>

I see, so the expectation is all actionable information would be in the glibc
git, and the purely information stuff would be in advisories-glibc.git? If so
that seems reasonable.

> All of them admittedly share different amounts of information, but I was
> hoping for us to be as informative as possible.
>
> Thanks,
> Sid

Re: [RFC] Publishing glibc advisories

[DJ Delorie]

Is it the mechanics of the repo that are the problem, or the rules that
come with mixing with our source code?

I'm thinking, an unrooted branch in glibc.git would let us use the same
git repo but keep the new information separate from the source tree.

Re: [RFC] Publishing glibc advisories

[Siddhesh Poyarekar]

On 2023-10-12 19:26, DJ Delorie wrote:
> 
> Is it the mechanics of the repo that are the problem, or the rules that
> come with mixing with our source code?

I think both; the machanics are unwieldy *and* it seems wrong to mix 
data with the source of data.

> I'm thinking, an unrooted branch in glibc.git would let us use the same
> git repo but keep the new information separate from the source tree.

It still kinda mixes data with the source of that data, which seems 
unsanitary.

Thanks,
Sid

Re: [RFC] Publishing glibc advisories

[Siddhesh Poyarekar]

On 2023-10-12 18:59, Noah Goldstein wrote:
> On Thu, Oct 12, 2023 at 5:25 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-10-12 18:09, Noah Goldstein wrote:
>>> Personally would think it makes more sense to keep in the current repo.
>>> Not everyone checking out the code will know to look for glibc-advisories.git
>>> so it just seems liable to cause people to miss them.
>>
>> Oh so the code would continue to have the information it currently does,
>> e.g. CVE numbers in the commits and in NEWS.  This is for additional
>> information that gets announced as advisories, that refer to, e.g.
>> commits in the repository that contributed to fixing the CVE, branches
>> the fixes were backported to, etc.  Here are some example announcements:
>>
>> https://www.openwall.com/lists/oss-security/2023/10/11/1
>> https://mail.python.org/archives/list/security-announce@python.org/thread/TRTM4UVSANUWNHC2QY2X73E5IBQLQU76/
>> https://www.openwall.com/lists/oss-security/2023/10/10/9
>>
> 
> I see, so the expectation is all actionable information would be in the glibc
> git, and the purely information stuff would be in advisories-glibc.git? If so
> that seems reasonable.

Exactly that, yes.

Thanks,
Sid

Re: [RFC] Publishing glibc advisories

[Frank Ch. Eigler]

> [...]
>> I'm thinking, an unrooted branch in glibc.git would let us use the same
>> git repo but keep the new information separate from the source tree.
>
> It still kinda mixes data with the source of that data, which seems
> unsanitary.

As long as the branch/tag namespaces don't overlap, there's no problem
with such an arrangement.  The histories don't need to intermingle - but
still could if you wanted to, for example to develop fixes for some
particular cve on a forked side branch.

- FChE

Re: [RFC] Publishing glibc advisories

[Florian Weimer]

* Siddhesh Poyarekar:

> I'm working on a way to publish glibc advisories and my first thought
> was to host all advisories in the repository in a `advisories`
> toplevel directory, but there's a bunch of information that is
> typically shared, that will be cumbersome to maintain within the
> repository.

I think we should put it in the main repository.  It's easier to
integrate it with our current review prcedures.

> As a result, I am thinking of requesting a separate repository,
> e.g. glibc-advisories.git to host the advisory files along with
> scripts to process them.  I'm thinking of using the OSV[1] format for
> the advisory files since that appears to be the growing standard for
> maintaining and sharing CVE information.

It's more important that we include information about impacted commit
ranges, including backports to release branches.  We should leave the
format to others.  I have not seen many folks publishing data in OSV
format.

> For formal announcements of CVEs (typically when they're fixed) I was
> thinking of sending out notifications to the openwall oss-security
> mailing list[2] since again, that seems to be where a bunch of FOSS
> projects that do their own security announcements send their
> notifications.

We could also send it to libc-announce (separately).

Thanks,
Florian

Re: [RFC] Publishing glibc advisories

[Siddhesh Poyarekar]

On 2023-10-13 03:40, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> I'm working on a way to publish glibc advisories and my first thought
>> was to host all advisories in the repository in a `advisories`
>> toplevel directory, but there's a bunch of information that is
>> typically shared, that will be cumbersome to maintain within the
>> repository.
> 
> I think we should put it in the main repository.  It's easier to
> integrate it with our current review prcedures.

Hmm, I guess I'm mainly concerned about referring to commit fixes, 
everything else may be easy enough to maintain in the same patchset as 
the CVE fixed and could be trivially backported.  It still feels 
unsanitary to me, but fair enough, since that seems to be the preference 
and I agree it integrates easily with our current review procedures.

>> As a result, I am thinking of requesting a separate repository,
>> e.g. glibc-advisories.git to host the advisory files along with
>> scripts to process them.  I'm thinking of using the OSV[1] format for
>> the advisory files since that appears to be the growing standard for
>> maintaining and sharing CVE information.
> 
> It's more important that we include information about impacted commit
> ranges, including backports to release branches.  We should leave the
> format to others.  I have not seen many folks publishing data in OSV
> format.

Python uses the OSV format[1], I haven't looked hard to see who else 
does, but there does seem to be a growing movement around it.  I don't 
feel too strongly about it though, we can leave the OSV format to others 
or consider it later if we feel like it.  In that case, we could do a 
simple git-commit-like format with a subject line and free text 
description along with tags to add specific data, e.g. Affected-ref: 
<ref>, Reported-by: <entity>, Fixed-by: <one for each ref>, etc.

Impacted commit ranges are the easy bit, refs for fixes are not. 
However, I wonder if it would be acceptable to add git tags to mark the 
fix refs, e.g. CVE-2023-4911_glibc-2.39_1, CVE-2023-4911_glibc-2.38_1, 
CVE-2023-4806_glibc-2.34_1, CVE-2023-4806_glibc-2.34_2, etc.  That would 
eliminate the need for a Fixed-by tag and a script could auto-generate 
that information for the announcement text (or even to list commit refs 
for a specific branch) from the git tags.

That could also make the separation of effort clearer; the developer 
fixing the CVE would be responsible for writing the text and tagging the 
commit refs and someone from the CNA team would be responsible for 
generating the announcement and sending it out.  To begin with, maybe 
the CNA team could help with tagging, until everyone's used to the 
process or we figure out a way to automate it.  What do you think?

>> For formal announcements of CVEs (typically when they're fixed) I was
>> thinking of sending out notifications to the openwall oss-security
>> mailing list[2] since again, that seems to be where a bunch of FOSS
>> projects that do their own security announcements send their
>> notifications.
> 
> We could also send it to libc-announce (separately).

Agreed, so oss-security and libc-announce.

Thanks,
Sid

[1] https://github.com/psf/advisory-database

Re: [RFC] Publishing glibc advisories

[Florian Weimer]

* Siddhesh Poyarekar:

> On 2023-10-13 03:40, Florian Weimer wrote:
>> * Siddhesh Poyarekar:
>> 
>>> I'm working on a way to publish glibc advisories and my first thought
>>> was to host all advisories in the repository in a `advisories`
>>> toplevel directory, but there's a bunch of information that is
>>> typically shared, that will be cumbersome to maintain within the
>>> repository.
>> I think we should put it in the main repository.  It's easier to
>> integrate it with our current review prcedures.
>
> Hmm, I guess I'm mainly concerned about referring to commit fixes,
> everything else may be easy enough to maintain in the same patchset as
> the CVE fixed and could be trivially backported.  It still feels
> unsanitary to me, but fair enough, since that seems to be the
> preference and I agree it integrates easily with our current review
> procedures.

We'll have to update the advisory anyway once people do more backports.
The initial list of releases will likely grow over time.

>>> As a result, I am thinking of requesting a separate repository,
>>> e.g. glibc-advisories.git to host the advisory files along with
>>> scripts to process them.  I'm thinking of using the OSV[1] format for
>>> the advisory files since that appears to be the growing standard for
>>> maintaining and sharing CVE information.
>> It's more important that we include information about impacted
>> commit
>> ranges, including backports to release branches.  We should leave the
>> format to others.  I have not seen many folks publishing data in OSV
>> format.
>
> Python uses the OSV format[1], I haven't looked hard to see who else
> does, but there does seem to be a growing movement around it.  I don't
> feel too strongly about it though, we can leave the OSV format to
> others or consider it later if we feel like it.  In that case, we
> could do a simple git-commit-like format with a subject line and free
> text description along with tags to add specific data,
> e.g. Affected-ref: <ref>, Reported-by: <entity>, Fixed-by: <one for
> each ref>, etc.

I think we should focus on content first, and once we know what we need,
we can start formalizing it if we still feel like it. 8-)

> Impacted commit ranges are the easy bit, refs for fixes are
> not. However, I wonder if it would be acceptable to add git tags to
> mark the fix refs, e.g. CVE-2023-4911_glibc-2.39_1,
> CVE-2023-4911_glibc-2.38_1, CVE-2023-4806_glibc-2.34_1,
> CVE-2023-4806_glibc-2.34_2, etc.  That would eliminate the need for a
> Fixed-by tag and a script could auto-generate that information for the
> announcement text (or even to list commit refs for a specific branch)
> from the git tags.

In my experience, tags are rather cumbersome.  What's worse, people will
demand signed tags, and then we have to figure out key management for
that.  Tags can move, too, but these really shouldn't.  I think we
should just mention commit hashes.

Thanks,
Florian