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.
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.
(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?
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.
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.
First of all, the project in question (Sunlight) is not a Google project and its author (Filippo) is not employed by Google.
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.
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.
"This is not a security issue" and "we can improve things here" are entirely compatible.
Also doesn't seem like a Google project?
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.
Let’s not turn harmless fixes into drama.
It isn't. Filippo is a x-googler that used to work on Go crypto for Google, so assumptions are easy to make.
The project seems to be sponsored by Let's Encrypt, fwiw.
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".
> akin to a "google project".
LOL, ok.
Dupe of a dupe of a dupe:
Tell HN: Google banned me for reporting CT vulns they fixed hours later - https://news.ycombinator.com/item?id=44454141 - 3 July 2025 (1 comment)
Tell HN: Google says "not vuln", fixes hours later without attribution - https://news.ycombinator.com/item?id=44456382 - 3 July 2025 (3 comments)
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.
I think "critical" is due to the context, it's supposed to be trusted software that participates in the trusted public key infrastructure.
If your seed is corrupted, the whole model collapses. There's not a ton of diversity in CT implementations.
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 not true,
1. Operator correctly runs: cat /dev/urandom > seed.bin
2. Filesystem corruption fills seed with nulls/spaces (happens in production)
3. Sunlight silently generates predictable keys from corrupted seed
4. CT log operates "normally" - valid signatures, no errors
5. Anyone knowing about corruption can recreate the private keys
What other "end-user" crypto-related app runs with a user-produced seed to generate key pairs on the fly?
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.
Why would you even do that?
Why is this flagged?
Because the title is a blatant lie.
You could have at least disclosed your current position.
"Staff Software Engineer, Google - Full-time"
That really does not read well, especially on a post that was flagged and not seen since _hours_ on the "main" website, LOL.
Very dishonest. Dismissing reports based on 'technical gotchas', but acting on them happens way too regularly and just kills responsible disclosure.
(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.
I'm not even asking for money!
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?
Chill. It is just NSA backdoor. (joke)
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.
[flagged]
Was the right outcome achieved in the end? Move on.
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.
The black market isn't going to care about it. It isn't really exploitable.