31 ms·

Maybe I'm a bit paranoid, but I find it harder to trust the binaries generated by such a project than the ones provided by the Big Techs (even though they are t

by haolez 3y ago

Maybe I'm a bit paranoid, but I find it harder to trust the binaries generated by such a project than the ones provided by the Big Techs (even though they are the biggest stalkers). I'm afraid that such projects, with much less man power and skin in the game, are more vulnerable to supply chain attacks or a hostile takeover if a dev sells the project. I'm not very knowledgeable in this area. Would someone contribute here some resources on how this is avoided in such projects? Or maybe my concerns are valid :)

gostsamo 3y ago
this is using the ms source, just not the logo and signing key. should be as safe as they come.
- robinwassen 3y ago
  The problem is most likely how do you know it's the ms source unmodified?
  - wheelerof4te 3y ago
    You don't, unless you build it yourself. That's the key value of open-source projects. You don't have to release a binary, just source code and a build guide. It's also one of the reasons why I have such high respect for OS distributions like BSDs and Slackware. They give you a good base that you can build upon if you know what you're doing. The problem is, many PC users don't really know what they're doing.
    - no_wizard 3y ago
      >many PC users I'd say most, even software engineers. Can't tell you how many times I've had to explain how environmental variables work to developers, and that's a pretty simple concept compared to many other things in an operating system.
      - Pxtl 3y ago
        Most people cut their teeth on Windows, where the system environment bars are just a basically a section of the registry.
  - vorticalbox 3y ago
    Becuase the repo uses github actions to pull changes and build the binary https://github.com/VSCodium/vscodium/blob/master/.github/workflows/stable-linux.yml https://github.com/VSCodium/vscodium/blob/master/.github/wor...
    - danpalmer 3y ago
      Having had a quick look through this workflow it seems to miss most opportunities to ensure a safe build. - Downloads binaries for use in build with no hash/signing verification. - Doesn't pin shared actions. - Uses Yarn to install dependencies (which can involve downloading/executing arbitrary code from anywhere) - Doesn't sign the final binary. None of this is necessarily wrong, all would make maintenance harder in the long run, but it means this project is really about removing MS branding and some telemetry, and that there is a security trade-off to get those benefits.
      - benatkin 3y ago
        None of these are a big deal. > - Downloads binaries for use in build with no hash/signing verification. It downloads them using TLS. > - Doesn't pin shared actions. The shared actions are just @actions/checkout and @actions/setup-node. They're official. I wouldn't pin them - YAGNI. > - Uses Yarn to install dependencies (which can involve downloading/executing arbitrary code from anywhere) It downloads/executes code based on the carefully chosen dependencies > - Doesn't sign the final binary. That's platform dependent I think. For Mac OS X it does. Seems like FUD, which you might be able to recognize because you say "None of this is necessarily wrong". Especially the part about pinning first party GitHub Actions. There would be nothing wrong with that but it is much more useful to pin third party GitHub Actions, and IMHO suboptimal to pin first party actions.
        danpalmer 3y ago
        Ah yes it does sign on macOS. I don't think it's quite FUD, but I do agree none of these are strictly necessary, all can be rationalised as unnecessary and for many users this project probably provides a perfectly reasonable security posture. However the fact that there's so little explicit acknowledgement of the security concerns, and that 2 minutes looking at the repo turned these things up, suggests that security is not a priority of the project. Again, not the wrong thing to do, but maybe not the trade-offs all users will want. Pinning actions is so low effort/high reward that even the low risk makes it worth it for a project like this in my opinion. Official actions are certainly much safer, but ultimately it's still just human review and PRs being merged. Downloading over TLS negates some impact of hash/signing verification, but it would be a nice extra layer. You're otherwise putting a lot of trust in the combination of DNS+CDN+Hosting. I've seen hijacked sites due to IPs being re-used on cloud providers for example. Unlikely, but again easy to do and high impact in the rare situation that is is taken advantage of. Yarn dependencies may be carefully chosen, I'm not familiar with the VSCode practices. I bet that official binaries however are not built like this – I'd bet that there are allowances for specific network connectivity and binary execution, and that everything else is locked down. To my knowledge GitHub Actions have open internet access. I wouldn't even say this is low risk either, the NPM ecosystem is so deeply nested that I'm sure malicious code could be snuck in somewhere. This is a lot harder to solve for this project, and certainly the most debatable aspect as to whether it's worth it or not.
