Loony2's comments

I agree, but I still believe that one issue here is the lack of understanding of what the process around software development should be.

We would get rid of some issues if we used a safer language, but the real issue is that we don't find the issues, the attacker does instead. So people are finding the issues, but why are not the people writing the software finding them?

I believe that you should have a development team that make sure there are no issues to be found, no matter the language you are writing your application in. That means you run the same tests, no matter the language, so in the end it doesn't matter what language you write it in. And you chose a language that fits the problem, you don't make the language fit the problem.

So I think your analogy of an airbag is wrong in some sense. The issue isn't weather we have an airbag or not, the issue is that we don't test if we have an airbag and then go "Whoops, the airbag didn't deploy in the crash and somebody died".

We as programmers like to think of ourselves as engineers, but we don't treat the profession as engineers, we very often deploy code we know are not tested, we might even know it is buggy, you open yourself up to a lot of damage if you do that as a bridge builder (even though it has happened).

I'm tired and this turned into a rant, but I hope that my point comes across.

EDIT: I don't mean that we should write bug free code, I mean that we should strive for code without security issues. It can be done, I work at a place where we have written code for 15 years, not only C code, or more without any remote exploitable holes.

I have to say that I feel as if the problem here isn't competent programmers though. It's competent testing that is lacking.

Sure, it's possible to make a lot of stupid mistakes in C, but most of these mistakes should be found in testing, before the code is deployed. You'll probably say that "We don't even have those problems in language X." and I agree, but you should run the same tests no matter the language, because you want to find as many problems as possible, even if you write your code in language X.

I've worked in "IT security" as a C programmer for about 10 years. I both agree and disagree with this article.

A competent C/C++ programmer will have a lot less of problems like buffer overflows and crap like that, I don't think a buffer overflow has been found in any code I've written during my 10 years as a C programmer.

I have still written code that has security issues though, most of them stem from poorly designed code and are not necessarily a language problem.

I'm not claiming to be a super human here, I've had my fair share of gotchas, like off by one errors and issues with pointer arithmetic when refactoring code and so on and we might actually reduce the time needed to verify that C code is safe if we change to another "safer" language, but I'm 100 % sure that you still have the issue with poorly designed code even with a "safe" language. And from my experience it's a lot harder to find those problems, since you need to understand how the code base works and how it fits together to find those issues.

That's the thing though, can you prove that you haven't been exploited several times that you didn't notice and grsec which grsec didn't mitigate?

And you give up your anonymity as soon as you do.

Personally I feel as if underengineering is less of a problem than overengineering.

I've seen both in real life scenarios and usually you just throw the underegineered code away and start over with knowledge gained from the previous solution. And the reason you can do that is because you usually realize that you have an underengineered solution fairly early.

Just as far as everybody knows, that doesn't mean that it's necessarily true.

There can be a distinct difference between what is believed to be true and what's actually true.

There might very well be entities that has the information, but it's sitting on it for later use.

I work in the field and anybody that says that a piece of software is secure before it has even had a security evaluation by a third party does not know what they are talking about.

I think what you have seen is security people saying that the design of Wireguard seems to be equal or better than other, current, options, that doesn't mean that the implementation is just yet.

PIA might actually log everything and send to the FBI as a regular part of their operation, hell, they might even be funded by the FBI and you would never know.

You should not trust what people tell you over the internet.

I think you misunderstand the reason for using a VPN. Privacy is not the same as anonymity.

Let me try to explain. You use a VPN to protect your connection from MiM attacks, for example if you connect to a public wifi-hotspot, or even when you are connected from home. It also gives you some privacy, because nobody can sniff your traffic, but it does not give you anonymity, well it can, but you'll not be able to verify that it does.

Sure, you hide from your ISP, but you can't verify that your VPN-provider is more trustworthy than your ISP. They might actually log everything and send it on to a third party and you'll never know. Hell, they might even be funded by the NSA...

Use Tor if you want anonymity, even though that's not 100 % sure either.

The security of Wireguard is completely unknown. Sure, it might be more secure after a formal release and a security evaluation.

They even state themselves that they should not be used if security is required.

One still stay away from stuff that is patented in the US as a European company though, most European companies want to go to market in the US sooner or later.