Hacker News new | ask | show | jobs
by AnaniasAnanas 2558 days ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1544386

I find it really gross that they do not allow others to access it. This behavior damages the forks.

4 comments

The source code for the fix is public. Presumably the bug report includes working exploit code. I don't see how this is "damaging" for forks.
It is important to also understand what causes the issue, how it was exploited, etc. Plus I am pretty sure that they had the bug report before the fix was released.
Are there any fork that modifies Firefox so thoroughly that one needs a context to patch SpiderMonkey?
Mozilla can still give access for the developers of forks without opening it to the public before they (and the forks!) have managed to rollout a full update.
Anyone can run a fork though, I right now might be running my personal fork. This is part of the point of free software.

Plus, you assume that the select few developers that are given the exploit information are trustworthy. The exploit being public from the first day is better than if even a single developer is untrustworthy or compromised.

I don't understand this logic. It's better to have everyone see it and to guarantee it is seen by a malicious actor, instead of only a small few seeing it and there being some small potential for it to be seen by a malicious actor?
It will be seen by a malicious actor anyway after the fix is released. The difference is that there will be more time for a malicious actor to act against a fork if an embargo is applied.
Mozilla used to open up the security bugs after the fix is out for a while.

I say used to because I notice that the security issues fixed in Firefox 66.0 (released in March according to the release notes) still appear to be private. I suspect the internal people that cared about it have left, and their process is now broken. Somebody might read this thread and poke people to open access, but it would have to be done as an exceptional step (given that it hasn't been the first time I've noticed this happening).

The same people who were in charge of opening up security bugs are still around and still in charge of it.

Security bugs are opened up once in-the-wild usage of affected versions is low enough, if I recall correctly. This usually takes a while after the fix is shipped. At no point were bugs opened up immediately after the Firefox release with the fix shipped. It's usually a year or so between the fix being shipped and the bug getting opened up, in my experience.

Ah, okay, thanks! My (very unreliable) memory thought it was sooner; that was why I picked 66 (released in March) rather than 67 (May).

The security issues in 60.0.2 (June 6 2018) is now public.

Unless things have changed dramatically since I left Mozilla, forks that are willing to be active in the Mozilla security community are able to get access to security bugs.