search

FiloSottile / age

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.
https://age-encryption.org
BSD 3-Clause "New" or "Revised" License
16.83k stars 492 forks source link

Recipient file support #165

Closed sylr closed 3 years ago

codesoap commented 3 years ago

I'm not a fan of this pull request. The new behaviour seems unintuitive to me and is achievable with the features that age provide already. age is supposed to be a UNIX-style tool, so I think combining it with xargs would be a simpler way to support recipient files (you can easily put this into a script if you do it often):

$ cat recipients
age1cted2nsw07mzjue9uwlxh020zhvf42sh5lywzunqnggepver8yjq0t0jtp
age1x7xk50anca87rcvuw6u3k88dvkfkwlf58dwyz3t5rum94vw2l5hq6k6d0s
$ awk '{print "-r", $0}' recipients | xargs -J % age % -o data.age data

I highly value orthogonality in the features of tools and would hate to see such unneeded feature creep in age.

sylr commented 3 years ago

How can

age -r recipients -o data.age data

be less intuitive than

awk '{print "-r", $0}' recipients | xargs -J % age % -o data.age data

?

codesoap commented 3 years ago

I find it unintuitive that -r should take a string, which could be either interpreted as a key or a filename. I find this ambiguity confusing. As I suggested already, you could put the xargs stuff into a script, if you find yourself using something like this frequently.

FiloSottile commented 3 years ago

Hi! Thank you for contributing! I took a different path in #173, but it was useful to look at open PRs for the users' expectations. Let me know if that implementation works for you!

I wrote up an explanation of why I ended up implementing recipient files and not HTTPS sources on the mailing list, and I appreciate feedback! https://groups.google.com/g/age-dev/c/StmWsOyb-H8/m/a44rSBIWCAAJ