examples-configs: set maintainers components

[fepitre]

• Set @fepitre as a maintainer of linux-kernel, builder-gentoo and gentoo
• Add @marmarta's key
• Set @marmarta as a maintainer of the Qube manager

[fepitre]

A first pass on declaring maintainers. Probably it is worth to do some announcement while merging (@andrewdavidwong).

[andrewdavidwong]

Hm, interesting. I'm not sure if we've ever done an announcement for this sort of thing before. Can you tell me more about what exactly is happening or changing? In other words, are we announcing that you are the new maintainer of linux-kernel, builder-gentoo, and gentoo; and Marta is the new maintainer of the Qube Manager? Who were the maintainers before? What does that mean for contributors (perhaps something) and users (probably nothing)?

[fepitre]

With this PR #118, we can define maintainer(s) per component, allowed to be trusted for creating signed tag. The direct consequence is that when someone clones sources with the qubes-builder, the verify step for a specific component is now enlarged to not only keys into https://github.com/QubesOS/qubes-builder/blob/master/qubes-developers-keys.asc but with the declared maintainer(s). The goal is to lower Marek's tasks.

[andrewdavidwong]

Ah, I see. How about if we (1) update the Team page to properly reflect your and Marta's new responsibilities, and (2) document how this infrastructure works in an appropriate place in the Developer Documentation?

I have no problem with also making an announcement, if you think it's a good idea, but this strikes me as more of an internal security infrastructure topic that will be of interest primarily to those who are concerned about the security practices of the project. No doubt, some advanced users and contributors will be interested in this, so making the information readily available in the Developer Docs is important, but I suspect that the majority of users may not see it as being actionable or relevant to them.

[fepitre]

Ah, I see. How about if we (1) update the Team page to properly reflect your and Marta's new responsibilities, and (2) document how this infrastructure works in an appropriate place in the Developer Documentation?

I have no problem with also making an announcement, if you think it's a good idea, but this strikes me as more of an internal security infrastructure topic that will be of interest primarily to those who are concerned about the security practices of the project. No doubt, some advanced users and contributors will be interested in this, so making the information readily available in the Developer Docs is important, but I suspect that the majority of users may not see it as being actionable or relevant to them.

Yes you are right, better doing this way. Let's wait for Marek's feedback.

[marmarek]

With the current shape of the qubes-builder, I'm not comfortable with setting per-component maintainers this way, in components that are included in the main qubes-builder instance. Since Makefile.builder files are effectively executed unsandboxed, allowing to maintain a single component in practice gives access to code execution within the main qubes-builder instance and modify anything.
Note the above concern does not apply for components used only during template builds (see template-configs repo), because those are isolated within DispVM during the build process.

I can think of two solutions for this problem:

1. avoid executing any code from individual components in the main qubes-builder instance - this includes Makefile.builder, but also auxiliary files like parsing spec files (this also can include executable parts at the parse stage)
2. have some auto-review bot that automatically adds a signed tag if both a) it is already signed by designated maintainer(s) b) qubes-builder critical files are not modified

The first point we already have implemented for the template builds, including isolation the build in DispVM. We'd need to extend it for normal components too (which is a good idea anyway). One challenge with this approach is getting package names without executing any of those files - we have .list files for rpm packages used in some places, perhaps this can be extended for other cases too.
The second point we already have for our website repo in a very simplified form (currently only checks the signatures, the files checking is in development for the website translation).

[fepitre]

The first point we already have implemented for the template builds, including isolation the build in DispVM. We'd need to extend it for normal components too (which is a good idea anyway). One challenge with this approach is getting package names without executing any of those files - we have .list files for rpm packages used in some places, perhaps this can be extended for other cases too.

Do you mean that having list of related packages for a component would prevent having others packages potentially overwritten?

[marmarek]

Do you mean that having list of related packages for a component would prevent having others packages potentially overwritten?

No, I mean if we save a list of built packages into a .list file, we do not need to parse the spec file to get package names (for the purpose of update-repo-* targets for example, or for just checking it the package was built)

[fepitre]

Ok so maybe there is common purposes with the problem of getting corresponding packages names and Qubes component names? I remind you the work on sources: https://gist.github.com/fepitre/dbf42ec7fd6a370c5e9479ab92c92bad

[fepitre]

Closing as we have now builder v2 handling that.