From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24255 invoked from network); 27 Feb 2023 23:42:40 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 27 Feb 2023 23:42:40 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7444E432D7; Tue, 28 Feb 2023 09:42:38 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id B8218432CB for ; Tue, 28 Feb 2023 09:42:34 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 4FC4735E91F; Mon, 27 Feb 2023 15:42:34 -0800 (PST) Date: Mon, 27 Feb 2023 15:42:34 -0800 From: Larry McVoy To: Chet Ramey Message-ID: <20230227234234.GO12116@mcvoy.com> References: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> <735c811e-62ce-5384-b83f-a3887baac89d@case.edu> <5a7aa991-7656-3faf-b34a-d613736716fd@case.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Message-ID-Hash: OKAPYGHUCQQDIUEIPQELOACYZNBGKQHY X-Message-ID-Hash: OKAPYGHUCQQDIUEIPQELOACYZNBGKQHY X-MailFrom: lm@mcvoy.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: segaloco , COFF X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux] List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: I think you guys are on the same team but are maybe arguing with each other more than is needed? On Mon, Feb 27, 2023 at 06:23:32PM -0500, Chet Ramey wrote: > 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 > this. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat