ostree commit sign with using external key/cert files

[mrzenwiz]

Is there a way for ostree to take an external signature key (the signature, not the secret key) to sign a commit I can later verify with the public key extracted from the cert?

The project I have been given is to use a signature generated by a private key server that gives no external access to the secret key used for the signature generation. It also produces a cert file from which I can obtain the public key (for verification), but I have no access to the secret key, and the server itself does not host the builds or ostree repos.

I have been told I can overwrite the commitmeta with the external signature, but so far this only generates errors.

Guidance here would be greatly appreciated. I am totally new to ostree and have no familiarity with the overall GI methodology.

Many thanks!

[cgwalters]

I answered this one on the list: https://mail.gnome.org/archives/ostree-list/2021-July/msg00017.html But feel free to continue discussing or reopen the issue if you think there's more to do!

[cgwalters]

Also I forgot to mention https://github.com/coreos/coreos-assembler/blob/main/src/cmd-sign which is a similar thing that talks to Fedora's HSM.

(There's a lot of other stuff in there too that deals with how we currently serialize ostree commits as tar-of-archive-repo in S3, etc. But the core idea is the same)

[mrzenwiz]

Unless I misread the replies, these are terrific for use on Fedora systems where you have access to the keys (secret and public).

I meant to ask, and probably mangled the question so as not to be what I really want to know, is this:

BTW, I am running on an Ubuntu 20.04 container (that's all I get as a contractor right now...) with the nix install of ostree version 2021.1. The company wants that for the ed25519 signing capability.

Is it possible to specify to 'ostree sign' the actual signature (not keys) to use, either in a file or base64 input or something, where the secret key is not accessible?

Everything I've seen so far tells me that if ostree itself doesn't do the signing using the secret key, ostree sign --verify fails.

I wrote a program that takes as input a signature filename, the repo directory and the hash (ostree commit output) of the commit to sign. It reads the existing commitmeta if there is one, rewrites the key in the data and overwrites the commitmeta using ostree_repo_read_commit_detached_metadata and ostree_repo_write_commit_detached_metadata. However, ostree sign --verify fails on this every time with "error: no valid signatures detected."

Am I doing this incorrectly or did I miss a step or ... ???

Thanks.

[cgwalters]

There's two parts to this:

1. Actually performing the ed25519 signature outside of the ostree code. If you look at the code it's invoking the libsodium crypto_sign_detached. So your code will need to do exactly what libsodium does. I assume this is a stable format, but it doesn't seem to be documented. The implementation seems aggressively lacking in comments :wink: I think using libsodium on the signing server is the primary viable path right now.
2. Actually injecting the signature into the commit metadata. This is the bits that are handled by the Python programs above. We could definitely add something like ostree commit-metadata add-signature ed25519 /path/to/sig or so too?

[cgwalters]

Unless I misread the replies, these are terrific for use on Fedora systems where you have access to the keys (secret and public).

While some parts of the code are Fedora specific, I think it's solving mechanically the same problem - accessing a signing service via RPC and adding the signature to the local build. So I linked to them as a reference.

[mrzenwiz]

Adding the 'ostree commit-metadata add-signature ed25519 /path/to/sig' as an option would be great.

Should I file a request for that feature (and how do I do so)?

Thanks!

[dbnicholson]

I hadn't actually looked at the ostree sign API before, but most of the pieces are there to not even have to interface with libsodium.

ostree_sign_data will make the signature after you load the secret key and give it the commit object bytes. After that you can get the name of the detached metadata key and signature format. Then it's just a matter of updating the detached metadata.

One thing that would be helpful is an ostree_sign_append_commit_signature API similar to the ostree_repo_append_gpg_signature API. Then you wouldn't need to mess around with reading and writing the detached metadata in the correct format. That would make it simpler to offload the signing with a couple calls and to implement the above suggested CLI.