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.

> 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.

Really what much else could you ask for?

It only takes 1 trusted friend to verify the codebase, and from there it can spread. Luckily there are a lot of talented people on the Internet whom several people can vouch for, easy to find. It's pretty much a non-problem in the age of the Internet.

The same natural logic applies to anything else really... like cars - "yo what car do you trust?"

It's just the nature of living. If you don't have the skills, you need to find someone who does to trust. And no just because it comes from a company doesn't mean you can trust it, that's a fallacy. "Safety" doesn't necessary equate to "profits" which is what a business needs to live. It's an organism.

I'm certainly not equating safety to profits, but I think that a company such as Microsoft with decades of experience distributing cryptographically verified software to a range of demanding consumers (e.g. governments) and being big enough to be able to have teams running things like their certificate authority infrastructure, is much more likely to produce secure binary distributions than some GitHub Actions and shell scripts.

I don't think your car analogy quite fits, as there are ongoing updates, and it's not like the end-user perception of regular VSCode, or backdoored VSCode, are going to be any different until someone spots the backdoor (and we can't rely on that).

Meanwhile in the real world, Microsoft is actively screwing up, losing control of their signing keys, failing to implementing even basics of Azure authentication, destroying Azure customer VM security, and so on.

https://news.ycombinator.com/item?id=37261500

https://news.ycombinator.com/item?id=28347141

https://news.ycombinator.com/item?id=28532531

Seems your assumptions about their practices are wrong based on the other comment, but let's pretend that's the truth.

Why would a GitHub Action be worse? You're just telling me it is, asking me to believe that...

The car analogy is just that - you can break any analogy if you try. You've got a better one to help prove me right? :)

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.

I'm speaking from experience at Google, and honestly our software integrity processes are like nothing I could have imagined coming in. Not everything is perfect and it has clearly evolved over time, but basically for a modern internal Google codebase I don't think I could have much more trust that it is what it claims to be.

I don't know if other big tech is quite the same, but from the little I've heard, I suspect that Microsoft, Amazon, Apple, and others in that ilk are similar.

I'm very much in the camp of "trust but verify" here. You're right that Solar Winds was an utter disaster. It should never have been able to happen.

Microsoft has had some serious recent faults in their fundamental handling of a couple of areas (like driver signing! https://news.ycombinator.com/item?id=37261500).

And that's on top of Azure's recent appearance in the news.

https://news.ycombinator.com/item?id=36979532 (Microsoft comes under blistering criticism for “grossly irresponsible” security)

Trusting "open source" is also how we get tons of other kinds of vulnerabilities, but that doesn't mean open source is unworthy of trust.

The reason why organizations turn to other companies to deliver this is because there's a "throat to choke" for when things go wrong and a financial incentive to fix the inevitable issues when they come up.

To be honest when an attack like this happens at big companies, our expectations to mitigate the attack are much higher than if it's a project maintained by a small group of people.

For example, Microsoft recently "lost" (they didn't disclose what happened) some sort of authentication key that allowed Chinese hackers to break into their network: https://techcrunch.com/2023/07/17/microsoft-lost-keys-govern...

How does this even happen at a big company like Microsoft? Then you take a look at small, <100 people company, their security policies are much more strict than Microsoft's. And even if it happened the same way, we wouldn't have such high expectations because they have a small team.

Honestly, I prefer trusting a small project than a big company project. Take a look at Terraform now, HashiCorp pulled the plug and made it a proprietary app with source available requiring you to sign a CLA to prevent them from being sued later on. Red Hat is manipulating the GPL2 to force people to buy their subscriptions.

EDIT: how can we forget how GitHub was before Microsoft bought it in 2016? GitHub was much more friendly to open source and nowadays they just use any open source code available on their service to train their Copilot AI without respecting the terms of the licenses of the millions of projects hosted there. They killed Atom. They scan your private and public repos for "vulnerabilities". They literally read everything on your repo and feed it into Copilot. If GitHub wasn't sold, I'm pretty sure the situation would be different.

Call me crazy or dumb but I strongly believe that the bigger a company is, the worse their policies are. They neglect security at the cost of higher profits (ahem, looking at Facebook for allowing people to mine their users' data via an exploit that was just fixed when they called out Facebook for selling users' data).

The best option would have been for the source project to not be distributing malware in the first place.

Ya I used to buy into that idea about using vendor products with the rationale that "at very least they wouldn't want to get sued for negligence so they have to have some basic security in place" then that huge bug came out where you got root access in Azure if you simply didn't send an AuthN header.

Well let’s not forget the importance of being able to sue. You use free software without warranty there is nobody to sue.

Good luck trying to sue Microsoft over a security vulnerability.

I think it is worth mentioning here that Microsoft does not care about user privacy.

I don't know if this is because Microsoft took down the blog posts and press releases or because Google web search sucks now (different conversation) but I had trouble finding the source for Microsoft statement. I'm talking about the incident when Microsoft spied into a user's hotmail email contents.

> However, to determine the identity of the leaker, CNET reveals, Microsoft actually looked through the Hotmail email of a French blogger who was in contact with the leaker, and make available online early copies of Windows 7 and Windows 8, as well as means that allowed users to circumvent activations protection for Microsoft and Windows.

https://bgr.com/general/microsoft-hotmail-and-outlook-privac...

I wouldn't give Microsoft any benefit of the doubt. While I have utmost respect for the people (who I know and) who work there, the senior leadership has always been poopy at best. I would never trust a word they say.

"Yeah but you can sue" is not really that viable. How's that going for anybody? Not everyone can dedicate their time and savings to gambling on getting compensated. At the very least, the open source community is vigilant and quick to ostracize bad actors. Big tech companies get tax breaks to screw us over

You can use a commercial (paid-for) Linux distro if you really want the legal protections of being a customer, while staying with Free and Open Source software.

As Capricorn2481 points out though, suing isn't really on the cards for most individual.

>big companies go to great lengths to ensure chain of trust

lol.

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

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.

The problem is most likely how do you know it's the ms source unmodified?

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.

>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.

Most people cut their teeth on Windows, where the system environment bars are just a basically a section of the registry.

Becuase the repo uses github actions to pull changes and build the binary

https://github.com/VSCodium/vscodium/blob/master/.github/wor...

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.

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.

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.

> low effort/high reward

Are there any shared actions that aren't actions/name-of-project? If not, that's zero reward.

I'm not sure I follow why the "official" actions under the actions org are materially different to others? I agree they're likely to have better processes around contributions, but they are fundamentally an open contribution model with human review, and human review is fallible. Unless they had extra sandboxing, pinning requirements, materially better testing, etc, I'm not sure there's a huge difference.

No, PR review isn't the only thing that prevents these from being updated. In the yml it's set to a release branch. So it isn't especially fallible.

https://github.com/actions/setup-node/tree/releases/v2

However, the Linux one grabs two from third party, to GitHub, repos. These seem relatively safe, from official systems level projects — snapcraft and docker. I'm going to suggest to Codium they add a SHA to pin those, just like I would suggest they unpin GitHub Actions if they'd had them pinned. Sorry I was looking at the Mac one because I have a Mac even though the link up the thread was for Linux.

The yarn.lock includes checksums, if yarn is not checking checksums properly then that affects every project in Node.js, not just this one.

Malicious code with the correct checksum? VSCode team is not auto updating dependencies but I also doubt they are reviewing the source code of every package they update. I've never worked anywhere that does. So yeah, "gulp-vinyl-zip" (or any other package used at build time) could add some code that secretly triggers when run in the VSCode repository and makes some malicious source code changes. But, it's still going to be the same code in VSCode and VSCodium. Unless the attacker decides to use specific logic to target one or the other.

It's possible, and common, for NPM packages to download additional binaries at install and/or run time. These would not be included in the hashes, and are essentially untrusted, often hosted on random S3 buckets. I'd hope there are checks in the official project to ensure these aren't being used, but there aren't any checks in this project.

How would you write such a check?

Using socket.dev is one way!

As for writing such a check manually, you would just need to check "bin" in */package.json after installing everything, and verify each script.

Trusting a big company seems to be another suggestion I see in this thread too. I don't agree with that one.

My employer uses artifactory as a mirror of npm and one step of adding a package to the mirror is installing it on a VM/container with no network access. If the package has a "postinstall" script requiring internet access then it will fail. There's also code scanning that will find at least casual attacks like "download and run this crypto ransomware".

I think the idea MS has deployed this is over optimistic. Look at this with Google. https://giraffesecurity.dev/posts/google-remote-code-executi...

Also, it depends how determined your attacker is. If they write code to detect whether they're being installed in the vscode project, have access to commercially available security scanning tools to ensure they evade detection, etc...

Isn't the whole point of this comment thread "vulnerabilities to supply chain attacks"?

>> - Downloads binaries for use in build with no hash/signing verification.

> It downloads them using TLS.

If the binary is updated to a shady version, sure, no one will be able to tamper with the download, they're certain to have received the correct shady stuff.

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...

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.

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.

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

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.

Vscode packaging as/is famously not public. Plus, trust to do what exactly? Come with telemetry flipped on?

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.

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

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!

> 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 has existed for a long time, but one would need to spend a few hours to know if it works well enough.

> 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.

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.

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

Isn't VSCodium just VSCode without the telemetry code?

So if there is a supply chain risk it's the same for VS Code

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.

The supply chain does not end at the source code.

What does VSCodium add?

If their CI is one day compromised by an attacker, potentially anything.

Just like MS's CI, and I guess MS is the more valuable target.

But one might also assume, the hardest target to actually hit.

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

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

This is what happened to FileZilla I think?

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.

Buying it for libre dollars and free cents.

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

The choice is obvious.

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

Spyware sucks, but ransomware and joining a botnet suck much more.

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)

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.

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.

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.

> 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.

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.

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.