chore(deps): update russh, use crates.io of hakoniwa, update deps - #642

crates/minimald/src/connection.rs (2)

464-465: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Stale doc comment: handler no longer returns false.

channel_open_direct_tcpip now returns Result<(), Self::Error> and rejects via ChannelOpenHandle; the doc comment referencing "rejected by returning false" is outdated.

📝 Proposed fix

-    /// Only authenticated (local) connections may forward ports; unauthenticated
-    /// connections are rejected by returning `false`.
+    /// Only authenticated (local) connections may forward ports; unauthenticated
+    /// connections are rejected via `reply.reject(...)`.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/minimald/src/connection.rs` around lines 464 - 465, Update the stale
doc comment on the `channel_open_direct_tcpip` handler in `connection.rs` so it
matches the current `Result<(), Self::Error>` behavior instead of saying
unauthenticated connections are rejected by returning `false`. Keep the comment
aligned with the actual rejection path used by `ChannelOpenHandle`, and refer to
the handler’s current signature/authorization behavior rather than the old
boolean-return wording.

---

277-296: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Consider dropping the connection lock before awaiting reply.reject()/reply.accept().

s is held across the network-bound .await calls at lines 287 and 294, even though it's no longer needed once the auth check/channel-insert is done. channel_open_direct_tcpip avoids this by scoping the lock to a block (lines 484-491) before any reply call. Matching that pattern here removes an unnecessary async-mutex-held-across-I/O window that could add lock contention for other connection state accesses (e.g. handle_channel_close, env_request) racing on the same connection.

♻️ Proposed fix

     async fn channel_open_session(
         &mut self,
         c: RuChannel<Msg>,
         reply: ChannelOpenHandle,
         _: &mut Session,
     ) -> Result<(), Self::Error> {
-        let mut s = self.0.lock().await;
-        if s.auth != Auth::Local {
+        let is_local = {
+            let s = self.0.lock().await;
+            s.auth == Auth::Local
+        };
+        if !is_local {
             reply
                 .reject(russh::ChannelOpenFailure::AdministrativelyProhibited)
                 .await; // indicate failure
             return Ok(());
         }

         protocol_trace!("Minting session channel with id {}", c.id());
-        s.channels.insert(c.id(), Channel::new_session(c.id(), c));
+        {
+            let mut s = self.0.lock().await;
+            s.channels.insert(c.id(), Channel::new_session(c.id(), c));
+        }

         reply.accept().await; // indicate success
         Ok(())
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/minimald/src/connection.rs` around lines 277 - 296, In
channel_open_session, the connection mutex guard s is held across the network
await on reply.reject()/reply.accept(), which is unnecessary after the auth
check and channel insert. Scope the lock to only cover the Auth::Local check and
s.channels.insert, then drop it before calling either reply method, following
the same pattern used by channel_open_direct_tcpip to avoid holding the async
lock during I/O.