- danpalmer 3y ago
  The signing key is the important bit though right? This project breaks the chain of trust, as it clones the source repo, [does some shady stuff?] builds a new release, and uploads it to GitHub. It's unlikely that this project knowingly does shady stuff – I've heard of it before, seems to be a long running legit project – but there are lots of unverified factors in that, and the lack of signing (I think?) on the final binaries also means it's hard to know if they get tampered with at some other step.
danpalmer 3y ago
Your concerns are absolutely valid. Without casting any judgement on this project, the process of taking, modifying, and redistributing is hard to do in a trustworthy way. Big companies go to extreme lengths to ensure a chain of trust of the software they build, and app distribution platforms[^1] go to extreme lengths to ensure a full chain of trust end-to-end[^2] from developer to apps running on users devices. There's basically no way to do this without trusting the redistributor in addition to the original publisher, but some things can reduce the amount of trust. Having a verifiable build process, that checks signing keys and hashes, that re-signs, etc, that all helps. If end-users can theoretically produce exactly the same build themselves it's easier to trust it. The best option however is for the source project to produce unbranded builds themselves, and potentially for a project like VSCodium to become "config only" for things like disabling telemetry, and therefore not requiring re-signing. The Chromium project distributes its own Chromium binaries which lack the Google-specific stuff for example. [^1]: Mostly thinking of app stores, but the same is basically true of things like Debian package repositories. [^2]: App stores typically re-sign in the middle, so you do have to trust the store, but see (1), these companies go to great lengths to ensure trustworthiness there.
- sqeaky 3y ago
  Trusting "big companies" because we presume they have guard rails seems like a bad idea, it is how we got the solar winds supply chain attack. When I worked for one of the largest voting machine companies I was astounded how the final build process for the software was done just before it was sent to the customer. It was built on a Jenkins server that several people had access to change and update with minimal oversight and the devops person had freedom to do anything to with no oversight. For the year I worked there this one man could have changed dozens of elections if he chose to and figuring it out would have been very hard. I am sure a large enough investigation could could have figured out such a thing, but by then the damage would already be done. If he changed only municipal elections that couldn't affors such an investigation it might never have been done. I have no reason to claim this happened, but we certainly can't prove it didn't and this is in one of the most paranoid and regulated spaces in software development.
  - 3y ago
dataflow 3y ago
I've never tried this, but in theory, if these projects produce builds on GitHub Actions and you trust Microsoft's security, then you should be able to just look at the commit hash that got pulled in the action and diff that against upstream and just study that. If the diff looks safe [1] then I think that implies the binary can be trusted. [1] Of course this includes ensuring it doesn't e.g. pull anything from the internet whose integrity you can't similarly guarantee...
- krick 3y ago
  Somebody please bother to explain why this is downvoted. The reasoning seems perfectly valid. Of course, there are a lot of ways how somebody could fuck up, but in theory automated builds on github have the same trustworthiness guarantees as Microsoft's very own VSCode binaries.
