fix: validate username and truncate worker name at authorize time

[average-gary]

The UserIdentity TLV field has a protocol-specified maximum of 32 bytes. When downstream miners send mining.authorize with long worker names, the translator would panic on unwrap().

This fix:

• Rejects mining.authorize if the username portion (before the dot) exceeds 32 bytes, as this indicates an invalid configuration
• Truncates only the worker name portion if the total length exceeds 32 bytes, preserving the username
• Adds defensive error handling in sv1_server.rs as a fallback

[average-gary]

Rebased onto #162

Pr ot that branch here:
Shourya742#1

[gimballock]

Is there a more specific error type we should use here?

[average-gary]

The return type is defined upstream in stratum_core::sv2_api

[GitGab19]

I think we have some misconceptions, and that's probably due to how we called and managed some fields in the DownstreamData in the past.

We currently have authorized_worker_name and user_identity there, but we are currently setting both values with the same string we receive from the mining.authorize message.

Here the changes I would apply:

• rename authorized_worker_name into worker_name_from_authorize to better reflect that this field contains the exact string we receive from the Sv1 mining.authorize
• assign to user_identity only the suffix part of what we receive from the Sv1 mining.authorize (e.g. in case of gitgab.worker1 the user_identity will contain only worker1)
  • if there's no . delimiter, assign the same value as authorized_worker_name
• we don't check the length of any of these fields in the authorize step of the initial "Sv1 handshake", because we don't even know if we need to use the extension or not there
• in the Sv1Server, where we create the TLV using the user_identity field of the DownstreamData we handle the result and, if we get an error from the new() (the check on the length is already made there), we return an error and we disconnect the client

Does it make sense to you @average-gary ?

[average-gary]

Yes. I see now. But why are we waiting for share submission to fail?

we don't check the length of any of these fields in the authorize step of the initial "Sv1 handshake", because we don't even know if we need to use the extension or not there

We should know. The sv1_server.start() doesn't execute until Upstream is connected and started (included extension negotiation).

[GitGab19]

(included extension negotiation)

I'm not sure about this assertion, are you?

In general, if there's an easy way to get the negotiated extensions from there, I guess we can eventually refuse the mining.authorize in case the username exceeds the max 32 bytes,only when the extension is required and negotiated.

[average-gary]

I'm not sure about this assertion, are you?

initialize_upstream() of TranlatorSv2 -> try_initialize_upstream() -> creates new() Upstream and then start() -> setup_connection() which has extension negotiation messaging.
Once we're done awaiting try_initialize_upstream() for TranslatorSv2, we then sv1_server_instance.start().

Ah, I see, it's just a request extension message we're sending and then we handle messages.

Is there a reason we don't fully negotiate extensions in connection setup?

[GitGab19]

Is there a reason we don't fully negotiate extensions in connection setup?

I don't remember exactly why I implemented it in that way tbh.

[average-gary]

Closing in favor of #276.