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.
[ Parent
| on HN ]
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.