Hacker News Reader

Comment by andix | Hacker News Reader

Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it.

Those changes of maintainers need to be synced to package distribution sites like npm.js or Debian packages and put in context with versions/releases.

In Europe this was introduced for banks after the banking crisis. If a bank does any organizational change, a report is sent out to all member states of the EU right away and any of the 27 national bank agencies can check if they notice something unusual. It might be possible to bribe a few people in your own country, but it’s really hard to bribe all responsible people in 26 other countries.

View on HN

I'm sure some security researcher is doing this, but we could easily create a visualization of "who has contributed over time" and identify transitioning of maintainers automatically just from git.

This might be worth doing and contributing to a site like bestofjs or libraries.io (I don't really use that one though!)

> who has contributed over time

When major security players insist that using GPG is bad, there is no way of knowing if bob@bob.bob is the same account that it was last month or not.

It is not the idea of GPG thats bad. In fact, the idea is great! The implementation of GPG however is quite another thing. Ease of use and user experience are really not that great with GPG. It is difficult to use even for developers. Developers are users too amd so on.

Try uploading a signed package on pypi. Sign it with sequoia instead of GPG if you like.

You'll receive an email asking you to stop uploading signatures.

you can sell/steal keys just as easily as accounts

Ok. Can you get my private key? Feel free to respond to this comment with my private GPG key.

I think guessing a password and getting lucky is much easier.

> Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it.

The rust project does it. There's a repo with all [active] members and their permissions on github, etc. These get synchronized and updated every time there's a change.

This is, in my eyes, one of the most important parts of "Infrastructure as Code". You should make the list of who has what permissions a critical artifact, as immutably part of the repo as any other change.

Just for the main project, or for all/most packages on crates.io?

Every repository and team under rust-lang on github.

That's great, but I think that's not enough. This would need to extend to crates.io, I'm sure there are some packages, that are very commonly used and not part of rust-lang.

The major projects aren't on github.

Could you elaborate?

While I love open source, this feels to me like something companies need to pay for.

It might be that no open source contributions I've made are things people care about, but I'm not spending one second of my time for free updating databases so multi-billion dollar companies can feel safer.

How about simply paying the maintainers and then getting stuff done like the classical business does.

Well yes, sounds great, but it doesn't really address the security problem. Now you've just got the bad guys getting two paychecks instead of one and the good guys getting one paycheck instead of zero.

> bad guys getting two paychecks instead of one

1 to 2 paychecks = 100% increase.

> good guys getting one paycheck instead of zero

0 to 1 paycheck = infinity increase.

With a known baseline of "good paychecks", financial analytics can pursue identification of "bad paychecks".

One of the biggest risks for companies is securing dormant code, it's perfectly fine for a project to be no longer sexy enough to maintain. Platforms like thanks.dev have already proven how reward & recognition can help promote development in an ecosystem https://www.youtube.com/watch?v=e5FV-AnKPlo&t=1s

Did you mean: instead of trying to become a maintainer to a trusted open source project, how about bad actors simply bribe the existing maintainer to do their bidding? There would be no maintainer changes in that scenario.

Related, the motivation for trying to gain privileged access to open source projects is to leverage the existing trust associated with that project. A different long game that could be played is to create a new project with the intent on backdooring it a few years down the road, after it has gained sufficient trust.

Is it really though? Cum-ex and cumcum appear to still work great.

Cum-ex is about taxes (and criminal law). It's unrelated to the stability of banks.

Reply on news.ycombinator.com