5 ms·

This is why I fear our dependence on 'authoritative versions' of libraries. We've already seen the perils of ownership transfers being used to embed vulnerabili

This is why I fear our dependence on 'authoritative versions' of libraries. We've already seen the perils of ownership transfers being used to embed vulnerabilities or outright malware, all under the pretense that the new versions are still authoritative and trusted. A more mature approach seems to me to be to ensure forks are first-class, and that dependence is restricted to a specific fork: either by full name (@owner/repository), or - better yet - by Git coordinate (url/sha). This means an abandoned project can be picked up by any number of people. The primary cost I can see is one of cohesion and divergent enhancement under the same library name. But in a way, we have ways to refer to that already. "Mordenkainen's Magic Missile" - the owner + name coordinate already has a natural representation. And perhaps once we've made that step, more progress can be made to help forks coordinate common changes and improvements where possible, or to split into more distinct artifacts where applicable.

johannes1234321 7y ago
Another view: It is an issue of libraries owned by individual developers. I commonly argue for organisations of some kind to take over ownership over "relevant" libraries. This of course is nothing which can be enforced. Benefits are not only reduction of "bus factor" on a single developer, but also enables review procedures. Depending on the project this could be a custom organisation, a "generic" organisation like ASF. Libraries owned by a single developer for me are a notable risk, when taking them as dependency.
em-bee 7y ago
could you elaborate on how that is supposed to work? how would a dependence on a fork help with the maintainer transfer risk?
- Fellshard 7y ago
  Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to maintain a non-abused version of the library? Can you replace the owner's authoritative builds with your own? If you instead have no 'authoritative version' of a library, you lose some elegance to be sure; you can no longer say simply, 'let's use Magic Missile!' as there may be multiple forks of what could be labeled the original 'Magic Missile' library. But what you gain is the ability to maintain multiple versions of the library, and to be able to point out which versions are poorly maintained or even hazardous: "We don't use Drizzt's Magic Missile, it was tailored pretty heavily towards his own projects." "If I recall, Persophone's Magic Missile included a hidden cryptominer. Avoid at all costs."
  - em-bee 7y ago
    so this is not a technical change but a change of presentation and perception. instead of one person or team having the authority, there is a community notion of who can be trusted. this does exist. and it seems to happen when authority falls down or is not there to begin with. for example several community builds around distributions for the GPD pocket emerged, and some lived longer than others and some where more reliable than others. in fact the emergence of linux distributions themselves follows this model. each distribution is packaging applications they did not create, and are hence not the owners of the authoritative builds. and we pick distributions based on which one does the best job. of course distributions create their own authority on their collection, but the principle remains. they also may easily switch the source for their packages. i do remember a few examples where this has happened. another area where this can be seen is with binary builds for projects where the original developers only release the source. it's the same dynamic. build your own, or pick a community contributed build by someone else. either way noone gets to use the authoritative builds because they don't exist. (or they exist only for one platform, in which case the situation is limited to those who are on different platforms for which there are no authoritative builds)
    - Fellshard 7y ago
      It's both a matter of perception and of tooling. Consider the Java ecosystem. Dependency targets are specified by coordinates of both group and artifact, which satisfies the above separation fairly well, to the best of my knowledge. Consider the NPM and rubygems ecosystems: they specify dependencies by the name of the library alone, implicitly enforcing the 'authorized artifact' model.
      - em-bee 7y ago
        so you are saying that in java this works because i can choose the group where i get the artifact from, just like i can chose a different package repo for a package for my linux distribution. but in NPM and ruby i am limited to one single global repo and thus have no choice but to get the one that is controlled by whoever owns the name.

johannes1234321 7y ago

Another view: It is an issue of libraries owned by individual developers. I commonly argue for organisations of some kind to take over ownership over "relevant" libraries. This of course is nothing which can be enforced. Benefits are not only reduction of "bus factor" on a single developer, but also enables review procedures. Depending on the project this could be a custom organisation, a "generic" organisation like ASF. Libraries owned by a single developer for me are a notable risk, when taking them as dependency.

em-bee 7y ago

could you elaborate on how that is supposed to work? how would a dependence on a fork help with the maintainer transfer risk?

Fellshard 7y ago
Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to maintain a non-abused version of the library? Can you replace the owner's authoritative builds with your own? If you instead have no 'authoritative version' of a library, you lose some elegance to be sure; you can no longer say simply, 'let's use Magic Missile!' as there may be multiple forks of what could be labeled the original 'Magic Missile' library. But what you gain is the ability to maintain multiple versions of the library, and to be able to point out which versions are poorly maintained or even hazardous: "We don't use Drizzt's Magic Missile, it was tailored pretty heavily towards his own projects." "If I recall, Persophone's Magic Missile included a hidden cryptominer. Avoid at all costs."
- em-bee 7y ago
  so this is not a technical change but a change of presentation and perception. instead of one person or team having the authority, there is a community notion of who can be trusted. this does exist. and it seems to happen when authority falls down or is not there to begin with. for example several community builds around distributions for the GPD pocket emerged, and some lived longer than others and some where more reliable than others. in fact the emergence of linux distributions themselves follows this model. each distribution is packaging applications they did not create, and are hence not the owners of the authoritative builds. and we pick distributions based on which one does the best job. of course distributions create their own authority on their collection, but the principle remains. they also may easily switch the source for their packages. i do remember a few examples where this has happened. another area where this can be seen is with binary builds for projects where the original developers only release the source. it's the same dynamic. build your own, or pick a community contributed build by someone else. either way noone gets to use the authoritative builds because they don't exist. (or they exist only for one platform, in which case the situation is limited to those who are on different platforms for which there are no authoritative builds)
  - Fellshard 7y ago
    It's both a matter of perception and of tooling. Consider the Java ecosystem. Dependency targets are specified by coordinates of both group and artifact, which satisfies the above separation fairly well, to the best of my knowledge. Consider the NPM and rubygems ecosystems: they specify dependencies by the name of the library alone, implicitly enforcing the 'authorized artifact' model.
    - em-bee 7y ago
      so you are saying that in java this works because i can choose the group where i get the artifact from, just like i can chose a different package repo for a package for my linux distribution. but in NPM and ruby i am limited to one single global repo and thus have no choice but to get the one that is controlled by whoever owns the name.