Xelbair 3y ago
with how the current tech world is, and after working in it, I'm the opposite. I have absolutely 0 trust towards any big corp doing things properly, and not cramming the applications full of spyware in the name of telemetry. and i would rather trust a bunch of insane dedicated people trying to make FOSS software.
skybrian 3y ago
Yes, I also trust the original company more, for now. It would be nice to have more choices. Reproducible builds would help here, like Go did for their newest SDK [1]. This would be particularly true for a fork when the source changes are fairly minimal, since you could just verify the patch. Linux distros are fairly similar; why do we mostly trust Debian packages? Because there’s an umbrella organization and a process. That’s less true of a standalone organization. Maybe eventually there will be an umbrella organization that just does reproducible builds, and people will use that to distribute binaries. (And independent verification could keep them honest, like happens with domain registrars.) [1] https://go.dev/blog/rebuild https://go.dev/blog/rebuild
- haolez 3y ago
  Good point. That's one problem that might be well solved by something like BitTorrent, which hashes all the files as part of the protocol. Once a binary gets analyzed and trusted (the current binary, not the process or every new upgrade), it can be safely used.
- brnt 3y ago
  Vscode packaging as/is famously not public. Plus, trust to do what exactly? Come with telemetry flipped on?
  - skybrian 3y ago
    Trust is always relative to a threat model. I trust that the people who work on VS Code won't do all sorts of nefarious things that hackers might want to do if they can get code running on your system. I trust that their telemetry settings do what they say they'll do. And if someone finds a security bug, they'll fix it. I don't assume that there won't be security holes, but in effect, I'm assuming they probably won't affect me.
hedora 3y ago
I just installed vscodium on my manjaro machine. It built from the AUR source. I’m sure you could diff the source code the package used, and the upstream Microsoft git SHA it is claims to be derived from: https://aur.archlinux.org/packages/vscodium https://aur.archlinux.org/packages/vscodium Incidentally, there is now an open source remote mode extension, so I have no reason to use the proprietary version. No more telemetry from me!
- yencabulator 3y ago
  > there is now an open source remote mode extension URL please? Open VSX lists several but it's hard to evaluate if they're complete & stable from just the READMEs. For example, https://github.com/xaberus/vscode-remote-oss https://github.com/xaberus/vscode-remote-oss has existed for a long time, but one would need to spend a few hours to know if it works well enough.
- unstuck3958 3y ago
  > Incidentally, there is now an open source remote mode extension God bless the Arch User Repo. Stuff like this has made it impossible for me to move on from Arch.
- ranguna 3y ago
  The open source remote extensions doesn't support hardware keys as ssh keys. They have an issue open for this for years now. I use vscodium either way, you need to get used to stuff like this from time to time.
dist-epoch 3y ago
Your approach is valid, if you also avoid npm/pip/cargo/... packages. Otherwise...
croes 3y ago
Isn't VSCodium just VSCode without the telemetry code? So if there is a supply chain risk it's the same for VS Code
- Retr0id 3y ago
  The supply chain does not end at the source code.
  - croes 3y ago
    What does VSCodium add?
    - jamesgeck0 3y ago
      If their CI is one day compromised by an attacker, potentially anything.
      - croes 3y ago
        Just like MS's CI, and I guess MS is the more valuable target.
        fredoliveira 3y ago
        But one might also assume, the hardest target to actually hit.
- krick 3y ago
  You're missing the point. GP is discussing binaries. I.e., the assumption is that published source code (on Github) is perfectly fine, and then either the (malign) developer is changing the code before compiling it, or the (malign) third party is somehow using some vulnerability to replace the official binaries with compiled code of their own. And then you think that you are using "VSCode without the telemetry code", but in reality you're running a botnet.
slim 3y ago
it is less vulnerable simply because it's less used. hackers target the supply chain with the majority of consumers
asddubs 3y ago
I think skin in the game is the big one, much moreso than manpower. I use a lot of things that are probably mostly one-person projects, but if that person poured their love and time into it, it seems unlikely they'd permanently tarnish not just their reputation, but also the thing they spent all this time on. If you're just setting a couple compile flags and changing a name, I am a little more suspicious
beAbU 3y ago
This is what happened to FileZilla I think?
Barrin92 3y ago
It's not paranoid, the scepticism is completely warranted as this is security theatre. People are afraid Microsoft will screw them over with a text editor but run random binaries provided by people for whom a thousand bucks may as well be enough motivation to ship you malware. It's like buying your heart medication off an anonymous guy on Craigslist to stick it to big pharma.
- RunSet 3y ago
  Buying it for libre dollars and free cents.
