4 ms·

If you have the time, I invite you to take the project's cargo lock file and analyse for every single one of them - what does it to justify its inclusion - wh

If you have the time, I invite you to take the project's cargo lock file and analyse for every single one of them - what does it to justify its inclusion - who wrote it - who else has commit access to the repositories - how do these people secure their git access - are these people susceptible to state actor pressure - will these people never in the future add new maintainers who are moles/blackmailable/have sloppy security hygiene

_flux 2y ago
I mean just this solely person already could tick all those boxes or I don't have a way to access that information. By glancing the direct dependencies of this project it is pretty easy to see why they have been selected. Yes, it would be more prudent to check all transitive dependencies as well, in addition to reviewing their source code, but frankly that's just too much effort. Does this mean the dependencies are random? But it does seem like it would be cool to have a tool to collect as much of that information as possible.
- Groxx 2y ago
  There also can and should be mechanical checks on libraries, to reduce the number of things that need heavy ongoing human review. E.g. if a library provides a pure function, does it matter if the owner changes? It's still pure. If it becomes not-pure, yes that's immediately concerning, but in the meantime its ability to do anything nefarious is infinitely smaller than most current module systems allow, and your review-budgets should probably be spent elsewhere.
  - _flux 2y ago
    Some kind of capability system would be interesting, but to work within function level it would need some pretty sophisticated support from the type system. On package level it might be easier? But then again you need to have quite fine-grained capabilities to describe what a package should be able to do. Of course, in Rust all unsafe code would need to be out (and it would be its own capability), but it still leaves exploiting the compiler bugs. For malicious changes that would of course be the vector to exploit and it might be very difficult to automatically detect them.

_flux 2y ago

I mean just this solely person already could tick all those boxes or I don't have a way to access that information. By glancing the direct dependencies of this project it is pretty easy to see why they have been selected. Yes, it would be more prudent to check all transitive dependencies as well, in addition to reviewing their source code, but frankly that's just too much effort. Does this mean the dependencies are random? But it does seem like it would be cool to have a tool to collect as much of that information as possible.

Groxx 2y ago
There also can and should be mechanical checks on libraries, to reduce the number of things that need heavy ongoing human review. E.g. if a library provides a pure function, does it matter if the owner changes? It's still pure. If it becomes not-pure, yes that's immediately concerning, but in the meantime its ability to do anything nefarious is infinitely smaller than most current module systems allow, and your review-budgets should probably be spent elsewhere.
- _flux 2y ago
  Some kind of capability system would be interesting, but to work within function level it would need some pretty sophisticated support from the type system. On package level it might be easier? But then again you need to have quite fine-grained capabilities to describe what a package should be able to do. Of course, in Rust all unsafe code would need to be out (and it would be its own capability), but it still leaves exploiting the compiler bugs. For malicious changes that would of course be the vector to exploit and it might be very difficult to automatically detect them.