Implications of Rewriting a Browser Component in Rust

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.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]