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)
Also doesn't seem like a Google project?
The project seems to be sponsored by Let's Encrypt, fwiw.
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.
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.
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?
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?
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.
If your seed is corrupted, the whole model collapses. There's not a ton of diversity in CT implementations.
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.
"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.
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.
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.
Trying to help making things better is great and the spirit of open source. Trying to create drama is useless and unhelpful.
You apply obviously double standards to the same situation.
I'm talking about this. In your "answer" you talk about something else, that just has nothing to do with what I was talking about.
You do this in other threads here. This isn't helpful, or constructive.
Nobody will, or can, help you while you behave like this.
Meanwhile, if I was just a troll, you wouldn’t keep coming to this thread to prove me right.
I’ll leave it here.
ggm•7mo ago
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?