GNU C Library as its own CNA?

GNU C Library as its own CNA?

[Siddhesh Poyarekar]

Hello folks,

We have, for many years, been using distribution security teams to help 
with CVE triage and assignment.  It has worked for the most part, but 
it's not uncommon to have CVEs assigned by organizations that don't 
always have a proper understanding of the security impact of bugs in 
glibc despite us having a clearly documented Security Process[1]; a 
recent example is CVE-2023-0687[2], which we had to jump through many 
hoops just to get it disputed and get the record straight on the bug.

If the GNU C Library had it's own CNA, all vulnerabilities reported 
against CVE would have to come to this CNA for triage, thus making sure 
that security issues in glibc get correctly assessed.  As root CNA, Red 
Hat is open to sponsoring FOSS organizations[3] that are willing to have 
their own CNA, subject to certain conditions (all organizational) being 
met.  Is this something that would interest the community?

I am volunteering to take primary responsibility in helping set things 
up, including coordination with the CTI (for whatever additional 
infrastructure this would need), coordination with Red Hat and helping 
build consensus on what the organizational structure should look like.

At the outset, we'll need to have broad agreement on the following:

1. How should users submit issues?  We would need an independent, 
private mailing list, possibly one that can also do PGP for users to 
report security issues.

2. Identify a group of people who ought to be on that list.  A starting 
group could be a cross section of named maintainers from various 
distributions and FSF stewards but we probably need a way to make sure 
that the group is inclusive without being too broad.

3. A formal representation to the root CNA, i.e. Red Hat.  We would need 
a group of volunteers that would be willing to step in as signees for 
this.  I'm in, but I can't do it alone and would need more volunteers; 
it could perhaps be the same set of people who would be part of the 
initial security team in (2).

Thanks,
Sid

[1] https://sourceware.org/glibc/wiki/Security%20Process
[2] https://vuldb.com/?id.220246
[3] https://access.redhat.com/articles/red_hat_cve_program

Re: GNU C Library as its own CNA?

[Florian Weimer]

* Siddhesh Poyarekar:

> At the outset, we'll need to have broad agreement on the following:
>
> 1. How should users submit issues?  We would need an independent,
> private mailing list, possibly one that can also do PGP for users to
> report security issues.
>
> 2. Identify a group of people who ought to be on that list.  A
> starting group could be a cross section of named maintainers from
> various distributions and FSF stewards but we probably need a way to
> make sure that the group is inclusive without being too broad.
>
> 3. A formal representation to the root CNA, i.e. Red Hat.  We would
> need a group of volunteers that would be willing to step in as signees
> for this.  I'm in, but I can't do it alone and would need more
> volunteers; it could perhaps be the same set of people who would be
> part of the initial security team in (2).

I think the CNA rules sort of assume that a CNA issues security
advisories:

  <https://www.cve.org/ResourcesSupport/AllResources/CNARules>

So we'd have to start doing that, too.

Thanks,
Florian

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-07-28 12:09, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> At the outset, we'll need to have broad agreement on the following:
>>
>> 1. How should users submit issues?  We would need an independent,
>> private mailing list, possibly one that can also do PGP for users to
>> report security issues.
>>
>> 2. Identify a group of people who ought to be on that list.  A
>> starting group could be a cross section of named maintainers from
>> various distributions and FSF stewards but we probably need a way to
>> make sure that the group is inclusive without being too broad.
>>
>> 3. A formal representation to the root CNA, i.e. Red Hat.  We would
>> need a group of volunteers that would be willing to step in as signees
>> for this.  I'm in, but I can't do it alone and would need more
>> volunteers; it could perhaps be the same set of people who would be
>> part of the initial security team in (2).
> 
> I think the CNA rules sort of assume that a CNA issues security
> advisories:
> 
>    <https://www.cve.org/ResourcesSupport/AllResources/CNARules>
> 
> So we'd have to start doing that, too.

Yes, and we would have to honour some SLAs for the entire process, from 
acknowledging CVEs to making them public.  I reckon we could still rely 
on some help from distro maintainers for some of this coordination.

Sid

Re: GNU C Library as its own CNA?

[Joseph Myers]

On Fri, 28 Jul 2023, Siddhesh Poyarekar wrote:

