split-gpg2 does not work with Sequoia Chameleon

[DemiMarie]

How to file a helpful issue

Qubes OS release

R4.2

Brief summary

split-gpg2 does not work with Sequoia Chameleon.

Steps to reproduce

Use split-gpg2 with Sequoia Chameleon.

Expected behavior

Works

Actual behavior

Fails. Part of this (not supporting NOP) is fixed by QubesOS/qubes-app-linux-split-gpg2#17 but the failure mode is now “unusable secret key” instead of the connection being dropped.

[h01ger]

after I shared this issue on on #sequoia on irc.ofct.net, upstream developer neal said:

| h01ger: ideally the chameleon should be fixed rather than client software or if the client software is going to be fixed, perhaps it should use a completely different interface

[h01ger]

filed upstream as https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/96 now.

[h01ger]

upstream asks for more info as grepping GnuPG's source revealed that GnuPG used to have a nop action, but it was removed in 1998...

[DemiMarie]

I created a separate test qube, with worthless keys, so I could enable debug logging. This revealed the following:

• KEYINFO takes --list, but split-gpg2 wrongly rejected this, breaking --list-secret-keys. It does not work after the fix either, but returns no keys instead of a "command filtered out" error.
• Sequoia Chameleon sends OPTION pinentry-mode=ask which split-gpg2 should accept (it’s a no-op) but instead returns an error on.
• If key generation is not enabled, which is the default behavior, split-gpg2 connects to the restricted agent socket, rather than the non-restricted one.
• Sequoia Chameleon doesn’t check for a restricted socket, sends commands that gpg-agent rejects, and disconnects when it receives an error.

[marmarek]

If key generation is not enabled, which is the default behavior, split-gpg2 connects to the restricted agent socket, rather than the non-restricted one.

That's extra defense that @HW42 added, and it IMO makes sense. Maybe make it configurable, so user can still use this extra filtering with compatible applications?

[DemiMarie]

If key generation is not enabled, which is the default behavior, split-gpg2 connects to the restricted agent socket, rather than the non-restricted one.

That's extra defense that @HW42 added, and it IMO makes sense. Maybe make it configurable, so user can still use this extra filtering with compatible applications?

I’d prefer for the default connection to be unrestricted, mostly because I expect gpg-sq to be much safer than gpg and I don’t want to discourage users from switching to it.

[marmarek]

I’d prefer for the default connection to be unrestricted, mostly because I expect gpg-sq to be much safer than gpg and I don’t want to discourage users from switching to it.

From split-gpg2 perspective, it's more important what is used as the backend (gpg-agent side), not the frontend. And here IIUC sequoia can't help (yet?). That said, even with the unrestricted socket it's probably safe enough. @HW42 what do you think?

[h01ger]

On Tue, Oct 22, 2024 at 07:30:48PM -0700, Marek Marczykowski-Górecki wrote:

From split-gpg2 perspective, it's more important what is used as the backend (gpg-agent side), not the frontend. And here IIUC sequoia can't help (yet?).

why do you think so? (that sq cant help..)

-- cheers, Holger

⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄

It started as a virus and has mutated into an IQ test.

[marmarek]

AFAIK sequoia does not implement gpg-agent itself (it can just talk to the GnuPG's gpg-agent).

[HW42]

From split-gpg2 perspective, it's more important what is used as the backend (gpg-agent side), not the frontend. And here IIUC sequoia can't help (yet?). That said, even with the unrestricted socket it's probably safe enough. @HW42 what do you think?

Unless the functionality is really needed I would prefer to use the restricted socket. The protocol filtering approach has the risk of the filter and gpg interpreting things differently. In such case using the restricted socket has the big advantages that you would need another bug in gpg (that's also accessible via the filter) to be able to extract a secret.

Why does sequoia need the unrestricted socket?

Even with a agent implementation by sequoia this would only address memory safety issues, not necessarily other bugs. OTOH depending on how nicely their code is to adopt, it might be easiert to implement a restricted agent with their code, thereby avoiding the protocol confusion problem altogether.

[DemiMarie]

From split-gpg2 perspective, it's more important what is used as the backend (gpg-agent side), not the frontend. And here IIUC sequoia can't help (yet?). That said, even with the unrestricted socket it's probably safe enough. @HW42 what do you think?

Unless the functionality is really needed I would prefer to use the restricted socket. The protocol filtering approach has the risk of the filter and gpg interpreting things differently. In such case using the restricted socket has the big advantages that you would need another bug in gpg (that's also accessible via the filter) to be able to extract a secret.

I just looked through the code to see if there were any such cases. I believe there are none (which is good), but it wasn’t trivial to check this (which is bad).

Why does sequoia need the unrestricted socket?

Sequoia Chameleon only knows how to list secret keys via KEYINFO --list, not to query each secret key separately with the version of KEYINFO taking a keygrip. The restricted socket connection doesn’t allow this. I flied an issue with Sequoia Chameleon: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/102

Even with a agent implementation by sequoia this would only address memory safety issues, not necessarily other bugs. OTOH depending on how nicely their code is to adopt, it might be easiert to implement a restricted agent with their code, thereby avoiding the protocol confusion problem altogether.

In the long term I agree. In the short term, I wonder if a workaround could be used: make a separate unrestricted agent connection and send KEYINFO --list there. This command is sufficiently trivial that it should not be possible to mess it up.

[HW42]

I flied an issue with Sequoia Chameleon: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/102

Thanks. Given that in the code comment you mentioned that the warning message from gpg confuses for example mutt it might be worth taking it upstream. Both for the specific case, but also maybe it would make sense to reevaluate if it's worth blocking this command.

In the short term, I wonder if a workaround could be used: make a separate unrestricted agent connection and send KEYINFO --list there. This command is sufficiently trivial that it should not be possible to mess it up.

That's an interesting idea.