Hi, In light of the recent xz supply-side attack [1], I wonder if we should have a discussion about security issues around packages on build.o.o that may be similarly exploited by a packager either acting in bad faith or working from a compromised system themself. Some specific issues that I repeatedly keep thinking of: 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. For new packages, yes, there is a License check done by SUSE, but not security checks unless the package in question raises specific AUDIT level reviews (like installing polkit privileges etc). This means a packager either acting on bad faith or working from a compromised system could generate a tarball containing an exploit and push it, eventually, to Factory. I hope I am wrong. Perhaps we should reconfigure the Factory bot to forbid non-URL sources from Factory packages entirely. I am not sure how many packages currently have these, but I am fixing one right now. 2. Perhaps it is time to allow 2FA, and indeed make it mandatory, for packagers on build.o.o. 2FA is certainly not hack-proof, but it is better than the simple password based authentication we currently use. This will also cut down on spam comments, that have been slowly growing in number. I noticed that they have been discussing this over on Fedora [3] as well. 3. At the level of prj and Factory reviewers, perhaps we should encourage — and eventually enforce — running `autoreconf -fvi` for all autotools based packages after cleaning up pre-generated build scripts from the tarball in %prep. This could be optimally done with a new rpm macro. I understand that this will not be possible for all packages, and that there are still packages that have weird manually written m4 scripts, etc. However, they are a minority, and we should reconsider whether such poorly maintained packages have a place in our distro any more. 4. And finally, please, please, let there be a 15-day, or even 30-day, waiting period for new users on build.o.o before they can start commenting on projects and packages. This will cut down on stupid spammers and "new version please" pressure creators who simply add noise and affect the workload of packagers and project reviewers, most of whom — myself included — do voluntary work, and are often anyway pressed for time. Our comment reporting system, although good that we now have one anyway, only adds to the workload of project and package maintainers and is rather sub-optimal. It often feels like I am sending my reports to a black hole. Thanks for reading through what turned into a rather long email and best wishes. [1]: https://tukaani.org/xz-backdoor/ [2]: https://en.opensuse.org/openSUSE:Specfile_guidelines#Metadata_Tags [3]: https://pagure.io/fesco/issue/3186 -- Atri