I'll respond to this comment to provide a general response for all of the sub-comments here.
As I highlighted in my post, LLM's generally are still not in a position to replace a developer for more complex tasks and refactoring. We're in the early days of the technology, but we are seeing extremely strong improvements in it over the last year. We on the team have QA'd thousands of results for public, and private repositories. The private ones are particularly interesting because the LLM's do not have that in their corpus, and have seen very strong fix results.
Most people just assume we're wrapping around an LLM, but there's a lot that goes underneath the hood that needs to happen to ensure that fixes are going to be secure and correct. Here are the standards we're setting for fix quality:
- The fix needs to be best-practice and complete. A partial security fix isn't a security fix. This is something we're constantly working on.
- Supporting the widest coverage in CWE's.
- Not introducing any breaking changes in the rest of the code.
- Understanding the language, the framework being used, and any specific packages. For example, fixing an CSRF issue in Django is different than Flask. Both are python frameworks but approach it differently.
- Reusing existing packages correctly to improve security and if it does need to add a package does so in a standard way.
- Placing imports in the correct part of the file.
- Not using deprecated or risky packages.
- Avoiding LLM hallucinations.
- Ensuring syntax and formatting are correct.
- Follow the coding and naming convention in the file being fixed.
- Making sure fixes are consistent within the same issue type.
- Explain the fix properly and clearly so that someone can understand it.
- Avoiding assumptions that could cause problems.
- Not removing any code that is not part of the issue.
Our goal is to get to 90% - 95% accuracy in fixes this year, and we're on a trajectory to do that. I will be the first to say 100% accuracy is impossible, and our goal is to get it right more times than engineers would.
We take fix quality and transparency extremely seriously. We'll be publishing a whitepaper showing the accuracy in results because it's the right thing to do. I hope this helps.
If you don't know that - or rather, if nobody on your team recognized this issue and brought it up - you should not be selling and shipping this product.
I created/maintained a popular project for years[^1], and recently passed ownership to someone else. It's been great seeing issues resolve, PRs merge, etc, after languishing for a while :)
The point is that with a powerful Effects system, devs calling the logger would have to account for the network call in their own code. Someone might have wondered why that was needed and gotten this addressed before it was ever widespread.
> The point is that with a powerful Effects system, devs calling the logger would have to account for the network call in their own code. Someone might have wondered why that was needed and gotten this addressed before it was ever widespread.
No one would have wondered anything - it's a networked logger, with network functionality.
They might have wondered it already. And even asked, “why are we doing this? Seems like a bad idea.” But when the response is a list of reasons that may or may not be good, you just go with it. All of this was done with intention.
For a much simpler example: newtypes can make enforcing proper escaping[0] completely trivial and checked by the compiler. It's very similar to tainted values in Perl except enforced at compile time.
So is the conversation now split into a preunretweeted half and a postunretweeted half, or is it a retrounretweeting where we act like it never happened?
No, it isn't. There isn't consensus on what weakly/strongly typed actually means, but C is strongly typed (with some unfortunate loopholes) by most definitions.
This class of bug (CSRF bypass via route confusion) is probably more common in Phoenix apps. I’ve found a handful of apps vulnerable to this issue with Sobelow.
People create (for example) a get ‘/profile’ and a post ‘/profile’, and the action intended to correspond with post requests really just pattern matches against params.
I’ve also seen at least one app implement this properly, matching against the HTTP method as you described.
This is a horribly misinformed article, and is incorrect about the most fundamental arguments it is making. E.g. Among many other issues, it implies that a compromised CA would allow passive MitM.
The article does have some issues, but a compromised CA would certainly make MitM easier. Not passive, but certainly ssl-strip [1] / ssl-sniff options get much easier.
Pinning certs (HPKP) is too dangerous so very few people implement it. That means if I have a signing cert for any trusted CA, I can ssl-strip with ease. This really has nothing specific to do with Lets Encrypt however. Any trusted CA signing cert will do. Or even an unlocked server cert (missing constraints) will do.
Sure, the "passive" was what I was calling out as incorrect. And as you noted, a compromised trusted CA affects all domains. Which is another thing this article gets explicitly wrong.
> If DigiCert’s Key Management System is compromised, all of their SSL certificates will have to be revoked and re-issued. But if one of the other CAs is compromised, it would not affect Medium’s site.
Agreed. This is where folks must risk-rank their traffic contents and determine if HTTPS alone is enough, or if in some cases, encrypted payloads using other forms of encryption and trust are useful. i.e. gpg, psk, etc... Secure email is the first thing that comes to mind.
Agreed that you don't gain anything if you're using 1Password. But users may be required to set up MFA to access something like GitHub organizations, in which case having it available in 1Password is convenient.
