Lazer exporter fixes #166
Lazer exporter fixes #166
Conversation
merolish
commented
Jun 16, 2025
merolish
commented
- Use Lazer pubkey as authorization token for relayer
- Fetch symbol list from history service periodically
| // can safely drop first receiver for ease of iteration | ||
| let (relayer_sender, _) = broadcast::channel(RELAYER_CHANNEL_CAPACITY); | ||
|
|
||
| for url in config.relayer_urls.iter() { | ||
| let mut task = RelayerSessionTask { | ||
| url: url.clone(), | ||
| token: config.authorization_token.to_owned(), | ||
| token: BASE64_STANDARD.encode(signing_key.verifying_key().to_bytes()), |
There was a problem hiding this comment.
Can we separate the signing key from the verifying key really early in the process, and pass them around separately? This is like one typo away from accidentally encoding and sending the private key, which makes me nervous. In fact, I wonder if we can put some guards in to prevent the private key from being encoded after its read or something.
There was a problem hiding this comment.
Also why are we setting the public key as the token? The plan was to retain access tokens unitl we can remove them.
There was a problem hiding this comment.
The latter was an ask from Ali.
There was a problem hiding this comment.
@darunrs we want pythnet publishers to start publishing asap. We will remove this when we implement the changes in the relayer. For now we still need to use tokens to match with publishers.
There was a problem hiding this comment.
I'm also worried about accidentally exposing private keys, but since it's temporary it might be ok. Let's hear what @ali-behjati thinks.
There was a problem hiding this comment.
Gotcha. Thanks for filling me in. That makes sense, and I don't think it is problematic to make the public key and access key shared in the short term.
There was a problem hiding this comment.
Regarding private key leaking, we can override (or not derive) things like Debug, Serialize, Encode with something that produces dummy values for the signing key by wrapping it in a struct or type and making it a private member of the struct. I think it might not be too hard to get something in place. Doesn't necessarily have to be a blocker but I would feel better about it being implemented before having publishers use it.
Once we have the signing key on hand, I believe we only need to do two things: produce verifying key, and sign data. By exposing a limited interface I think we could protect against private key leakage to some degree.
