-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Make the client more secure #3742
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
Conversation
jamadeo
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.
Nice. When I searched the right way to do this, electron IPC was suggested, so this seems right!
shellz-n-stuff
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.
Defs an improvement getting it out of the config.
Out of interest can we not have an interceptor for requests defined to keep the value only being handled/used in one place? Given it's electron could be a nice protection from leaking via XSS
| // On Windows, use taskkill to forcefully terminate the process tree | ||
| // Security: Validate PID is numeric and use safe arguments | ||
| const pid = goosedProcess.pid?.toString() || '0'; | ||
| if (!/^\d+$/.test(pid)) { |
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.
will this be needed on windows?
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.
ah - centralising it
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.
well, it strikes me that either we can kill the thing or we can't. why would we try to guess what a pid looks like if we got it from the os and pass it to the os?
|
"Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)" (which is causing the bundle failure) |
| }); | ||
| } | ||
|
|
||
| await initializeClient(); |
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 what stops it from bundling with the error (you can see it with just make-ui)
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.
yeah I am aware. it ran fine for me though. but can move to app.tsx
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.
(might have a fix... standby)
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.
ok vitejs/vite#6985 - says it isn't a vite issue (hrm...)
seems ok to set the build target to "newer" stuff, given this is an electron app, not a regular web app (otherwise can just not to await there...)
(just kidding, this was all by hand)
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.
would be nice if the build https://github.com/block/goose/actions/runs/16632635914/job/47065764905?pr=3742#step:19:131 would fail at the right point (not that the test launch app stage)
but still - good to catch this now vs later.
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.
na, it is easy, just call it from the useEffect below instead. probably should have done that always
* main: Increase req body limit (#2965) Stable goose info -v (#3760) Speed up app initialization and improve refresh crashing (#3717) docs: consolidate search session content, doc import recipe (#3759) Improve power save blocker mechanism (#3698) Ensure adding/removing extensions refreshes extensions list (#3695) Env parsing for primitive types (#3706) Autocompact + One Shot Summarization algorithm (#3559) fix: initial prompt not filled in after accepting new recipe (#3637) fix not being able to click on searchbar buttons in chat (#3723) center session summary modal description text (#3737) Persist first message to local history in case of failure or cancellation (#3744) Make the client more secure (#3742) feat: Allow configuring hints filename(s) (#3269) Add support for mouse back nav button to Settings screen (#3195) chore: Remove the wrong tailwind package (#3754) chore: fix typo in desktop readme for goosed (#3752) feat: upgrade rmcp (#3738) feat: allow users view and edit their non-secret config's (#3005) fix: View extensions link (#3751)
We were storing the server secret in the appConfig that was transported through extra params to the individual windows which means they become part of the parameters which makes the secret visible for any process that can see other processes.
This centralizes the secret in one place and provides access to it through the electron protocol.