mintpilo
commented
3 days ago Going out on a limb, but this seems quite a bit out of scope, because not only is it novel functionality that is unrelated to security, it would be entirely antithetical to security as, if I am understanding correctly, this is a suggestion towards adding attack surface to the browser.
But in many ways that would go against the spirit of secureblue... by relying on a vendor who controls everything, with no auditable code, etc.
Says who? It's still ultimately up to users to decide what tools they should trust. (If any, not everyone using secureblue is using it for development) Also, "no auditable code" is unrelated to security. (And there are other ways to verify that software is working as intended regardless of source code being available, security audits are rarely done entirely by reading the code.)
symbiogenesis
qoijjj
The most popular IDE today is VS Code. It runs in electron. Electron is based on Chromium, and as such, all of the caveats about browser flatpaks apply to it. The native sandboxing of Chromium itself would be superior, and flatpak sandboxing collides with it.
On top of that, two of the main VS Code flatpaks are unverified and request full permissions.
As such, using a native IDE of some kind, or using a fully browser-based IDE or a verified flatpak with minimal permissions seems best.
I think it would be nice if secureblue offered some guidance on setting up a secure dev environment.
Which verified non-Electron flatpaks are recommended? Which configurations for browser-based IDEs are recommended? Which are definitively not recommended?
Are any of these recommended? Since Vscodium is electron-based, I'm guessing that one is not.
A cloud IDE theoretically could be secure, and probably would provide a nice experience. But in many ways that would go against the spirit of secureblue... by relying on a vendor who controls everything, with no auditable code, etc.
Running VS Code in the browser fully locally, while persisting settings, seems like a great idea. If there's no great existing option, then that kind of thing could even be the basis of a new mode of hardened-chromium. If you pass a certain argument it could wire that up for you maybe?
Of course, once you go down the road of a fully FOSS distro of vscode then all the Microsoft EULA stuff applies, and you need to do what the OSS version of vscode does... excluding any proprietary debuggers and branding, figuring out an update process that is outside of the normal auto-updater, and only linking to a FOSS extension store like https://open-vsx.org/