d0mine 3y ago
- option A: definite known spyware; - option B: maybe potentially one day there is an attack/take over. The choice is obvious.
davidgerard 3y ago
It could be much worse - you could install the official vendor binary, which is known to contain spyware.
- haolez 3y ago
  Spyware sucks, but ransomware and joining a botnet suck much more.
3np 3y ago
Example Arch AUR but similar for Nix, Guix, Gentoo, others: On first install: - read AUR file - audit build & patching framework - audit patches On upgrade: - review patch changes - treat upstream changes like you would otherwise On upgrade with AUR file change: - review AUR file changes - review build & patching framework changes If you've bothered to set up your own repos and build pipeline integrating your patches already (and you can get a lot of that for free), the additional overhead isn't as large as it may sound. vscodium is doing the much larger work of cross-checking vscode and in exchange I do the smaller work of cross-checking theirs - and putting in my own so I have zeroconf installs with prebundled extensions and whatnot on new machines. Same for browser (ungoogled-chromium, vanadium, librewolf or whathaveyou)
eternityforest 3y ago
I trust big tech more than most FOSS. I'm not worried about the government spying on me or ad tracking, I'm worried about a random hacker. It's ironic that for a lot of people the concept of privacy has been inverted: The closer someone is to you the more we want to hide from them. Facebook showing my online status to acquaintances(Or the lack of an online status, which could also create suspicion that I'm hiding something) bothers me more often than a random Google employee listening in through my alarm clock.
- pulpfictional 3y ago
  It's not ironic, it's concern over the influence big tech yields over society with said data, unlike your concerns which are scoped on you and immediate.
  - eternityforest 3y ago
    The majority of people seem to have immediate -scoped concerns I suppose. Most of the really scary big data possibilities seems more like political issues than data issues, the data is just something they could use to do the things people are worried about. It's not great, but it's competing for mind share with a lot of other possibile horrors people are afraid of and people are rather fatigued. The more subtle stuff they're already doing seems like it would be a problem with even the most basic data. The biggest issue I see is personalized content which causes fights, hate, wasted time, and all that, because the algorithms want you to engage with it as much as possible, and it shits on real journalism by giving all the attention to clickbaits. I suspect every time I've responded to such clickbaits might be more problematic than all the data they get from all my smart devices in a year... Protecting one's privacy because of societal harm is a worthy thing but also a pretty big effort and I sure don't have a solution, or even any confident prediction of how big the problem is or where it's coming from... But I probably won't truly be worried unless one of those horrid encryption bans gets close to passing.
    - pulpfictional 3y ago
      > The majority of people seem to have immediate -scoped concerns I suppose. Well, like you write, aggregated data is already being used to influence populations which makes it immediate. An hypothetical hacker is not. > Most of the really scary big data possibilities seems more like political issues than data issues, the data is just something they could use to do the things people are worried about. I don't follow. Not giving away the data removes the need for politics. Crime is illegal nevertheless it exists because it is possible to commit. > It's not great, but it's competing for mind share with a lot of other possibile horrors people are afraid of and people are rather fatigued. Not everyone shares the same concerns and nobody likes problems, that doesn't' mean they should be accepted. > The more subtle stuff they're already doing seems like it would be a problem with even the most basic data. All the more reason not to give them more. The personalized hate content is a direct consequence of big data aggregation. All in all, seems like more of an issue than a possible compromise of a FOSS project.
lathiat 3y ago
On the one hand there is 100% validity to what you say. On the other, people download entire trees of dependencies from pypi, npm, homebrew, independent non sandboxed apps, chrome extensions, etc. So don’t lull yourself into thinking the supply chain on everything on your system is any better :) It’s likely substantially worse.
ninjha 3y ago
I would have assumed the win here would be that your Linux distribution or package manager on another OS can compile "VSCodium" themselves -- and you already trust them for all your other software, so this simplifies the trust chain somewhat. In reality I think distributions that are willing to ship binaries (NixOS, Homebrew on MacOS) ship VSCodium, and other distributions (Alpine) have packages called things like `code-oss` that are basically the distribution's internal compiled version of VSCode and have nothing (?) to do with VSCodium.

