Re: Resources for glibc CNA

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 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.

>>>> 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:

- index.md
- policy/
   - glibc-SECURITY.md (Gives us space to add more projects in future)
- advisories/
   - CVE-9999-99999.md
   - CVE-9999-99998.md
   - CVE-9999-99997.md
   ...

Sid