Bug 2394588 - Please branch and build rust-sequoia-keystore-server for EPEL 10
Summary: Please branch and build rust-sequoia-keystore-server for EPEL 10
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: rust-sequoia-keystore-server
Version: epel10
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rust SIG
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-09-11 16:09 UTC by Jeremy Cline
Modified: 2025-09-18 20:21 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jeremy Cline 2025-09-11 16:09:54 UTC
I'm looking to use Sequoia's keystore server in the rewrite of the Sigul signing server. Right now Sigul runs on EL 9, but for various reasons (mostly OpenSSL-related) I'd like to move to EL 10 when we migrate to the new signing service.
 
This is not urgent - I'm not sure when I'll be done with the rewrite, but a couple more months seems likely - but it would be convenient to start running CI against an EL 10 environment without building sequoia-keystore-server from crates.io.

Comment 1 Fabio Valentini 2025-09-18 20:06:19 UTC
This shouldn't be too difficult, but probably involves branching quite a few additional packages for EPEL 10 since no sequoia stuff is there yet (sq and sqv are in RHEL proper).

Have you talked to Sequoia-PGP upstream about what you need and whether the keystore-server is a good fit? As far as I know, it's currently not even used in Fedora since I haven't made the necessary modifications in sq yet.

Comment 2 Jeremy Cline 2025-09-18 20:21:55 UTC
(In reply to Fabio Valentini from comment #1)
> This shouldn't be too difficult, but probably involves branching quite a few
> additional packages for EPEL 10 since no sequoia stuff is there yet (sq and
> sqv are in RHEL proper).
> 
> Have you talked to Sequoia-PGP upstream about what you need and whether the
> keystore-server is a good fit? As far as I know, it's currently not even
> used in Fedora since I haven't made the necessary modifications in sq yet.

I've not spoken with them about it, no, but I can describe why I'm using it. For the signing server, each signing key is encrypted with a server-generated secret. That secret is then encrypted with a user-specific password. A client starts a connection with the server and can request the server unlock keys which can then be used to sign things. This needs to happen per-connection.

For each connection, I create a keystore-server in which I load the encrypted key and then unlock it via the user password. Then, when that connection gets a signing request, it uses the keystore-server instance to sign the data. It keeps the decrypted key material in a separate process, which is nice, and each client is isolated from each other.


Note You need to log in before you can comment on or make changes to this bug.