4 ms·
I wonder if both are possible with a trust system where releases can be approved or signed by community members. This way we can have automatic semver updates f
by zorr 5y ago
I wonder if both are possible with a trust system where releases can be approved or signed by community members. This way we can have automatic semver updates for releases approved by people we trust.
Something like "I trust NPM so accept all releases that NPM has approved". Large companies could have their own internal approval keys etc.
- remram 5y agoThis exists, it's called crev: https://github.com/crev-dev/crev https://github.com/crev-dev/crev It is really good, allowing for distributed reviews, not necessarily from the people authoring your dependencies. The OP suggests that if you -> A -> B, the package manager should only install versions of B vetted by A (or close); I think this doesn't scale well in practice (all the more so if the only way A can vet a new version of B is by doing a new release). Having the possibility to rely on other people to vet releases (possibly in your company) opens a lot of doors, such as the ability to not trust the author of A at all.
- boris 5y agoThat's in a sense what Debian is doing with its experimental/unstable/testing/stable repositories. We also adopted a similar approach in build2 where we have queue/testing/stable sections of the repository. A newly submitted package version first lands in the queue where it is not yet visible to anyone. After it has been tested and reviewed, it is migrated to testing where it becomes available for testing by the larger community. After some time, if no issues are found in the package, it is migrated to stable. You as a user of build2 have a choice from which section(s) of the repository you want your dependencies.