> 1. How should users submit issues?  We would need an independent, private
> mailing list, possibly one that can also do PGP for users to report security
> issues.

Probably at least 95% of glibc security issues are low-risk and most 
appropriately submitted in public to Bugzilla (the exceptions being things 
such as CVE-2015-7547).  If we add some kind of private submission 
mechanism, we should also strongly discourage its use for the bulk of 
low-risk issues to avoid adding unnecessary overhead for those.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GNU C Library as its own CNA?

[Paul Eggert]

On 2023-07-28 09:41, Joseph Myers wrote:
> If we add some kind of private submission
> mechanism, we should also strongly discourage its use for the bulk of
> low-risk issues to avoid adding unnecessary overhead for those.

One possibility is to use an already-existing submission mechanism, 
namely the GNU Security Escalation Contact <security@gnu.org>. For what 
it's worth, that mailing list gets little email, mostly false alarms.

https://savannah.gnu.org/mail/?group=security

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-07-28 12:41, Joseph Myers wrote:
> On Fri, 28 Jul 2023, Siddhesh Poyarekar wrote:
> 
>> 1. How should users submit issues?  We would need an independent, private
>> mailing list, possibly one that can also do PGP for users to report security
>> issues.
> 
> Probably at least 95% of glibc security issues are low-risk and most
> appropriately submitted in public to Bugzilla (the exceptions being things
> such as CVE-2015-7547).  If we add some kind of private submission
> mechanism, we should also strongly discourage its use for the bulk of
> low-risk issues to avoid adding unnecessary overhead for those.
> 

Agreed, we already encourage filing public reports[1].  Only the target 
of the private reports would change, from distro emails to a glibc email.

Sid

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=SECURITY.md#l126

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

Hello,

Trying to revive this conversation since there haven't been any 
objections to this.

On 2023-07-28 11:56, Siddhesh Poyarekar wrote:
> 2. Identify a group of people who ought to be on that list.  A starting 
> group could be a cross section of named maintainers from various 
> distributions and FSF stewards but we probably need a way to make sure 
> that the group is inclusive without being too broad.
> 
> 3. A formal representation to the root CNA, i.e. Red Hat.  We would need 
> a group of volunteers that would be willing to step in as signees for 
> this.  I'm in, but I can't do it alone and would need more volunteers; 
> it could perhaps be the same set of people who would be part of the 
> initial security team in (2).

Who ought to qualify as volunteers?  I reckon at least one distro 
maintainer per distro who also already has write access to the repo and 
maybe some others.

Thanks,
Sid

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-07-28 13:28, Paul Eggert wrote:
> On 2023-07-28 09:41, Joseph Myers wrote:
>> If we add some kind of private submission
>> mechanism, we should also strongly discourage its use for the bulk of
>> low-risk issues to avoid adding unnecessary overhead for those.
> 
> One possibility is to use an already-existing submission mechanism, 
> namely the GNU Security Escalation Contact <security@gnu.org>. For what 
> it's worth, that mailing list gets little email, mostly false alarms.
> 
> https://savannah.gnu.org/mail/?group=security

Or alternatively, a private mailing list on sourceware alongside other 
current lists.  One of the future challenges may be to support encrypted 
submissions since that seems to be a preference for some security 
researchers.  We could do that for now by just listing public keys of 
volunteers in the security group but if we end up with too many such 
submissions or have too many volunteers or otherwise have operational 
difficulties then we may have to think of another solution.

Thanks,
Sid

Re: GNU C Library as its own CNA?

[Florian Weimer]

* Paul Eggert:

> On 2023-07-28 09:41, Joseph Myers wrote:
>> If we add some kind of private submission
>> mechanism, we should also strongly discourage its use for the bulk of
>> low-risk issues to avoid adding unnecessary overhead for those.
>
> One possibility is to use an already-existing submission mechanism,
> namely the GNU Security Escalation Contact <security@gnu.org>. For
> what it's worth, that mailing list gets little email, mostly false
> alarms.
>
> https://savannah.gnu.org/mail/?group=security

That's not the documented purpose of <security@gnu.org>:

