[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2023 08:48:58 +0200
From: Johannes Segitz <jsegitz@...e.de>
To: oss-security@...ts.openwall.com
Cc: Daniel Stenberg <daniel@...x.se>
Subject: Re: semi-public issues on (linux-)distros
Hi,
first of all let me take the opportunity to thank you for your work in this
area. I'm not a member of the distros list anymore (have been for years),
but I appreciate very much what you do for the community.
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.
> 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.
Johannes
--
GPG Key EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
