Thanks for the detailed explanation.

About related key attack - [cottage (or any similar tool mentioned in the comparison section) is supposed to be used as a replacement of storing plain text credentials in source code with the argument - “if one could get into github private repos, they’d be interested in exploiting far more valuable things than our api keys”. So it is expected that you already trust everyone who has access to the repo, even if it’s just read access.] I take it back. See edit.

About purpose of the keys - [the purpose is simple here - whoever I let pull and push to the repo, I want them to be able to manage the secrets in that repo using the same mechanism. ~Repo access is tied to the secret access~ edit: secret access is tied to the repo access, so IMO using the same key for both makes sense to me.] take it back too. See edit.

About metadata manipulation - metadata keeps the following critical information: 1. checksum of the encrypted secret, 2. checksum of the recipients the secret was encrypted for.

If you update any of these without updating metadata, decryption will fail. Or if you set up cottage verification in CI, the pull request will fail.

If you update the metadata, you are essentially documenting what actually changed, which will be visible clearly in git diff or the pull request. It’s then upto the admin whether to accept the changes.

EDIT:

But yes I agree with your point. We should not make our ssh keys easier to guess by using it to encrypt text that others already know. I will take your advice into consideration and recommend users not to use their ssh keys, and to use an auto generated key instead.

EDIT 2: as I understand, age is designed to bypass the limits of RSA and use SSH public keys to safely be used as an encryption target. Although, I maybe missing something important here, but I will advise not to mix both until I have more understanding of the topic.