Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Mar 2024 19:15:11 -0400
From: Marc Deslauriers <>
Subject: Re: Re: backdoor in upstream xz/liblzma leading to ssh
 server compromise

On 2024-03-29 18:59, Liguori, Anthony wrote:
> On 2024-03-29, Andres Freund wrote:
>> Hi,
>> On 2024-03-29 21:54:11 -0000, Tavis Ormandy wrote:
>>> On 2024-03-29, Solar Designer wrote:
>>>>> I have a minor procedural question for Solar though, shouldn't this
>>>>> have been redirected to oss-security immediately from distros? What's
>>>>> the rationale for an embargo here?
>>>> We don't have a clear policy for such case.  Some distros list members
>>>> have indeed suggested making this public ASAP.  We ended up delaying
>>>> publication by one day per my suggestion (as a compromise between ASAP
>>>> and having no specific CRD), and I think these are some reasons why:
>>> Thanks, a compromise is better than nothing :) I think I would have
>>> argued for immediately discussing this in the open.
>> FWIW, I don't know much of the tradeoffs in this space. With that caveat:
> I think we should have a policy that if issues are suspected to be actively exploited, that the issue goes public immediately.  If even there is no patch or mitigation, there's not a lot of benefit to keeping it private.

In this case, we had no reason to believe it was being actively exploited.

If you make it public before a patch or mitigation is available, it has now gone 
from a single entity being able to exploit it to the whole world being able to 
exploit it.

That's a whole lot worse.

> I think everyone was acting in good faith here and did great work, but there wasn't a clear policy for handling this type of issue.

> I very much agree that there's very little benefit to limiting the number of folks that know what's going on when someone is actively taking advantage of an issue.

I would argue against having a policy requiring something like this to be made 
public immediately. The important thing here is to do whatever it takes to make 
sure users are secure as fast as possible, not expose them to even bigger attack 
surface with no mitigation available.


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.