Live data from Hacker News

Over 100k Infected Repos Found on GitHub

apiiro.com

51–60 of 187 posts

Re: Over 100k Infected Repos Found on GitHub

#51
post #48

For NPMs you can mitigate executing malware with `--ignore-scripts` https://blog.uirig.com/getting-rid-of-npm-scripts

instead the downloaded malicious code runs in prod. maybe, if you are lucky, it does something strange in CI and you can catch it.

the only real solution is a reputation system (like https://github.com/crev-dev/cargo-crev ), which of course is unfortunately barely used

Re: Over 100k Infected Repos Found on GitHub

#53

I've noticed these too by randomly stumbling over similar repos. I usually don't run code from random repos, but now I have reached a point where I spin up a sandbox vm even when I trust the repo and the owners. If you are a dev today, you should probably have at least thee firmly separated environments for work, hobby and personal stuff.

Sounds like a good reason to use Qubes OS, where everything runs in VMs by default (my daily driver).

My experience with Qubes OS had been so so last time I've tried it.

Have they managed to get rid of Xorg and the terrible screen tearing issue that should be a thing of the past in 2023? I remember there was a project named SpectrumOS that tried to do something similar to QubesOS but with nixos, crosVM and wayland. AFAIK the project stalled.

I am using a sort of middle ground between traditionnal desktop and QubesOS. I run a number of VMs on my machine for different purpose and use waypipe to start apps as individual windows on the main desktop. I don't really have the copy/paste separation that QubesOS has, nor a separation between host and network VM but at least I can separate duties, filesystems and seamless windows showing on only one desktop. To distinguishes the browser and terminal windows I use different themes.

Re: Over 100k Infected Repos Found on GitHub

#54
Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository.

When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk.

Github should figure out if their product is "a repository for everybody" or it is "I can trust this code".

E.g. look at the official PG JDBC: nothing here couldn't be reproduced by a spammer. How do I know that I can trust this and that it is not an infected repos? https://github.com/pgjdbc

Re: Over 100k Infected Repos Found on GitHub

#55
post #51
post #48

For NPMs you can mitigate executing malware with `--ignore-scripts` https://blog.uirig.com/getting-rid-of-npm-scripts

instead the downloaded malicious code runs in prod. maybe, if you are lucky, it does something strange in CI and you can catch it. the only real solution is a reputation system (like https://github.com/crev-dev/cargo-crev ), which of course is unfortunately barely used

Correct, the above mitigation is only for malware on the dev laptops and build servers. IOW, it doesn't prevent injecting the malware on your program when compiling it.

Re: Over 100k Infected Repos Found on GitHub

#56

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

Although finding over 100k infected repos is not good, it does not mean github is failing because the kind of programmer who would include an infected repo can find many other ways to create an insecure product if there weren't infected repos on github.

Re: Over 100k Infected Repos Found on GitHub

#57

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

It’s possible to get a verified badge on your org page if you prove you own your domain. This can go a long way to improve trust. Your example just seems to have not done it.

Re: Over 100k Infected Repos Found on GitHub

#58
post #21

Earlier quoted context omitted.

> there's no real reason to run everything on the one system you happen to be sitting at theoretically. in practice the added latency is a problem outside of casual use. update: clarification seems to be neccessary as i was talking about audio/video/gaming type workload, NOT office stuff

The latency issue is increasingly disappearing or at least becoming negligible in most population centers. For example, in my country almost every company uses Citrix (no affiliation) or similar workspace solutions, where the entire workstation is virtualized in a data center and you only access via a thin client. Entire nations of people work like this already. Cloud gaming will probably be the next frontier in this…

> The latency issue is increasingly disappearing or at least becoming negligible in most population centers

I believe that thats your experience. Its not really because the technology is improving though, its because you're growing older.

The latency is absolutely horrendous, and anyone thats used to a decently performing system will not agree with your opinion.

As a simple example: i can easily code 6+h with no break on a good system, with these mainframe system i'm gonna take a break at least every hour because the fatigue builds up so quickly. Its every little interaction, simple input that doesn't appear for 50+ms, switching owrkspaces thats delayed for 150+ms.

Re: Over 100k Infected Repos Found on GitHub

#59
post #55
post #51

Earlier quoted context omitted.

instead the downloaded malicious code runs in prod. maybe, if you are lucky, it does something strange in CI and you can catch it. the only real solution is a reputation system (like https://github.com/crev-dev/cargo-crev ), which of course is unfortunately barely used

Correct, the above mitigation is only for malware on the dev laptops and build servers. IOW, it doesn't prevent injecting the malware on your program when compiling it.

Prod is bad, but stealing signing keys or credentials is worse.

Re: Over 100k Infected Repos Found on GitHub

#60
post #21

Earlier quoted context omitted.

> there's no real reason to run everything on the one system you happen to be sitting at theoretically. in practice the added latency is a problem outside of casual use. update: clarification seems to be neccessary as i was talking about audio/video/gaming type workload, NOT office stuff

The latency issue is increasingly disappearing or at least becoming negligible in most population centers. For example, in my country almost every company uses Citrix (no affiliation) or similar workspace solutions, where the entire workstation is virtualized in a data center and you only access via a thin client. Entire nations of people work like this already. Cloud gaming will probably be the next frontier in this…

My experience is the opposite on this. I have had my first job where Citrix was used for day-to-day tasks in 2023 September, and I would estimate the latency was around 300-400ms. It was very noticeable and frustrating, especially when coding. I would be typing code and I knew I made a typo, but had to wait for the characters to actually show up on the screen, before I knew how many characters to backspace over. Switching windows and workspaces felt sluggish. This was with both the server and the client being in the same country.

It was a bad enough experience, that it is now a part of my interview questions if the company works through remote desktop solutions.

Post reply on HN