by haolez 3y ago

gostsamo 3y ago

this is using the ms source, just not the logo and signing key. should be as safe as they come.

robinwassen 3y ago
The problem is most likely how do you know it's the ms source unmodified?
- wheelerof4te 3y ago
  You don't, unless you build it yourself. That's the key value of open-source projects. You don't have to release a binary, just source code and a build guide. It's also one of the reasons why I have such high respect for OS distributions like BSDs and Slackware. They give you a good base that you can build upon if you know what you're doing. The problem is, many PC users don't really know what they're doing.
  - no_wizard 3y ago
    >many PC users I'd say most, even software engineers. Can't tell you how many times I've had to explain how environmental variables work to developers, and that's a pretty simple concept compared to many other things in an operating system.
    - Pxtl 3y ago
      Most people cut their teeth on Windows, where the system environment bars are just a basically a section of the registry.
- vorticalbox 3y ago
  Becuase the repo uses github actions to pull changes and build the binary https://github.com/VSCodium/vscodium/blob/master/.github/workflows/stable-linux.yml https://github.com/VSCodium/vscodium/blob/master/.github/wor...
  - danpalmer 3y ago
    Having had a quick look through this workflow it seems to miss most opportunities to ensure a safe build. - Downloads binaries for use in build with no hash/signing verification. - Doesn't pin shared actions. - Uses Yarn to install dependencies (which can involve downloading/executing arbitrary code from anywhere) - Doesn't sign the final binary. None of this is necessarily wrong, all would make maintenance harder in the long run, but it means this project is really about removing MS branding and some telemetry, and that there is a security trade-off to get those benefits.
    - benatkin 3y ago
      None of these are a big deal. > - Downloads binaries for use in build with no hash/signing verification. It downloads them using TLS. > - Doesn't pin shared actions. The shared actions are just @actions/checkout and @actions/setup-node. They're official. I wouldn't pin them - YAGNI. > - Uses Yarn to install dependencies (which can involve downloading/executing arbitrary code from anywhere) It downloads/executes code based on the carefully chosen dependencies > - Doesn't sign the final binary. That's platform dependent I think. For Mac OS X it does. Seems like FUD, which you might be able to recognize because you say "None of this is necessarily wrong". Especially the part about pinning first party GitHub Actions. There would be nothing wrong with that but it is much more useful to pin third party GitHub Actions, and IMHO suboptimal to pin first party actions.
      - danpalmer 3y ago
        Ah yes it does sign on macOS. I don't think it's quite FUD, but I do agree none of these are strictly necessary, all can be rationalised as unnecessary and for many users this project probably provides a perfectly reasonable security posture. However the fact that there's so little explicit acknowledgement of the security concerns, and that 2 minutes looking at the repo turned these things up, suggests that security is not a priority of the project. Again, not the wrong thing to do, but maybe not the trade-offs all users will want. Pinning actions is so low effort/high reward that even the low risk makes it worth it for a project like this in my opinion. Official actions are certainly much safer, but ultimately it's still just human review and PRs being merged. Downloading over TLS negates some impact of hash/signing verification, but it would be a nice extra layer. You're otherwise putting a lot of trust in the combination of DNS+CDN+Hosting. I've seen hijacked sites due to IPs being re-used on cloud providers for example. Unlikely, but again easy to do and high impact in the rare situation that is is taken advantage of. Yarn dependencies may be carefully chosen, I'm not familiar with the VSCode practices. I bet that official binaries however are not built like this – I'd bet that there are allowances for specific network connectivity and binary execution, and that everything else is locked down. To my knowledge GitHub Actions have open internet access. I wouldn't even say this is low risk either, the NPM ecosystem is so deeply nested that I'm sure malicious code could be snuck in somewhere. This is a lot harder to solve for this project, and certainly the most debatable aspect as to whether it's worth it or not.
