Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Chet Ramey <>
To: Dan Cross <>
Cc: segaloco <>, COFF <>
Subject: [COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]
Date: Mon, 27 Feb 2023 18:23:32 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2/27/23 5:01 PM, Dan Cross wrote:
> On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <> wrote:
>> On 2/27/23 4:22 PM, Dan Cross wrote:
>>> [COFF]
>>> On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <> wrote:
>>>> On 2/27/23 4:01 PM, segaloco wrote:
>>>>> The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
>>>> Well, I suppose if it's from a trustworthy source...
>>>> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
>>> I find this a little odd. If I go back to O'Reilly books from the
>>> early 90s, there was advice to do all sorts of suspect things in them,
>> Sure. My sense is that the world is a less trustworthy place today, that
>> there are more bad actors out there, and that promoting unsafe practices
>> like this does little good. If practices like this become the norm (and
>> they have), it gets very easy to trick someone (or worse, compromise the
>> server and replace the script with something that does just a little bit
>> extra). Blindly executing code you get from elsewhere as root isn't a
>> great idea.
> FTR, you don't usually do this as root, as by default `rustup`
> installs into $HOME.

You seem to be concentrating on `rustup', which is fine, it's your
preferred example. But just because you don't run `sudo sh' when using
`rustup' doesn't mean there aren't a disturbingly large number of
installers -- or whatever -- for which that is the recommended workflow.
Nor does the fact that `rustup' is a safe example mean that this is a safe
practice in general. I posit that it's a bad idea in general to blindly
run scripts you download from the Internet, and it's especially bad to
do it as root. Depending on how you accept risk, you can choose to do
things about it, but that's often not part of recommendations.

> I'm not sure how this is any less safe than downloading, say, a
> tarball and running the contained `configure` script, except that in
> the latter case one at least has the chance to look at the script
> contents.

Yeah, but with configure you don't want to. :-). In any case, if you want
to, you can have a workflow where you rebuild configure yourself.

>> Look at the compromises the Python community has been dealing with
>> recently, involving replacing common packages on well-known repository
>> sites with malicious ones.
> That seems like an issue that is independent of the delivery mechanism.

I suppose it's workflow-dependent. If your workflow for python development
involves using open-source components (ctx, pytorch, etc.) you get from
some repository like PyPI, you're going to be susceptible to attacks like

``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU

  reply	other threads:[~2023-02-27 23:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
2023-02-27 21:22       ` Dan Cross
2023-02-27 21:42         ` Chet Ramey
2023-02-27 22:01           ` Dan Cross
2023-02-27 23:23             ` Chet Ramey [this message]
2023-02-27 23:42               ` Larry McVoy
2023-02-28  0:29                 ` Dan Cross
2023-02-28  0:28               ` Dan Cross
2023-02-28 14:53                 ` Chet Ramey
2023-02-28 15:25                   ` Dan Cross
2023-02-28 16:03                     ` Chet Ramey
     [not found]         ` <>
2023-02-27 22:07           ` [COFF] Re: [TUHS] " Dan Cross
     [not found]         ` <>
2023-02-27 22:17           ` [COFF] Re: [TUHS] " Dan Cross
2023-02-27 23:20             ` Stuff Received
     [not found] <>
     [not found] ` <Y/>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
2023-02-27 21:04             ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).