2025-07-02 16:41 UTC: Filippo implements my suggestions
I don't know if it's a coincidence that OP emailed Filippo in the 20 hours between Filippo agreeing with my suggestions and implementing my suggestions, or if OP saw my suggestions in the Sunlight issue tracker and decided to make a mountain out of a molehill. Either way - the changes were always going to happen regardless of OP.
This is not a strong take, the "fix" doesn't completely fixes the vulnerability. Passwords or private keys are not the same as a user-provided crypto-seed without checksums. This is supposed to be critical PKI software.
It's about corruption and bit rot, not about seed length.
My finding are unrelated and started from when I wanted to benchmark his software. I wanted to know which format it expected for the seed, turns out spaces will do.
It's not about a "corrupted password", it's about that the software generates private keys on the fly based on an unverified seed input. Anyone understanding crypto a tiny bit gets that. This is first-week-of-crypto-class material
Btw, this is a project of a ex-google employee, used in chromium, that google publicly endorses; that's definitely akin to a "google project". Is it damage control yet?
Pretty interesting that you are directly involved in this project yourself but feel the need to defend the same (wrong) narrative here.
You agreeing with the claim that this is not a vulnerability, and somehow being involved in developing CT software is deeply concerning.
You messed this up in at least 5 different ways. Trying to frame this as an official Google project makes everything else you say worthless. Stay with the facts, or GTFO.
Trying to help making things better is great and the spirit of open source. Trying to create drama is useless and unhelpful.
The technical vulnerabilities I reported are factual regardless of organizational relationships. The concerning issue here is that my private security disclosure was forwarded to a public,
Google moderated venue, without consent. Then, I was banned from the same venue to prevent me from being able to defend myself. That’s the actual breach of good faith practice and was actually intended to create drama.
You apply obviously double standards to the same situation.
Exactly, the two statements aren’t contradictory. The fix was super simple, and Filippo (whom I don’t know personally) just went ahead and did it.
Also, bringing up Project Zero’s 30-day disclosure policy while complaining about someone sharing what they thought was a vulnerability report for visibility feels off. If it’s not a security issue, then there’s no reason it needs to be kept quiet. Grow up.
I have some projects "used by Google" as a dependency. Can I now expect someone posting three threads here in a day using deceitful title if I'm not nice enough to you? Will my words now be misrepresented as "Google said [..]"?
You lied to whip up outrage so you can piss an open source maintainer in the face, seemingly just to get revenge? Well done. Good job. 10/10 contributing.
This is not a strong take, the "fix" doesn't completely fixes the vulnerability. Passwords or private keys are not the same as a user-provided crypto-seed without checksums. This is supposed to be critical PKI software.
It's about corruption and bit rot, not about seed length. This is a project of a ex-google employee, used in chromium, that google publicly endorses; that's definitely akin to a "google project".
The actual issue seems to be that some tools ask the user to provide a random seed, then accept anything non-empty, even if it’s too short or otherwise obviously not random. The reporter argues this is a critical security vulnerability, Google argues this is just a usability issue. Google subsequently added additional validation to make sure it’s also the right length.
Personally, I think usability issues can have security implications. Taken to the extreme, look at RSA: technically possible to use securely, but widely considered insecure because everybody screws it up. Modern crypto libraries are all about achieving better security by fixing footguns. This issue isn’t RSA, but I bet fully fixing this issue would make a small but tangible number of insecure users secure. I think Google should have a clear and spelled out policy re usability issues with security implications, and should give this guy at least some reward, even if it’s not the “critical vulnerability” he makes it out to be.
The fact that something was fixed doesn't make it a security vulnerability, the "security vulnerability" here is equivalent to a command line tool not accepting weak passwords, defenetly something worth having, but not a vulnerability.
this is out of scope for the project, it is insane to expect every software project to deal with random file system corruptions. if this kind of thing was considered a security vulnerability we would have 100x the vulnerabilities we have now.
There's a distinction between "Corrupted seed" and corrupted PK / password. The seed is provided without validation or checksuming, generating perfectly valid keys on the fly from unknown entropy quality.
If you have bad entropy (partially or fully corrupted/weak seed), you'll generate valid-looking keys that are actually insecure.
There's a reason there's not a single "end-user" crypto-related app / cli tool or server that takes a user-specified arbitrary seed as input. That's dangerous, broken design.
BTW most common "self made crypto" misconfiguration is not discarding 0 byte data .... so just scanning for that you can get at least 10 000 sites in just US.
(standing on the gallows awaiting his execution) First time? :)
I've run into this a few times (only more so with Meta, not Google): well, they're within their rights not to pay. Purely theoretically, in my case it would be a lawsuit for violating GDPR (not hacking), but they know that there is no one to sue.
Judge Jury and Executioner, no appeal path, and no transparency on process.
Really Google, this isn't good. Yes, a breach of your code of conduct but no, not abusive, and you appear to have taken the input and acted on it without credit. That's Intellectually dishonest.
I don't know Pierre from a bar of soap. He could be a complete asshat. Does it alter the power imbalance here?
If this is the way you treat people who report vulnerabilities, next time they're going to report them to the black market, not you. It's incredibly short sighted.
Here's what actually happened:
2025-07-01 19:01 UTC: I suggest making some changes to Sunlight to improve usability of key generation and mitigate a potential misconfiguration risk with keys: https://github.com/FiloSottile/sunlight/issues/35#issue-3193...
2025-07-01 20:08 UTC: Filippo agrees with my suggestions: https://github.com/FiloSottile/sunlight/issues/35#issuecomme...
2025-07-02 12:20 UTC: OP emails Filippo claiming to have found a vulnerability in Sunlight
2025-07-02 13:03 UTC: Filippo replies to OP explaining why this is not a vulnerability (an assessment which I agree with entirely): https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9...
2025-07-02 16:41 UTC: Filippo implements my suggestions
I don't know if it's a coincidence that OP emailed Filippo in the 20 hours between Filippo agreeing with my suggestions and implementing my suggestions, or if OP saw my suggestions in the Sunlight issue tracker and decided to make a mountain out of a molehill. Either way - the changes were always going to happen regardless of OP.
reply