danpalmer 3y ago
The signing key is the important bit though right? This project breaks the chain of trust, as it clones the source repo, [does some shady stuff?] builds a new release, and uploads it to GitHub. It's unlikely that this project knowingly does shady stuff – I've heard of it before, seems to be a long running legit project – but there are lots of unverified factors in that, and the lack of signing (I think?) on the final binaries also means it's hard to know if they get tampered with at some other step.

danpalmer 3y ago

Your concerns are absolutely valid. Without casting any judgement on this project, the process of taking, modifying, and redistributing is hard to do in a trustworthy way. Big companies go to extreme lengths to ensure a chain of trust of the software they build, and app distribution platforms[^1] go to extreme lengths to ensure a full chain of trust end-to-end[^2] from developer to apps running on users devices. There's basically no way to do this without trusting the redistributor in addition to the original publisher, but some things can reduce the amount of trust. Having a verifiable build process, that checks signing keys and hashes, that re-signs, etc, that all helps. If end-users can theoretically produce exactly the same build themselves it's easier to trust it. The best option however is for the source project to produce unbranded builds themselves, and potentially for a project like VSCodium to become "config only" for things like disabling telemetry, and therefore not requiring re-signing. The Chromium project distributes its own Chromium binaries which lack the Google-specific stuff for example. [^1]: Mostly thinking of app stores, but the same is basically true of things like Debian package repositories. [^2]: App stores typically re-sign in the middle, so you do have to trust the store, but see (1), these companies go to great lengths to ensure trustworthiness there.

sqeaky 3y ago
Trusting "big companies" because we presume they have guard rails seems like a bad idea, it is how we got the solar winds supply chain attack. When I worked for one of the largest voting machine companies I was astounded how the final build process for the software was done just before it was sent to the customer. It was built on a Jenkins server that several people had access to change and update with minimal oversight and the devops person had freedom to do anything to with no oversight. For the year I worked there this one man could have changed dozens of elections if he chose to and figuring it out would have been very hard. I am sure a large enough investigation could could have figured out such a thing, but by then the damage would already be done. If he changed only municipal elections that couldn't affors such an investigation it might never have been done. I have no reason to claim this happened, but we certainly can't prove it didn't and this is in one of the most paranoid and regulated spaces in software development.
- 3y ago

dataflow 3y ago

I've never tried this, but in theory, if these projects produce builds on GitHub Actions and you trust Microsoft's security, then you should be able to just look at the commit hash that got pulled in the action and diff that against upstream and just study that. If the diff looks safe [1] then I think that implies the binary can be trusted. [1] Of course this includes ensuring it doesn't e.g. pull anything from the internet whose integrity you can't similarly guarantee...

krick 3y ago
Somebody please bother to explain why this is downvoted. The reasoning seems perfectly valid. Of course, there are a lot of ways how somebody could fuck up, but in theory automated builds on github have the same trustworthiness guarantees as Microsoft's very own VSCode binaries.

Xelbair 3y ago

with how the current tech world is, and after working in it, I'm the opposite. I have absolutely 0 trust towards any big corp doing things properly, and not cramming the applications full of spyware in the name of telemetry. and i would rather trust a bunch of insane dedicated people trying to make FOSS software.

skybrian 3y ago

Yes, I also trust the original company more, for now. It would be nice to have more choices. Reproducible builds would help here, like Go did for their newest SDK [1]. This would be particularly true for a fork when the source changes are fairly minimal, since you could just verify the patch. Linux distros are fairly similar; why do we mostly trust Debian packages? Because there’s an umbrella organization and a process. That’s less true of a standalone organization. Maybe eventually there will be an umbrella organization that just does reproducible builds, and people will use that to distribute binaries. (And independent verification could keep them honest, like happens with domain registrars.) [1] https://go.dev/blog/rebuild https://go.dev/blog/rebuild

