[FEATURE REQUEST] Allow file/archive signature verification with different backends

[lkubb]

Is your feature request related to a problem? Please describe.
In 3007.0, file.managed and archive.extracted learned to verify GPG signatures. While GPG is the most widely used algorithm, there are other ones that are in use such as raw signatures and the sequoia-pgp suite (https://sequoia-pgp.org/), especially Sequoia Chameleon, which in its current state is not compatible with the gpg modules.

It would be nice to offer a similar level of integration to alternatives.

Describe the solution you'd like
Add a sig_backend parameter that allows to specify the execution module to use for verifying signatures, defaulting to gpg. This would even allow a deep integration of quite custom verification, e.g. of the Vault transit service.

Describe alternatives you've considered
None

[nwalfield]

especially Sequoia Chameleon, which in its current state is not compatible with the gpg modules.

What problems are you having exactly? It would be great if you could report the incompatibilities, and as-of-yet unimplemented functionality so that we can prioritize our work. Let's continue the discussion over here.

[lkubb]

Well, I didn't expect someone working on Sequoia to react here. Thank you for your awesome work!

What problems are you having exactly? It would be great if you could report the incompatibilities, and as-of-yet unimplemented functionality so that we can prioritize our work.

I only recently discovered it through another user mentioning it in connection with the functionality this issue is about (the comment above the one in the following link). Running both the python-gnupg and Salt GPG-specific test suite using it yielded a mixed result: QubesOS/qubes-issues#2162 (comment)

Afair it mostly concerned private key management and reading key info without importing, but my memory is foggy. I can repeat the test runs and report specifics if that would be of any help.

There is one more specific report for python-gnupg here (from a bit over a year ago though): vsajip/python-gnupg#217 (comment)

Let's continue the discussion over here.

If you see value in the test suite results, I can create an account over there.

Thanks again!

[nwalfield]

Well, I didn't expect someone working on Sequoia to react here. Thank you for your awesome work!

Thanks :)

What problems are you having exactly? It would be great if you could report the incompatibilities, and as-of-yet unimplemented functionality so that we can prioritize our work.

I only recently discovered it through another user mentioning it in connection with the functionality this issue is about (the comment above the one in the following link). Running both the python-gnupg and Salt GPG-specific test suite using it yielded a mixed result: QubesOS/qubes-issues#2162 (comment)

Afair it mostly concerned private key management and reading key info without importing, but my memory is foggy. I can repeat the test runs and report specifics if that would be of any help.

There is one more specific report for python-gnupg here (from a bit over a year ago though): vsajip/python-gnupg#217 (comment)

I believe that issue has been resolved.

Let's continue the discussion over here.

If you see value in the test suite results, I can create an account over there.

Supporting Qubes is a high priority for us. The simpliest thing you could do would be to open an issue that you want to use this software, but that the test suite fails with the chameleon. If possible, including the test results would be good. Even better would be going through the results, and opening issue about each unimplemented or buggy feature. Thanks!