-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[BEEEP|PM27032] Clean ssh agent rewrite #16265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Great job! No new security vulnerabilities introduced in this pull request |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #16265 +/- ##
==========================================
- Coverage 39.16% 38.92% -0.24%
==========================================
Files 3456 3469 +13
Lines 97968 99194 +1226
Branches 14730 14739 +9
==========================================
+ Hits 38368 38615 +247
- Misses 57932 58910 +978
- Partials 1668 1669 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
neuronull
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've taken some solid time to review the high level here, and though I'm still coming up to speed on the protocol, I really like the move to bring the agent implementation into the client repo, very on board with that. I also think the code is well organized into appropriate modules. It'd be great to see unit tests (or integration tests I guess 🤔 ), that exercise the combinations of requests+replies to assert expected behavior.
I'm holding off on giving a full code review with detailed suggestions, can do that when it's fully ready. But the high level approach looks good to me and a great improvement.
I fully support this effort!
c5e0bdf to
8272221
Compare
|
Integration test is added (runs on linux only). |
|
neuronull
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a first pass... after a few hours, I need to take a break. Will publish what I have and try to get to the rest tomorrow.
| "napi", | ||
| "process_isolation", | ||
| "proxy", | ||
| "ssh_agent", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great, it was on my mental list to bring this out of core.
| ], optional = true } | ||
| windows-future = { workspace = true } | ||
|
|
||
| [dependencies] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense ,though it looks like there are workspace deps being used? Did you mean that we can only use some workspace deps?
Also noting that we should add a link to Jira ticket for FF removal to make sure we circle back and take care of this.
| pub mod agent; | ||
| pub mod knownhosts; | ||
| pub mod memory; | ||
| pub mod protocol; | ||
| pub mod transport; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⛏️ nit on scoping. Seems like these could be pub(crate) ? Also, it'd be more clean to expose the structs/functions that actually need to be used externally to this library, for example
mod protocol;
pub(crate) use protocol::types::{KeyPair, PrivateKey};|
|
||
| #[cfg(target_os = "linux")] | ||
| #[tokio::test] | ||
| #[test_log::test] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which part is this referring to? The test logging? If so, yes, by default the tracing does not log in tests.
| @@ -0,0 +1,208 @@ | |||
| #[cfg(target_os = "linux")] | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like all elements in this file have this gate. Seems like we could do this more globally at a different level.
| #[cfg(windows)] | ||
| NamedPipe, | ||
| UnixSocket, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems off to have a gate on the named pipe but not the unix socket
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent is to have this reflect the transports that could be implemented on each platform. Windows has unix socket support on cygwin, and WSL1/2. However, rusts default unix socket implementation does not support Windows UDS. There are some alternative libraries, but I have not looked into that yet / it is a future feature request to support it.
Still, that's why it makes sense to have unix socket on Windows non-flagged.
apps/desktop/desktop_native/ssh_agent/src/transport/peer_info.rs
Outdated
Show resolved
Hide resolved
apps/desktop/desktop_native/ssh_agent/src/transport/peer_info.rs
Outdated
Show resolved
Hide resolved
| agent: BitwardenDesktopAgent, | ||
| ) -> Result<(), anyhow::Error> { | ||
| info!("Starting SSH Named Pipe listener"); | ||
| let (tx, rx) = tokio::sync::mpsc::channel(16); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it imply we have a limit of 16 concurrent connections? can you add a comment describing what these channels are used for
I missed this comment, just saw it. I flagged the integration test in one of my review comments. Firstly, I think it's awesome to be introducing integration tests for this, so thank you. I do think we should make sure that they are executed in CI and done in a separate CI job from the unit tests. Long term I'd like to see our desktop integration tests run in their own GH workflow, and we can detect whether to run a given int test based on what files were changed in the PR. |




🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-27032
📔 Objective
This PR re-implements the SSH agent completely, and does the following changes:
desktop_native. It is a fresh codebase.bitwarden-russhwill be archived and unmaintainedThis work is feature flagged. After the code is rolled out, bitwarden-russh can be dropped entirely and the module in
corecan be dropped.This re-write also fixes a swath of bugs, not mentioned individually here, and we probably need to revisit some of the backlog. One of these is signing with RSA on sha256 / 512.
Note: The error handling is not optimal in this PR, but adding proper error types here seems like it would even more increase the scope, so unless reviewers consider it blocking, I would suggest this as follow-up tech debt.
📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes