Hector Martin

Seriously, how incompetent do you have to be to not only write code like this, but also *once the bug is found, completely fail at educating yourself as to what the correct, sane, safe way to fix it is*? I might excuse lack of knowledge, but not the utter inability to learn.

Seriously, this incident raises *serious* questions about the quality of development at @yubico. It might be an isolated problem, but how did this mess slip through the cracks? Who reviewed this code? Does an entire team at Yubico think this is okay? Who hired them?

Do the same standards apply to every other team at @yubico? How do we know this isn't a pervasive problem? Are there any companywide standards on code quality? Is there even a security team dedicated to auditing stuff in general? HOW DID THIS HAPPEN?!?

Btw, someone joked about http://php.net  having this as the correct solution, and, well. But "knowing better than http://php.net " is definitely a prerequisite to be in the security business writing PHP. Or just don't write PHP.https://twitter.com/marcan42/status/1089238169839489025 …

OMG IT'S STILL BROKEN. THIS IS HOW THEY'RE SANITIZING URLS FOR INSERTING INTO SQL QUERIES $ echo "<?php echo filter_var('http://inject/\'', FILTER_VALIDATE_URL);" | php http://inject/' AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Your tweets are quite toxic. The attitude displyed in this thread is the reason why we cannot have a possitive and open relationship with vendors.

There is a minimum set of expectations from vendors, which was thoroughly violated here. I'm all for positivity, especially when it comes to teaching security to those who are not in the industry... But if you *sell security* and do this, there is no excuse.

Alternatively: I have *no idea* how one could possibly ever handle this in a positive way. I get the problems with negativity... but the only option I see here is to just stop being in this field altogether.