4 ms·

> Making truly secure software products is incredibly hard in this day and age I politely disagree. Writing secure software is easier than ever. For example,

> Making truly secure software products is incredibly hard in this day and age I politely disagree. Writing secure software is easier than ever. For example, there are several mainstream and full-featured web frameworks that use managed virtual machine runtimes. Node.js and ASP.NET come to mind, but there are many other examples. These are largely immune to memory safety attacks and the like that plague older languages. Most popular languages also have a wide variety of ORMs available that prevent SQL injection by default. Don't like heavyweight ORMs? No problem! There's like a dozen micro-ORMs like Dapper that do nothing to your SQL other than block injection vulnerabilities and eliminate the boilerplate. Similarly, web templating frameworks like Razor pages prevent script injection by default. Cloud app platforms, containerisation, or even just virtual machines make it trivial to provide hardware enforced isolation on a per-app basis instead of relying on the much weaker process isolation within an OS with shared app hosting. TLS 1.3 has essentially eliminated cryptographic vulnerabilities in network protocols. You no longer have to "think" about this concern in normal circumstances. What's even better is that back end protocols have also uniformly adopted TLS 1.3. Even Microsoft Windows has started using for the wire protocol of Microsoft SQL Server and for the SMB file sharing protocol! Most modern queues, databases, and the like use at least TLS 1.2 or the equivalent. It's now safe to have SQL[1] and SMB shares[2] exposed to the Internet. Try telling that to someone in sec-ops twenty years ago! Most modern PaaS platforms such as cloud-native databases have very fine-grained RBAC, built-in auditing, read-only modes, and other security features on by default. Developers are spoiled with features such as SAS tokens that can be used to trivially generate signed URLs with the absolute bare minimum access required. Speaking of PaaS platforms like Azure App Service, these have completely eliminated the OS management aspect of security. Developers never again need to think about operating system security updates or OS-level configuration. Just deploy your code and go. Etc... You have to be deliberately making bad choices to end up writing insecure software in 2025. Purposefully staring at the smörgåsbord of secure options and saying: "I really don't care about security, I'm doing something else instead... just because." I know that might be controversial, but seriously, the writing has been on the wall for nearly a decade now for large swaths of the IT industry. If you're picking C or even C++ in 2025 for anything you're almost certainly making a mistake. Rust is available now even in the Linux kernel, and I hear the Windows kernel is not far behind. Don't like Rust? Use Go. Don't like Go? Use .NET 9. Seriously! It's open-source, supports AOT compilation, works on Linux just fine, and is within spitting distance of C++ for performance! [1] https://learn.microsoft.com/en-us/azure/azure-sql/database/network-access-controls-overview?view=azuresql https://learn.microsoft.com/en-us/azure/azure-sql/database/n... [2] https://learn.microsoft.com/en-us/azure/storage/files/files-smb-protocol?tabs=azure-portal https://learn.microsoft.com/en-us/azure/storage/files/files-...

