On Sat, Mar 30, 2024 at 09:07:19PM -0000, Daniel Alley wrote: > It's not how free software works, but there are some interesting projects > working on (distributed, not centrally managed) code review systems that are > kind of similar in spirit to what OP describes. > > https://github.com/crev-dev/crev > https://github.com/crev-dev/cargo-crev > https://mozilla.github.io/cargo-vet/ > > That is, individuals and organizations can publish the results of their code > audits publicly in a standardized format, tied to a package artifact, and a > downstream consumer could denote which individuals and organizations they > trust to perform said audits. > > It's technically possible and not an entirely ridiculous idea, it's just > economically challenging. How do you find enough people willing and able to > audit a package (including e.g. autotools build scripts), in multiple, to the > level of scrutiny that would be required to catch something like this.
I think such cross-checks already happen in practice. When distro packages are updated, maintainers will do _some_ review. We can't force them to full reviews every time, and it wouldn't even make sense, but we can be certain that if anything malicious is found, notifications too the other distros will go out immediately. Or to put in a different way: if distribution publishes a package, we implicitly know that they did the review of that package in that version to the level they consider acceptable. We if asked them to make an additional signature, it wouldn't add much. As a maintainer, the level of review I do for updates varies a lot: for some upstreams I'll do a patch-by-patch review and maybe use diffoscope to see what changed in the internals, for some upstreams I'll scan the NEWS file, and for other upstreams I'll not even do that, if I know what is hapenning in the project and I trust the quality and integrity. If there was a "task force" auditing packages, I think it should apply some variant of that rule: focus on packages which are a) important, b) have few maintainers, c) have lots of ugly internals, d) raise suspicion for whatever other reason. This would probably yield better results then trying to apply the same level of scrutiny accross the board. -- That said, one useful variant of the auditing proposal would be to check that different distributions actually have the same source tarballs, for the same versions of the same packages. This is something that could scripted and occasionally executed. It'd be very suspicious if it turned out that the "upstream tarball" differs in Fedora or Arch or Debian or Suse or any other distro. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