haolez 3y ago
Good point. That's one problem that might be well solved by something like BitTorrent, which hashes all the files as part of the protocol. Once a binary gets analyzed and trusted (the current binary, not the process or every new upgrade), it can be safely used.
brnt 3y ago
Vscode packaging as/is famously not public. Plus, trust to do what exactly? Come with telemetry flipped on?
- skybrian 3y ago
  Trust is always relative to a threat model. I trust that the people who work on VS Code won't do all sorts of nefarious things that hackers might want to do if they can get code running on your system. I trust that their telemetry settings do what they say they'll do. And if someone finds a security bug, they'll fix it. I don't assume that there won't be security holes, but in effect, I'm assuming they probably won't affect me.

hedora 3y ago

I just installed vscodium on my manjaro machine. It built from the AUR source. I’m sure you could diff the source code the package used, and the upstream Microsoft git SHA it is claims to be derived from: https://aur.archlinux.org/packages/vscodium https://aur.archlinux.org/packages/vscodium Incidentally, there is now an open source remote mode extension, so I have no reason to use the proprietary version. No more telemetry from me!

yencabulator 3y ago
> there is now an open source remote mode extension URL please? Open VSX lists several but it's hard to evaluate if they're complete & stable from just the READMEs. For example, https://github.com/xaberus/vscode-remote-oss https://github.com/xaberus/vscode-remote-oss has existed for a long time, but one would need to spend a few hours to know if it works well enough.
unstuck3958 3y ago
> Incidentally, there is now an open source remote mode extension God bless the Arch User Repo. Stuff like this has made it impossible for me to move on from Arch.
ranguna 3y ago
The open source remote extensions doesn't support hardware keys as ssh keys. They have an issue open for this for years now. I use vscodium either way, you need to get used to stuff like this from time to time.

dist-epoch 3y ago

Your approach is valid, if you also avoid npm/pip/cargo/... packages. Otherwise...

croes 3y ago

Isn't VSCodium just VSCode without the telemetry code? So if there is a supply chain risk it's the same for VS Code

Retr0id 3y ago
The supply chain does not end at the source code.
- croes 3y ago
  What does VSCodium add?
  - jamesgeck0 3y ago
    If their CI is one day compromised by an attacker, potentially anything.
    - croes 3y ago
      Just like MS's CI, and I guess MS is the more valuable target.
      - fredoliveira 3y ago
        But one might also assume, the hardest target to actually hit.
krick 3y ago
You're missing the point. GP is discussing binaries. I.e., the assumption is that published source code (on Github) is perfectly fine, and then either the (malign) developer is changing the code before compiling it, or the (malign) third party is somehow using some vulnerability to replace the official binaries with compiled code of their own. And then you think that you are using "VSCode without the telemetry code", but in reality you're running a botnet.

slim 3y ago

it is less vulnerable simply because it's less used. hackers target the supply chain with the majority of consumers

asddubs 3y ago

I think skin in the game is the big one, much moreso than manpower. I use a lot of things that are probably mostly one-person projects, but if that person poured their love and time into it, it seems unlikely they'd permanently tarnish not just their reputation, but also the thing they spent all this time on. If you're just setting a couple compile flags and changing a name, I am a little more suspicious

beAbU 3y ago

This is what happened to FileZilla I think?

Barrin92 3y ago

It's not paranoid, the scepticism is completely warranted as this is security theatre. People are afraid Microsoft will screw them over with a text editor but run random binaries provided by people for whom a thousand bucks may as well be enough motivation to ship you malware. It's like buying your heart medication off an anonymous guy on Craigslist to stick it to big pharma.

RunSet 3y ago
Buying it for libre dollars and free cents.

d0mine 3y ago

- option A: definite known spyware; - option B: maybe potentially one day there is an attack/take over. The choice is obvious.

davidgerard 3y ago

