[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Sep 2022 12:53:29 +0200
From: Carlos Alberto Lopez Perez <clopez@...lia.com>
To: oss-security@...ts.openwall.com,
Demi Marie Obenour <demi@...isiblethingslab.com>,
John Helmert III <ajak@...too.org>
Subject: Re: WebKitGTK and WPE WebKit Security Advisory
WSA-2022-0008
On 02/09/2022 00:11, Demi Marie Obenour wrote:
> On Thu, Sep 01, 2022 at 10:31:16PM +0200, Carlos Alberto Lopez Perez wrote:
>> On 29/08/2022 20:03, Demi Marie Obenour wrote:
>>>> We (maintainers of Linux WebKit ports) don't have access to the security
>>>> issues affecting Apple products until those issues are made public by them.
>>> That is unfortunate. I thought you would have access to embargoed
>>> bugzilla tickets.
>>>
>>
>> We do have access to the tickets on WebKit bugzilla that are marked as
>> security-related and are hidden from other users by default.
>
> Okay, that makes sense. As an aside, why are these tickets kept hidden
> indefinitely even after patches have been available for a long time?
>
I don't know the reason.
But I suspect it maybe has something to do how bugzilla works, since the
whole "Security" category on the WebKit bugzilla is private.
And I'm unsure if Bugzilla allows access to a private issue based on the
age and status (closed/open) of the issue.
>> However, we don't receive the information about which WebKit fixes will
>> be included in any Apple security update until those advisories are public.
>>
>>
>>>> So, we didn't knew until August 17th of this issue. Also you can see
>>>> that the bug report itself or the patch doesn't has any indication that
>>>> it fixes a security-related problem.
>>>>
>>>> Therefore, the time it took us to notice the issue, backport the fix and
>>>> do a new release was just 7-8 days (from 17th to 24-25th of August).
>>>> Which, honestely, it is quite good taking into account that: 1)
>>>> back-porting the fix was not straightforward since it required
>>>> back-porting also a few previous patches in order to be able to merge it
>>>> properly and that 2) we are in August and people is usually on holidays.
>>> Was backporting needed, as opposed to shipping a new minor version?
>>>
>>
>> It was. Fixes land in the master (main) branch. Those fixes don't
>> necessarely apply or work on the branch of the last webkitgtk-stable branch.
>
> I see. Have you considered using the same branch of WebKit that Apple
> does, or backporting security patches as soon as they land in main
> without waiting for an upstream release? Presumably you know which
> commits are security fixes.
We have considered using the same stable branches that them, but in the
end it didn't fit well our release process. We aim at a 6-month release
cadence for major stable releases in order to align with the GNOME
release process. And Apple has a differente release cadence than that.
We also monitor patches landing on master (main) that are tagged as
security releated and sometimes we backport them even when those don't
have (still) assigned a CVE.
In the case of this CVE (CVE-2022-32893) the patch fixing it was not
marked as security related.
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.
