5 ms·

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

by andix 2y ago

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.

PartiallyTyped 2y ago
> 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.
- GauntletWizard 2y ago
  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.
- andix 2y ago
  Just for the main project, or for all/most packages on crates.io?
  - PartiallyTyped 2y ago
    Every repository and team under rust-lang on github.
    - andix 2y ago
      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.
- guappa 2y ago
  The major projects aren't on github.
  - PartiallyTyped 2y ago
    Could you elaborate?
triblemaster 2y ago
How about simply paying the maintainers and then getting stuff done like the classical business does.
- __MatrixMan__ 2y ago
  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.
  - transpute 2y ago
    > 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".
  - armini 2y ago
    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 https://www.youtube.com/watch?v=e5FV-AnKPlo&t=1s
  - deleted 2y ago
    [deleted]
- omoikane 2y ago
  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.
wrsh07 2y ago
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!)
- guappa 2y ago
  > 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.
  - StrauXX 2y ago
    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.
    - guappa 2y ago
      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.
  - arccy 2y ago
    you can sell/steal keys just as easily as accounts
    - guappa 2y ago
      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.
jmakov 2y ago
Is it really though? Cum-ex and cumcum appear to still work great.
- andix 2y ago
  Cum-ex is about taxes (and criminal law). It's unrelated to the stability of banks.
CJefferson 2y ago
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.

by andix 2y ago

PartiallyTyped 2y ago

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

GauntletWizard 2y ago
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.
andix 2y ago
Just for the main project, or for all/most packages on crates.io?
- PartiallyTyped 2y ago
  Every repository and team under rust-lang on github.
  - andix 2y ago
    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.
guappa 2y ago
The major projects aren't on github.
- PartiallyTyped 2y ago
  Could you elaborate?

triblemaster 2y ago

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

__MatrixMan__ 2y ago
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.
- transpute 2y ago
  > 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".
- armini 2y ago
  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 https://www.youtube.com/watch?v=e5FV-AnKPlo&t=1s
- deleted 2y ago
  [deleted]
omoikane 2y ago
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.

wrsh07 2y ago

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!)

guappa 2y ago
> 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.
- StrauXX 2y ago
  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.
  - guappa 2y ago
    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.
- arccy 2y ago
  you can sell/steal keys just as easily as accounts
  - guappa 2y ago
    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.

jmakov 2y ago

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

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

CJefferson 2y ago

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.