It could be much worse - you could install the official vendor binary, which is known to contain spyware.

haolez 3y ago
Spyware sucks, but ransomware and joining a botnet suck much more.

3np 3y ago

Example Arch AUR but similar for Nix, Guix, Gentoo, others: On first install: - read AUR file - audit build & patching framework - audit patches On upgrade: - review patch changes - treat upstream changes like you would otherwise On upgrade with AUR file change: - review AUR file changes - review build & patching framework changes If you've bothered to set up your own repos and build pipeline integrating your patches already (and you can get a lot of that for free), the additional overhead isn't as large as it may sound. vscodium is doing the much larger work of cross-checking vscode and in exchange I do the smaller work of cross-checking theirs - and putting in my own so I have zeroconf installs with prebundled extensions and whatnot on new machines. Same for browser (ungoogled-chromium, vanadium, librewolf or whathaveyou)

eternityforest 3y ago

I trust big tech more than most FOSS. I'm not worried about the government spying on me or ad tracking, I'm worried about a random hacker. It's ironic that for a lot of people the concept of privacy has been inverted: The closer someone is to you the more we want to hide from them. Facebook showing my online status to acquaintances(Or the lack of an online status, which could also create suspicion that I'm hiding something) bothers me more often than a random Google employee listening in through my alarm clock.

pulpfictional 3y ago
It's not ironic, it's concern over the influence big tech yields over society with said data, unlike your concerns which are scoped on you and immediate.
- eternityforest 3y ago
  The majority of people seem to have immediate -scoped concerns I suppose. Most of the really scary big data possibilities seems more like political issues than data issues, the data is just something they could use to do the things people are worried about. It's not great, but it's competing for mind share with a lot of other possibile horrors people are afraid of and people are rather fatigued. The more subtle stuff they're already doing seems like it would be a problem with even the most basic data. The biggest issue I see is personalized content which causes fights, hate, wasted time, and all that, because the algorithms want you to engage with it as much as possible, and it shits on real journalism by giving all the attention to clickbaits. I suspect every time I've responded to such clickbaits might be more problematic than all the data they get from all my smart devices in a year... Protecting one's privacy because of societal harm is a worthy thing but also a pretty big effort and I sure don't have a solution, or even any confident prediction of how big the problem is or where it's coming from... But I probably won't truly be worried unless one of those horrid encryption bans gets close to passing.
  - pulpfictional 3y ago
    > The majority of people seem to have immediate -scoped concerns I suppose. Well, like you write, aggregated data is already being used to influence populations which makes it immediate. An hypothetical hacker is not. > Most of the really scary big data possibilities seems more like political issues than data issues, the data is just something they could use to do the things people are worried about. I don't follow. Not giving away the data removes the need for politics. Crime is illegal nevertheless it exists because it is possible to commit. > It's not great, but it's competing for mind share with a lot of other possibile horrors people are afraid of and people are rather fatigued. Not everyone shares the same concerns and nobody likes problems, that doesn't' mean they should be accepted. > The more subtle stuff they're already doing seems like it would be a problem with even the most basic data. All the more reason not to give them more. The personalized hate content is a direct consequence of big data aggregation. All in all, seems like more of an issue than a possible compromise of a FOSS project.

lathiat 3y ago

On the one hand there is 100% validity to what you say. On the other, people download entire trees of dependencies from pypi, npm, homebrew, independent non sandboxed apps, chrome extensions, etc. So don’t lull yourself into thinking the supply chain on everything on your system is any better :) It’s likely substantially worse.

ninjha 3y ago

I would have assumed the win here would be that your Linux distribution or package manager on another OS can compile "VSCodium" themselves -- and you already trust them for all your other software, so this simplifies the trust chain somewhat. In reality I think distributions that are willing to ship binaries (NixOS, Homebrew on MacOS) ship VSCodium, and other distributions (Alpine) have packages called things like `code-oss` that are basically the distribution's internal compiled version of VSCode and have nothing (?) to do with VSCodium.