Consider migrating pass-driver to GPG library

[udf2457]

At present containers/common/blob/pkg/secrets/passdriver/passdriver.go shells out to gpg.

However, it may not always be reasonable to assume that gpg is available. This is perhaps the case with immutable operating systems such as Fedora CoreOS, OpenSuSe MicroOS and others.

Availability of gpg aside, shelling out is also risky from a security perspective, leaving you open to all sorts of side-channel and other attacks.

Meanwhile there are readily available, widely deployed, Go gpg libraries such as ProtonMail/gopenpgp

[mtrmac]

Compare containers/image#2569 , we probably don’t want to add any more direct dependencies on the GnuPG implementation.

[udf2457]

But instead you prefer to make assumptions on the gpg implementation and CLI flag / behaviour stability ?

I would suggest a direct go mod dependency is more stable than an external CLI shell ?

And what if a malicious actor replaces the gpg binary ?

[mtrmac]

… Oh, actually, this is not based on GPGME, it’s a separate Go implementation.

Anyway, I’m saying that the direction we should move is to use neither. We want to centralize on specific maintained and certified implementations.

[Luap99]

I agree using another library seems totally undesirable, we gain more dependencies, more update churn for us, bigger binary size. And there is the question if this is going to be FIPS compliant. We should stick to one implementation.

Second as far a secrets drivers go I really prefer not to maintain a lot of extra go code to handle this. It has very little users and receives even less testing.

gpg seems to be a very stable cli so I have no worries there. Security wise this also doesn't matter IMO. Calling gpg directly or using a lib as the same attack surface. If you have an malicious actor replacing the gpg binary nothing would prevent said actor from replacing podman as well with something malicious. So to me this is no argument.