News for hackers. Stuff that matters.
Re:Implications of Rewriting a Browser Component in Rust by tspiteri on Thursday February 28, 2019 @10:27AM (#19271945)
It also highlights an example of a security bug introduced during rewriting; highlighting that rewriting any significantly large piece of software is bound to introduce bugs.
Re:Implications of Rewriting a Browser Component in Rust by dmix on Thursday February 28, 2019 @03:33PM (#19274895)
Not just introducing new bugs but reintroducing old bugs which were publicly documented and/or previously exploited. Which you could argue are worse as it’s a lower barrier for detection by attackers, but also on the otherhand by the team/community.

Also of note was that there was already an automated test for one of the high priority bugs that got reintroduced but the that particular tests was turned off.

Re:Implications of Rewriting a Browser Component in Rust by eridius on Thursday February 28, 2019 @05:32PM (#19275971)
What confuses me about this is the tests were turned off because they were taking too long. But wouldn't the appropriate behavior there be "run a subset of the tests normally, but run the full test suite occasionally" rather than just disabling the tests completely?
Re:Implications of Rewriting a Browser Component in Rust by dmix on Thursday February 28, 2019 @09:37PM (#19277501)
Or turn off some during development but run the whole suite before release?

I have a feeling the a bunch of the tests in that particular category needed to be updated, so it wasn't simply just too long.

Re:Implications of Rewriting a Browser Component in Rust by indolering on Friday March 08, 2019 @10:06AM (#19338088)
Pretty clear that the QA process is at fault here, which is sadly common in the software industry.