[1dom]

This is a really cool idea, and very appealing. Also very nice that it looks usable with just an SSH client. It would be useful if it was explained what the companion client is for?

Another small personal gripe: I think you should either remove the 1 line copy/paste sh install on the homepage, or add a link to a git repo on the homepage. I know it's possible to view the sh by visiting it, but a raw text file doesn't give any info about contributors or development process. Current form of no git repo and copy/paste bash pipe on homepage feels like a dark pattern.

[Izmaki]

Not to mention that a webserver can be configured to show one sh file when a regular browser visits and another when curl etc. gets it. Show one thing, install another.

[nkrisc]

So download it with curl and read it first before executing it from your local disk.

[codegladiator]

read it ? we dont do what kind of stuff here, i got my army of reader agents.

[Izmaki]

Except you can't really be sure, still: http://web.archive.org/web/20250622061208/https://www.idontp...

[drabbiticus]

This is helpful to know, but also pretty general security practice. If you are auditing an artifact, only use that audited artifact after, don't assume that a network endpoint can never change what it serves. If you must use a newly downloaded artifact, verify it matches whatever you audited by comparing some sort of hash or derived value.

[nkrisc]

The link won’t load for me, but I’m having a hard imagining how a remote server could change a file on your hard drive.

Is it about deceptive commands that look like they’ll do something different using weird characters to alter what commands run or something?

[Izmaki]

The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash. I don't remember the magic by heart, but the blog post conclusion was essentially that you can't / shouldn't blindly trust which scripts you pipe straight into bash from the internet, because even if it looks correct in a browser, the script you might end up running could be different.

It's more of a "this is possible" than "this is a real concern", of course.

[nkrisc]

> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash.

Maybe I’m not that clever but I can’t imagine at all how that would even be remotely possible. How would curl even know it’s being piped into something else? And if curl can’t know, how would the remote server know?

Send different response to browser vs curl, sure, that’s easy. But I’m saying download it to your local disk first, read it from there, then run your local copy, that you read. Don’t read it in the browser.

[endofreach]

> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash

I think you must be mixing something up here. At least i would be very surprised to learn how pipes are that leaky over the wire. It would be very interesting. But i can't imagine how a remote would differentiate between curl and curl piped. And the article doesn't load unfortunately.

[bl4ckbe4r]

noted, good feedback :) will change it later, thanks!

[rob]

You don't have to change it just because one person complained. I personally like the "copy and paste curl command" to install something and I'm sure many others do as well. It's very convenient, and I can inspect the file myself if I'm that paranoid about it.

[1dom]

Sorry, it wasn't meant to come across as a complaint with copy and paste curl command, I agree with you it's convenient and I generally like it.

However, the sort of tools that generally provide it also generally have a GitHub link nearby to encourage reading/writing the source. That too is convenient and I generally like it. Seemed like a fair suggestion.