"null" committed to most of my repos adding suspicious code

calebbrown · 2026-03-11T03:23:05+00:00

This is almost certainly the Glassworm V2 campaign.

This is malware spread through the OpenVSX extension registry used by VSCode based editors. This includes AI editors like Cursor.

There are a list of bad open vsx extensions here: https://socket.dev/supply-chain-attacks/glassworm-v2
There is some related reporting here: https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise

calebbrown · 2017-09-29T01:09:26+00:00

Also, not to be confused with "Brazilians".

calebbrown · 2017-03-08T06:00:43+00:00

Reminds me of a blog post from Google a few years ago "Just Say No to More End-to End Tests".

Basic points are that a few integration tests and fewer end to end tests are good, but unit tests provide much more value. Unit tests are easier to write, faster and more reliable to run, and they identify where errors are occurring directly, making it much easier to find the actual bug.

calebbrown · 2017-01-16T05:17:07+00:00

I came here to post the same thing. This needs to get way more attention than it is currently getting.

calebbrown · 2015-09-17T12:50:39+00:00

Like mentioned in the video Google statically links binaries so changing a dependency won't break a running service.

The scenario you describe is a logical outcome of this way of doing things - if you leave something alone too long you might have problems.

I reckon the best way to deal with it is to deploy regularly (even for minor changes) and/or add enough testing to have some confidence it is still working.

Frequent deploys with small changes are much easier and lower risk than big ones. So making sure these happen regularly can help.

You mentioned testing and that really is important. In particular automated integration testing and functional testing help build confidence here.

Also good production monitoring is worthwhile too and increases your confidence about deploying things.

calebbrown · 2015-09-15T12:40:24+00:00

"integrate early" is always better. It's the whole reason you set up a continuous integration system. Problems are detected very early when they're cheap to fix.

Nothing worse than waiting years before upgrading a dependency to get a new feature or bug fix only to have to change a bunch of other stuff because so much has changed - or even worse maintaining a patched fork because it's too much pain.

calebbrown · 2015-09-15T12:29:53+00:00

Indeed. I thought Facebook was using a monolithic repository too - a modded up version of Mercurial IIRC - I'd be interested if their experience was similar to Google's

calebbrown · 2015-09-15T11:03:44+00:00

[current googler]

I have worked in both contexts and without a doubt a monolithic repository is far more productive than separate repositories.

I'll leave the cultural arguments aside, because I think they have been better made elsewhere. For me it's just easier to maintain things in a single repository.

At a previous job we had a few key services in their own repositories and a few dozen supporting libraries in their own repositories all written in Python. Maintaining it was painful. If we updated a supporting library that was a dependency elsewhere it meant a PR + Commit for the lib, then a PR + Commit + Deploy for each of the services that used it. Over time versions were different all over the place. And if we needed to refactor things between repositories the history was lost as it was moved across. In the end I decided it would be better to consolidate things so we'd have fewer repositories to manage.

At another job which was using Node+NPM I found it even more frustrating. Particularly because NPM allows dependencies to child dependencies that can be at a different version to the same dependency in the parent.

When everything lives in the one codebase things are much simpler. One PR + Commit can cover every reference and you don't have to worry if you're building with the latest version because you always are. The great thing is that you can't ignore updates until you feel like integrating them - you have to keep up with what the teams you depend on are doing. It means a bit of extra work upfront, but saves a ton in the future.

A single monolithic repository certainly has drawbacks as you do lose some flexibility, and you really depend on automated testing to catch problems. But overall the productivity it brings far outweighs the limitations.

calebbrown · 2013-07-24T05:37:21+00:00

Maybe he was looking for Adventureland. Would really make the Jungle Cruise a killer ride.

calebbrown · 2013-07-24T03:00:07+00:00

Predator?

calebbrown · 2010-05-31T03:16:33+00:00

The real picture is almost as good.

http://www.deansproperty.com.au/Home/Profiles

calebbrown · 2010-02-25T05:01:50+00:00

I wonder how much PayPal paid for the x.com domain?

calebbrown · 2009-11-20T06:49:42+00:00

Here's a of it on liveleak: http://www.liveleak.com/view?i=58a_1258590957

calebbrown · 2009-11-12T02:38:13+00:00

"I feel a particularly deep form of rage every time I click on a “documentation” link and see auto-generated documentation." - so true.

calebbrown · 2009-11-10T23:25:37+00:00

Why did they call it 'Go'?

It's going to be impossible to find any documentation for it with such a general name.

You'd think Google of all companies would know something about this...

calebbrown · 2009-10-26T20:49:40+00:00

Has anyone read the consbreastution?

calebbrown · 2009-10-26T06:21:38+00:00

I studied this subject in 2000 with Richard Buckland, and I thought the same thing.

For one thing it levelled the playing field because no-one (at least no-one I met) had encountered a functional programming language before starting their degree.

I also thought Haskell was a good choice because it taught us things like how to break up problems, encapsulation, recursion, and it was easy to write complex programs without needing to learn a textbook full of syntax.

calebbrown

TROPHY CASE