thesmokingman

I don’t think you’re using straw man correctly.

You’re naively referring to how consensus should work while completely ignoring both the well-defined attacks I referenced and the reality of large actors in a consensus network. You don’t know what you’re talking about or you don’t understand how the theory works or you’re possibly just being obtuse. No matter what, this is pointless. Good luck.

If login tokens are stored on a public ledger replay attacks write themselves. Public or private, keeping every login token ever is a horrible audit mechanism and doesn’t scale well. At scale, speed to generate becomes a concern. Not at scale, something lighter is faster.

A normal database scales better than a license blockchain and doesn’t require extra computation to write. Audit logs and hashes prevent extra edits. License files signed by a central authority don’t require a database and the central authority is functionally equivalent albeit less expensive than a blockchain.

I am still interested in a good use for the tech. I have yet to see one that is genuine.

If any of it is rewritable, none of it is immutable. You can’t have it both ways.

“You just don’t know” doesn’t answer my question. A private blockchain, by design, is already owned by its largest actors.

I don’t know that it is, though. Can you show me form of blockchain in the real world where this doesn’t apply? Saying large actors can’t affect a specific piece of internet technology, so far, is rather like teaching physics without friction. It’s nice and fun and easy to understand but completely ignores the reality of any implementation.

Go ahead and prove me wrong. Show me blockchain implementations that are immutable post append. On my end, we can talk about Bitcoin forks. We can also talk about the current state of consensus mechanisms, each of which has the explicit ability for large actors to rewrite history in their favor. Even Monero is susceptible because this is fundamental to the blockchain in any form. It’s been a huge reason why I make sure I get paid up front for any consulting I do in this space.

What exactly are some of the use cases for an infinitely growing, append-only database built primarily so its largest users can rewrite history at will?

The pyproject.toml spec is ten years old. Python 3 is almost twenty years old. The community standard moved within the last five years. Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry. If you’ve got GitHub workflows that’s the standard anyway so you should be running something like act locally. Static typing redundancy is a waste of compute.

If you’re going to be an asshole, make sure you can back everything up. You can’t so I’d recommend taking a breath and going outside.

Edit: I looked through your GitHub and even though your profile name is “msftcangoblowm” you don’t seem to use .yaml but instead the YAML extension Windows devs use.

If you really want to be creeped out, check out Flesh and Code. Not only will you feel incredibly uncomfortable, you’ll question who the fuck thought it was a good idea to release such an uncritical (as in lack of research and investigation not negative) of AI relationships.

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.