aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
blob: 5234c3c6801bb2500c7c5004a7148505cb8569fc (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# Hashpipe
#### by [Jason A. Donenfeld](mailto:Jason@zx2c4.com)

Scared of `curl https://... | bash`, but can't resist sending attractive one-liner install commands to your friends? `hashpipe(1)` lets you put hash verification into the pipeline:

```
$ curl https://... | hashpipe sha256 e8ad3b2b10fa2a5778950ba028f70ca4e5401ea23b52412227eaf908eb7d9b3e | sh -
```

It supports all hash algorithms supported by OpenSSL.

### Building

```
$ make
$ sudo make install PREFIX=/usr
```

### Work in Progress

We still need to make sure this works as intended (it might not right now!) and write man pages. But perhaps we'll wind up deleting this repository, if it turns out this is a bad idea. Consider this a little simple-idea-trial. Among many issues, one obvious one is that right now this supports everything that OpenSSL does, but is that actually a good property? That means, for example, this supports md\_gost94; perhaps we should cut back on the agility. A better design might be to _only_ support something common like SHA256, and remove the choice argument all together. That would simplify the code, too, and we could get rid of the OpenSSL dependency. (Or we could have this support _only_ BLAKE2, and use short 44-character base64 strings for it instead.) Also, maybe we shouldn't even be `curl|bash`ing in the first place. For these, and for many other reasons, *this thing is likely a bad idea*.

### License

This project is released under the [GPLv2](COPYING).