Re: No Country for Old System Administrators

From	cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups	comp.os.vms
Subject	Re: No Country for Old System Administrators
Date	2026-05-06 17:20 +0000
Organization	PANIX Public Access Internet and UNIX, NYC
Message-ID	<10tft85$hu8$1@reader1.panix.com> (permalink)
References	<10t685f$2ilti$1@dont-email.me> <10tcpk2$e86o$1@dont-email.me> <10tdngr$t21$1@reader1.panix.com> <10tdt4k$must$2@dont-email.me>

Show all headers | View raw

In article <10tdt4k$must$2@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>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.

Absent a threat model, relative statements about "bad" or "good"
are just opinions.

>Good security is forcing or at least encouraging the users to
>do the right thing.

Again, what "the right thing" is varies.

You may not like the decisions they made, but the people who put
together rustup have actually thought about these issues and
that this is not a likely scenario among their active threat
models, and thus not an attack vector that they need to defend
against.

>> 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.

I don't think you understand the point.  It is being claimed,
without evidence, that the directions for installing `rustup`
are a "security issue."

What I'm saying is that, under the threat model the people who
built that infrastructure are using, this is not a "security
issue."

You may disagree, but it sounds more like you are cargo-culting
what you've been told, rather than actually trying to identify a
real threat.

Anyhow, if you don't want to use rustup, there are other ways to
install Rust:
https://forge.rust-lang.org/infra/other-installation-methods.html

Note that the third bullet point under the list of reasons, "why
one might _not_ want to install using..." [rustup] is
"preference against `curl | sh`". 

Or did you think the Rust people are so naive that they are not
aware that some people find `rustup`'s suggested installation
method troublesome, and wouldn't provide an alterative?

>>                            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.

Correct.

>But having both foobar-n.n.n.tar.gz and foobar-n.n.n.tar.gz.sig
>are rather common today.

Yes.  But where does the .sig file come from?  And how do you
know that it was not tampered with?  How do you know that the
person in charge of signing the binary wasn't actively
threatened, or bribed?  Is there a well-maintained, audited,
chain of custody for the signing key?  What if it was stolen?
Is any of that in your threat model?  Do you _have_ a threat
model?  Do you even know what one is?

Maybe, before declaring that someone is "wrong", you should seek
to understand what criteria they are defining correctness.

>>> 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.

But that's not what is happening.  The site itself is
authenticated using certificate based security (notice the
"https" in the URL: this means to use TLS).

It's not just that the "address looks correct", it's that the
underlying transport layer security protocol authenticates the
server's identity by validating the certificate it presents in
the TLS exchange.

>>> 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.

I wasn't talking about certificates.  I was talking about public
key cryptography.  The latter is used for the former, but the
two are distinct.

A known problem with public-key cryptography schemes in general
is secure distribution of the public key.

Certificate-based authentication is hierarchical, with
certificate authorities authorized to sign public keys
descending from a root of trust at the top of the hierarchy;
presumably the root signing keys are physically secured and
well protected.  It is assumed that a trusted set of CAs are
securely shipped with systems externally, and may be
subsequently relied upon.  To guard against compromise, there
are provisions for revocation.  Collectively, this is generally
referred to as PKI, or "public-key infrastructure."

SSH-based authentication, on the other hand, relies on two
layers of authentication: the host is authenticated using a
Diffie-Hellman (by default) key exchange, and an ephemeral
secret key is generated for a symmetric cipher that is to
establish a covered channel between client and server, and then
the user is authenticated over that encrypted channel.  But this
is susceptible to a TOFU ("time of first use") attack.  Wide
distribution of host public keys has traditionally been the
mechanism used to address this, providing a means for end-users
to verify that they match what is expected from a given host.
OpenSSH can use a CA to sign the host public key, but that is
not widely used.

PGP, in turn, has traditionally relied on an informal "web of
trust", with users manually validating each other and signing
each other's keys; more recent work has introduced integration
with PKI.

All of these mechanisms make use of best-known cryptographic
techniques for public key, digital signature, and hash
algorithms.

The point with respect to Rustup is that Simon suggested that
they should use digital signatures.  But that's vague; and in
particular, which of the many variants of signature verification
does one use?  And how does one address the public key
distribution issue?

>Will you accept using HTTP (non S) to your banks web site,
>because the banks certificate could be compromised due to
>similar reasons?

Huh?  That is not at all the same thing.

>Of course not.
>
>Nothing is 100% secure. But one add multiple layers of security
>to make it as secure as possible.

Again, absent any details of a threat model, all of this is just
speculation and opinion.

>> 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.

No, that is exactly what they did.

And moreover, why would you assume that is a joke?  If you
really want to avoid "trusting trust" issues and verify the
provenance of your toolchain, that is one technique to do so.
If your organization is actually concerned with build integrity,
because (say) your threat model includes nation state actors,
then that's the kind of thing you do.  Google cares about that.

If your threat model does NOT include that kind of thing, then
you do not.  You probably do not have to worry about it.

	- Dan C.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

No Country for Old System Administrators Subcommandante XDelta <vlf@star.enet.dec.com> - 2026-05-03 11:25 +1000
  Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-02 22:08 -0400
    Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-03 06:43 +0000
    Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-04 01:02 +0000
  Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-03 06:45 +0000
    Re: No Country for Old System Administrators bill <bill.gunshannon@gmail.com> - 2026-05-03 08:59 -0400
      Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 11:53 -0400
      Re: No Country for Old System Administrators kludge@panix.com (Scott Dorsey) - 2026-05-03 12:10 -0400
        Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 13:24 -0400
          Re: No Country for Old System Administrators kludge@panix.com (Scott Dorsey) - 2026-05-03 19:27 -0400
            Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 20:28 -0400
              Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-04 02:26 +0000
                Re: No Country for Old System Administrators kludge@panix.com (Scott Dorsey) - 2026-05-03 22:46 -0400
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 23:29 -0400
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 23:39 -0400
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-04 11:17 -0400
        Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-04 02:24 +0000
        Re: No Country for Old System Administrators Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-05 13:02 +0000
          Re: No Country for Old System Administrators kludge@panix.com (Scott Dorsey) - 2026-05-05 16:10 -0400
            Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 16:29 -0400
              Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-05 21:59 +0000
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 18:43 -0400
                Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-05 23:04 +0000
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 19:13 -0400
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 19:41 -0400
                Re: No Country for Old System Administrators kludge@panix.com (Scott Dorsey) - 2026-05-05 21:47 -0400
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 22:17 -0400
                Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-06 04:17 +0000
                Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-06 09:29 -0400
                Re: No Country for Old System Administrators Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-06 21:20 +0000
                Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 12:55 +0000
                Re: No Country for Old System Administrators Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-06 12:46 +0000
                Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 17:36 +0000
              New language features Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-06 12:44 +0000
      Safer programming languages Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-05 12:24 +0000
    Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-03 13:28 -0400
    Re: No Country for Old System Administrators Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-05 12:59 +0000
      Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 21:30 +0000
        Re: No Country for Old System Administrators Arne Vajhøj <arne@vajhoej.dk> - 2026-05-05 19:05 -0400
          Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 17:20 +0000
            Re: No Country for Old System Administrators drb@ihatespam.msu.edu (Dennis Boone) - 2026-05-07 03:04 +0000
              Re: No Country for Old System Administrators Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2026-05-07 12:36 +0000
                Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 14:22 +0000
              Re: No Country for Old System Administrators cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 13:00 +0000

csiph-web