Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Allow use of ssh public key *path* rather than key contents for recipient #84

Closed
larsks opened this issue Jan 8, 2020 · 2 comments
Milestone

Comments

@larsks
Copy link

larsks commented Jan 8, 2020

Environment

  • OS: fedora 30
  • age version: e43cf8b

What were you trying to do

I wish that I could encrypt to a public key by specifying a path to the public key file:

age -r ~/keys/someperson.pub

Rather than the *contents * of the public key file:

age -r $(cat ~/keys/someperson.pub)

(Maybe this would require a new option (-R?) rather than overloading the behavior of the existing --recipient/-r option)

And obviously it would be nice if this same feature were available for age public keys as well.

@cyb3rz3us
Copy link

If possible, I would vote for using the same '-r' but if not feasible, then whatever works to get this implemented.

@nxg
Copy link

nxg commented Jul 20, 2020

(This comment may be redundant, given the presence of the linked pull request; if so, just ignore)

Another possibility is to distinguish a key-file from a key by prefixing it with @

age -r @~/keys/someperson.pub

(curl --data-binary has a syntax like this, if it's useful to quote a precedent).

Another possibility is to regard the -r option value as referring to a file if there's a file by that name, and as an explicit key otherwise. It's true that adds a heuristic element, but it's only likely to get the wrong answer if there is (deliberately, mischievously, or accidentally) a file which shares its name with a key-value.

Adding file:// URLs is cute, and very general, but not massively easier to script (which is the real problem with the key-only value for -r). Excess generality can be a vice, as well, especially if it requires that other libraries be pulled in.

Overall, adding -R seems simpler.

FiloSottile added a commit that referenced this issue Jan 2, 2021
Fixes #84
Closes #165
Closes #158
Closes #115
Closes #64
Closes #43
Closes #20
FiloSottile added a commit that referenced this issue Jan 2, 2021
Fixes #84
Fixes #66
Closes #165
Closes #158
Closes #115
Closes #64
Closes #43
Closes #20
FiloSottile added a commit that referenced this issue Jan 3, 2021
Fixes #84
Fixes #66
Closes #165
Closes #158
Closes #115
Closes #64
Closes #43
Closes #20
@FiloSottile FiloSottile added this to the v1.0.0 milestone Apr 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants