[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261110045440.GA8897@openwall.com>
Date: Tue, 10 Nov 2026 05:54:40 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Home Assistant: the password is not the key — token secrets in cleartext, two token classes never expire, password change revokes none (2026.11.0, live-proven)
On Mon, Nov 09, 2026 at 02:00:35PM -0800, Gregory Mullen wrote:
> > Coordination: none, and that is not an oversight you caught. [name]
> > publishes day-of, without advance notice, as a stated policy. You may
> > dislike the policy; it is not hidden, and it is not a secret.
>
> Are there list policies published anywhere?
Yes, here:
https://oss-security.openwall.org/wiki/mailing-lists/oss-security#list-content-guidelines
> I've been operating under the
> assumption that this list wouldn't help participate in malicious disclosure
> behavior like this, but if it does, I feel I'd need to unsubscribe for ethical
> reasons.
While it's typical that issues disclosed on oss-security had been
communicated to the vendors first, there are currently no "responsible
disclosure" requirements here, and have never been. If someone wants to
post a 0-day, they generally can. It'd take extreme circumstances for
the moderators to decide differently, and this would require a public
explanation later.
Posting a 0-day is not necessarily malicious. The "full" vs.
"responsible" disclosure debate existed for decades and there isn't a
universally accepted right or wrong. Cases and opinions still vary.
However:
> Behavior like this isn't ok, and it shouldn't be rewarded with attention.
I see other signs of malicious behavior here, and policies we could want
to add to deal with it in this age of LLMs. This list is by and for
people, not machines. When we want to interact with a machine, we can,
but we may not want such interactions pushed to us via a mailing list,
or at least not via this one.
It is going to be increasingly difficult to determine whether and to
what extent is a posting generated by a machine. The quality of
machine-generated content will be increasing, so frankly for purposes of
awareness of and dealing with each one security issue it could become no
worse than human-created. The problem is its sheer volume and lower
average importance. Content too cheap to create may explore issues that
were not worth a human's time to write about, and so may not be worth a
human's time to read.
I agree that machine-generated postings here shouldn't be rewarded with
attention, if accepted at all... unless they're about important issues?
However, I don't see a good way for the moderators to enforce this.
"Is this posting human-written or at least important?" isn't a question
that can be answered quickly and reliably during pre-moderation.
Now that we know this specific sender that side-steps direct questions
about human involvement (and instead keeps writing about the content
being signed, which is irrelevant), we can start rejecting that sender's
postings irrespective of content. Should we? If you (any subscriber
here) have either preference on this, please let me know off-list.
Please take the time to review all postings by this sender first - not
only in this thread. There have been a few in several threads in the
last few days, starting with the sshole thread.
On Mon, Nov 09, 2026 at 03:49:22PM -0800, Gregory Mullen wrote:
> With the number of LLM generated/assisted exploits being disclosed
> irresponsibly. I feel it's important to draw a line in the sand, and not just
> allow malicious disclosures to become the new normal. This report isn't
> critically important, but I *strongly* feel that rejecting behavior like this is
> important.
>
> I suspect the people who use LLMs to find exploits for them also aren't smart
> enough to understand the risks they could expose people to. Those who don't
> need an LLM to understand, need to be careful we don't forget it either. It's a
> game, until it isn't.
Some others in this community argued that LLMs are a reason to move away
from embargoes, or from "responsible" to "full" or rather more immediate
disclosure, at least for issues discovered by LLMs. That's because with
LLMs someone else, even someone not otherwise "smart enough", could
rediscover the issue and use it irresponsibly during what would
otherwise be our embargo period.
If someone or their machine sends some important 0-day disclosure in
here, what would we achieve by not letting it through to subscribers?
We would discourage such behavior, but at the same time we'd deprive the
subscribers from this knowledge while letting others rediscover and
exploit the issue possibly maliciously.
Further, the information would have already passed through the Internet
to the list server and from there to the moderators. There's risk of
this being seen by third-parties. Again, we'd deprive the subscribers
from the info while letting potential adversaries have it. For issues
sent to the (linux-)distros list we mitigate this by keeping track of
them and enforcing the maximum embargo duration, but we don't have
anything like that for oss-security postings rejected in moderation.
In summary, I agree there are problems, but I don't see good solutions.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
