3 ms·

> Almost every day. Sometimes multiple times a day in case of a new project / new embedded hardware (toolchain) / new devkit to "quickly test" / tight deadlines

> Almost every day. Sometimes multiple times a day in case of a new project / new embedded hardware (toolchain) / new devkit to "quickly test" / tight deadlines, etc. The approach normally doesn't count project local tools which don't install like normal applications. E.g. some frameworks you install into your project instead of having user or system wide installations (e.g. with npm for web-dev stuff). I know that for embedding computing a lot of tools which are normally ad-hoc project installations are instead system wide "normally installed programs". But that isn't the case for most software development fields. In many other fields that new tool-chain you want to try out is just a dependency you add to your projects dependency management tool. And keeping it up to date is done in the same way you keep your other dependencies up to date (e.g. a scheduled CI job checking for updates). Rootless OCI (docker) containers can help with that. But embedding also often touches on driver aspects so it might not be an option. Anyway if you ignore embedding programming, parts of system programming (e.g. linux kernel), some legacy software and some cases of important C/C++ tools needing too many permissions nearly all other programming jobs should be viable on a locked down system as long as you have the right not too big set of tools preinstalled and access to rootless containers (independent of weather they run in a VM or not). EDIT: formulations, for clearity

voxic11 4y ago
vscode has a portable version that can be installed as a project local tool. So would vscode installed in such a way also be an exception to this approach?
- dathinab 4y ago
  It's less about if it's install-able in a project and more if it's project specific, so IDEs should if possible not be included. Furthermore if possible stand alone tooling which tend to not be very version sensitive can be nice to not include: E.g. git, npm, rustup, pip and similar are preferable system installations. Furthermore frameworks and similar tend to go through the package manager and whatever update handling you have for it. But a drop in IDE likely would not.
aflukasz 4y ago
Given various recent supply chain attacks, I would say "installing dependencies into your projects" is becoming just as dangerous as downloading and running arbitrary executable.
- dathinab 4y ago
  Its IS running arbitrary executable, but so is installing some 3rd party Program and even some program uploaded to the Microsoft app store or a Linux package manager isn't necessary much different. Sure Linux package index maintainers give them "due diligence" but that has limits and Microsoft replaces that mostly with some automated scanning, which isn't better. But when it comes to the aspect of managing updates, project specific installs are better. And when it comes to security then the answer for both installed and project tool-chains is: Sandboxing. - run your toolchain in a container - run your IDE in a different container - run hardly trusted tools in another container - use reasonable phishing proof 2FA (i.e. FIDO2) for authentication, use authentication tokens. This applies to "normal" applications, too. They also should run in their own container. Just because it has an installer or is signed by a company or is on a app store doesn't mean it's trustable. Thats one of the things phones at least somewhat got right, their apps are containerized by default (through they might give too much permissions to apps but that's a different problem)

voxic11 4y ago

vscode has a portable version that can be installed as a project local tool. So would vscode installed in such a way also be an exception to this approach?

dathinab 4y ago
It's less about if it's install-able in a project and more if it's project specific, so IDEs should if possible not be included. Furthermore if possible stand alone tooling which tend to not be very version sensitive can be nice to not include: E.g. git, npm, rustup, pip and similar are preferable system installations. Furthermore frameworks and similar tend to go through the package manager and whatever update handling you have for it. But a drop in IDE likely would not.

aflukasz 4y ago

Given various recent supply chain attacks, I would say "installing dependencies into your projects" is becoming just as dangerous as downloading and running arbitrary executable.

dathinab 4y ago
Its IS running arbitrary executable, but so is installing some 3rd party Program and even some program uploaded to the Microsoft app store or a Linux package manager isn't necessary much different. Sure Linux package index maintainers give them "due diligence" but that has limits and Microsoft replaces that mostly with some automated scanning, which isn't better. But when it comes to the aspect of managing updates, project specific installs are better. And when it comes to security then the answer for both installed and project tool-chains is: Sandboxing. - run your toolchain in a container - run your IDE in a different container - run hardly trusted tools in another container - use reasonable phishing proof 2FA (i.e. FIDO2) for authentication, use authentication tokens. This applies to "normal" applications, too. They also should run in their own container. Just because it has an installer or is signed by a company or is on a app store doesn't mean it's trustable. Thats one of the things phones at least somewhat got right, their apps are containerized by default (through they might give too much permissions to apps but that's a different problem)