4 ms·

As an VSCode extension author, I am always terrified by the amount of power I have. It is a shame that the team never prioritized extension permission issues [

by g947o 9mo ago

As an VSCode extension author, I am always terrified by the amount of power I have. It is a shame that the team never prioritized extension permission issues [0] despite their big boss said security is the top priority [1]. All they have is "workspace trust" and various other marginally useful security measures. I don't install a VSCode extension unless it is either official or well known and audited and I have to use it. I keep most of them disabled by default unless I need something for a project. (Even if you don't care about security, it's good for VSCode performance. I'll save that story for another day.) [0] https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116 [1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/ https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...

yomismoaqui 9mo ago
When some minor extension that I have installed on VSCode updates (like parens colorizing and the like) I think what could happend if the author sells it to some bad actor (or decides to push some weird code in an update). So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago. I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.
- thedanbob 9mo ago
  It doesn't even have to be malicious. I used a certain syntax highlighting theme for years, when out of nowhere the author pushed an update that rearranged all the colors. It was extremely disorienting. I forked the extension and reverted the change, so I know that one at least won't change out from under me anymore.
  - freedomben 9mo ago
    This is the thing I hate the most about "automatic updates" in general. I've disabled them and gone back to updating manually because the constant unexpected and unwanted UI changes finally broke a part of my soul. Unfortunately that is something that can't be done on the web, where major UI changes can be rolled out right in the middle of a session on you.
fc417fc802 9mo ago
> As an VSCode extension author, I am always terrified by the amount of power I have. Meanwhile random FOSS projects be like "please sudo curl bash to install the prebuilt binaries".
- g947o 9mo ago
  I agree. Sadly most of us aren't going to build from source, and some tools don't really work without sudo. (Did I mention VSCode? On Linux you get a .deb file. Yeah.)
  - lo_zamoyski 9mo ago
    In practice, building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves, certainly not for larger projects. It also takes a long time to compile larger projects. So, realistically, these rarely happen. Of course, the one advantage of having source is that it is easier to run things like SAST tools against source, but how many people do that in practice? How integrated is that with package systems? And when package maintainers might provide hashes of what they ostensibly checked, you still need trust. So we need a combination of static analysis tools that are integrated properly to produce trusted binaries, and you need earned trust and authority. Hyperindividualist self-reliance is, at the very minimum, impractical. And with authority, we know whose job it is to care for the quality of software and therefore whom to hang.
    - fc417fc802 9mo ago
      > building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves However commits tend to be much easier to trace at a later date than arbitrary binaries so attackers will be less inclined to go that route. Once committed it's there forever unless you can somehow get everyone to censor it from their own copies for an unrelated reason. Consider that the xz compromise involved downloading the payload later. My policy is to either obtain binaries from a major distro or to build from a clean commit in a network isolated environment. If I can't go one of those routes it's almost always a hard pass for me.

by g947o 9mo ago

yomismoaqui 9mo ago

When some minor extension that I have installed on VSCode updates (like parens colorizing and the like) I think what could happend if the author sells it to some bad actor (or decides to push some weird code in an update). So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago. I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.

thedanbob 9mo ago
It doesn't even have to be malicious. I used a certain syntax highlighting theme for years, when out of nowhere the author pushed an update that rearranged all the colors. It was extremely disorienting. I forked the extension and reverted the change, so I know that one at least won't change out from under me anymore.
- freedomben 9mo ago
  This is the thing I hate the most about "automatic updates" in general. I've disabled them and gone back to updating manually because the constant unexpected and unwanted UI changes finally broke a part of my soul. Unfortunately that is something that can't be done on the web, where major UI changes can be rolled out right in the middle of a session on you.

fc417fc802 9mo ago

> As an VSCode extension author, I am always terrified by the amount of power I have. Meanwhile random FOSS projects be like "please sudo curl bash to install the prebuilt binaries".

g947o 9mo ago
I agree. Sadly most of us aren't going to build from source, and some tools don't really work without sudo. (Did I mention VSCode? On Linux you get a .deb file. Yeah.)
- lo_zamoyski 9mo ago
  In practice, building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves, certainly not for larger projects. It also takes a long time to compile larger projects. So, realistically, these rarely happen. Of course, the one advantage of having source is that it is easier to run things like SAST tools against source, but how many people do that in practice? How integrated is that with package systems? And when package maintainers might provide hashes of what they ostensibly checked, you still need trust. So we need a combination of static analysis tools that are integrated properly to produce trusted binaries, and you need earned trust and authority. Hyperindividualist self-reliance is, at the very minimum, impractical. And with authority, we know whose job it is to care for the quality of software and therefore whom to hang.
  - fc417fc802 9mo ago
    > building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves However commits tend to be much easier to trace at a later date than arbitrary binaries so attackers will be less inclined to go that route. Once committed it's there forever unless you can somehow get everyone to censor it from their own copies for an unrelated reason. Consider that the xz compromise involved downloading the payload later. My policy is to either obtain binaries from a major distro or to build from a clean commit in a network isolated environment. If I can't go one of those routes it's almost always a hard pass for me.