Re: Resources for glibc CNA

On 8/11/23 11:28, Siddhesh Poyarekar wrote:
> On 2023-08-10 17:33, Carlos O'Donell wrote:
>> I don't have a strong opinion here, but I would rather start
>> *simple* and _then_ scale up to remail only if we need it. If we
>> can just use gpg/pgp then I would prefer that.
> 
> Maybe we could start with a regular, private mailing list and publish
> keys of some security team members to give reporters the option to
> use them if they need to encrypt their communication.  Team members
> that get contacted may need to act as pigeons between the mailing
> list and the reporter though.  We could start like this and see how
> quickly this gets painful.  I don't like the idea of sharing a subkey
> among multiple people :/

I don't like sharing any keys either.

I think we would publish the keys of the current group and update that as people
leave and join the group.
 
>> I agree we need to settle on the domain name, and I would also pick
>> "toolchain.dev" since we want to use that for other CTI projects,
>> and a landing page like "advisories.toolchain.dev" would be fine.
> 
> [bikeshed] security.toolchain.dev because we'll need a security
> policy page too, even if it just means pointing to or replicating the
> contents of our SECURITY.md.

Sure. Blue shed is fine with me.

>>>>> For the publication, I usually strongly advise a simple
>>>>> static site that can withstand very high traffic. I believe
>>>>> there is general consensus that "toolchain.dev" is the domain
>>>>> to be used for CTI purposes, so something could be published
>>>>> on advisories.toolchain.dev or similar.
>>>> 
>>>> Ack, a static site would be perfect, perhaps with markdown
>>>> pages and git access, similar to our plan for the wiki.
>>> 
>>> Another option is a restricted public advisories mailing list
>>> with a public-inbox frontend (similar to lore.kernel.org). This
>>> would provide you with both pull-based and push-based
>>> subscription options.
>> 
>> I like the static site backed by git better because it allows us to
>> do all kinds of git-based auditing and review. I get the appeal of
>> a mailing list, but I'd still end up committing something 
>> somewhere, and then sending an email via an API. Might as well just
>> commit and regenerate the pages.
>> 
> 
> ... and git allows us to edit advisories too.  In fact, all of
> security.toolchain.dev could just be a repo with:

Agreed 100% on a repo with md files or rst to publish with sphinx and readthedocs.

-- 
Cheers,
Carlos.