Stream: wasmtime

Topic: Should we rethink our disclosure policy?

Till Schneidereit (May 11 2026 at 10:40):

This post made think about whether our disclosure policy is still serving our users best. In particular the part where we do an announcement that we'll do a security release three days later.

Alternatives I can think of are to either shorten that window, perhaps to a single day, or even do away with it completely. Maybe the former, with an explicit invitation to reach out and get ahead-of-time access and giving that pretty broadly to people who can believably tell us that they have a production use case?

Alex Crichton (May 11 2026 at 14:37):

Personally I'd be tempted to do away with it entirely, by advertising that we have a security issue it seems like it'd invite anyone watching this to run an LLM and more-or-less figure it out right the and there.

Alex Crichton (May 11 2026 at 14:38):

I'm a bit wary to lead the charge here in terms of changing policies of projects. Do you know of other projects that have done away with a disclosure window in light of LLMs? Or, for example, other projects considering articles like this?

Till Schneidereit (May 11 2026 at 14:54):

I'm not, no. And yeah, I don't think we necessary need to be trailblazers all that much here, so it might be okay to just wait for a bit and see how things develop

Andy Wingo (May 11 2026 at 15:16):

"wasmtime adopts the industry-standard disclosure policy pioneered by the linux kernel"

Till Schneidereit (May 11 2026 at 15:17):

"Up next: our own CVE numbering authority, to manage the volume"

Till Schneidereit (May 12 2026 at 14:51):

another thought: we could do away with the pre-announcement, but instead prominently, including in disclosure announcements, invite people to reach out to be added to a private announcement list, which we would do for anyone with a plausible production use case

Chris Fallin (May 12 2026 at 15:01):

That sounds like quite a reasonable position to me: in practice today the security release pre-announcement is more or less serving a purpose of "ask to be included in the embargo if you'll need patches ahead of time"; no one responsible for a production use-case should treat it as "be ready to jump into action with the public patches at 8am Thursday". So doing the pre-announcement "statically", once, and maintaining a private embargo list seems like a reasonable optimization. I guess the thing to be vigilant about there is that there is some downward/audit pressure on the list: if it becomes a permanent list rather than a per-announcement judgment call, its natural tendency will be to grow

Till Schneidereit (May 12 2026 at 15:42):

yeah, definitely. We'd ideally pair that with a zero-based accounting like process where on some schedule we send a mail to the list requesting renewal opt-in, which would require a restatement of the use case. And we'd purge everyone who hasn't (convincingly) responded within a predetermined time frame

Alex Crichton (May 12 2026 at 17:06):

I like the idea of such a list, yeah, but some further thoughts on it:

• What exactly would this be? A set of emails to send out? A set of github usernames to add to advisories? A set of folks on a github team we'd add to an advisory?
• For folks subscribing this would be, in theory, much more noisy than the mailing list. We'd want to add folks the instant we determine a vulnerability is valid, even before we have a fix. That means subscribers would be subject to discussion on the advisory of how to fix, how to word, etc.

fitzgen (he/him) (May 12 2026 at 17:23):

Might be worth tying ADOPTERS.md to this list as well? Seems like the ~same bar to meet in both cases

Till Schneidereit (May 12 2026 at 18:10):

I was imagining this to basically be a private version of the current pre-announcement, not necessarily anything more. But I think it'd also be fine to have it be more active than that and give even earlier heads-up of the identified issues, yeah.

And I like the idea of tying it to ADOPTERS.md!

Last updated: May 26 2026 at 09:09 UTC