Conversation
jamadeo
left a comment
jamadeo
left a comment
There was a problem hiding this comment.
Nice. When I searched the right way to do this, electron IPC was suggested, so this seems right!
shellz-n-stuff
left a comment
shellz-n-stuff
left a comment
There was a problem hiding this comment.
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.
will this be needed on windows?
There was a problem hiding this comment.
ah - centralising it
There was a problem hiding this comment.
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.
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.
yeah I am aware. it ran fine for me though. but can move to app.tsx
There was a problem hiding this comment.
(might have a fix... standby)
There was a problem hiding this comment.
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.
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.
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)
4 participants
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.