Advanced Persistent Threat. For example, we assume the Lazarus Group is responsible for several high profile attacks. We don’t have anything close to the evidence here for direct attribution; using that as a bar I’d say the Proton attribution is pretty strong. Since my callout was security-focused, I wanted to ground it in other security terms. Your point was completely spot on and it was a great reminder to me because sometimes I forget the basics.

For folks that don’t know, there are a few bad things with the Proton response. First and foremost, you don’t rewrite main ever just from a development perspective. It usually causes more trouble than it’s worth unless you’re a team of one and no one else has ever touched your repo. From a security perspective, it’s very misleading to assume rewriting history can clear history from GitHub as I hope I’ve shown here. Additionally, anyone with a local copy of the repo from before the rewrite can use the reflog to access that history. While it won’t work for any new pulls post-rewrite, it’s still a risk for a large repo like this.

The correct way to handle this or other sensitive information being added to a repo is to use remove the file in a merge and rotate any secrets exposed. Take the hit on the chin; security is just about reducing risk not removing it. I have cleaned up plenty of repos before. Tools like gitleaks can search your active tree as well as your history for exposed secrets. Delete, commit, own the failure. Proper ignore files, meticulous review, and automated checks also help reduce risk.

Overall that’s why I think this is dumb. To me it would be a non-issue if a security-minded company had used security best practices to handle this.

Absolutely fair! The other commits in that tree for the .cursor folder match existing contributors. This unchanged PR and this unchanged PR both contain the same structure. This tree comes from this unmerged, closed PR which also matches. This closed issue, commented on by maintainers, references this tree which corroborates the other unlinked commit tree. (Edit: I stopped because I got bored; see the other unchanged issues and PRs that show a rewrite of history)

Attribution is never 100% especially when APTs are concerned. I am confident when I say there is way more evidence here showing the files officially exist and were officially part of the tree than many of the very confident yet unconfirmed APT attributions we actively rely on.

I’m annoyed because I had to go find a tree that actually had the cursor files. If there’s a smoking gun, you gotta fucking link it when you call someone out.

The irony of Proton attempting to remove it this way is that GitHub trees are permanently available. The only way to remove something once a link has been created is to delete the repo. I’d expect a security-minded company to understand that. To me that’s much more egg-on-face than vibe-coding secure applications. Neither is good; only one very explicitly highlights you don’t know shit about security.