1. Set a default label for issues (e.g. “autoclose”)
2. Make your auto closing and locking logic based on that label (eg the label-actions github action)
3. As a maintainer, remember to remove the label when creating an issue!
This seems to me to be the most likely explanation. Someone important and/or rich wants something memory-holed and the archive sites are amongst the last to contain the content, so someone else is creating a facade organization as an attempt to get it taken down in every way possible. And yes it's entirely possible that the archive sites have multiple "enemies".
What was even worse than there being dupe ChatGPT apps in the Mac app store was that Perplexity and Gemini both recommended installing chatgpt dot macupdate dot com as if it was the official app.
The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is:
1. An attacker had write access to the tj-actions/changed-files repo
2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate
3. Important: this spoofing of commits wasn't done to "trick" a maintainer into accepting any PR, instead it was just to obfuscate it a little. It was an orphan commit and not on top of main or any other branch
4. As you'd expect, the commit showed up as Unverified, although if we're being realistic, most people don't look at that or enforce signed commits only (the real bot signs its commits)
5. Kind of unrelated, but the "real" Renovate Bot - just like Dependabot presumably - then started proposing PRs to update the action, like it does any other outdated dependency
6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds
7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design
>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design
IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") and are just surprised if you call out the flaws.
It's one of many practises adopted because everyone does it but without basic awareness of the tradeoffs. Semver is another similar case of inherited practise, where surprisingly many people seem to believe that labelling software with a particular string magically translates into hard guarantees about its behaviour.
I theorized about this vulnerability a while back when I noticed new commits didn't disable automerging. This is an insane default from GH.
EDIT: seems GitHub has finally noticed (or started to care); just went to test this and auto merge has been seemingly disabled sitewide. Even though the setting is enabled, no option to automerge PRs shows up.
Seems I was right to worry!
EDIT2: We just tested this on GitLab's CI since they also have an auto-merge function and it appears they've done things correctly. Auto-merge enablement is only valid for the commit for which it was enabled; new pushes disable auto-merge. Much more sensible and secure.
Tags can be signed, and the signature can be verified. It's about as easy as signing / verifying commits. One can even make signing tags as the default option when creating tags.
This won't help in this case though, because a legitimate bot was tricked into working with a rogue commit; a tricked bot could as well sign a tag with a legitimate key.
"Immutable tags" of course exist, they are commit hashes, but they are uninformative :(
> 6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds
I'm not sure how this could exploited by just making a PR, unless you for some reason have secrets enabled for builds by unknown contributors, which obviously would be a mistake. Usually, only builds using secrets only run on certain branches which has a known contributor approving the code before it gets there.
> people mistakenly assume that git tags are immutable
If you're distributing a library on GitHub used by many other people/projects, then you really need to setup `protected branches` and `protected tags`, where you can prevent changes somewhat.
> I'm not sure how this could exploited by just making a PR, unless you for some reason have secrets enabled for builds by unknown contributors
In this context the renovate bot would be making the PR to a repo it had been installed on, making it a trusted contributor able to trigger CI builds on its PRs.
Neither Branch Protection nor the newer Rulesets allow to protect secrets from someone with push acces to the repo. From what I understand, only environment secrets provide this feature (and have the drawback that you can't share them among multiple repos in the same org without copying them everywhere, although you can script the copying with the github api)
Thanks for taking the time to comment. Not that it wasn't there before this, but this incident highlights a lot to take into consideration with respect to securing one's supply chain going forward.
Thanks for this writeup! It seems like #1 was the real weakness. Have you identified how the attacker was able to get write access to tj-actions/changed-files? Did this discovery result in any changes to how people can contribute to the project?
Unlike Instapaper, which focuses on saving full articles for reading, PostPocket is designed for quickly saving and organizing content via share extension from any mobile app, allowing seamless capture without interrupting your scrolling. PostPocket saves links and associated metadata rather than the full content to ensure privacy and data security.
It deleted 100s of files, most of which were Jest test files, and potentially all of which were a mistake. I restored them all with `git restore $(git ls-files -d)`.
I then ran `tsc` on the remaining _modified_ files and `Found 3920 errors in 511 files.`
Obviously at that point I had no choice but to discard all changes and unfortunately I would not recommend this for others to even try.
You need a valid tsconfig that defines the scope of the project and it seems renovate’s tsconfig doesn’t meet this requirement. You can always --skip manually as an alternative option.
Renovate's TS tooling seems to work fine otherwise, and for ts-remove-unused as a new tool wanting to get adoption then you should be aiming to work the way your users already work, and not fail + tell them that they are the ones which need to change.
BTW the VSCode extension which someone else linked to discovered everything perfectly, which is another hint that your tool needs to improve, not your users.
Even if tsconfig.json was very important, and the users are all wrong and you're right, the only thing your readme says is: "The CLI will respect the tsconfig.json for loading source files." which is insufficient.
Most transformations like this are not possible with pure static analysis and require some domain knowledge (or repo-specific knowledge) in order to pull off correctly. This is because some code gets "used" in ways that are not apparent i the code.
I'm surprised to find there's not more demand for "back to back" travel wifi routers, e.g. so you can connect once to a hotel wifi and immediately all devices are connected via the router's own wifi. This is useful not just for working around device limits but also for simplicity of setup when you have kids.
I own one and tried it for a business trip.
It's a cool nerd-toy. It's not cheap and not always easy to setup for anyone who is not technically savvy.
I like it, but I wonder if I want to carry it when I go carry-on only in Europe. I guess most people will trade some privacy and inconvience for weight- and cost-savings.
If you have a non-artificially-limited android phone (i.e. rooted), you can just open a hotspot with everything going thru your wireguard vpn back to home.
If you have stock android or IOS, then the real owners of your device won't allow you do this, since they get location data from your network on all those devices.
Visicom really pumped the ManyCam lifetime upsells. I found 15 emails over an 18 month period in 2020-2021 with them pitching lifetime (which I eventually bought). An example email text they used is:
> Upgrade now to ManyCam Studio Lifetime for only $39 and get access to all the future versions and updates, forever!
What they presented to the user was unequivocal. In a just world, the company who sold ManyCam (Visicom Media) should not be able to get away with this.
> On June 30, 2022, we entered into a License Agreement with Visicom (the "License
Agreement"), pursuant to which we agreed to distribute, at the discretion and
direction of Visicom, a specified number of ManyCam software updates to certain
license holders to whom Visicom has previously granted a "lifetime" license to
ManyCam software. As consideration for distributing the software updates,
Visicom paid us an initial upfront nonrefundable payment of $65,000. The License
Agreement provides that Visicom may purchase additional licenses at prices
specified therein. Other than providing a one-time, limited license to Visicom
for the distribution of ManyCam software updates pursuant to the terms of the
License Agreement, we do not have any obligation to provide support or service
to the licensee end users.
That pumping might have been seen as a warning that the company either does not intend to support the product much longer, or has doubts that it will be able to do so. And while I agree with your final sentence, unless Visicom was careless, the actual license agreement, which supersedes the promotional claim, will have permitted what happened and so essentially revoked the offer. Caveat emptor!
reply