I would claim that the adaptation of languages like Python,
JavaScript, Java, C# and PHP is very high in the IT industry.
They are all memory safe. In different ways. But still.
On 5/2/2026 9:25 PM, Subcommandante XDelta wrote:
I am glad that I have retired.
https://spectrum.ieee.org/ai-cyberattacks-memory-safe-code
Mythos got a lot of PR.
But it is worth noting that Anthropic is a business selling AI.
They are very far from being unbiased.
And not everyone reading the actual publication are
super impressed.
A couple of random links:
https://www.linkedin.com/pulse/reality-mythos-supposed-70-exploitation-rate-roger-grimes-0gw5e/
https://www.flyingpenguin.com/the-boy-that-cried-mythos-verification-is-collapsing-trust-in-anthropic/
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
I would claim that the adaptation of languages like Python,
JavaScript, Java, C# and PHP is very high in the IT industry.
They are all memory safe. In different ways. But still.
Not very memory safe. Java and C# are a little bit closer.
bill <bill.gunshannon@gmail.com> wrote:
On 5/3/2026 2:45 AM, Lawrence DrCOOliveiro wrote:
On Sun, 3 May 2026 11:25:00 +1000, Subcommandante XDelta wrote:
With $1 Cyberattacks on the Rise, Durable Defenses Pay Off Writing
memory-safe code beats patching your way to safety
Rust seems to be the language du jour for tackling this problem.
Google reported a significant decrease in memory-related bugs after
adopting Rust into the Android code base in a major way. Though,
oddly, not a decrease in bugs overall ...
There was memory safe C 40 years ago. No one was interested.
People in general aren't really interested at fixing security problems
at the source. Memory safe languages and safe computer architectures
have never met much popularity outside academia unfortunately.
We did get java, much to our dismay, and now rust. But actual adoption
is low.
Those languages all do that.
OK. I don't see PHP mentioned anywhere.
But given that Python and Ruby are on the list, then I cannot see
why PHP should not be on the list.
Could it just possibly be, that the design and implementation of PHP
are so crappy, that nobody can actually be sure it really *is*
memory-safe ... ?
On Sun, 3 May 2026 20:28:23 -0400, Arne Vajh|+j wrote:
OK. I don't see PHP mentioned anywhere.
Funny, that ...
But given that Python and Ruby are on the list, then I cannot see
why PHP should not be on the list.
Could it just possibly be, that the design and implementation of PHP
are so crappy, that nobody can actually be sure it really *is*
memory-safe ... ?
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
Could it just possibly be, that the design and implementation of PHP
are so crappy, that nobody can actually be sure it really *is*
memory-safe ... ?
"We use Fortran because you can't trust engineers with pointers."
-- Manny Salas (pre-Fortran-90)
And buffer overflow doesn't happen because PHP extend
as necessary. You can say that a PHP array is really
the equivalent of a Python dict. Strings also get extended
as necessary.
$s = 'ABC';
$s[3] = 'X';
echo $s;
just outputs:
ABCX
we may not like that behavior and prefer an exception.
But no buffer overflow.
On Sun, 3 May 2026 11:25:00 +1000, Subcommandante XDelta wrote:
With $1 Cyberattacks on the Rise, Durable Defenses Pay Off Writing
memory-safe code beats patching your way to safety
Rust seems to be the language du jour for tackling this problem.
Google reported a significant decrease in memory-related bugs after
adopting Rust into the Android code base in a major way. Though,
oddly, not a decrease in bugs overall ...
People in general aren't really interested at fixing security problems
at the source. Memory safe languages and safe computer architectures
have never met much popularity outside academia unfortunately.
On 2026-05-03, Scott Dorsey <kludge@panix.com> wrote:
People in general aren't really interested at fixing security problems
at the source. Memory safe languages and safe computer architectures
have never met much popularity outside academia unfortunately.
Ada. At least before the mandate got cancelled and then you got all the >overruns on the following projects that had stopped using it.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-05-03, Scott Dorsey <kludge@panix.com> wrote:
People in general aren't really interested at fixing security problems
at the source. Memory safe languages and safe computer architectures
have never met much popularity outside academia unfortunately.
Ada. At least before the mandate got cancelled and then you got all the
overruns on the following projects that had stopped using it.
Until they started adding everything and the kitchen sink to it, until it became the PL/1 of the 1990s.
On 2026-05-03, Lawrence D Oliveiro <ldo@nz.invalid> wrote:
On Sun, 3 May 2026 11:25:00 +1000, Subcommandante XDelta wrote:
With $1 Cyberattacks on the Rise, Durable Defenses Pay Off Writing
memory-safe code beats patching your way to safety
Rust seems to be the language du jour for tackling this problem.
Google reported a significant decrease in memory-related bugs after
adopting Rust into the Android code base in a major way. Though,
oddly, not a decrease in bugs overall ...
Writing secure code is a frame of mind, not merely just using a tool
and then expecting security magic to "just happen".
Excellent example from the Rust installation web page:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
This is from: https://rust-lang.org/tools/install/
This is an entire community that gets on its collective high horses about
how its new language is so superior from a security point of view to >everything else out there and starts forcing it down our throats.
It then tells us that we can install this new language by just directly >downloading a shell script from some random website and then directly
execute it on our own computer without bothering to first check that
it hasn't been tampered with by someone compromising the website.
Signature checking! Such an old fashioned concept! Can't let reality get
in the way of a little temporary convenience!
The grown up response would have been to insist on the user downloading
the shell script as a file, verifying the signature before execution,
and then saying that this is the kind of mindset required in this world.
* simple programming languages only trying to do a few things well
often thrive and live longer than complex languages trying to
do everything - Cobol and C did better than PL/I and Ada
On Tue, 5 May 2026 16:29:49 -0400, Arne Vajh|+j wrote:
* simple programming languages only trying to do a few things well
often thrive and live longer than complex languages trying to
do everything - Cobol and C did better than PL/I and Ada
Cobol is rCLsimplerCY?? Yeah, right ...
Ada is still with us, and spawning projects like Spark to point out to
the Rust folks that some people were worrying about memory safety
before they were even born ...
The Cobol language is relative simple.
I am sure there are also places where PL/I are still used.
Likely in the financial sector.
In article <10tcpk2$e86o$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-05-03, Lawrence D|+Oliveiro <ldo@nz.invalid> wrote:
On Sun, 3 May 2026 11:25:00 +1000, Subcommandante XDelta wrote:
With $1 Cyberattacks on the Rise, Durable Defenses Pay Off Writing
memory-safe code beats patching your way to safety
Rust seems to be the language du jour for tackling this problem.
Google reported a significant decrease in memory-related bugs after
adopting Rust into the Android code base in a major way. Though,
oddly, not a decrease in bugs overall ...
Writing secure code is a frame of mind, not merely just using a tool
and then expecting security magic to "just happen".
Excellent example from the Rust installation web page:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
This is from: https://rust-lang.org/tools/install/
I've heard this criticism before, but it's a bad argument.
First, nothing at all is preventing you from downloading
whatever is at that URL and inspecting it yourself, verifying
that its checksum matches a known hash, etc, before running it.
Second, nothing prevents a user from running that command line
in a sandbox, even if they didn't do the first things.
And furthermore, it elides any discussion of threat models; why
would I worry about the rustup.rs side being compromised any
more than I would worry about the compiler binaries themselves
being compromised?
Is this substantially different than
downloading a tarball from somewhere, unpacking it, and running
a contained "./configure" script?
It then tells us that we can install this new language by just directly
downloading a shell script from some random website and then directly
execute it on our own computer without bothering to first check that
it hasn't been tampered with by someone compromising the website.
I wouldn't call that, "some random website". It's the official
way to do that.
The grown up response would have been to insist on the user downloading
the shell script as a file, verifying the signature before execution,
and then saying that this is the kind of mindset required in this world.
But also, where do I get the signature in the first place, and
how do I verify that it is correct? Supposing the checksum is
signed with something like PGP or an equivalent, where do I get
the public key to verify the signature, and how can I be sure
that THAT hasn't been tampered with? What if I don't have
anyone in _my_ web of trust that verified the key the script was
signed with? And even if I did, how do I know the key wasn't
compromised? Some poor release engineer might be a basement
somewhere, RIGHT NOW, getting worked over by goons with a rubber
hose. Oh my!
On the other hand, I can tell you what the Android Security team
did when they first started exploring Rust: the used `mrustc`,
which is a Rust compiler written in C++, to compile a bootstrap
compiler, using a trusted C++ compiler.
Then they started rolling forward over point versions of the
compiler (mrustc lacked some features to compile the newest),
using the previous to compile the next, until they got to the
then-newest release compiler. Then they verified that it was
bitwise identical to what they saw coming from the Rust
project.
THAT is what the grownups do.
On Tue, 5 May 2026 18:43:59 -0400, Arne Vajh|+j wrote:
I am sure there are also places where PL/I are still used.
Likely in the financial sector.
Not likely.
On Tue, 5 May 2026 18:43:59 -0400, Arne Vajh|+j wrote:
The Cobol language is relative simple.
It forced you to spell out low-level details that were really only
relevant on mainframes from over half a century ago.
It was supposed
to be focused on rCLbusinessrCY use, but just a decade or two after it
came out, rCLbusinessrCY customers started to make more and more use of
SQL databases, and Cobol was never a good fit for that.
For the first 10-20 years of RDBMS then Cobol was the
most widely used language for RDBMS access.
Cobol with embedded SQL was a huge thing. Sort of still is.
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
For the first 10-20 years of RDBMS then Cobol was the
most widely used language for RDBMS access.
Cobol with embedded SQL was a huge thing. Sort of still is.
It's true that COBOL never implemented embedded relational database access
as well as it implemented heirarchical database access.
But I think that it's also true that no language has ever implemented embedded relational database access as well as COBOL implemented
heirarchical database access.
The COBOL syntax is ghastly but it's the price you pay.
On 5/5/2026 7:04 PM, Lawrence DrCOOliveiro wrote:
It was supposed to be focused on rCLbusinessrCY use, but just a decade
or two after it came out, rCLbusinessrCY customers started to make more
and more use of SQL databases, and Cobol was never a good fit for
that.
You keep claiming that, but it is ridiculous.
Note that when there are talk about what Rdb customers will do, then
two of the solutions Mimer and SQLRelay both come with an embedded
SQL pre-compiler for Cobol. Because that is what is needed. People
use Cobol with embedded SQL to access Rdb (and also Oracle DB for
that matter).
On Tue, 5 May 2026 16:29:49 -0400, Arne Vajhoj wrote:
* simple programming languages only trying to do a few things well
often thrive and live longer than complex languages trying to
do everything - Cobol and C did better than PL/I and Ada
Cobol is ?simple??? Yeah, right ...
Ada is still with us, and spawning projects like Spark to point out to
the Rust folks that some people were worrying about memory safety
before they were even born ...
<https://devclass.com/2022/11/08/spark-as-good-as-rust-for-safer-coding-adacore-cites-nvidia-case-study/>
On 5/5/2026 5:59 PM, Lawrence DrCOOliveiro wrote:
On Tue, 5 May 2026 16:29:49 -0400, Arne Vajh|+j wrote:
* simple programming languages only trying to do a few things well
often thrive and live longer than complex languages trying to
do everything - Cobol and C did better than PL/I and Ada
Cobol is rCLsimplerCY?? Yeah, right ...
Yes.
The Cobol language is relative simple.
When it was created there was actually people that believed
programmers would no longer be needed and the business people
could write their own Cobol.
That did not happen.
People that already know some of the modern programming
languages need to do a mental reset when learning Cobol,
because Cobol is do different. But different is not the
same as complex.
Ada is still with us, and spawning projects like Spark to point out to
the Rust folks that some people were worrying about memory safety
before they were even born ...
I am sure there are also places where PL/I are still used.
Likely in the financial sector.
But while PL/I and Ada were main languages many years ago,
then they are very niche today.
On Tue, 5 May 2026 19:41:58 -0400, Arne Vajh|+j wrote:
On 5/5/2026 7:04 PM, Lawrence DrCOOliveiro wrote:
It was supposed to be focused on rCLbusinessrCY use, but just a decade
or two after it came out, rCLbusinessrCY customers started to make more
and more use of SQL databases, and Cobol was never a good fit for
that.
You keep claiming that, but it is ridiculous.
Note that when there are talk about what Rdb customers will do, then
two of the solutions Mimer and SQLRelay both come with an embedded
SQL pre-compiler for Cobol. Because that is what is needed. People
use Cobol with embedded SQL to access Rdb (and also Oracle DB for
that matter).
See, thatrCOs what I mean. You say IrCOm being rCLridiculousrCY, then in the next breath you admit that some complicated patchwork of additional proprietary, nonportable tools is necessary to get it to work.
Cobol itself is supposed to be portable. But all this additional
fiddling necessary to implement SQL access is not.
On 5/5/2026 5:30 PM, Dan Cross wrote:
In article <10tcpk2$e86o$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-05-03, Lawrence D|+Oliveiro <ldo@nz.invalid> wrote:
On Sun, 3 May 2026 11:25:00 +1000, Subcommandante XDelta wrote:
With $1 Cyberattacks on the Rise, Durable Defenses Pay Off Writing
memory-safe code beats patching your way to safety
Rust seems to be the language du jour for tackling this problem.
Google reported a significant decrease in memory-related bugs after
adopting Rust into the Android code base in a major way. Though,
oddly, not a decrease in bugs overall ...
Writing secure code is a frame of mind, not merely just using a tool
and then expecting security magic to "just happen".
Excellent example from the Rust installation web page:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
This is from: https://rust-lang.org/tools/install/
I've heard this criticism before, but it's a bad argument.
First, nothing at all is preventing you from downloading
whatever is at that URL and inspecting it yourself, verifying
that its checksum matches a known hash, etc, before running it.
Second, nothing prevents a user from running that command line
in a sandbox, even if they didn't do the first things.
That applies to almost everything security related.
The users *could* do something by themselves to mitigate risks.
Experience show that a significant part of users *will* not.
That is bad security.
Good security is forcing or at least encouraging the users to
do the right thing.
And furthermore, it elides any discussion of threat models; why
would I worry about the rustup.rs side being compromised any
more than I would worry about the compiler binaries themselves
being compromised?
The fact that there are other security issues does make
a security issue go away.
Is this substantially different than
downloading a tarball from somewhere, unpacking it, and running
a contained "./configure" script?
If there is no .sig file and no recommendation of checking,
then there is no difference.
But having both foobar-n.n.n.tar.gz and foobar-n.n.n.tar.gz.sig
are rather common today.
It then tells us that we can install this new language by just directly
downloading a shell script from some random website and then directly
execute it on our own computer without bothering to first check that
it hasn't been tampered with by someone compromising the website.
I wouldn't call that, "some random website". It's the official
way to do that.
Assuming that because the address looks correct, then
it is fine is very bad security.
The grown up response would have been to insist on the user downloading
the shell script as a file, verifying the signature before execution,
and then saying that this is the kind of mindset required in this world.
But also, where do I get the signature in the first place, and
how do I verify that it is correct? Supposing the checksum is
signed with something like PGP or an equivalent, where do I get
the public key to verify the signature, and how can I be sure
that THAT hasn't been tampered with? What if I don't have
anyone in _my_ web of trust that verified the key the script was
signed with? And even if I did, how do I know the key wasn't
compromised? Some poor release engineer might be a basement
somewhere, RIGHT NOW, getting worked over by goons with a rubber
hose. Oh my!
That is how certificates work.
Will you accept using HTTP (non S) to your banks web site,
because the banks certificate could be compromised due to
similar reasons?
Of course not.
Nothing is 100% secure. But one add multiple layers of security
to make it as secure as possible.
On the other hand, I can tell you what the Android Security team
did when they first started exploring Rust: the used `mrustc`,
which is a Rust compiler written in C++, to compile a bootstrap
compiler, using a trusted C++ compiler.
Then they started rolling forward over point versions of the
compiler (mrustc lacked some features to compile the newest),
using the previous to compile the next, until they got to the
then-newest release compiler. Then they verified that it was
bitwise identical to what they saw coming from the Rust
project.
THAT is what the grownups do.
I will assume that is a joke.
On 2026-05-05, Lawrence D Oliveiro <ldo@nz.invalid> wrote:
On Tue, 5 May 2026 16:29:49 -0400, Arne Vajhoj wrote:
* simple programming languages only trying to do a few things well
often thrive and live longer than complex languages trying to
do everything - Cobol and C did better than PL/I and Ada
Cobol is ?simple??? Yeah, right ...
Ada is still with us, and spawning projects like Spark to point out to
the Rust folks that some people were worrying about memory safety
before they were even born ...
<https://devclass.com/2022/11/08/spark-as-good-as-rust-for-safer-coding-adacore-cites-nvidia-case-study/>
Also, type safety is one hell of a lot more than merely memory safety.
Any combination of language and RDBMS needs something
to connect them.
I don't think you understand the point. It is being claimed,
without evidence, that the directions for installing `rustup`
are a "security issue."
I don't think you understand the point. It is being claimed,
without evidence, that the directions for installing `rustup`
are a "security issue."
The problem here isn't really rustup. A better objection to "curl|bash"
is that it normalizes a habit of failing to think critically and act carefully.
I don't think you understand the point. It is being claimed,
without evidence, that the directions for installing `rustup`
are a "security issue."
The problem here isn't really rustup. A better objection to "curl|bash"
is that it normalizes a habit of failing to think critically and act >carefully.
On 2026-05-06, Dennis Boone <drb@ihatespam.msu.edu> wrote:
I don't think you understand the point. It is being claimed,
without evidence, that the directions for installing `rustup`
are a "security issue."
The problem here isn't really rustup. A better objection to "curl|bash"
is that it normalizes a habit of failing to think critically and act
carefully.
And that is _exactly_ the point I am making.
This is what I see on that installation page:
|Using rustup (Recommended)
|
|It looks like you're running macOS, Linux, or another Unix-like OS. To >|download Rustup and install Rust, run the following in your terminal,
|then follow the on-screen instructions. See "Other Installation
|Methods" if you are on Windows.
|
|curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
I never even read that other page because they said it was for Windows
but I now see they have actually been forced to say the exact same thing
as I have just done (but they have buried it on something they described
as a Windows-only page).
I stand by my original comments, especially after reading that "Windows"-only >page.
I also stand by my approach that security is a frame of mind, and which >cannot be replaced by some claimed "magic" tool. Tools can help (and are >required), but that's all they can do (and they are not magic).
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 00:57:26 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,187 |