| Security Team
| 
| The Security Team <security@gnu.org> helps to resolve security bugs in
| a timely fashion. If the maintainer of a GNU package fails to respond
| to a report of a security flaw, the reporter can escalate the issue to
| the security team. If it decides the issue is urgent, it can develop a
| patch and publish a fixed release of the package. Maintainers can also
| ask the security team for advice in securing their packages.
| 
| New members are recruited from existing GNU volunteers when needed.

<https://www.gnu.org/gnu/gnu-structure.html#security>

It's clearly not intended as an external first point of contact.

Thanks,
Florian

Re: GNU C Library as its own CNA?

[Paul Eggert]

On 2023-09-06 05:33, Florian Weimer wrote:
> That's not the documented purpose of<security@gnu.org>:

Good point; we'd need to change that mailing list's purpose. There would 
be pros and cons for that, the pros being mostly for people sending in 
bug reports (because to them it's simpler to have one security contact 
point for all GNU projects) and the cons being mostly for us.

Re: GNU C Library as its own CNA?

[Florian Weimer]

* Paul Eggert:

> On 2023-09-06 05:33, Florian Weimer wrote:
>> That's not the documented purpose of<security@gnu.org>:
>
> Good point; we'd need to change that mailing list's purpose. There
> would be pros and cons for that, the pros being mostly for people
> sending in bug reports (because to them it's simpler to have one
> security contact point for all GNU projects) and the cons being mostly
> for us.

But the people behind <security@gnu.org> would need some way to contact
glibc developers in private.  At that point, we can just that means of
contact to the general public, no?

Thanks,
Florian

Re: GNU C Library as its own CNA?

[Paul Eggert]

On 2023-09-06 09:33, Florian Weimer wrote:
> But the people behind<security@gnu.org>  would need some way to contact
> glibc developers in private.  At that point, we can just that means of
> contact to the general public, no?

That depends on what our goals are. If we want a simple face to the 
outside world there should be just one security contact for the GNU 
project; this is how most software developer organizations work. If we 
want to simplify our internal operations, and avoid delays in routing 
reports internally from one set of developers to another, we should have 
a separate security contact for each package.

It's easier for us to do the latter, obviously.

Re: GNU C Library as its own CNA?

[Alexandre Oliva]

On Sep  6, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> Trying to revive this conversation since there haven't been any
> objections to this.

FWIW, I looked brienfly into GNU's becoming a CNA, and...  that didn't
look good.

The web site to as much as get information about the process was fully
javascrippled, which not only made the information inaccessible to me,
but made me realize that GNU shouldn't recommend anyone to use that web
site.

There are tow angles to that:

