sops icon indicating copy to clipboard operation
sops copied to clipboard

Support for age recipients file

Open chris3ware opened this issue 3 years ago • 9 comments

I wondered if being able to encrypt a file with multiple age public keys (recipients) could be done by using the age recipients file as well as passing multiple comma separated keys?

This can be achieved natively with age by passing the -R, --recipients-file PATH argument.

chris3ware avatar Jun 20 '22 14:06 chris3ware

doesn't seem to work with version: 3.8.1

always uses the first key in the recipients file. This would come in really handy when working in a team.

alxndr13 avatar Mar 01 '24 12:03 alxndr13

I would love to have that working. I'm interested in taking a look and see if I can draft a PR.

wesbragagt avatar Apr 25 '24 12:04 wesbragagt

I too was looking to use sops/age for our team, but setting all the possible public keys in a SOPS_AGE_RECIPIENTS for every team member seems awkward when age support the recipients-file we can put in a repo to share.

chriscarpenter12 avatar May 07 '24 20:05 chriscarpenter12

@chriscarpenter12 why not simply put them in .sops.yaml and store that in the root of the repo that should contain the SOPS encrypted files?

felixfontein avatar May 08 '24 04:05 felixfontein

Is there an example of all the options in the .sops.yaml file? I didn’t see an example of what you’re describing. I’m new to sops and it seemed the age config was through env vars from the readme.

chriscarpenter12 avatar May 08 '24 11:05 chriscarpenter12

Here's a small example:

creation_rules:
    - age: >-
        age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw,
        age129h70qwx39k7h5x6l9hg566nwm53527zvamre8vep9e3plsm44uqgy8gla,
        age129h70qwx39k7h5x6l9hg56qxcxfaqycuprpmy89nr83ltx74tqdpszlw

(A more complex one: https://github.com/getsops/sops?tab=readme-ov-file#using-sopsyaml-conf-to-select-kms-pgp-and-age-for-new-files)

felixfontein avatar May 08 '24 17:05 felixfontein

@felixfontein

Is there a particular reason why this isn't supported?

creation_rules:
    - age:
        - age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw
        - age129h70qwx39k7h5x6l9hg566nwm53527zvamre8vep9e3plsm44uqgy8gla
        - age129h70qwx39k7h5x6l9hg56qxcxfaqycuprpmy89nr83ltx74tqdpszlw

or more importantly

keys:
  - &key1 age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw
  - &key2 age129h70qwx39k7h5x6l9hg566nwm53527zvamre8vep9e3plsm44uqgy8gla
  - &key2 age129h70qwx39k7h5x6l9hg56qxcxfaqycuprpmy89nr83ltx74tqdpszlw

creation_rules:
    - age:
        - *key1
        - *key2
        - *key2

tcurdt avatar May 04 '25 16:05 tcurdt

Is there a particular reason why this isn't supported?

It's simply because it is not implemented that way, and hasn't changed yet. (There's a PR (#849), but it needs resurrection. I also haven't checked whether it really works, so maybe it needs more than that.)

Using key groups and merge groups allows to use YAML lists right now.

felixfontein avatar May 04 '25 16:05 felixfontein

Using key groups and merge groups allows to use YAML lists right now.

Ah! I can confirm this works even without the PR.

creation_rules:
  - path_regex: \.yaml$
    key_groups:
      - age:
          - *key1
          - *key2

Thanks for the pointer!

tcurdt avatar May 04 '25 17:05 tcurdt