mgh95 2y ago
It's important to remember that even `npgsql` can have issues (see https://github.com/npgsql/npgsql/security/advisories/GHSA-x9vc-6hfv-hg8c https://github.com/npgsql/npgsql/security/advisories/GHSA-x9...). In your world, would the developer of a piece of software exploted by a vulnerability such as this be liable?
- jiggawatts 2y ago
  The point is that secure software is easier to write, not that it's impossible to have security vulnerabilities. Your specific example is a good one: interacting with Postgres is one of those things I said people choose despite it being riddled with security issues due to its age and choice of implementation language. Postgres is written in C and uses a complicated and bespoke network protocol. This is the root cause of that vulnerability. If Postgres was a modern RDBMS platform, it would use something like gRPC and there wouldn't be any need to hand-craft the code to perform binary encoding of its packet format. The security issue stems from a choice to use a legacy protocol, which in turn stems from the use of an old system written in C. Collectively, we need to start saying "no" to this legacy. Meanwhile, I just saw a video clip of an auditorium full of Linux kernel developers berating the one guy trying to fix their security issues by switching to Rust saying that Rust will be a second class citizen for the foreseeable future.
  - mgh95 2y ago
    > Your specific example is a good one: interacting with Postgres is one of those things I said people choose despite it being riddled with security issues due to its age and choice of implementation language. Ah there is the issue: protocol level bugs are language independent; even memory safe languages have issues. One example in the .net sphere is f* which is used to verify programs. I recommend you look at what the concepts of protocol safety actually look like. > The security issue stems from a choice to use a legacy protocol, which in turn stems from the use of an old system written in C. This defect in particular occurs in the c# portion of the stack, not in postgres. This could have occurred in rust if similar programming practices were used. > If Postgres was a modern RDBMS platform, it would use something like gRPC and there wouldn't be any need to hand-craft the code to perform binary encoding of its packet format. There is no guarantee a borked client implementation would be defect free. This is a much harder problem than I think you think it is. Without resorting to a very different paradigm for programming (which, frankly, I don't think you have exposure to based upon your comments) I'm not sure it can be accomplished without rendering most commercial software non-viable. > Meanwhile, I just saw a video clip of an auditorium full of Linux kernel developers berating the one guy trying to fix their security issues by switching to Rust saying that Rust will be a second class citizen for the foreseeable future. Yeah, I mean start your own OS in rust from scratch. There is a very real issue that RIIR isn't always an improvement. Rewriting a linux implementation from scratch in rust if it's a "must have right now" fix is probably better.

mgh95 2y ago

It's important to remember that even `npgsql` can have issues (see https://github.com/npgsql/npgsql/security/advisories/GHSA-x9vc-6hfv-hg8c https://github.com/npgsql/npgsql/security/advisories/GHSA-x9...). In your world, would the developer of a piece of software exploted by a vulnerability such as this be liable?

jiggawatts 2y ago
The point is that secure software is easier to write, not that it's impossible to have security vulnerabilities. Your specific example is a good one: interacting with Postgres is one of those things I said people choose despite it being riddled with security issues due to its age and choice of implementation language. Postgres is written in C and uses a complicated and bespoke network protocol. This is the root cause of that vulnerability. If Postgres was a modern RDBMS platform, it would use something like gRPC and there wouldn't be any need to hand-craft the code to perform binary encoding of its packet format. The security issue stems from a choice to use a legacy protocol, which in turn stems from the use of an old system written in C. Collectively, we need to start saying "no" to this legacy. Meanwhile, I just saw a video clip of an auditorium full of Linux kernel developers berating the one guy trying to fix their security issues by switching to Rust saying that Rust will be a second class citizen for the foreseeable future.
- mgh95 2y ago
  > Your specific example is a good one: interacting with Postgres is one of those things I said people choose despite it being riddled with security issues due to its age and choice of implementation language. Ah there is the issue: protocol level bugs are language independent; even memory safe languages have issues. One example in the .net sphere is f* which is used to verify programs. I recommend you look at what the concepts of protocol safety actually look like. > The security issue stems from a choice to use a legacy protocol, which in turn stems from the use of an old system written in C. This defect in particular occurs in the c# portion of the stack, not in postgres. This could have occurred in rust if similar programming practices were used. > If Postgres was a modern RDBMS platform, it would use something like gRPC and there wouldn't be any need to hand-craft the code to perform binary encoding of its packet format. There is no guarantee a borked client implementation would be defect free. This is a much harder problem than I think you think it is. Without resorting to a very different paradigm for programming (which, frankly, I don't think you have exposure to based upon your comments) I'm not sure it can be accomplished without rendering most commercial software non-viable. > Meanwhile, I just saw a video clip of an auditorium full of Linux kernel developers berating the one guy trying to fix their security issues by switching to Rust saying that Rust will be a second class citizen for the foreseeable future. Yeah, I mean start your own OS in rust from scratch. There is a very real issue that RIIR isn't always an improvement. Rewriting a linux implementation from scratch in rust if it's a "must have right now" fix is probably better.