[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 May 2023 21:00:11 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Daniel Stenberg <daniel@...x.se>
Subject: semi-public issues on (linux-)distros
Hi,
Sometimes upstream projects want to make a security fix technically
public (such as in a git repository and/or on a mailing list) before it
is included in a release and announced as such. This lets those
projects use their usual development, review, and testing workflow
instead of having to switch to a special security fix workflow, which
can save the maintainers time and provide greater quality assurance
(more eyes, more testing). Unfortunately, it also means that bad actors
can potentially spot the fix and infer and exploit the vulnerability
before the project's downstreams and end-users are made aware of it.
This is a tricky trade-off. The (linux-)distros list policy generally
does not allow for semi-public fixes like this to be brought to those
lists and stay "embargoed" there, with occasional exceptions granted on
a case-by-case basis. Last year, we also added a general exception for
the Linux kernel to accommodate their workflow:
https://www.openwall.com/lists/oss-security/2022/05/24/1
This year, the curl project switched to using publicly-committed fixes
for low and medium severity security issues. The first set of such
issues was brought to the distros list in March and fully publicly
disclosed a week later:
https://www.openwall.com/lists/oss-security/2023/03/20/
That was one of those rare exceptions granted on a case-by-case basis,
and I was going to disclose this fact here on oss-security, which I am
finally doing now (sorry for the delay!)
More importantly, since it's a change in curl's approach to handling
such issues in general, rather than a one-time occurrence, we need to
discuss how to approach that on further occasions - for curl, or/and in
general. Daniel suggests:
> I would of course prefer to see it being done as a proposal that
> updates the rules to cater for a process like ours. Which incidentally
> is shared by many other projects as well; it is not a unique situation
> for curl.
I think it's reasonable to grant a blanket exception like we did for the
Linux kernel also for curl, limited to low and medium severity issues.
curl project's handling of security issues has been exemplary so far, in
my opinion at least, which gives me reason to expect sound judgement
from Daniel on which issues to handle in which way. Also, like it or
not, starting to publicly commit some security fixes is a decision the
project has already made, so our only options are (1) to change the list
policy, (2) to grant one-time exceptions every time, or (3) to create
extra work for Daniel for notifying the individual distros other than
via the list (or choose not to).
I would also be happy to have a general solution if we _reasonably_ can,
for all projects, but I'm not sure how reasonable that is. The terms
for Linux kernel's vs. curl's exceptions may reasonably vary to meet
these project's exact needs and not more: for Linux kernel it's "issues
concurrently or very recently handled by the Linux kernel security team"
and for curl it can be "low and medium severity issues".
So my current proposal is to edit the policy to add curl's "low and
medium severity issues" as the second pre-granted exception. If more
projects request something like this later, we can reconsider and
generalize this.
I'd appreciate any feedback.
Thanks,
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.
