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: CLOSED NOTABUG
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: 2026-02-04 15:07 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-02-04 15:07:59 UTC
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.

Comment 3 Fabio Valentini 2026-01-03 18:16:44 UTC
I've now branched and built all dependencies of sequoia-openpgp for EPEL 10.

Further progress is blocked by rustc/LLVM on c10s being broken:
https://issues.redhat.com/browse/RHEL-118212

Comment 4 Fabio Valentini 2026-01-20 13:20:12 UTC
Looks like the LLVM 21 update in CentOS Stream 10 accidentally fixed this issue too.
I've continued to import sequoia-openpgp to EPEL 10, and will import the remaining missing packages soon.

Comment 5 Jeremy Cline 2026-01-27 19:12:41 UTC
Just a head's up, for various reasons I ended up not needing the keystore-server - I implemented my own since I also wanted to isolate non-PGP signing operations and use systemd socket activation to lock it all down - so if pulling it into EPEL 10 will be more work feel free to close this as WONTFIX.

Comment 6 Fabio Valentini 2026-02-04 15:07:59 UTC
Ok, if you don't need the keystore server in EPEL 10, then I'm going to close this ticket.

Since sq is in RHEL 10 proper, nothing in EPEL 10 would use the keystore server at all.


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