Add a mode of operation that requires only a singular passphrase (no secret keys)?

[mrmachine]

See also #51 for some background.

I'm deploying to ephemeral infrastructure (Docker Cloud) and currently have to jump through hoops to make git-secret work in a remote environment where there are no personal or machine/deployment GPG secret keys available.

Basically, I have to generate and commit a GPG secret key to my source code repository so that it is always available, so that I can decrypt secrets by supplying a passphrase as an environment variable (this is the only way to configure a container on Docker Cloud).

I'm no GPG guru, but I see on https://transfer.sh that GPG is used without secret keys to encrypt and decrypt files without a GPG secret key.

Would it be possible and align with the goals of git-secret to add a mode of operation that works with a single passphrase and no GPG secret keys?

There are already other projects that do this (e.g. Transcrypt) which I tried to use before git-secret specifically for this reason. But it has other problems.

Transcrypt executes gitattribute filters to transparently encrypt and decrypt, which makes it very easy to use. But I believe there are several Git clients (at least GitUp) which do not execute gitattribute filters, which makes it very easy to accidentally commit unencrypted versions of the secret files.

Or, should I just write my own simple scripts which read a list of files from a .secrets file and encrypt/decrypt them via passphrase?

[sobolevn]

Thank you for your suggestion. And sorry for the long reply.
I will dig into it. For now you can try to use something like this: https://github.com/sobolevn/git-secret/blob/master/src/_utils/_git_secret_tools.sh#L210

p.s. https://transfer.sh is awesome!

[sobolevn]

Sorry, this feature will never be implemented.

[andreineculau]

Sorry, this feature will never be implemented.

This is such a strong sentence @sobolevn . It would be beneficial to understand why it will never be implemented. Because of technical constraints? Because it doesn't align with the goals of git-secret? Because it brings down say security? Because "I say so"? All of those and more are valid. Highly appreciated if there's a followup some day 🙌

[joshrabinowitz]

The encryption model used by git-secret depends on gnupg, which in turn expects to use public/private key pairs, and optionally passwords.

To make the keys optional and requiring passwords would require a completely different encryption model.