>
> On Thu, Sep 25, 2025 at 2:11 PM Spyros Seimenis
> <spyros.seimenis@canonical.com> 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
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
