[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230514162713.GA14965@openwall.com>
Date: Sun, 14 May 2023 18:27:13 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Daniel Stenberg <daniel@...x.se>
Subject: Re: semi-public issues on (linux-)distros
Hi,
Thank you Johannes for commenting on this. I think there was plenty of
time for anyone else to comment as well if they wanted to, but no one
did, and that's fine. So I went ahead and made an edit to the policy.
On Thu, May 04, 2023 at 08:48:58AM +0200, Johannes Segitz wrote:
> On Wed, May 03, 2023 at 09:00:11PM +0200, Solar Designer wrote:
> > curl project's handling of security issues has been exemplary so far, in
>
> I agree. And I'm happy to see that this is being discussed, as I've seen
> Daniel talking on Mastodon about this and it would be a shame if they
> wouldn't provide their high quality reports to distributions up front
> anymore.
>
> > 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).
>
> My vote is for option 1.
The paragraph now reads:
"Please note that in case a fix for an issue is already in a publicly
accessible source code repository, we generally consider the issue
public (and thus you should post to oss-security right away, not report
the issue to (linux-)distros as we'd merely redirect you to oss-security
anyway and insist that you make the required posting ASAP). There can
be occasional exceptions to this, such as if the publicly accessible fix
doesn't look like it's for a security issue and not revealing this
publicly right away is somehow deemed desirable. In particular, we
grant such exceptions for (1) Linux kernel issues concurrently or very
recently handled by the Linux kernel security team and (2) curl issues
ranked as low or medium severity by the curl project. In all other
cases, you'd have to have very sound reasoning to claim an exception
like this and be prepared to lose your argument and if so to post to
oss-security ASAP anyway."
The addition is "(2) curl issues ranked as low or medium severity by the
curl project."
> > 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".
>
> This is indeed tricky. I would not try to sync this to specific conditions
> of the upstream policy, but to the proven track record of an upstream
> project. If they can show that they can reliable do this for security
> issues below a certain threshold they should get approved to post
> semi-public issues onto the list.
>
> And yes, this isn't a hard criterion that can be easily judged, which is
> indeed a problem. There could be some form of vote on the list to decide
> this for each project asking for it. In my experience the subscribers are
> reasonable and I would expect that this would lead to good results.
As you can see, I went for project-specific conditions now. What you
suggest above didn't look better to me. One reason why not is that if
we'd need "some form of vote on the list" anyway, we can as well do so
with threads like this one discussing the specific project's needs.
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.
