I think you're answering a different objection than they're making. Their concern is that people will choose to spend 8 hours on your 4 hour problem but then tell you they only spent 4. Then you'll think they're a leet hacker because their solution is so awesome and they did it so fast.
+1 to this. Other than people's reflexive anger or fear about AI coming for their code, I don't see anything to suggest that these are bugs that are due to the inclusion of AI vs bugs in a program with a bunch of complex interop with the filesystem and network.
Yeah, nothing to suggest that here. We went from some commits every so often (because rsync was basically finished software) with a handful of issues a month, to "a bajillion Claude commits then a release" with a pile of issues within weeks, at least one of which is about how the goddamn thing doesn't build.
I can't possibly see a correlation.
Weird how 3.4.2. didn't have a similar deluge of issue reports, though.
In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback.
Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.
> it's not a fact that the release does not include other regressions and [...]
Are you listening to yourself? The same exact thing also has applied, applies and will continue to apply to manually written code, in perpetuity. There's nothing new under the sun here; regressions happen when there's change, and the only way to mitigate is to have healthy feedback loops.
Do not going harassing developers because you think they are doing it wrong. If you can do better and don't want to actually contribute to the upstream you are always free to fork it.
No. It's not important. It's actually pretty shitty to go around looking for projects and then telling the maintainers you disagree with how they develop.
Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing. I absolutely want no AI slop in my commercial products that I pay money for, but your feedback is not important to people you are not paying to develop software for you. They gave away not only their software but the source code for free; if you have a problem with it, fork it. Which is something you can do with their generous allowance, and that is an allowance any maintainer can instead choose to not bother themselves with if publishing their code for free leads themselves to dealing with entitled internet commenters harassing them with complaints.
Reminder that CVD is a standard (in the same way that Test Driven Development is a standard approach that someone might choose), not the standard (something that everyone must or should do). Attempting to frame CVD as "responsible disclosure" is at attempt to staple a value judgement onto that approach.
Also, for software like Windows where researchers find vulnerabilities by inspecting software locally, the idea of prosecuting a US-based researcher for disclosing a vulnerability to the public is laughable and would not succeed.
More loosely, the fact that they deem this to be an appropriate action when it comes to their own interests would seem to condemn them if they refuse to take it when it comes to others’ interests, particularly those with whom it has a relationship of trust in any capacity.
1. Section 230 was largely enacted in 1996 to solve the 1995 ruling that "because Prodigy had taken an editorial role with regard to customer content, it was a publisher and was legally responsible for libel committed by its customers" (i.e. one of the biggest purposes of section 230 was to allow companies to make editorial decisions without causing them to become legally liable as a result).
2. The law was "designed to override the decision…, so that a service provider could moderate content as necessary and would not have to act as a wholly neutral conduit."
3. However, Trump has challenged that, including with Executive Orders, although I don't think Trump's rationale is well thought through, including because he explicitly complained that his posts like "Any difficulty and we will assume control but, when the looting starts, the shooting starts" being taken down was a specific example of why 230 should be revoked.
4. And some think the opposite as well, such as Democratic leaders who "believed that Section 230 led the companies to fail to take any preemptive action against the people who had planned and executed the Capitol riots" for example.
> Section 230 allows for web operators, large and small, to moderate user speech and content as they see fit. This reinforces the First Amendment’s protections for publishers to decide what content they will distribute. Different approaches to moderating users’ speech allows users to find the places online that they like, and avoid places they don’t.
Is this sarcasm? Or are you saying that the onus of providing proof is not on the those making the claim, but instead that the onus of proof is on those who did not make the claim?
> Sure you can provide an alternative explanation?
In terms of a possible explanation for why GitLab would take an action, was it considered whether the (disturbed?) user violated GitLab's Terms of Service? Is the assumption that GitLab didn't just enforce their ToS, but that they're instead more likely to be secretly acquiescing to backroom bullying between companies over specific users?
Stripe has a customer's bank saying "the customer says they didn't make this payment" and you saying "the customer told me they did make this purchase and got the item and they're making fun of me".
They have no way to know if your evidence is real, any more than the bank has a way to know if their customer's evidence is real. Either one (or both) of you could be full of shit.
In that world, what would you like Stripe to do better?
What do they feed into their Radar machine learning system? surely there are lots of signals to use here. I'm not saying take only my word and ban this customer forever.
But they have my record as a merchant (successful charges, chargebacks, disputes etc), they have the payer record as a consumer (payments, chargebacks etc), when a merchant submits a dispute, they provide evidence. I provided evidence from DHL that the product was delivered.
No single piece of data is enough on its own, but Stripe is in a perfect position to use all those pieces to be able to better detect fraud.
According to payment networks, that chargeback was entirely legitimate
That's why it doesn't get fed into any fraud prevention system. Legitimate chargebacks shouldn't be used to prevent transactions.
You are mad that what you claim to be a flagrantly fraudulent chargeback was approved. Who approved that chargeback, because that's where your actual anger should lie. Ban that bank/provider or whatever and move on with your life.
There's no fraud prevention in this. Payment networks purposely side with the customer here, it's a large part of their business. People use credit cards in part because of the safety and security they provide. They aren't going to suddenly abandon that system because you got scammed out of $30. They won't even do it for companies that get scammed out of millions of dollars a year. Ask me how I know.
If you don't like this system, you are free to stop accepting credit cards, and lose all that business. Most merchants are happy to lose money here and there to facilitate their business.
You insist that stripe's antifraud system should be treating this as fraud, but the process that decides what is fraud or not has decided it is not fraud. This should not be automated in any way. No system tries to automate this "problem customer prevention" because it's a million times harder of a problem than just fraud prevention, likely to ban just as many good customers as bad (because of the probabilistic nature of fraud prevention), and not even remotely worth it. Plenty of companies don't even try to fight it, because then at least you save the $20 chargeback fee.
If you have a problem customer who is more trouble than they are worth, YOU ban them. This customer might have never scammed any other merchant, and those merchants don't want to lose good business because you are nettled over getting scammed.
Yeah I totally get what you’re saying. It’s true. Still find it frustrating as a tiny merchant because it’s just too easy to get scammed and the system seems skewed against you.
> Plenty of companies don't even try to fight it, because then at least you save the $20 chargeback fee.
That’s sad in my opinion. It shouldn’t be the norm. Stripe support encouraged me to file a dispute and submit evidence but next time I prob won’t bother.
I personally find it disappointing that Stripe is in a position to do something about it but prefers the status quo that clearly allows such fraud to continue.
Based on the quote you provided, the CSR was very specific that what they don't use is merchant-provided evidence. They didn't say they don't leverage information about chargebacks or other disputes.
Even in the post you're wishy washy about what you want. They offer a product that does enhanced fraud detection but you don't like that. You correctly call out that there's major risks with taking a merchant's report and using it to flag a user's future transactions.
Again, this works when your userbase is a small group of highly technical people who already have social connections to each other. But then again, so would just swapping Signal security numbers.
It completely and totally collapses in the face of non-technical users or broad adoption, which is one of multiple reasons that PGP remains a thing that a small set of people use.
Just to be pedantic about this: it does not in fact work; PGP has failed those kinds of user groups and platforms over and over again over the last 3 decades.
And yet many of the highest risk systems that exist, the whole foundation of the internet, several governments, major corporations, and thousands of high risk individuals rely on it because centralized options will never be agreed to by all parties, for good reason.
I have lost count of the orgs I have personally trained to use PGP properly in recent years.
In spite of your claims, PGP solves the problem it was designed to solve for the groups that need it most and the tooling is getting rapidly more accessible to a wider audience with more development energy today than it has ever had.
This is not 2016 PGP we are talking about anymore.
That's a weird thing to say. Yes, it is? What are you claiming is different about it? In fact, there are ways in which it has regressed from 2016's incarnation.
A renewed IETF working group that aggressively deprecated legacy ciphers and mandated modern ones with optional PQ crypto support (RFC 9580). Lots of actively developed rust implementations like rPGP, rsop, rpgpie, sequioa. Easy key provisioning and backup with smartcard support via keyfork. Smartcards with rust firmware by Nitrokey. Modern key distribution and trust bootstrapping via openpgp-ca, hagrid, keyoxide, etc.
GnuPG is admittedly garbage, but also that has not been a valid implementation of PGP specifications for a while and no one should use it anymore. PGP != GPG
I would strongly suggest taking a hard look at the last decade of thankless work going on to modernize the PGP ecosystem we all rely on directly or indirectly.
Currently writing up the above and a lot more in detail to refute years of outdated rhetoric on this topic so we can start having more useful conversations about it.
It's thankless because it's a bunch of folks at the county fair running around putting lipstick on all the pigs.
Having a bunch of implementations of an omnibus package that tries to be a crypto swiss army knife, written almost exclusively without the input of cryptographers, is actually not a desirable goal.
And none of the back seat drivers ever have alternatives to suggest that solve the same problems while having bothered to endure the IETF standardization process, and thus PGP will continue to be the trust foundation of the software supply chain of the internet for the forseeable future.
This fragile network we all use is made of a mountain of pigs that continually need their lipstick reapplied by people that do it for free or near free out of a desire to keep the whole thing running for everyone.
Said people even do it for the users that stay at safe distance pointlessly saying "We should go back in time and build it differently in unspecified ways!".
> Is your pitch that the people who call out problems with PGP don’t have suggested replacements for workflows?
Yep. I have read every single blog post I can find from critics. Most several times. As have most people that work on this stuff. Some were partly relevant when they were posted and even less relevant today. All of them completely missed the boat on the problems PGP solves that none of the alternative do, or have any serious suggestions for migration paths or standards changes.
I will be quoting most of those posts in a blog post in the next couple weeks on https://distrust.co.
Most of them have corporate alternatives to sell you which have no chance of adoption by standards bodies.
There's like, a whole section on https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... that's specifically recommendations. The only ones that are "corporate" are chat (where PGP's UX and security model are absolutely horrendous in ways that both prevent mass adoption and make it comically easy to screw up, and where most of those problems are nearly impossible to resolve in a federated system) and I guess backups, if we consider Colin Percival to be "corporate" when he puts on his tarsnap hat.
Ah yes. That post. People send it to me all the time. It is my favorite.
It proposes that dissidents and security researchers from all countries from a wide range of backgrounds and beliefs on privacy, should all just accept the terms of service of their pick of two US based surveillance capitalism mega-corporations, trust they do not have any insiders or vulns, then reveal their identity to cell carriers in most countries, to get signal up and running, whose terms of service they must also accept, and then with the help of two corporations and their proprietary software supply chains, they can then submit an encrypted security vulnerability.
I legitimately laugh every time at the US corpo-brained takes in posts like these.
TL;DR: "Just let the US tech giants handle all identity and communication for the whole internet. What could go wrong? Super secure companies with great uptime like Microsoft GitHub can sign our commits for us and of course Google and Apple pinky swears to disobey executive orders to serve tampered updates of Signal to select devices. It will be fine."
The people that use their PGP keys to sign and securely distribute damn well near every binary that powers the internet are mostly in Europe, and not big fans of letting centralized and mostly proprietary US institutions control their online identity, let alone trusting them to not use a supply chain attack to read their private security correspondence. I for one have found a pile of serious vulns, including in GnuPG, and I do not have a Signal account and never will as I disagreed with the terms of service of Apple Google and Signal. Anyone that does not want plaintext disclosures would be wise to publish PGP keys for people like me. Thankfully most major tech firms still do, even if only to appease non US citizens and my fellow decorpoed americans.
Encrypted email is the only neutral decentralized and IETF standard comms tool we have. I say that as also a big fan of Matrix and would love to see it or something decentralized like it standardized but right now email is the standard so the snowdens and security researchers of the world should use PGP with modern ciphers and learn how to do it offline when doing high risk comms.
Even so, on the other side of this, having setup bug bounty programs for many orgs, the PGP encrypted/signed submissions from reputable folks were always the really spicy shit I would not want anywhere near a modern smartphone, and I would always decrypt them offline with a smartcard for good reason. I would not even consider being party to a bug bounty program that does not publish a PGP key to be maximally inclusive, even if they hate PGP.
Also re tarsnap. It does not even support smartcards, so just shove your private key for your entire filesystem in system memory, and back it up to a conventional password manager I guess? WTF.
Meanwhile with PGP you generate a key on a smartcard, you provide the public key to duplicity, and you can do backups without ever exposing your private key.
The alternatives suggested are strictly worse by any metric, and fail to understand the threat models of existing solutions.
GnuPG is not the final say for PGP any more than IE6 was the final say for the web. Migrating off IE6 took a while and so will migrating legacy systems off GnuPG. New users of PGP are thankfully mostly using new gen reasonably secure tools.
Just like IE6, GnuPG abandoned the global standardization processes and in doing so forced an expensive migration to successors.
Global changes on the internet take decades in part because of all the people far removed from the process spreading outdated information and demanding we give up on standards and move the whole world to centralized solutions that do not even solve the same problems, like Java Applets, Adobe Flash, or Signal.
Meanwhile those standardizing and rolling out longer term solutions roll their eyes and keep doing the work.
If everyone is moving to new software, in a migration that is barely 5% underway, why would you migrate to PGP of all possible cryptosystems? It's 2026.
I'd pose this challenge to you: find the most reputable cryptography engineer or academic cryptographer you can find that believes this is a good idea. I'd be interested if you could find even one. Fair warning: some of my confidence talking down PGP comes from knowing what the conventional wisdom among cryptographers is about the PGP cryptosystem.
New software that is compatible with any keys generated with good-enough ciphers from the last decade. Compatibility wins.
If we are going to play the appeal to authority game, I could just as easily challenge you to find any willing to publicly point out any serious issues with the current PQ focused OpenPGP standards with implementations using libraries by accomplished cryptographers. I am sure they would appreciate constructive feedback. Encourage them to join the specification process and recommend specific alternatives and migration paths.
I also wonder if we could find any that would not scrap TLS DNS and a lot of IETF protocols that run the internet today if they could. Decentralized protocols are messy but anything that tries to replace them without first taking the time to understand the current uses and migration path has no hope of success, and that is brutally difficult political work full of careful compromises.
Famous cryptographers have long advocated for things like tcpcrypt, and I even agree with them, but it will probably never happen. Too disruptive. We are still rolling out IPv6 FFS. When faced with an established global internet, compatible lower disruption migration steps are the only way forward as most experienced security engineers would begrudgingly agree.
Cryptographers should absolutely focus on the security of the ciphers, but when it comes to applications, and human privacy and security goals, and human to human trust bootstrapping protocols, the conversation has to get a lot wider. It is normally dominated by security engineers like us close to the hands on use cases, and the people doing the hard work in the working groups and tool development circles that understandably wish to quietly read different takes from a safe distance.
Cryptography basically always explodes at the joinery. One of the guiding principles of modern cryptographic tools is designing implementations that do not have footguns, where the default behavior solves the default threat model and dangerous things are outright impossible. This has been apparent in the string of GPG security failures over the past several years. It's not that somebody breaks RSA or AES. It's that the tools willingly emit bad data because of bad error handling, and then users are told they were holding it wrong and it's their fault for choosing a bad implementation.
Maybe it's worth asking if the reason cryptographers aren't engaging with the work to "modernize" PGP, and that instead we're seeing them building and shipping individual focused solutions to specific workflows, is perhaps because their constructive feedback is akin to ~"you are fundamentally trying to prop up a house of cards that should not exist"
So you are saying that the solution is that we go to the majority of active and reputable PGP keyholders, Linux maintainers, and tell them to stop signing the binaries that run the internet, and just yolo, because that worked so well for NPM?
I’m saying several things, but since you’re really focused on Linux package signing, I’m saying about that: PGP is a bunch of theatre there and distros should use minisign instead.
Linux package signing is a great example of where PGP is goofy. Users of Linux distros get their root of trust by downloading a keyring from the exact same place they download the distro ISO. To a rounding error, no users are checking a trust path from them to a distro maintainer, nor does the trust path between one maintainer and another matter.
Distros are themselves centralized entities. They already run bug trackers and forums and centralized package repos that necessitate an authentication system.
So PGP effectively becomes a clunky behemoth whose output is just “every package has a signature that is checked against a centrally curated set of keys that get shipped around to users”.
> PGP is a bunch of theatre there and distros should use minisign instead.
Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
Minisign is strictly worse in every way. Your camp will never convince Linux maintainers to switch with this pitch.
Many of us actually do verify the web of trust, extensively. I have many Linux maintainers in my own keychain independent from their usage in linux distros. Minisign has no such key distribution and accountability system.
> Okay so drop the IETF standard, web of trust, smartcard support, and external key discovery mechanisms to prove the whole keychain was not swapped out with a fake one, and just have everyone generate minisign keys exposed to system memory with no trust link backwards, and then sign things with probably the same algorithms. But then we cannot sign commits or code reviews with minisign because non standard, so i guess use ssh keys for those, and then maintain multiple keychains for each person.
At this point I can only conclude you are a troll, but if you are actually serious, I challenge you to prove it. I put in the work in the community for my side of this debate.
I would suggest you pick one of the mainline Linux distros that relies on PGP and make a detailed RFC with a plan to downgrade their security to your non standard minisign/ssh solution with private keys exposed in system memory as you propose, and make a convincing case why it is worth it and what advantages they get for doing so.
Let me know if you do. I am sure it will be a great case study.
So 0.1% of the internet is protected by Ed25519 signatures because of this move. Meanwhile PGP has had Ed25519 support for years, with hardware security key support.
OpenBSD does fantastic work, but you and I both know it will never have any significant adoption on the web at this point.
Try to convince an actual Linux distro running any significant portion of the web they should stop using Ed25519 via PGP smartcards and use Ed25519 via signify exposing their keys to system memory (and thus malware) instead, with no key discovery protocol, for unspecified reasons.
Would love to see a threat modeling case for that.
At this point you have shown your hand. You hate PGP so much you would make security for everyone worse to get rid of it. There is no reasonable threat model to support your position.
I'm going to take "the appeal to authority game" as an agreement that you think it's unlikely you'd find such a person to vouch for a modernized rebirth of PGP, or really any continued use of PGP.
I could name a few off the top of my head, some of which have audited my teams work, but I do not want to put specific people on blast. Most cryptographers I know tend to prefer math to internet controversy and I do not blame them.
I have dozens of more examples of high risk orgs with cryptography teams relying on PGP I am compiling for my post right now. Added a bunch of extra ones just for you.
Honestly from my side of the table, it is the anti-pgp camp that appears to be the loud minority. The world quietly runs on "dead" PGP technology so deeply that any calls for a complete replacement without any compatibility or trust transition path are clearly under-researched and should not be taken seriously.
I have a hard time imagining many cryptographers deeply aware of the impossibility of any rapid transition away from PGP would suggest we abandon the migration to secure modern ciphers now.
A lot of people would like to -eventually- move away from openssl too, myself among them, but not updating to openssl 4 and beyond in the short term would be a world burn kind of move.
They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.
reply