So this vulnerability isn't directly the result of using Steam, or any of the Steam profile customizations, such as avatars and profile page backgrounds. But rather, it is a vulnerability in a third-party application "Wallpaper Engine" which is available on Steam.

I recall when screen savers were a common malware vector on Windows. I suppose everything old is new again.

First thing I thought of when I saw the title was "since when does Steam have wallpapers?".

The article is at the least titled misleadingly and an attempt to sell fear.

It's not completely unrelated to Steam though. The malicious code is delivered by Steam Workshops. It might or might not be justified to put 'Steam' on the title, but it's par on HN standards (people always put 'npm' on the titles when there is a supply chain issue.)

Why do you need an "Engine" for wallpapers in the first place?

So you can have an animated or interactive "wallpaper". The malicious wallpapers in the OP are hentai games.

I use them because they look nice and with an OLED I wanted a dynamic wallpaper so I wouldn’t get screen burn in. There is adult stuff but everything I use is just video games and matrix scrolling patterns, that kind of stuff, so I can tell my monitor is on without getting burn in. I’ve got a high end desktop so can take the minor performance hit running it all the time.

Unfortunately seems like I’m going to be uninstalling it.

Opensuse (pre 11 iirc) used to have a really cool background where the lighting changed throughout the day, that probably used an engine of some sort.

The 'wallpapers' in question are pirated games made in renpy (python game engine) or rpgmaker (js based), which makes them a really good vector for malware. As another commenter noted this is a bizarrely common way for Chinese people to get porn through the great firewall.

Why would that be the only way to get porn that they don't crack down on?

Because they are not static images. That's the whole gimmick

Because it's one of the only ways to get porn in China

I'm still waiting for the new generations to rediscover screen savers.

Irrelevant comment, op said "this vulnerability isn't directly the result of using Steam", not that steam doesn't share responsibility

It said they are "on Steam" which is true. They are distributed through the Steam Workshop, which Valve runs and attempts to protect from abuse.

While it's not as high-profile as the official profile backgrounds and avatars, it's still in an area that most gamers would think was safe by default, since Valve moderates it.

Does the allow list in package.json pin to the package version, or only to the package name?

The compromise is to defer to a standard formatting tool such as prettier or pip8.

As long as the file extension changes to align with the format, that sounds great. There are far too many abuses of .json that allow comments, trailing commas, etc.

Most of the folks I caught pushing "changes" as a commit message are now letting AI write their commit messages for them. It has been a massive improvement.

This is not without struggles. Many times the changelog updates are missed. You can try to catch this in code review, but that could also be missed. So you can try to automatically verify the changelog was updated, but you can't force that as a pass/fail check since not all changes require a user facing change. Or your project maintainers simply copy the commit message and paste it into the changelog, and at that point, why not just automate it with something like conventional commits?

Could/should the changelog be considered a first-class deliverable with care and attention provided? I think so, but I'm not in a position to exert direct control over that across dozens of repos and team members.

> Many times the changelog updates are missed.

In my experience, LLMs are great at reviewing changelogs for potential gaps from a user POV (and even creating draft changelogs wholesale, if you're backfilling) based on git history.

I like this idea, but could see it working better as a git trailer to avoid adding noise to git log

The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed.

The issue is that if there was no release in between, or only a beta or similar, you now have two breaking changes indicated by the commits, although in sum there is none since the last official release.

That's true, but depends on your workflow and release strategy.

If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts.

If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.

If you have actual dependents in a SemVer fashion, then this isn’t useful for those still on the prior version. What you’d rather do is decrement the major version again because it’s compatible with the prior version again. Those dependents who already upgraded to the interim version have to consider another breaking change regardless.

And if you don’t have these kinds of dependents, then the versioning scheme isn’t important anyway.

release-please[0] allows you to do a manual version override in a commit, which would allow you to decrement the major version upon reverting a breaking change

I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch.

[0]: https://github.com/googleapis/release-please

It isn't a standard, it is a convention. You can set a standard within your team to include the ticket id in the commit message.

"Backyard" is obviously not to be taken literally. Anywhere you put one of these things is going to have an impact on the region. But perhaps you can provide some examples of places that are not in anyone's backyard?