5 ms·

It's not actionable for Gitlab, but it's actionable for anyone weighing what technologies they should use for future projects. Use one that doesn't open you to

It's not actionable for Gitlab, but it's actionable for anyone weighing what technologies they should use for future projects. Use one that doesn't open you to this kind of mistake, and ignore people who talk about "productivity" because that's going to be people arguing about their gut feelings anyway, and everyone will say their chosen stack is more productive. Something like Java is going to have the largest hiring pool, the largest ecosystem, and support from every major vendor. I don't particularly like it and think that Scala is pretty much a straight upgrade, but Java's a smart choice.

tptacek 3y ago
You get that the track record of Java and Java frameworks on web vulnerabilities is pretty abysmal, right? There's a whole gigantic RCE bug class (RCE! in the 2020s!) that originates there. My general take is: glass houses, etc. And: everybody is in a glass house.
- ndriscoll 3y ago
  I'm not sure what you mean with the bug class; Java serialization? If so I think that's been something where common advice is not to use it for 20+ years. Maybe Spring has had issues. Like I said I don't actually like Java and all the annotation stuff. I avoid it, but it's still going to be one of the more robust choices you can make since every major enterprise uses it. Java had log4shell, which was pretty bad, and probably wouldn't have happened if Java had had string macros. It's one of the reasons why Scala is a better language: people use things like compile time macros which prevents those sorts of mistakes. It looks like akka-http for example has only had DoS vulnerabilities (e.g. getting zip bombed) + some niche stuff like request smuggling if you used it to build a reverse proxy or usage of directory listing on Windows. That said, sure, large frameworks all have bugs. But not being able to tell whether you are dealing with a string or an array in your business logic is just silly.
  - tptacek 3y ago
    If you like Java, use Java. Don't worry about people pointing out how gnarly the security track record is; the security track record of every popular thing is gnarly. I'm not here to tell you what framework to use, only that empirically, you're not going to improve your odds significantly by choosing a different mainstream framework.
    - ndriscoll 3y ago
      I don't like Java and I don't consider jobs where I'd be doing a nontrivial amount of Java. But the original comment I replied to said this class of bug is hard to avoid, and it's not. Use any statically typed language, and it can't happen. Java's the obvious choice. C# is probably fine too. Same with something like SQL injection or log4shell. These are also preventable using string formatting macros. If `DatabaseConnection.run` takes a `SqlQuery`, not a `String`, and you can only make a `SqlQuery` through a safe API, and your escape hatch is a macro that does query parameterization instead of string substitution, then your users can't get it wrong. This is how Scala libraries actually work and have worked for years. Similarly if you build your logging library to take MDC objects that are built with format macros. These are solved problems.
      - tptacek 3y ago
        This is a logic bug, not a typing bug. One clear way you know this is: this bug occurs in both Java and C# applications, routinely. But that's OK! I'm not going to dunk on you for using C#, even though it is practically the ground spring from which all web app vulnerabilities have emerged (you'd think it'd be PHP, but C# has a better claim to the title).
        neonsunset 3y ago
        Can you show examples of such bug in these two languages? (I'm in particular interested in how it could manifest with EF Core)
        tptacek 3y ago
dheera 3y ago
Almost every technology today is the wrong choice if you look at it from the perspective of 20 years from now. When Facebook was founded there weren't actually many good alternatives to PHP.

tptacek 3y ago

You get that the track record of Java and Java frameworks on web vulnerabilities is pretty abysmal, right? There's a whole gigantic RCE bug class (RCE! in the 2020s!) that originates there. My general take is: glass houses, etc. And: everybody is in a glass house.

ndriscoll 3y ago
I'm not sure what you mean with the bug class; Java serialization? If so I think that's been something where common advice is not to use it for 20+ years. Maybe Spring has had issues. Like I said I don't actually like Java and all the annotation stuff. I avoid it, but it's still going to be one of the more robust choices you can make since every major enterprise uses it. Java had log4shell, which was pretty bad, and probably wouldn't have happened if Java had had string macros. It's one of the reasons why Scala is a better language: people use things like compile time macros which prevents those sorts of mistakes. It looks like akka-http for example has only had DoS vulnerabilities (e.g. getting zip bombed) + some niche stuff like request smuggling if you used it to build a reverse proxy or usage of directory listing on Windows. That said, sure, large frameworks all have bugs. But not being able to tell whether you are dealing with a string or an array in your business logic is just silly.
- tptacek 3y ago
  If you like Java, use Java. Don't worry about people pointing out how gnarly the security track record is; the security track record of every popular thing is gnarly. I'm not here to tell you what framework to use, only that empirically, you're not going to improve your odds significantly by choosing a different mainstream framework.
  - ndriscoll 3y ago
    I don't like Java and I don't consider jobs where I'd be doing a nontrivial amount of Java. But the original comment I replied to said this class of bug is hard to avoid, and it's not. Use any statically typed language, and it can't happen. Java's the obvious choice. C# is probably fine too. Same with something like SQL injection or log4shell. These are also preventable using string formatting macros. If `DatabaseConnection.run` takes a `SqlQuery`, not a `String`, and you can only make a `SqlQuery` through a safe API, and your escape hatch is a macro that does query parameterization instead of string substitution, then your users can't get it wrong. This is how Scala libraries actually work and have worked for years. Similarly if you build your logging library to take MDC objects that are built with format macros. These are solved problems.
    - tptacek 3y ago
      This is a logic bug, not a typing bug. One clear way you know this is: this bug occurs in both Java and C# applications, routinely. But that's OK! I'm not going to dunk on you for using C#, even though it is practically the ground spring from which all web app vulnerabilities have emerged (you'd think it'd be PHP, but C# has a better claim to the title).
      - neonsunset 3y ago
        Can you show examples of such bug in these two languages? (I'm in particular interested in how it could manifest with EF Core)
        tptacek 3y ago

dheera 3y ago

Almost every technology today is the wrong choice if you look at it from the perspective of 20 years from now. When Facebook was founded there weren't actually many good alternatives to PHP.