Tell HN: Google says "not vuln", fixes hours later without attribution

The Certificate Transparency system protects you from malicious HTTPS certificates. When CT logs have predictable private keys, the entire web PKI security model breaks down. This compromises every certificate the log ever signed - past, present, and future.

I reported security vulnerabilities in Certificate Transparency infrastructure that Google Chrome trusts. They dismissed them as "not vulnerabilities," made my private report public without consent, then silently implemented my fixes hours later.

The discovery:

While benchmarking, I used echo " " > seed.bin (32 spaces). Sunlight accepted this and generated valid but predictable private keys for a CT log. No warnings, no errors.

Why this matters:

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

Without checksums, even perfect operators get silently compromised. This is PKI infrastructure that protects HTTPS certificates.

This isn't hypothetical - filesystem corruption is common in production systems. Power failures, kernel panics and storage failures regulary cause partial writes and null bytes.

Google's response:

- "Not a vulnerability": https://groups.google.com/a/chromium.org/g/ct-policy/c/qboz9s8b9j8/m/B6JXa2q1BAAJ

- Published my private security report without consent

- Implemented my exact fixes hours later

  - https://github.com/FiloSottile/sunlight/commit/f62f9084016c4c377d3855471720d7d0cdea3663

  - https://github.com/FiloSottile/sunlight/commit/32cc3ea2524e89f93febb967683c6467753f484d

- Banned me for pointing out the contradiction: https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ

Bonus vulnerability:

They authenticate using User-Agent strings. Anyone can spoof these headers to bypass rate limits and overwhelm the service:

- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L176

- https://github.com/FiloSottile/sunlight/blob/main/cmd/skylight/skylight.go#L148

This is production code, trusted by Google Chrome today (https://www.gstatic.com/ct/log_list/v3/all_logs_list.json) see the "sunlight" logs.

The exact email that got me banned is here https://groups.google.com/g/certificate-transparency/c/u8SsXgSFbz4/m/14ePyeCrBAAJ - judge for yourself if it violates any reasonable code of conduct.

Has anyone else experienced retaliation for responsible security disclosure? How do we fix a system where reporting vulnerabilities gets you banned while the issues get quietly patched?