- JavaScript on web pages served by third parties is often nonfree
  software to boot, but even when it is licensed in freedom-respecting
  terms, the specific setting (served out by a remote server, run by a
  third party, for blind and unmodified execution on one's own computer)
  is analogous to Tivoization, that renders the software ultimately
  nonfree for users that run it that way

- JavaScript on web browsers opens a gratuitous and huge attack surface,
  that IMHO no self-respecting security professional should voluntarily
  expose, and no self-respecting security organization should impose on
  its users, especially those in charge of improving security.  It's an
  extremely poor example of promoting insecurity, as we all know that
  these sandboxes are porous and constantly threatened, and there's no
  defensible reason to require them to begin with.

I hope someone with access to that organization can pass on this
constructive criticism and recommend them to drop this self-defeating
requirements from their web pages, so that we can consider joining as a
CNA, whether as a package or as a project.

Thanks,

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-06 14:35, Alexandre Oliva wrote:
> I hope someone with access to that organization can pass on this
> constructive criticism and recommend them to drop this self-defeating
> requirements from their web pages, so that we can consider joining as a
> CNA, whether as a package or as a project.

Are you implying that the decision to become a CNA (or not) has to be 
taken by the GNU maintainers and that volunteers from the glibc 
community cannot self-organize and do that?  If that is the case (and I 
assume there's no consensus since it looks like you raised an objection) 
then (like the LFIT case) it probably makes sense to have the FSF 
stewards vote to take that decision before we spend cycles trying to set 
things up.

Sid

Re: GNU C Library as its own CNA?

[Paul Eggert]

On 2023-09-06 11:57, Siddhesh Poyarekar wrote:
> 
> Are you implying that the decision to become a CNA (or not) has to be 
> taken by the GNU maintainers and that volunteers from the glibc 
> community cannot self-organize and do that?

In practice this sort of thing has been decentralized (one might even 
say "disorganized"...) and I don't think there's any requirement by the 
GNU project that it be centralized. It's merely a matter of what's 
better for users and maintainers.

Re: GNU C Library as its own CNA?

[Alexandre Oliva]

On Sep  6, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> On 2023-09-06 14:35, Alexandre Oliva wrote:
>> I hope someone with access to that organization can pass on this
>> constructive criticism and recommend them to drop this self-defeating
>> requirements from their web pages, so that we can consider joining as a
>> CNA, whether as a package or as a project.

> Are you implying that the decision to become a CNA (or not) has to be
> taken by the GNU maintainers and that volunteers from the glibc 
> community cannot self-organize and do that?

No, that would be reading too much into what I wrote about an earlier
attempt to make GNU a CNA.

I'd just be surprised if anyone serious about software freedom and
security would seriously consider engaging with that web site while it
remains detrimental to both of these concerns.

If we can find people who don't mind interacting with it as it is, I
suppose we might, but there might be continuity challenges, and, having
been denied access to the site because of javascrippling, I don't even
know how much of a commitment by any community it would amount to.

I expect finding people who care about freedom and security but don't
mind interacting with that website to be difficult, so that is a point
of concern for me.

If we do find a path forward, however, it would be useful to extend it
to all of GNU, because there was much interest, we just couldn't figure
out a way to make interaction viable.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-06 18:01, Alexandre Oliva wrote:
> No, that would be reading too much into what I wrote about an earlier
> attempt to make GNU a CNA.

OK, thanks for clarifying.  Then I continue to look for volunteers.

> I'd just be surprised if anyone serious about software freedom and
> security would seriously consider engaging with that web site while it
> remains detrimental to both of these concerns.
> 
> If we can find people who don't mind interacting with it as it is, I
> suppose we might, but there might be continuity challenges, and, having
> been denied access to the site because of javascrippling, I don't even
> know how much of a commitment by any community it would amount to.
> 
> I expect finding people who care about freedom and security but don't
> mind interacting with that website to be difficult, so that is a point
> of concern for me.
> 
> If we do find a path forward, however, it would be useful to extend it
> to all of GNU, because there was much interest, we just couldn't figure
> out a way to make interaction viable.

That would be a worthy goal, but it may be best to have individual CNAs 
for glibc, binutils, gcc, etc. because it allows the individual 
communities to nominate their own security teams for example and run 
independently.  Lets see how the glibc experiment goes and then we can 
extend the idea to other parts of the toolchain.

Thanks,
Sid

Re: GNU C Library as its own CNA?

[Alexandre Oliva]

On Sep  6, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> That would be a worthy goal, but it may be best to have individual
> CNAs for glibc, binutils, gcc, etc. because it allows the individual 
> communities to nominate their own security teams for example and run
> independently.

I had understood, from the conversations I had when the invitation to
join was presented to GNU, that making GNU the CNA, and then having GNU
packages under the GNU umbrella, would make things much simpler, and
would not stand in the way of nominating separate security teams for
specific packages.  So that seemed to make more sense to me.

I'm concerned that starting out with a package, as if it was
independent, would make it harder to bring it into the scope of the GNU
CNA once that was set up, so I'd rather avoid that hassle.

Now, if you're familiar with the requirements and processes, would you
be willing to advise us (GNU leadership and advisory committee) towards
becoming a CNA for GNU packages, with appointed security response teams
for GNU packages that have their own dedicated teams?

Thanks in advance,

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-06 23:27, Alexandre Oliva wrote:
> On Sep  6, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> That would be a worthy goal, but it may be best to have individual
>> CNAs for glibc, binutils, gcc, etc. because it allows the individual
>> communities to nominate their own security teams for example and run
>> independently.
> 
> I had understood, from the conversations I had when the invitation to
> join was presented to GNU, that making GNU the CNA, and then having GNU
> packages under the GNU umbrella, would make things much simpler, and
> would not stand in the way of nominating separate security teams for
> specific packages.  So that seemed to make more sense to me.

Maybe they were looking at GNU as a root CNA under Mitre, which requires 
much more compliance and formal organization as I understand it.  What 
I'm proposing is simpler, which is to become a CNA under Red Hat as the 
root CNA under its CVE program[1].  I think it's much easier for 
individual packages to do this as opposed to GNU trying to become root 
CNA directly under Mitre and then setting up individual teams/CNAs for 
packages under it.

> I'm concerned that starting out with a package, as if it was
> independent, would make it harder to bring it into the scope of the GNU
> CNA once that was set up, so I'd rather avoid that hassle.
> 
> Now, if you're familiar with the requirements and processes, would you
> be willing to advise us (GNU leadership and advisory committee) towards
> becoming a CNA for GNU packages, with appointed security response teams
> for GNU packages that have their own dedicated teams?

I still don't think a single CNA for all of GNU is a good idea because 
packages under GNU have very different processes and security 
requirements.  Maybe GNU as a root CNA (and then projects as subordinate 
CNAs) is something you may be interested in but I'm of limited use 
there.  Given the looseness of the setup for the subordinate CNAs, I 
don't think it should be too hard to move root CNAs later on if that is 
of interest to the community.

Thanks,
Sid

[1] https://access.redhat.com/articles/red_hat_cve_program

Re: GNU C Library as its own CNA?

[Florian Weimer]

* Siddhesh Poyarekar:

> On 2023-09-06 23:27, Alexandre Oliva wrote:
>> On Sep  6, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> 
>>> That would be a worthy goal, but it may be best to have individual
>>> CNAs for glibc, binutils, gcc, etc. because it allows the individual
>>> communities to nominate their own security teams for example and run
>>> independently.
>> I had understood, from the conversations I had when the invitation
>> to
>> join was presented to GNU, that making GNU the CNA, and then having GNU
>> packages under the GNU umbrella, would make things much simpler, and
>> would not stand in the way of nominating separate security teams for
>> specific packages.  So that seemed to make more sense to me.
>
> Maybe they were looking at GNU as a root CNA under Mitre, which
> requires much more compliance and formal organization as I understand
> it.  What I'm proposing is simpler, which is to become a CNA under Red
> Hat as the root CNA under its CVE program[1].  I think it's much
> easier for individual packages to do this as opposed to GNU trying to
> become root CNA directly under Mitre and then setting up individual
> teams/CNAs for packages under it.

GNU is not a legal entity, it would have to be the FSF for the root CNA
agreement.  Delegated CNAs do not need to be legal entities, that's up
to the root CNA to handle according to their policies.

Once the FSF has completed the paperwork, we can consindering the
existing GNU-related CNAs under the FSF root CNA umbrella.  Products and
teams move between organizations all the time, there must be a process
for this already.

A single CNA for GNU wouldn't work because once you are a CNA, it sort
of takes away the ability for any person within the CNA's scope to
interact directly with MITRE.  All communication about disputes, CVE
requests and updates etc. have to go through the CNA instead, so it's a
function that needs to be staffed appropriately.  A component-specific
CNA can just hand out API keys as appropriate, but that's going to be
difficult across the whole of GNU.  If the FSF is a root CNA, it can
management the component-specific CNAs on its own, as far as I
understand the process.

Thanks,
Florian

Re: GNU C Library as its own CNA?

[Alexandre Oliva]

On Sep  7, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> Maybe they were looking at GNU as a root CNA under Mitre

No, the invitation was from Red Hat, same thing you describe.

> I think it's much
> easier for individual packages to do this

It should be just as easy for GNU to do that, and then GNU packages can
enroll even more easily.  That was the picture I got from the
interactions at the time anyway, and it seemed to make sense.

On Sep  7, 2023, Florian Weimer <fweimer@redhat.com> wrote:

> GNU is not a legal entity

Minor point, but it is, it's just not incorporated.  The FSF is its
fiscal sponsor, so if we were talking about root CNA with MITRE, it
would indeed be the FSF that would sign the papers on behalf of GNU, at
GNU's request.

This is quite different from GNU libc, that's not incorporated and is
part of GNU, so ultimately in either case it is GNU and its delegates
who have the autonomy and legitimacy to enter agreements on behalf of
GNU and its parts.  That's why I find it more reasonable to have GNU as
the CNA, and interested GNU packages underneath.

> Products and teams move between organizations all the time, there must
> be a process for this already.

But why make for that trouble if we can help it by doing it right at
first?

> All communication about disputes, CVE
> requests and updates etc. have to go through the CNA instead, so it's a
> function that needs to be staffed appropriately.  A component-specific
> CNA can just hand out API keys as appropriate, but that's going to be
> difficult across the whole of GNU.

There appears to be a boatload of confusing assumptions here.  GNU, as a
larger entity, and with direct FSF support, is far more likely to be
able to staff one or more security teams appropriately than any of its
component packages.  And then, if any single GNU component package is
able to handle that job appropriately, then it follows that GNU can
handle that job appropriately, at least when it comes to that package.
Right?

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-07 13:14, Alexandre Oliva wrote:
> On Sep  7, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> Maybe they were looking at GNU as a root CNA under Mitre
> 
> No, the invitation was from Red Hat, same thing you describe.

Then it's not as root, which means it would be a single CNA for all of GNU.

>> I think it's much
>> easier for individual packages to do this
> 
> It should be just as easy for GNU to do that, and then GNU packages can
> enroll even more easily.  That was the picture I got from the
> interactions at the time anyway, and it seemed to make sense.

A single non-root CNA for all of the GNU project doesn't make sense to 
me, given that packages have very distinct communities and needs.  Maybe 
there's a case for some packages to band together because, e.g. they 
have small communities and a single group could handle their security 
needs but for projects like glibc and the other toolchain projects I 
think it makes sense to have separate CNAs.  I don't mind helping other 
GNU maintainers that want to set up their own CNA; for toolchain 
projects other than glibc I'm happy to be directly involved too since I 
actively work on them.

Thanks,
Sid

Re: GNU C Library as its own CNA?

[Alexandre Oliva]

On Sep  8, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:

> A single non-root CNA for all of the GNU project doesn't make sense to
> me, given that packages have very distinct communities and needs.

It seem like you're saying that GNU, as a CNA, would be unable to offer
to individual packages whatever it is that Red Hat, as root CNA, would.
Could you please elaborate on that distinction you're making?
Presumably you know more about it than I do, and if you're on to
something, that would suggest that GNU should pursue becoming a root
CNA, so that it can offer its packages the same sort of status you
appear to expect when you state that it would make no sense for them to
be under a non-root CNA.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: GNU C Library as its own CNA?

[Florian Weimer]

* Alexandre Oliva:

> On Sep  8, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
>> A single non-root CNA for all of the GNU project doesn't make sense to
>> me, given that packages have very distinct communities and needs.
>
> It seem like you're saying that GNU, as a CNA, would be unable to offer
> to individual packages whatever it is that Red Hat, as root CNA, would.
> Could you please elaborate on that distinction you're making?

I think we'd still want per-component CNAs, whether the GNU project is a
(root) CNA or not.

I suggest we start with Red Hat as the root CNA, get the glibc CNA set
up.  Once you have figured out the details with MITRE and the FSF and
the GNU root is established, we can move over.

Thanks,
Florian

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-10 12:57, Alexandre Oliva wrote:
> On Sep  8, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> A single non-root CNA for all of the GNU project doesn't make sense to
>> me, given that packages have very distinct communities and needs.
> 
> It seem like you're saying that GNU, as a CNA, would be unable to offer
> to individual packages whatever it is that Red Hat, as root CNA, would.
> Could you please elaborate on that distinction you're making?
> Presumably you know more about it than I do, and if you're on to
> something, that would suggest that GNU should pursue becoming a root
> CNA, so that it can offer its packages the same sort of status you
> appear to expect when you state that it would make no sense for them to
> be under a non-root CNA.

A root CNA may have subordinate CNAs under it that would be responsible 
for triage and CVE assignment for their project, a subordinate CNA may 
not.  It may be possible to have a single GNU subordinate CNA under Red 
Hat and then form a GNU security organization that emulates this 
internally somehow but I don't see the point of doing that because the 
security needs of individual projects in GNU vary widely and they're 
best served by their individual communities.

If GNU registers as a root CNA with Mitre at some point, like Florian 
said, the glibc CNA could just move under it.  It is pointless to try 
and complicate the process at this initial stage IMO.

Sid

Re: GNU C Library as its own CNA?

[Carlos O'Donell]

On 7/28/23 11:56, Siddhesh Poyarekar wrote:
> We have, for many years, been using distribution security teams to
> help with CVE triage and assignment.  It has worked for the most
> part, but it's not uncommon to have CVEs assigned by organizations
> that don't always have a proper understanding of the security impact
> of bugs in glibc despite us having a clearly documented Security
> Process[1]; a recent example is CVE-2023-0687[2], which we had to
> jump through many hoops just to get it disputed and get the record
> straight on the bug.
> 
> If the GNU C Library had it's own CNA, all vulnerabilities reported
> against CVE would have to come to this CNA for triage, thus making
> sure that security issues in glibc get correctly assessed.  As root
> CNA, Red Hat is open to sponsoring FOSS organizations[3] that are
> willing to have their own CNA, subject to certain conditions (all
> organizational) being met.  Is this something that would interest the
> community?
> 
> I am volunteering to take primary responsibility in helping set
> things up, including coordination with the CTI (for whatever
> additional infrastructure this would need), coordination with Red Hat
> and helping build consensus on what the organizational structure
> should look like.

Please include me in the list of volunteers.

I think this is a great step forward in reducing downstream CVE work by ensuring
we have a good upstream review process.
 
> At the outset, we'll need to have broad agreement on the following:
> 
> 1. How should users submit issues?  We would need an independent,
> private mailing list, possibly one that can also do PGP for users to
> report security issues.

Start small. Private mailing list works. I expect we will have to publish and
accept PGP signed email to all volunteers. So we'll need to publish volunteer
keys, and have a process for withdrawing volunteer keys.
 
> 2. Identify a group of people who ought to be on that list.  A
> starting group could be a cross section of named maintainers from
> various distributions and FSF stewards but we probably need a way to
> make sure that the group is inclusive without being too broad.

Count me in.

> 3. A formal representation to the root CNA, i.e. Red Hat.  We would
> need a group of volunteers that would be willing to step in as
> signees for this.  I'm in, but I can't do it alone and would need
> more volunteers; it could perhaps be the same set of people who would
> be part of the initial security team in (2).

I'm in.
 
> Thanks, Sid
> 
> [1] https://sourceware.org/glibc/wiki/Security%20Process [2]
> https://vuldb.com/?id.220246 [3]
> https://access.redhat.com/articles/red_hat_cve_program
> 

-- 
Cheers,
Carlos.

Re: GNU C Library as its own CNA?

[Carlos O'Donell]

On 9/11/23 03:46, Florian Weimer wrote:
> * Alexandre Oliva:
> 
>> On Sep  8, 2023, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>>> A single non-root CNA for all of the GNU project doesn't make sense to
>>> me, given that packages have very distinct communities and needs.
>>
>> It seem like you're saying that GNU, as a CNA, would be unable to offer
>> to individual packages whatever it is that Red Hat, as root CNA, would.
>> Could you please elaborate on that distinction you're making?
> 
> I think we'd still want per-component CNAs, whether the GNU project is a
> (root) CNA or not.

Agreed. Per-component CNAs creates the least back-and-forth between the reporter and the
people who wrote the code and know how it works and the security policies for the
project.

> I suggest we start with Red Hat as the root CNA, get the glibc CNA set
> up.  Once you have figured out the details with MITRE and the FSF and
> the GNU root is established, we can move over.

Agreed, this is the best first step IMO.

-- 
Cheers,
Carlos.

Re: GNU C Library as its own CNA?

[Siddhesh Poyarekar]

On 2023-09-11 08:47, Carlos O'Donell wrote:
> On 7/28/23 11:56, Siddhesh Poyarekar wrote:
>> We have, for many years, been using distribution security teams to
>> help with CVE triage and assignment.  It has worked for the most
>> part, but it's not uncommon to have CVEs assigned by organizations
>> that don't always have a proper understanding of the security impact
>> of bugs in glibc despite us having a clearly documented Security
>> Process[1]; a recent example is CVE-2023-0687[2], which we had to
>> jump through many hoops just to get it disputed and get the record
>> straight on the bug.
>>
>> If the GNU C Library had it's own CNA, all vulnerabilities reported
>> against CVE would have to come to this CNA for triage, thus making
>> sure that security issues in glibc get correctly assessed.  As root
>> CNA, Red Hat is open to sponsoring FOSS organizations[3] that are
>> willing to have their own CNA, subject to certain conditions (all
>> organizational) being met.  Is this something that would interest the
>> community?
>>
>> I am volunteering to take primary responsibility in helping set
>> things up, including coordination with the CTI (for whatever
>> additional infrastructure this would need), coordination with Red Hat
>> and helping build consensus on what the organizational structure
>> should look like.
> 
> Please include me in the list of volunteers.
> 
> I think this is a great step forward in reducing downstream CVE work by ensuring
> we have a good upstream review process.
>   
>> At the outset, we'll need to have broad agreement on the following:
>>
>> 1. How should users submit issues?  We would need an independent,
>> private mailing list, possibly one that can also do PGP for users to
>> report security issues.
> 
> Start small. Private mailing list works. I expect we will have to publish and
> accept PGP signed email to all volunteers. So we'll need to publish volunteer
> keys, and have a process for withdrawing volunteer keys.
>   
>> 2. Identify a group of people who ought to be on that list.  A
>> starting group could be a cross section of named maintainers from
>> various distributions and FSF stewards but we probably need a way to
>> make sure that the group is inclusive without being too broad.
> 
> Count me in.
> 
>> 3. A formal representation to the root CNA, i.e. Red Hat.  We would
>> need a group of volunteers that would be willing to step in as
>> signees for this.  I'm in, but I can't do it alone and would need
>> more volunteers; it could perhaps be the same set of people who would
>> be part of the initial security team in (2).
> 
> I'm in.

Thanks, anybody else willing to volunteer?

Thanks,
Sid

Re: GNU C Library as its own CNA?

[Adhemerval Zanella Netto]

On 12/09/23 08:40, Siddhesh Poyarekar wrote:
> On 2023-09-11 08:47, Carlos O'Donell wrote:
>> On 7/28/23 11:56, Siddhesh Poyarekar wrote:
>>> We have, for many years, been using distribution security teams to
>>> help with CVE triage and assignment.  It has worked for the most
>>> part, but it's not uncommon to have CVEs assigned by organizations
>>> that don't always have a proper understanding of the security impact
>>> of bugs in glibc despite us having a clearly documented Security
>>> Process[1]; a recent example is CVE-2023-0687[2], which we had to
>>> jump through many hoops just to get it disputed and get the record
>>> straight on the bug.
>>>
>>> If the GNU C Library had it's own CNA, all vulnerabilities reported
>>> against CVE would have to come to this CNA for triage, thus making
>>> sure that security issues in glibc get correctly assessed.  As root
>>> CNA, Red Hat is open to sponsoring FOSS organizations[3] that are
>>> willing to have their own CNA, subject to certain conditions (all
>>> organizational) being met.  Is this something that would interest the
>>> community?
>>>
>>> I am volunteering to take primary responsibility in helping set
>>> things up, including coordination with the CTI (for whatever
>>> additional infrastructure this would need), coordination with Red Hat
>>> and helping build consensus on what the organizational structure
>>> should look like.
>>
>> Please include me in the list of volunteers.
>>
>> I think this is a great step forward in reducing downstream CVE work by ensuring
>> we have a good upstream review process.
>>  
>>> At the outset, we'll need to have broad agreement on the following:
>>>
>>> 1. How should users submit issues?  We would need an independent,
>>> private mailing list, possibly one that can also do PGP for users to
>>> report security issues.
>>
>> Start small. Private mailing list works. I expect we will have to publish and
>> accept PGP signed email to all volunteers. So we'll need to publish volunteer
>> keys, and have a process for withdrawing volunteer keys.
>>  
>>> 2. Identify a group of people who ought to be on that list.  A
>>> starting group could be a cross section of named maintainers from
>>> various distributions and FSF stewards but we probably need a way to
>>> make sure that the group is inclusive without being too broad.
>>
>> Count me in.
>>
>>> 3. A formal representation to the root CNA, i.e. Red Hat.  We would
>>> need a group of volunteers that would be willing to step in as
>>> signees for this.  I'm in, but I can't do it alone and would need
>>> more volunteers; it could perhaps be the same set of people who would
>>> be part of the initial security team in (2).
>>
>> I'm in.
> 
> Thanks, anybody else willing to volunteer?

I can help on this as well.