public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Alexandre Oliva <oliva@gnu.org>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: GNU C Library as its own CNA?
Date: Thu, 7 Sep 2023 06:48:54 -0400	[thread overview]
Message-ID: <e08d2ce8-a9d2-df8f-7189-1f3a4fd042bd@gotplt.org> (raw)
In-Reply-To: <ormsxybr3e.fsf@lxoliva.fsfla.org>

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

  reply	other threads:[~2023-09-07 10:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28 15:56 Siddhesh Poyarekar
2023-07-28 16:09 ` Florian Weimer
2023-07-28 16:11   ` Siddhesh Poyarekar
2023-07-28 16:41 ` Joseph Myers
2023-07-28 17:28   ` Paul Eggert
2023-09-06 11:41     ` Siddhesh Poyarekar
2023-09-06 12:33     ` Florian Weimer
2023-09-06 16:00       ` Paul Eggert
2023-09-06 16:33         ` Florian Weimer
2023-09-06 17:04           ` Paul Eggert
2023-07-31 17:42   ` Siddhesh Poyarekar
2023-09-06 11:40 ` Siddhesh Poyarekar
2023-09-06 18:35   ` Alexandre Oliva
2023-09-06 18:57     ` Siddhesh Poyarekar
2023-09-06 19:02       ` Paul Eggert
2023-09-06 22:01       ` Alexandre Oliva
2023-09-07  0:56         ` Siddhesh Poyarekar
2023-09-07  3:27           ` Alexandre Oliva
2023-09-07 10:48             ` Siddhesh Poyarekar [this message]
2023-09-07 15:46               ` Florian Weimer
2023-09-07 17:14               ` Alexandre Oliva
2023-09-08 10:58                 ` Siddhesh Poyarekar
2023-09-10 16:57                   ` Alexandre Oliva
2023-09-11  7:46                     ` Florian Weimer
2023-09-11 12:59                       ` Carlos O'Donell
2023-09-11  9:58                     ` Siddhesh Poyarekar
2023-09-11 12:47 ` Carlos O'Donell
2023-09-12 11:40   ` Siddhesh Poyarekar
2023-09-12 13:15     ` Adhemerval Zanella Netto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e08d2ce8-a9d2-df8f-7189-1f3a4fd042bd@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=libc-alpha@sourceware.org \
    --cc=oliva@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).