On Thu, Sep 25, 2025 at 9:46 PM Aaron Rainbolt <[email protected]> wrote: > > On Thu, Sep 25, 2025 at 2:11 PM Spyros Seimenis > <[email protected]> wrote: > >> > > We should have clear guidelines about what are the requirements for an > > alternative method to be considered as trusted as the ones I mentioned > > above (what are the necessary attestations, how feasible it is to automate > > verification as a whole/in parts etc). For the Qubes example, I want to see > > cryptographic proof that the signing happened inside the "air-gapped" qube, > > proof that the key was indeed generated inside of it and cannot leave it, > > proof that you have set up your system properly and that your system comes > > from a manufacturer I consider trusted so that I can trust its hardware > > isolation mechanisms etc. (turtles all the way down) and I also want a > > system to do that verification for me as much as possible.
Thanks for the suggestion Spyros and all the details. I agree that we'd want such requirements to become defined over time. We'd want that for being able to process an alternatives which we might consider required to make some of it fully mandatory. But I do not think having these requirements fully defined needs to block recommending a good setup today. Trying to balance efforts and gains now vs what is needed into the future I'd say that the first alternative that will be processed will be more intense having to find out in discussions and evaluations what the requirements need to be. Still - I'll add this into the "alternative" section that I started in the PR - as it is important to not forget about this. > I think you're approaching this from the standpoint of Ubuntu being a > corporate project with security requirements from employees. That > would be great if that is what Ubuntu was, but that is not what Ubuntu > is. To be clear once more if there have been any misunderstandings, my intend hereby is not to enforce anything yet, for today we are talking about improving this for any Ubuntu contributor from "no docs - good luck" to "a reasonable recommendation" which will improve the status quo a lot. I hinted at potential enforcement in the future, partially to have exactly such a discussion in time and highly appreciate you and Spyros for having engaged on the topic here! > Ubuntu is a community project with a largely volunteer-based > workforce. As such, we have traditionally always taken steps to ensure > that the volunteers who work as part of Ubuntu are highly trusted - we > work with them on a personal level for months before trusting them > with archive upload privileges, ensuring that they are non-malicious, > constructive members of the community who know what they're doing and > will work closely with the rest of Ubuntu to do their job correctly. > If someone is trustworthy enough to do everything else with their > development work correctly, I see no reason they shouldn't be trusted > to do their key management correctly, provided they have been trained > on how to manage their keys just like they were trained on how to > manage packages. > > Ensuring that the key comes from a source that is somehow considered > objectively trustworthy is essentially enforcing an enterprise policy > across a non-enterprise community. The community is diverse, and gladly so. But in my example around potentially mandating in the future I had already acknowledged that by suggesting that companies can decide to do that earlier. Like Canonical could then say internally "nice recommendation - and for our folks we make it mandatory". That is enterprise rules for enterprise folks and not for all - which is a great middle ground for progress where possible. > It's also very insufficient as far > as real-world security goes; a person could So far - all major discussion participants have already acknowledged that any solution will have weaknesses. At least for me and now, I'm trying to be helpful in getting a recommendation up at all, and I'll therefore avoid that side of the debate of "a person could ...". > The entirety of that community ... I get the feeling that I should be happy to have triggered this discussion, but IMHO that aspect only is blocked once someone would later change it to "it is mandatory for ..." covering groups that are project but not company. To go forward I think there are two paths that are independent 1) And as long as "it is mandatory" is out of the picture for now, I consider all we got as "+1" or "+1 with helpful suggestions" I'm happy to continue, to facilitate all input to make the PR better and at some point land it. 2) For a future change to make anything mandatory that can be inside any company or need to finalize this aspect of the discussion. After all this is why I also called the tech board to state their position for this PR, even not yet making anything mandatory (I actually called them earlier than here, but things take time https://lists.ubuntu.com/archives/technical-board/2025-September/003049.html) > -- > Aaron > > > [1]: https://developers.yubico.com/PKI/yubico-ca-certs.txt -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
