This has been an ongoing topic esp in the C and C++ worlds for at least the last few years (and decades), but brought to prominence recently due to the US Govt make an official release on the topic.
This is exactly the point we made in our article. Delphi (and RAD Studio with Delphi) encourages best practices and helps highlight memory-unsafe code. You can still do things which can make it unsafe.
It’s also important to consider other things like SCA and supply-chain analysis and so on. I’ve written a few articles and presented some webinars on just that subject.
I’m still conflicted. C is terrible. We can be clear on that.
C++ is both terrible and difficult in many ways … but also sophisticated, modern, highly examined, powerful, and surrounded with tooling.
(I know lots of people don’t need me to tell them …) the C++ community is highly self-critical of their own language.
It’s a conference classic to pull apart in detail all the cuckoo implications of a particular language feature, or proposed change.
And between them, C and C++ have generated active efforts towards successor languages trying to be “better”.
D a long time ago.
Rust, Swift (indirectly).
Zig and Odin.
Carbon, Circle, CppFront. and Val (now Hylo).
C++ is currently important to some very big companies, and also has some very strong tooling, address sanitizer, ub sanitiser, thread sanitizer, …
And C++ has been adding more and more capability for compile-time program correctness.
The C++ landscape is like Indiana Jones’ Singapore … bustling, semi-chaotic, and active.
It feels wrong to me for Delphi as a language and community if we sit complacently, within sight of that churn of activity.
(When we are pretty much on a par in terms of manual memory management)
There have been several additions to the compiler recently to support weird things in connection with security and we were already ahead of the curve in recognizing that security has emerged as a significant topic and requirement (lots of larger customers we deal with have it as one of their highest requirements).
This is going to be an unending battle, just as virus and trojan detection and mitigation is a battle of one-upmanship for the antivirus vendors. Being called out for memory safety by the NSA and White House is definitely a plus point but our blog article makes it clear we’re not saying that’s the end of it, or even the end of the beginning of it, but it’s definitely a good starting point.
As time goes on computational security and IT infrastructure security is going to continue to evolve - see, for instance, the changes in iOS this month and the upcoming changes in Windows too. As a company Embarcadero absolutely understands that this is both an opportunity to be on the right side of the topic (for a change) and that being on the right side is a moving target which we need to keep aiming for.
Correct (everything SHOULD be memory-safe), but impossible, since nobody ever redevelops a legacy system unless there is a dire need for it. I have been using C# for the past 15 years, and it was built into C# from day one (good design choice). But nobody ever redevelops a C++ or Delphi application just to make it “memory safe”. It “is what it is”
Well, maybe, but in the past year as we’ve been working with Tech Partners who provide things like SCA and other scanning services it’s become obvious that there are a significant number of customers who are seeking out that kind of security analysis. The reasons are varied; some due to changes in compliance requirements, audits, or even an increased awareness of vulnerabilities, you name it.
In all cases the results of that activity are an identification of problem areas, the production of a plan to mitigate them, and, the yes, coding or revising to make that happen.
So, I guess the answer there is a caveat: re-engineering in the light of emergent threats, of changes in end-user expectations, of new governmental, political, or administrative initiatives, or purely because it’s part of a manifest of technical debt that it becomes prescient to address.
That’s great and very necessary, but there is a MASSIVE difference between something designed to be totally “memory-safe” and diagnosis, detection, and amelioration after the fact. In the end, with non-memory-safe languages, you are forever chasing these problems down and cannot, with any certainty, stop them from re-occurring. Of course it’s best to put the effort into minimising these issues
Well, maybe, but in the past year as we’ve been working with Tech Partners who provide things like SCA and other scanning services it’s become obvious that there are a significant number of customers who are seeking out that kind of security analysis. The reasons are varied; some due to changes in compliance requirements, audits, or even an increased awareness of vulnerabilities, you name it.
In all cases the results of that activity are an identification of problem areas, the production of a plan to mitigate them, and, the yes, coding or revising to make that happen.
So, I guess the answer there is a caveat: re-engineering in the light of emergent threats, of changes in end-user expectations, of new governmental, political, or administrative initiatives, or purely because it’s part of a manifest of technical debt that it becomes prescient to address
Just some experiment examples of the sort of thing that Rust prevents, and that we need static analysis to find …
(This inspired by @GrahameDGrieve’s presentation semi-recently)
{$APPTYPE CONSOLE}
program Project1;
uses
system.SysUtils;
type
TMyClass = class
field : integer;
procedure read;
procedure incr;
constructor create;
end;
procedure TMyClass.read;
begin writeln(field); end;
procedure TMyClass.incr;
begin inc(field); end;
constructor TMyClass.create;
begin field := 42; end;
begin
var c := TMyClass.create;
var fn1 := c.incr;
var fn2 := c.read;
c.incr; c.read;
c.free;
c.incr; c.read;
//freeandnil(c);
fn1();
fn2();
readln;
end.
Output :
43
44
45
FreeAndNil works “better” than free, but only at runtime.
I believe the term “memory safe” is probably meant to be about buffer overflow type problems that seem to cause the majority of major security bugs. I’m sure a Delphi programmer can cause themselves harm but the general approval would have been around the default string etc not having those same buffer overflow issues. It will be a nice line to use that Delphi is on the NSA list of approved languages as it’s always been an uphill battle getting people to approve Delphi. I still remember my frustration when I first started my career pitching Delphi to do a job with ANZ and them telling my VBA/Excel etc was an approved technology but Delphi wasn’t so it couldn’t be done that way even though their approved way would have made it super simple to expose to their customers all their internal secrets they wanted to keep safe.
" The percentage was compiled after Google engineers analyzed 912 security bugs fixed in the Chrome stable branch since 2015, bugs that had a “high” or “critical” severity rating.
The number is identical to stats shared by Microsoft. Speaking at a security conference in February 2019, Microsoft engineers said that for the past 12 years, around 70% of all security updates for Microsoft products addressed memory safety vulnerabilities."
