3 ms·

Google says "not a security vulnerability", quickly fixes without attribution

45 points by Eikon 1y ago

ggm 1y ago
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?
- deleted 1y ago
  [deleted]
neptuneios 1y ago
Was the right outcome achieved in the end? Move on.
- Etheryte 1y ago
  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.
  - perbu 1y ago
    The black market isn't going to care about it. It isn't really exploitable.
potatoproduct 1y ago
Very dishonest. Dismissing reports based on 'technical gotchas', but acting on them happens way too regularly and just kills responsible disclosure.
NaOH 1y ago
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 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 https://news.ycombinator.com/item?id=44456382 - 3 July 2025 (3 comments)
arp242 1y ago
"This is not a security issue" and "we can improve things here" are entirely compatible. Also doesn't seem like a Google project?
- perbu 1y ago
  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.
- deleted 1y ago
  [deleted]
  - arp242 1y ago
    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.
    - Eikon 1y ago
      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".
      - eddythompson80 1y ago
        > akin to a "google project". LOL, ok.
- eran- 1y ago
  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.
Calwestjobs 1y ago
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.
dodomodo 1y ago
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.
- Eikon 1y ago
  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?
  - dodomodo 1y ago
    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.
    - Eikon 1y ago
      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?
chaotic_human 1y ago
[flagged]
handsclean 1y ago
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.
- Eikon 1y ago
  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.
Lockal 1y ago
(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.
- Eikon 1y ago
  I'm not even asking for money!
akagusu 1y ago
Why is this flagged?
- jsnell 1y ago
  Because the title is a blatant lie.
  - Eikon 1y ago
    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.
agwa 1y ago
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-3193522205 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#issuecomment-3025355315 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/qboz9s8b9j8/m/B6JXa2q1BAAJ 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.
- Eikon 1y ago
  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.

45 points by Eikon 1y ago

ggm 1y ago

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?

deleted 1y ago
[deleted]

neptuneios 1y ago

Was the right outcome achieved in the end? Move on.

Etheryte 1y ago
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.
- perbu 1y ago
  The black market isn't going to care about it. It isn't really exploitable.

potatoproduct 1y ago

Very dishonest. Dismissing reports based on 'technical gotchas', but acting on them happens way too regularly and just kills responsible disclosure.

NaOH 1y ago

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 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 https://news.ycombinator.com/item?id=44456382 - 3 July 2025 (3 comments)

arp242 1y ago

"This is not a security issue" and "we can improve things here" are entirely compatible. Also doesn't seem like a Google project?

perbu 1y ago
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.
deleted 1y ago
[deleted]
- arp242 1y ago
  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.
  - Eikon 1y ago
    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".
    - eddythompson80 1y ago
      > akin to a "google project". LOL, ok.
eran- 1y ago
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.

Calwestjobs 1y ago

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.

dodomodo 1y ago

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.

Eikon 1y ago
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?
- dodomodo 1y ago
  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.
  - Eikon 1y ago
    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?

chaotic_human 1y ago

[flagged]

handsclean 1y ago

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.

Eikon 1y ago
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.

Lockal 1y ago

(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.

Eikon 1y ago
I'm not even asking for money!

akagusu 1y ago

Why is this flagged?

jsnell 1y ago
Because the title is a blatant lie.
- Eikon 1y ago
  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.

agwa 1y ago

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-3193522205 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#issuecomment-3025355315 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/qboz9s8b9j8/m/B6JXa2q1BAAJ 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.

Eikon 1y ago
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.