Are those things you are personally struggling with (if you are considering quitting open source contribitions wholesale: don't let this make you) or is this a showcase of rationalization?
You can test this locally yourself with mitmproxy, opensnitch, or whatever.
You can try building the (supposedly) open-source apps you use from source.
Everyone opining here should MitM themselves every now and then. If not for your own security then maybe to make sure you're not participating in psyop when opining online and resharing hearsay or old truisms.
> Obviously playing Kasparov on the board requires more planning ability than managing a McDonald's
Not obvious and in fact I think the opposite is way more likely. Chess is well-defined and self-contained in a way that managing a restaurant with fleshy customers never will be.
But that is also non-obvious. Even managing human employees — let alone customers — required a planning ability related to emotional intelligence that many a person with good pure logic ability simply lacks.
Also, there will be hundreds of disparate tasks that are happening in parallel, and even humans still make up frameworks to discover most urgent/important work that needs to be done first.
At what point did/does it start feeling naive to trust the integrity and output of Github Actions on general? Does it feel unlikely that an attacker would be able to get a foothold in that infrastructure?
I won't say "you can take my VS Code from cold dead hands" or anything, but it is a very good tool, and Microsoft hasn't yet fucked it up the way they have so many other things.
I guess I'd say "you take my VS Code ... willingly ... but only after M$ fucks it up and makes me not want it anymore (like they've done to everything else they acquired)".
Makes me wish, we could just have some "Metric" sin-goat, that is basically some nonsense fork of the project, that the process can ruin for "promotion" crystals or whatever, while the actual project runs unaffected on in the background.
That seems like a very, very long-winded way of accusing them of "embrace, extend, extinguish"? Which is obviously not falsifiable, but just feels a bit trite at this point, IMO.
Doesn't have to be. It's been empiracally proven the case for MS time and again. How many times do you need it to happen because you treat it as the default?
The root(-ish) cause here is the ease of publishing and installing extension code, and in particular the fact that there's no independent validation/verification step between the upstream author and armageddon. And upstream authors aren't set up with the needed precautions themselves, they're just hackers.
Basically if you phish Just One Account with write access to an extension you wan pwn everyone who's running it.
> Any extensible, customizable display editor can be coerced into behaving badly by installing external code.
But I think only VS Code (And Jetbrain's ones) is so pushy about installing extensions. With Emacs, you actually have to go find them and install it. And then you actually have to make a conscious effort to update them. Same with vim. I'm pretty sure VS Code enable auto updates. And I would guess the people publishing Emacs's package and Vim's plugin are way more conscious about security.
I like neovim but I am under no illusion that plugins developers would be more conscious about security. The thing is there is no marketplace so it is less easy to make your plugin suddently advertised and installed by thousands of people without having a killer feature.
To hijack a vim plugin/emacs package, you would have to take over the repo. Or take over elpa/melpa (for emacs) or vim awesome (to redirect users to your malicious repo). Both are way tricker than the exploitation tactics used on JS based projects.
The problem is not VS code itself. It's the fact extensions can access things outside of the editor. As far as I am aware, no editor sandboxes extensions.
True developers don't leak the keys to their sources just because they need convenience-features from a "free IDE with tons of sexy bells and whistles" ..
Features that would, incidentally, be obviated by making just a bit of a better effort to be better managers of the filesystem and ones' source code - and thus: become more competent developers.
There is a limit to the positive impact of convenience features in any tools, not just IDE's. We are seeing that limit being broached with every exfiltration of repo keys attributed to VSCodes' crap anti-user architecture ...
You'll scream at the universe when it happens to you.
Your comment implies that you've somehow misunderstood my comments and thus think that I am using Microsoft's hot garbage text editor with a million plugins.
Your comment came across as sarcasm directed at aa-jv's position that folks are lured into the VSCode abyss and stay there because their comfort level won't let them leave, while VSCode - meanwhile - continues to be a huge security liability for any project where it is used.
... the only sarcasm I posted was about screaming at the universe in response to his suggestion that the only alternative to people loading up a text editor with a million shonky plugins to try and make it an IDE, is to eschew all IDEs.
The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".
VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.
Well your point didn't come across at all, just sayin'.
But here's the point: All IDE's eventually become liabilities as they attempt to become an operating system.
Better to just use a text editor, learn to use the build tools, navigate the filesystem with tools that don't have plugins sourced from external sources, etc.
Of course, if your language and execution environment of choice don't allow this, thats another thing entirely. I know you can't do proper javascript development without an IDE - and that's the issue, actually. You shouldn't need a special editor with bells and whistles to do development, and on that point I agree with you entirely.
Zed is the closest thing I've found to meet my needs, and I do plan to try it. However it's dev container support looks to be lacking in some important ways so we'll see.
Let me save you some hassle. I test drove Zed for a week after the v1.0 release. My projects deal exclusively in dev containers. I spent more time troubleshooting issues than actually working. Things which VS Code handles transparently, like installing the support libraries to run a chrome debug session, say. Your local SSH agent isn’t forwarded into the container, so git push doesn’t work natively. That’s after you’ve had to add your project as a safe directory in your container’s git config, because it isn’t mapped to your local git config. Things which I was disappointed and surprised were not addressed prior to v1.
It will auto-install and configure any LSPs that it thinks is suitable for the code you're working on. Found that out the hard way when a new experimental Elixir LSP got added which conflicted badly with my existing installed one
There's nothing really special about VSCode here, except that it's really popular. You could just as easily attack Emacs or Vim or Sublime or [...] users by distributing a malicious extension.
You can’t attack them that easily because of the different publication method. Emacs, Vim, and Sublime have a pull model (like linux distros), not a push model. Meaning you add your repos to the package hub, you do not upload an archive to them. The Hub will pull in you changes (or the plugin manager will do so). The only way in is to take over the repo itself.
Not sure how Vim and Sublime work, but for Emacs, publishing to MELPA is absolutely a push process, where you open a PR to MELPA's repo with a recipe for your new package; and, once it's accepted, every commit to your repo results in a new package build on MELPA's servers that Emacs users will get when they update / install the new plugin.
It’s not. The developer never build a package and then upload on melpa. Melpa will fetch the needed files and build the package. It’s not truly secure, but an attacker would need to publish a new commit and wait for quite some time for people to update.
Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintainer would be quite surprised to see a new commit they’ve not approved of.
My point is, if I want to create a malicious Emacs plugin, I can do the following:
1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point.
2. Wait for people to pick up this new extension, while it's still benign.
3. Push the malicious version to my own GitHub repo. MELPA will automatically pick it up, build it, and package it.
4. Anyone updating their Emacs packages from MELPA or installing it from MELPA will pick up this malicious version.
Now, this does require that the malicious code is visible on the extension's GitHub page; I'm not sure if this would be true on VSCode as well.
> 2. Wait for people to pick up this new extension, while it's still benign
Good luck on that. Check the most popular packages and they all belong to fairly well known people in the community. If it’s something small, people usually just copy the relevant bit to their config. And rarely do huge systems pick up users without active advocacy (helm, ivy, vertico, company, magit, consult, hyperbole, emms, org-mode,…) which means collaboration and plenty of people looking at upstream.
Sure, but this is just an accident of Emacs being a much more niche product, not related in any way to the design of the package system. If Emacs suddenly gained VSCode's popularity, I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware - nothing in Emacs prevents this any more than VSCode.
> I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware
But the issue is not new users picking up unconfirmed packages. It’s about active employees getting compromised by extensions they trusted. As the nature of packages update is opaque and the default settings leave you vulnerable.
If you go on magit’s page on melpa, you get the commit id used for the build and if you wanted too, you could diff the files with upstream. Everything is transparent. Meanwhile what you got on marketplace is whatever is pushed by a token.
And another nice thing about packaging system like emacs is that they rely on peer dependencies instead of pulling their own from the internet. Which is nice, because when a bug is patched, you update that single dependency and you’re done. No need to update every package that depends on it.
Transparent doesn't mean secure. The very source of this issue was a recent NPM supply-chain attack, and you can also check the sources of any NPM package that you use. NPM also relies on peer dependencies, and this is exactly why malware spreads so efficiently in the ecosystem - just like it helps spread bug fixes, it also helps spread malware as efficiently.
Very, very few people, even in tech circles, check the sources of all of their dependencies. Sure, compromising magit's sources will be hard - but you don't need to compromise magit. Just compromise one of magit's dependencies and watch the malware spread.
Edit: in fact, you don't even need to compromise Magit's dependencies. Since the developers of Magit probably use Emacs themselves, you can probably just compromise some small Emacs package that happens to be used by someone on the Magit team, get access to their repo from there, and then you actually may be able to compromise Magit itself (depending on how strict their code review etc rules are).
Emacs has been a viable option for going on a half century now. The GNU Emacs 31 branch[0] was cut recently and is barreling towards a new release. It might be time to give it another look.
I'm not saying its package ecosystem isn't vulnerable to these kind of attacks, it is, but it's at least developed by folks with very different goals and ambitions than Microsoft.
In this case it does. You can't funnel huge amounts through a coin with usually small volume and market cap and expect any sense of anonymity or privacy. The delta makes it obvious. It would probably be visible via movements on markets too.
For smaller amounts this is not a problem for the same coin and network.
You are not responding to the debunking of your "Value doesn't have anything to do with utility" claim.
The only relevant thing I can see here is that yes, the volume is too low to provide any sense of untracability for the scenario discussed. It might for paying your VPN subscription.
