oss-sec mailing list archives
Re: semi-public issues on (linux-)distros
From: Solar Designer <solar () openwall com>
Date: Sun, 14 May 2023 18:27:13 +0200
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, inI 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
Current thread:
- semi-public issues on (linux-)distros Solar Designer (May 03)
- Re: semi-public issues on (linux-)distros Johannes Segitz (May 04)
- Re: semi-public issues on (linux-)distros Solar Designer (May 14)
- Re: semi-public issues on (linux-)distros Johannes Segitz (May 04)