Re: Resources for glibc CNA

On 8/10/23 14:41, Konstantin Ryabitsev wrote:
> On Thu, Aug 10, 2023 at 02:25:36PM -0400, Siddhesh Poyarekar wrote:
>>> Yes and no. We do have infrastructure for encrypted communication called
>>> "remail" where hardware vendors discuss vulnerabilities that are likely to
>>> affect millions of high-profile devices. For example, it was used for
>>> collaborating on the patches fixing the recent speculative execution
>>> vulnerabilities. The setup is described in this document:
>>> https://korg.docs.kernel.org/remail.html
>>>
>>> However, this may be an overkill for what you need and also introduces
>>> multiple levels of complexity that you may not want. The alternative is to set
>>> up a private PGP keypair and share the decryption and signing subkeys among
>>> members who are duty bound to respond to vulnerability reports.
>>
>> remail functionality is exactly what I had in mind actually.  What
>> complexity would be involved in setting this up?
> 
> It's managed via a backend git repository and mostly just requires getting
> familiar with the format. While it does support S/MIME, the general experience
> thus far has been that it's not worth the trouble, so everyone just does PGP.
> 
> It wouldn't take too much effort to roll it out, but we do need to settle on
> the domain name to use, since we'd have to set it up for mail delivery.

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.

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.

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

-- 
Cheers,
Carlos.