Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


You wrote this: 'Google says "not a security vulnerability", quickly fixes without attribution'.

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.


You accuse me of doing exactly the the thing you keep doing: deflecting with random stuff and ignoring the substance.

Meanwhile, if I was just a troll, you wouldn’t keep coming to this thread to prove me right.

I’ll leave it here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: