Skip to content

Conversation

@tankyleo
Copy link
Contributor

@tankyleo tankyleo commented Dec 6, 2025

No description provided.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Dec 6, 2025

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems relatively straightforward - but for my understanding: is the plan to also add the issuance part in this PR?

pub(crate) struct Config {
pub(crate) server_config: ServerConfig,
pub(crate) postgresql_config: Option<PostgreSQLConfig>,
pub(crate) postgresql_config: PostgreSQLConfig,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this mandatory now? How will this work with the InMemoryStore or any other impl we'll add?

Copy link
Contributor Author

@tankyleo tankyleo Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently don't support any alternative backends, and expect if this is None. I would prefer failing earlier, with the Config member type to represent our current status (ie not Option<PostgreSQLConfig> but PostgreSQLConfig).

The error message if the postgresql_config table is not present is this one:

Failed to load configuration: TOML parse error at line 1, column 1
  |
1 | [server_config]
  | ^
missing field `postgresql_config`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That being said, I'm thinking we keep this Option to open up the InMemoryStore use case later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That being said, I'm thinking we keep this Option to open up the InMemoryStore use case later.

Yeah, I think it would be preferable if we already know that we'll have different backends.

@tankyleo
Copy link
Contributor Author

tankyleo commented Dec 8, 2025

Seems relatively straightforward - but for my understanding: is the plan to also add the issuance part in this PR?

Do you think issuance is in-scope for VSS-server ? My immediate thinking is VSS-server should only be verifying, and not touch the private key. Issuance should be handled by something separate with different security measures that does have this privileged access to the private key.

See vss channel, it seems the immediate request from users is just the ability to set the public key for verifying JWT tokens.

@tankyleo tankyleo requested a review from tnull December 8, 2025 16:51
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@tnull
Copy link
Contributor

tnull commented Dec 11, 2025

Do you think issuance is in-scope for VSS-server ? My immediate thinking is VSS-server should only be verifying, and not touch the private key. Issuance should be handled by something separate with different security measures that does have this privileged access to the private key.

See vss channel, it seems the immediate request from users is just the ability to set the public key for verifying JWT tokens.

Discussed this elsewhere: it would be good to add issuance to the vss-server in order to provide users with a ready-to-go solution. Though, that doesn't need to happen as part of this PR ofc.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good, some minor comments.

Do we see a chance of adding a test for the authorizer? Maybe with some fixtures?

pub(crate) struct ServerConfig {
pub(crate) host: String,
pub(crate) port: u16,
pub(crate) rsa_pub_file_path: Option<String>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't that rather be part of a new optional JwtAuthConfig section?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make it also possible to use an env var, since it's easier to use that on a k8s environment

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See below @frnandu we now ask for the full PEM string, not the file that contains the string, either as an env var, or in the config.

use serde::{Deserialize, Serialize};
use std::collections::HashMap;

pub use jsonwebtoken::DecodingKey;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Hmm, leaking this auth-depdenent type to main.rs is a bit strange. Wouldn't it rather make sense to have JWTAuthorizer::new be fallible and handle the teh DecodingKey::from_rsa_pem step?

mod util;
mod vss_service;

use util::config::{Config, ServerConfig};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This likely should import be added in the above group.

std::process::exit(1);
},
};
let addr: SocketAddr = match format!("{}:{}", host, port).parse() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot going on here. Can we declutter this? Btw, since we're already here, might make sense to switch this to the From<(I, u16)> for SocketAddr implementation rather than allocating a string and then parsing it again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is personal preference, but in the follow-up PR I consolidate the host and port setting into a single address setting, string type, ie "127.0.0.1:54234". We would then allocate the string upfront. WDYT ? Overall looking to reduce the number of lines in the config files, and the number of different settings. The address the server binds to is a single setting in my head :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah probably makes sense to make it one.

@tankyleo tankyleo self-assigned this Dec 11, 2025
@tankyleo tankyleo moved this to Goal: Merge in Weekly Goals Dec 11, 2025
@tankyleo tankyleo force-pushed the rust-jwt-auth branch 3 times, most recently from 7d4b8bd to 5c555c0 Compare December 15, 2025 23:54
@tankyleo tankyleo requested a review from tnull December 16, 2025 00:02
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, please squash.

The RSA public key against which the JWT tokens are verified can be set
either via a configuration file setting, or an environment variable,
with the latter having the higher priority.
@tankyleo
Copy link
Contributor Author

Squashed with no further changes.

@tnull tnull merged commit 6a2278a into lightningdevkit:main Dec 17, 2025
2 checks passed
@github-project-automation github-project-automation bot moved this from Goal: Merge to Done in Weekly Goals Dec 17, 2025
@tankyleo tankyleo deleted the rust-jwt-auth branch December 17, 2025 17:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants