Re: Validation of keyring changes [was: Enhancing cross-distro collaboration via foreign archive keyring] availability

On Fri, Sep 13, 2024 at 05:20:34PM +0200, Luca Boccassi wrote:
> I think we need to be careful to avoid making our lives unnecessarily
> hard without good reasons.

I agree with this principle. However, I think that given that you're
asking to make changes to a trust root for the purposes of maintaining
that trust root in the archive itself, it's reasonable to spend, at a
minimum, the effort needed to arrive at a documented scheme that
describes how that trust is established. So I hope that you don't
consider this converation here to be unnecessary.

> If certain workflows are good enough for
> example to import new kernel or compiler sources, or for
> ubuntu-keyring updates, then they also must be good enough for this,
> which has a much narrower and less impactful use case. That said, an
> agreed and documented robust-enough workflow is a good idea.

I think these are false equivalences. ubuntu-keyring updates are almost
never done, and validating them against the actual keys used by Ubuntu
infrastructure is trivial for Ubuntu developers to do. Further, for
trust purposes, the updates were provided by an employee of the same
entity that provides Ubuntu's infrastructure (Canonical), so there can
be some level of inherent trust that any replacement keys provided did
indeed belong to the same entity. Validation of the individual
employees' identities can be done trivially on our own infrastructure
that we must fully trust already for our archive publication
(Launchpad). But in the general case that you're requesting here, that
trust connection isn't present. This isn't a showstopper, but it does
mean that we need to establish an alternate means of validating the
trust chain.

Further, I don't know what specific validation was actually done in the
rare cases that ubuntu-keyring was changed in a stable release in the
past, but any shortcomings there are something we should fix in the wake
of supply chain attacks such as what happened in xz-utils. You're
proposing to do something new in ways that haven't been done before, so
now is the time to decide what level of validation is appropriate for
the security landscape today. What happened with ubuntu-keyring for a
couple of one-off events in the past cannot be considered to be a
precedent for the rather different thing you are proposing to do now.

In the common case for stable updates in Ubuntu, we review the actual
code changes themselves, so authenticating their origin isn't critical
for supply chain security. In contrast, for keyring changes, validating
the upstream origin is absolutely critical since key changes cannot be
checked by mere inspection.

One of the (many) aspects that saved us is the delay between Debian sid
being updated and Ubuntu stable releases getting it. But here, you're
proposing to take that delay away, updating Ubuntu stable releases as
soon as the change is signed and pushed to Debian Salsa. So this
situation is different and standards applied elsewhere do not transfer
because the security implications are different.

> So, a good enough workflow that should suffice for all intent and
> purposes in my view would be: instruct to never upload from a random
> tarball attached to a launchpad bug or an email. Always and only
> upload from a tag laid on the ubuntu/<release> branch on Salsa, after
> checking that the tag is signed.

I don't think we can expect sponsors to follow this kind of rule. Since
we usually expect them to use careful code inspection only, it's
difficult to create a place that they would automatically for special
rules such that we'd be confident that they'd follow them. That's not to
say that we shouldn't define and document this somewhere, but rather
that our process shouldn't depend on it.

Instead, I think we should use the SRU review process to ensure this
kind of checking is done. I'm less keen on using autopkgtests (again, to
rely upon; having them is fine) because in our pipeline packages would
still be published to -proposed and therefore available "officially"
before that validation has happened. This would need the tooling to be
able to be run outside the autopkgtest environment.

I think we need more specifics though.

We would check that the tag is signed, but by whom? Who decides the set
of signers that is acceptable? How do we manage changes to that set?

If that's all managed at the Salsa end, then that's worse security than
what Debian have today, because that's not necessarily even restricted
to those who can upload to the Debian archive!

I can sense potential frustration in anyone reading this. But
unfortunately this sort of validation provides no security value unless
these things are specified.

# How to automatically perform the validation

Could we place the set of acceptable signers for the git tag signature
in the source package itself? Then have a script in the source tree that
the sponsor and SRU reviewer can both run that validates against Salsa
as you suggest? The special case documention would then specify that
expectation and the SRU reviewer would merely have to run the script.
They already expect an explanation for any other changes, so that would
maintain the integrity of this check.

This is necessary because in our workflow we upload before the
autopkgtests run.

This way, when reviewing we would normally expect that script and the
acceptable signature list not to change, and it would be very clearly
evident if the proposed update requires them to change.

> The current trustworthiness of git
> tags is good enough for everything else including the kernel, so it's
> good enough for this too, and there are no real attacks that can be
> done against git tags that need to worry anyone at this stage. Only
> members of the Salsa RPM Packaging Team have permission to push tags
> there. I am not the only person in the team, there are a couple of
> other people, so also the single-person-bottleneck issue is solved.

There's still the question of the entire trust chain failing if a single
person's personal keys are compromised.

We generally accept this in development release, but normally all
changes to stable releases in SRUs are reviewed by at least two people.
Is it possible to require the tag to have been signed by two appropriate
people who have independently checked that keys are correct? How is that
checking to be done and what commitment is the team signing tags on
Salsa making to do such checking?

Robie

Re: PPU Application (s390-tools) by Frank Heimes

Thank you Utkarsh, and the entire DMB !

On Wed, Sep 18, 2024 at 1:38 PM Utkarsh Gupta <utkarsh.gupta@canonical.com> wrote:

Hello,

On Tue, Aug 6, 2024 at 9:13 PM Frank Heimes <frank.heimes@canonical.com> wrote:
> I've added my application to the DMB's agenda for the meeting
> on Monday 2024-08-19, since I would like to apply for PPU upload
> rights for the s390-tools package(s).

DMB unanimously voted in favor of Frank's application for s390-tools*
PPU. Please join me in welcoming him as an Ubuntu member, too.

Frank, you should have all the ACL in order now, please let me know
if you have any questions or concerns.


- u

Re: PPU Application (s390-tools) by Frank Heimes

Hello,

On Tue, Aug 6, 2024 at 9:13 PM Frank Heimes <frank.heimes@canonical.com> wrote:
> I've added my application to the DMB's agenda for the meeting
> on Monday 2024-08-19, since I would like to apply for PPU upload
> rights for the s390-tools package(s).

DMB unanimously voted in favor of Frank's application for s390-tools*
PPU. Please join me in welcoming him as an Ubuntu member, too.

Frank, you should have all the ACL in order now, please let me know
if you have any questions or concerns.

- u

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Cloud-init PPU application by Alberto Contreras

Hello,

On Wed, Sep 11, 2024 at 12:41 PM Alberto Contreras
<alberto.contreras@canonical.com> wrote:
> As the meeting on 2024-09-30 did not happen, I rescheduled
> my application for 2024-09-16. I hope that is alright.

DMB unanimously voted in favor of Alberto's application for cloud-init
PPU. Please join me in welcoming him as an Ubuntu member, too.

Alberto, you should have all the ACL in order now, please let me know
if you have any questions or concerns.

- u

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Second Oracular Oriole test rebuild

The second test rebuild of Oracular Oriole was started on September
12, 2024 for all architectures and all components. The rebuild is
finished for the main component on all architectures except riscv64,
and is still running for universe and multiverse.

Results (please also look at the superseded builds) can be found at:

https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20240912-oracular-oracular.html

Additional build failures for packages in oracular-proposed (not yet
in Oracular) can be found at:

http://qa.ubuntuwire.com/ftbfs/

Please help with fixing the build failures.

Thanks
Graham

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Waiting for a package to be available in an archive

Hi,

After some discussions a few months ago and some more last week, I wrote
a quick script during the week-end to be able to wait until a package is
updated in a PPA so that I could do automatically trigger tests.

The script is available at https://gitlab.com/-/snippets/3747331

As I note in the link above, this uses two libraries that are not
packaged and is therefore not as friendly to install as I had hoped.
It's also written in OCaml (which makes sense as I'll reuse everything
for my project of an updated excuses page).

I expect that at least a few people have taken offense reading the
above due to the use of OCaml and will write the same in another
language, with more polish!

For such a rewrite, you should look at the fetch function: it's mostly
API calls to curl in order to avoid re-downloading the Packages.gz file
when it hasn't changed (on a PPA with only three packages, HTTP time is
cut from 150ms to 70ms IIRC; expect the 150ms to become a lot more on a
larger archive, and to also be heavier for servers).

Are you still wondering if you should rewrite in your preferred and
superior programming language? It's just another proof that it's
actually inferior to OCaml since for the past 20 years or more, there
haven't been an implementation of this frequent task in that language,
and there still isn't.

PS: I'm available to discuss implementation details more.
PPS: this email is meant to fit in the ideas of
https://en.wikipedia.org/wiki/Ward_Cunningham#Law and
https://xkcd.com/386/

--
Adrien

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Oracular Oriole (to be 24.10) now in Kernel Feature Freeze

Matthias Klose kirjoitti 16.9.2024 klo 12.49:
> On 13.09.24 10:48, Timo Aaltonen wrote:
>>
>> Hi,
>>
>> We are now under the Kernel Feature Freeze for Oracular Oriole:
>>
>> https://wiki.ubuntu.com/KernelFeatureFreeze
>>
>> This means that all the new features for the kernel (6.11) have landed
>> in oracular-proposed, and from now on we will focus on fixing bugs.
>>
>>
>>
>> On behalf of the Kernel team,
>
> The oracular release pocket still has the linux-libc-dev user space
> headers from 6.8 (the same major version that was released with noble).
> The oracular release pocket never saw any newer user space headers, and
> we were doing our test rebuilds for oracular with the old user space
> headers.
>
> Now when 6.11 migrated to the release pocket, we are flying blind with
> these updates to the user space headers, not knowing anything what fails
> to build and what stops working.
>
> I think we should avoid that situation, as updating affected packages at
> this point requires much more work during freezes.  Please consider
> providing the updated linux-libc-dev package a few weeks before feature
> freeze in the future.

That was the intent, but nvidia updates blocked the new kernel from
migrating, and all attempts to make it happen without needing a hammer
failed, and in the end I had to remove the old l-r-m's anyway to get the
new kernels in the release..

--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel