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

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

  parent reply	other threads:[~2023-09-07 17:15 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
2023-09-07 15:46               ` Florian Weimer
2023-09-07 17:14               ` Alexandre Oliva [this message]
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=orbkedj46k.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@gotplt.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).