Add support for alternative signature systems

[jlaako]

I am planning to implement alternative signing/verification system to current gpgme. This would benefit from having a plugin system, or more complete internal API abstracting signature parts.

At the moment gpgme approach has two challenges. One is that it brings in GPLv3 through gnupg dependency which is not optimal for all cases. And another one is performance challenges on large OS rebuilds that can happen in distro development phase in CI systems and developer systems. This is due to way gpgme interfaces with gnupg binary.

My current plan is to utilize PKCS#7 signature and X.509 certificate standards which work well for signature purposes. This also allows flexibility of choice for the used algorithms. GnuTLS has good support for both and the implementation should be fairly straightforward.

At the moment, clean implementation is somewhat challenging because ostree directly relies on gpgme/gpg concepts, instead of abstraction. Some internal abstraction for this part would be nice. One option is plugin interface, but I am assuming one would rarely use more than one signature scheme, so configure-time selection could be more straightforward. Unless there is particular need for multiple independent source repos on one system, in which case plugin system would be good. More schemes than these two could be added in future.

[cgwalters]

Hm. It may be hard to get away from supporting both schemes being compiled in. I mentioned this somewhere else; but I'd definitely like to make it easier for external users to plug in their own verification. Right now all logic like the timestamp checks lives inside the libostree pull layer, but if we had a generic API that provided a callback with commit objects we were going to write, then higher level apps could perform any arbitrary signature or security checks they wanted.

Also relatedly, one thing I'd like to do probably is have the signature verification run in a subprocess, and then we can sandbox that subprocess. (This would of course be ironic in the case of gpg, as libgpgme runs gpg as a subprocess, which in turn forks a daemon, which can leak).

[cgwalters]

Right now things like ostree show do indeed support showing the commit signature status, and rendering it. Doing full support for an alternative scheme would indeed involve a lot of work.

But what I'm thinking instead (and I'd like to do with GPG for that matter) is to hook the signature status as an xattr or something off the commit object. xattr space restrictions may be an issue though; failing that we could look at adding a generic local-only detached metadata that's lifecycle bound to the commit.

[cgwalters]

However, all of this aside, you still need to support entirely disabling the GPG dependency, right?

[jlaako]

However, all of this aside, you still need to support entirely disabling the GPG dependency, right?

Yes, although with a plugin/external process architecture selection of plugins to be built could be configure time option? So different systems could deploy different subsets of those plugins.

[em-]

Note that if GPLv3 is a concern, then relying on GnuTLS is not the best way forward as it depends on GPLv3 libraries like idn, hogweed, gmp, and nettle. OSTree in most cases depends on GnuTLS anyway via libsoup/glib-networking, but depending on the specific case one could use the OpenSSL backend which has been recently merged in glib-networking to avoid that.

[petersenna]

OpenSSL has also an "interesting" license. Similar to the #BSD with advertising license, the OpenSSL license contains a couple clauses that don't make it non-free but do make it incompatible with the GPL (all versions). From: https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F

[d4s]

From my findings -- looks like libsodium library is good enough:

• have no additional dependencies
• using the ISC license
• provides ed25519 for signing.
  So really need to have a plugable signing schema selectable in runtime or buildtime.

[petersenna]

@d4s reopened this topic on the mailing list: https://mail.gnome.org/archives/ostree-list/2019-May/msg00000.html

[cgwalters]

I think we need to decide first if we're scoping in generic pluggable signature mechanism, or defining ed25519 as a new signature type.

If it's the latter, then it feels to me like the question of crypto library could still be "pluggable"; e.g. OpenSSL supports ed25519 as well. From Fedora's perspective AIUI it's OK to link OpenSSL and LGPLv2 libraries, so I'd lean to continuing to use OpenSSL rather than introduce libsodium.
But it's probably not a huge amount of code to have an abstraction layer, particularly if we don't have things like a "create key" op, just "sign" and "verify".

Like I said above though it may also solve other problems to introduce generic hooks suitable for verification on pull; that pushes the signing question outside of libostree as well. Any software using libostree could inject whatever data it wanted in detached metadata objects. The main downside of course is that things like ostree show wouldn't display signatures.

[cgwalters]

On the flip side of my previous comment though, since this issue is primarily being driven by (L)GPLv3 concerns, it does seem like we'd need to link libsodium or equivalent.

But I'd like the people who are desiring this to really triple check that they can't use OpenSSL though.

Also I did briefly glance at Sequoia and it's also LGPLv3.

[d4s]

TBH I don't like the defining a new signature type -- it just postpone the problem solving and increase the amount of code to refactor later. Even with GPG-only refactoring is not a trivial task as far as I see (or I didn't familiar with internals so close as I want).

For generic pluggable signature mechanism -- I thought initially about something in that way -- from my point of view it is enough to provide modules which could be easily switched on/off in a build time. Something similar to ostree-repo-finder* mechanism but for signing looks good enough. BTW it would solve the issue with printing for ostree show.
Not sure if opensource project will have any value from modules loadable in runtime.

I like the idea with generic hooks but not sure how to deal with current systems which already rely to "automatically supported" GPG and keyrings. Would be appreciate if you push me in right direction for this approach.

PS @cgwalters Sequoia is GPLv3 unfortunately.

[d4s]

@cgwalters, I will be happy to hear any feedback for PoC proposal of alternative signing mechanism from #1878.
The code is under heavy development yet, so MR is added mostly for approach demonstration and check if it fits for your vision (and other projects).

[cgwalters]

This was fixed by #1878