Read from STDIN

[ellotheth]

Because curl |pipethis would be nifty.

[ellotheth]

So there are a couple problems with this.

First, PIPETHIS_SIG should probably come back, to avoid forcing users to set --signature (because there's no <script location>.sig available).

Second, reading the script from stdin means pipethis can't accept interactive input, which means user verification of the author is impossible. Non-interactive verification is probably not a good idea:

• pipethis could force a single author match from the key service and bail if there are none or more than one. That breaks if an attacker sets up their own unique identity in the key service.
• pipethis could require a public key to be specified on the command line. That would bypass the third-party identity provider entirely, which is still not ideal.
• pipethis could require an author match against a public key fingerprint, specified on the command line. The key service would come back into play, but it has the same weakness as the first option.

[odeke-em]

Yap @ellotheth good points about not accepting interactive input since after encountering EOF from the script read, os.Stdin is closed. A bad hack could re-open os.Stdin but we probably wouldn't want that. If you see a way out of this, I have a PR for you implementing reading from stdin ;)

[ellotheth]

@odeke-em Thanks for the PR! I've had reading from stdin floating around in a local branch, so I'll push that up and see if we sync. [e] ca6473d

I was contemplating having some kind of client-side config file that contains trusted PGP fingerprints, and allowing a non-interactive install if the author fingerprint matches one in the trusted list. That'd be a colossal extra hassle for most users, but most users would probably be fine with the non-stdin, interactive process. The primary beneficiaries of a prompt-free install are the people who want to use pipethis into their own scripts--CI/CD, build scripts, system provisioning, etc.

Security-wise, users would be in the same boat as before: improved over a straight content hash verification, but still vulnerable to social engineering (hi i'm fakegemma and this is my new fingerprint please update your trusted file). On the other hand, I don't see a huge difference between that and adding somebody's public key to your apt config so you can use their third-party repo.

[kapouer]

It could also output to stdout, so curl | pipethis | bash. Oh ! wait...

[ellotheth]

@kapouer Yes, that'd be lovely! If there's a good solution for non-interactive processing, | bash would be feasible too.

[TheZ3ro]

A very very (stupid) workaroud can be:
Print to stdout a bash script that Warn user about HTTP vs HTTPS and the actual Author/Fingerprint, if user press "Y" the bash script execute the verified insert_software_name_here installer

Edit: Piping to bash disable the read command so, no stdin input.

[ellotheth]

Operating on the assumption that the primary use case for this is automated scripts:

• Interactive script verification is irrelevant
• Interactive author selection is impossible

I could disable the --inspect option when pipethis reads from stdin, which is fine because it's broken anyway in that case (and really, people could do something like curl | pipethis | vipe | bash). With #5, I can force the author match to come from the local keyring. On top of that, I could add a requirement that there only be one match for the author.

The flow would be something like

1. Get the script from stdin
2. Find PIPETHIS_AUTHOR in the local keyring
3. Bail unless there's exactly one match
4. Verify the signature (so the script will need to be clearsigned, or the user will specify --signature)
5. Echo the script back to stdout so vipe or bash (or whatever) can read it

Properly, "trust" is only signified when Alice signs Bob's key and publishes the signature, not when she adds Bob's key to her keyring. In practice, I import people's keys and use them to verify signatures (without signing them myself) all the time.

[TheZ3ro]

IMHO it's great.

But I have a doubt in the local keyring part.
The user will add the author key to the local keyring? Or pipethis ?

In the first case (I suppose it's the "correct" way)
The step zero in the flow should be:
0. Manually add the author key in your local keyring (?)

[ellotheth]

@TheZ3ro The user would be responsible for adding the author key to their keyring, so your "zeroth" step is correct.