Hello Hector, thank you for your comments and questions!
On Wed, 09 Oct 2024, Hector Oron wrote: > First of all that comes to mind is the chain of *dependencies* of the > software in terms of long term *maintainability*, the ease to adapt the > code for newer needs and the ease to update and upgrade this system when > running in a production environment. https://salsa.debian.org/freexian-team/debusine/-/blob/devel/pyproject.toml?ref_type=heads#L25 has a pretty extensive list of the dependencies. It also includes dependencies outside of the Python ecosystem with comment lines listing the Debian packages that we rely on. It is certainly larger than the current infrastructure, but it's also not comparable given the much wider scope of debusine, and significantly smaller than the average project using similar technology nowadays. We also take care to make sure that all the project dependencies are in Debian Stable and are covered by security support. This is to say that dependencies are something we are aware of and take pains to manage. > Who would be the long term maintainer of this infrastructure providing > security support and newer updates. There are two sides here: 1/ While we hope debusine to be useful for Debian, it is also useful for the LTS, ELTS and packaging work that we do within Freexian. So we are committed to maintain debusine for the foreseeable future. 2/ While Freexian collaborators will continue to be involved, we have built everything required to let a community flourish around debusine. We believe that we are close to the point where other Debian developers will see the potential of debusine, and will want to try to scratch their itches by developing new tasks and new workflows. > So, the obvious question arise, why should we upgrade the > existing to a different one? (retoric question, later I give a potential > reply to this) If you look only from the perspective of the package build, the benefits might not be obvious. If you have read the document we wrote, you can identify some notable improvements in the way builds are scheduled on workers, or in the possibility to control the build with more parameters (build options, build profiles, build backend, etc.). But to me the most important benefit is that it enables us to propose improved workflows to Debian developers. The current development model (upload to unstable, wait for builds, run QA on built packages, prepare some fixes, and then rinse and repeat) is sub-optimal in the sense that we discover issues when they are already present in unstable while we could anticipate them better and fix some of them even before the package hits unstable. With next year's work (on package repositories within debusine, and repository-level operations), we ought to reach a point where a full transition can be prepared outside of unstable and be copied into unstable as a single operation, which we believe would be very hard in the current infrastructure. > The need of few dependencies is also good for controlling > the attack surface, which brings up the topic of *security* of the system, > an assessment/audit should be made and be taken seriously. Sure. We are currently developing a permission system in the current milestone, in particular with the aim to correctly manage embargoed updates. So it's a bit early to go through an audit since we don't have any sane checks in place yet. However SovereignTechFund offered us to participate to a program where they fund "bounties" for security researchers to find flaws in debusine. This is something that we will look into next year. > crontab. I also mentioned I was exceptive and that is because I feel that > replacing all the current sub-systems or even orchestrating them over a > single tool is very challenging and hard work. It certainly is! We have been working on it for a full year with roughly the equivalent of 3 persons full time, and we still have many challenges ahead of us. But we have put our hearts in it, and while it's not yet production ready, I think it deserves a closer look. > Getting into this particular topic on replacing buildd and potentially > other components needs much more discussion, first item for me would be on > building embargoed security updates (how secure and confidential that would > be?) It's bit early to give details about this, but basically debusine has a concept of workspaces. Workspaces can be private or public. If they are private, then only users that have been assigned some specific roles in that workspace have visibility in it. We plan to have a "contributor" role that doesn't give you visibility on the workspace, but lets you submit a source package and start a workflow on that source package. As the submitter, you would possibly have visibility on that workflow but only on that one. If you want to follow more closely our work here, you can check out those links: https://salsa.debian.org/freexian-team/debusine/-/issues/395 https://salsa.debian.org/freexian-team/debusine/-/issues/396 https://freexian-team.pages.debian.net/debusine/reference/devel-blueprints/permissions.html Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
