Ben Greiner wrote:
Hi Atri,
Thank you for raising this.
We have the same problem not only with Source tags but also with Patch. They are sometimes too big to be properly reviewed by the accepting obs maintainer. I always use the GitHub URL (github.com/org/pkg/pull/NNN.patch#/pkg-prNNN-shortdesc.patch) when possible in order to have a stable version. But sometimes you have to apply patches which have not been merged yet. In that case, there might be later additional commits (relevant or not) and the URL will yield a different patch which a bot in factory will complain about. So you leave out the URL and only reference it by comment.
Agree, this is a very good practice that we should make explicit on the wiki (if we have general consensus): https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines
Am 04.04.24 um 11:16 schrieb Atri Bhattacharya:
1. Packages where spec files do not have traceable source tarballs with full URLs pointing to upstream. I understand that this is already discouraged but not entirely forbidden [2], so a user could have something like ``` Source0: totally_not_an_exploit.tar.gz ``` in their specfile, have the package build and submit it to a devel project and eventually Factory. Unless project or Factory reviewers have the time to untar the sources and carefully study them, which seems an almost impossible burden on either, the tarball could, intentionally or not, carry through an exploit. For sources that do indicate the full URL, I understand that bots in the Factory check the bundled tarballs against upstream ones, and decline them in case of any mismatch. However, for locally generated tarballs with no traceability, there is no check that prevents them from being shipped around as part of the distro proper.
I plead guilty as charged. There are many packages of mine where there is a Source without associated URL.
Ha ha, relax, no one is charging anyone! I think we are all guilty and the faith in trust-based-models that we have had so far has been shaken. Instead, let me take this chance to thank you earnestly for all the help you have accorded me with many packages, python packages in particular.
This ranges from _source generated rust vendor.tar.xz (Who audits these?) to test data tarballs generated by manual downloads. Spot the connection to the XZ backdoor.
As far as cargo vendor.tar.xz tarballs are concerned, I may be mistaken, but it is possible to check these by regenerating them from the `cargo.toml` file in the upstream git repository. I think this is done by the cargo_vendor.service already. The vendor.tar.xz contains sources from various different upstream repositories, but all of them are traceable. So, a downstream packager may find it difficult to maliciously alter this. For data files that concern tests, I think we should simply not run tests that require data files not available from upstream. Sometimes upstream will recommend "run this script to download the data files" and as packagers we do run them on our machines and generate a tarball out of them. I think we should stop doing that. Thanks for your response. Best wishes. -- Atri