Hacker News Reader

Comment by kimsterv | Hacker News Reader

Honk! I represent Google on the OpenSSF, and help lead our Google Open Source Security Team. We've kicked off several projects inside the OpenSSF, and contribute to several other related efforts.

Here's a non-exhaustive list: Security Scorecards (https://github.com/ossf/scorecard): auto-generated security checks for OSS, Criticality Score (https://github.com/ossf/criticality_score): auto-generated criticality score for OSS, Package Feeds (https://github.com/ossf/package-feeds): watches package registries for updates, malware analysis tools, SLSA (https://github.com/slsa-framework/slsa): proposal for a supply chain integrity framework, Sigstore/Cosign (https://sigstore.dev/): code signing made easy!

We are also investing and exploring different efforts for improving security of critical OSS projects, and making it sustainable! If any of these projects sound interesting, come join us in the OpenSSF Working Groups!

*edited formatting

View on HN

tbh, the Criticality score has done a lot to make me mistrust the quality of pretty much everything associated with it (cf https://news.ycombinator.com/item?id=25381397).

And then there's https://security.googleblog.com/2021/02/know-prevent-fix-fra... which effectively calls for the end of open-source contributors staying pseudonymous.

Google does a lot of good for open-source security, but these recent things are a terrible look.

> And then there's https://security.googleblog.com/2021/02/know-prevent-fix-fra... which effectively calls for the end of open-source contributors staying pseudonymous.

I think that will do more harm than good. First of all a lot of critical software is security related and encryption related and I would guess a higher proportion of contributors in that area are more sensitive to protecting their identity than the general developer population. So you would lose out on some contributions that you would otherwise have gotten.

Second, a major threat in this area arises from nation states. However, due to experience with physical espionage, nation states are already pretty good at establishing fake identities for people (for example it would be no problem for them to supply a fake (or even real) passport/ birth certificate/etc or turning people who are already working in critical areas. Thus getting rid of anonymity would not even be a speed bump for Five Eyes, Russia, China, North Korea, etc.

So I don’t thing there would be much benefit, but there would be a lot of cost.

I think a known pseudonymous identity is better than an unknown fake identity. Real names lower guard but most have no way to actually verify.

Whether or not there is an impenetrable fake identity is a different question from "now that identity Foo is untrustworthy, what other things do I need to inspect?"

For that, you don’t need any type of real world identity. If you require that people sign their commits/reviews with a PGP key and base their reputation on that, that still gives you much the same benefit, while at the same time allowing people to be anonymous.

To be clear, I agree.

The point I was trying to make was that stable identity, whether real or pseudonymous, has value in a security context.

From the second link:

> It is conceivable that contributors, unlike owners and maintainers, could be anonymous, but only if their code has passed multiple reviews by trusted parties. It is also conceivable that we could have “verified” identities, in which a trusted entity knows the real identity, but for privacy reasons the public does not. This would enable decisions about independence as well as prosecution for illegal behavior.

Who gets to decided who this "trusted entity" is?

For example, I don't want anyone to know my real name. I'm not up to any mischief (criminal or otherwise), I just want the separation of identities. There isn't a single entity on Earth that I'd feel safe delegating this knowledge with if I could avoid it.

It sounds like, unless someone is an owner or maintainer of a critical open-source project, the blog post isn't necessarily calling for that person's deanonymization. For projects that are both critical and owned/maintained by anonymous entities, I think it's reasonable for an organization to think twice before taking a dependency on such projects, given the sort of anonymous attacks mentioned in the article.

Disclaimer: opinions are my own, not my employer's (Google)

> I think it's reasonable for an organization to think twice before taking a dependency on such projects, given the sort of anonymous attacks mentioned in the article.

I'd argue that "thinking twice" should be the standard bar for all open source dependencies, not a discrimination levied towards anonymous or pseudonymous developers.

(Though, to be fair, I doubt Google would ever use any of my code. I know your cryptographers; they don't need me to contribute lol.)

Does someone at google want to be the "trusted entity"?

> which effectively calls for the end of open-source contributors staying pseudonymous

Among other things, attacking pseudonymity is an effective means for ensuring the exclusion of trans people, wherein they're forced to identify as their legal name (a.k.a. dead name).

Google needs to correct course on this if they're to be trusted at all.

> Among other things, attacking pseudonymity is an effective means for ensuring the exclusion of trans people

Like you said, trans people are far from the only ones affected. Here is a more extensive list:

https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Re...

I was very aware of how it hurt LGBT folks, but that link really punctuates how bad these ideas are for everyone else too.

In most first world countries I'm fairly certain one can change their legal name.

So I've talked to a number of people at various companies about open security work for various areas of detection and response, which is something I don't see really represented in the existing working groups for OSSF. Is there somewhere I can discuss ideas about this?

I see tons of opportunity for guidance to OSS devs that, when implemented, would have massive positive impact for detection and response.

I don't have the experience with such foundations, or the time, to really form a working group, but I'd certainly be interested in discussing this with others.

What attacks would these measures stop? OpenSSL had all of them and was still a disaster.

>Honk!

We finally found out who runs GooseInfosec!

Reply on news.ycombinator.com