Wednesday, 24 September 2025

Re: PGP key recommendations for Ubuntu Development

On Wed, Sep 24, 2025 at 4:53 AM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> Hi Ubuntu Developers of the past, the present, and the future!
>
> For a while I'm working on an improvement to how Ubuntu
> developers set up and handle their PGP keys. Without any
> offense, up to now it mostly is an undocumented:
> "Create a key, and somehow try to handle it safely".
> But throughout the population of developers I've seen
> various different interpretations of "safely" :-)
>
> Most of those that take it rather seriously have settled on a setup
> that utilizes hardware keys and I was collecting their input and
> experience for a while. I think it is time to drive a public policy
> about what we would recommend.
>
> After some internal rounds with early adopters as well as internal
> stakeholders on my draft, I've recently opened it up as a
> public PR to the project docs [1] and already got quite good feedback
> which is integrated by now. The intention is now to reach out
> further, by pointing all of you to the PR [1].
>
> [1]: https://github.com/ubuntu/ubuntu-project-docs/pull/182
>
> P.S. I know there is more that can be done as subsequent steps in the future,
> but I'm intentionally trying to not let future perfection be the
> blocker of this helpful step today, like:
>
> - Testing and documenting exact steps to do that setup. For that I'd
> want to get an agreement on the policy first, then distribute such
> keys among some of our folks and ensure we polish any rough edges by
> using them the way the policy says.
>
> - There are related aspects like the Launchpad API not yet having
> such capabilities, we are pushing for that feature and we'd
> adopt the policy here once available. I allude to that in the
> presented PR, but until the capability exists I can't do much more.
>
> - It is considered to one day make some of this mandatory, at least for
> roles with highly elevated permissions or e.g. within Canonical. But for
> that we need to have the policy and steps (above), the way to set up
> and use it (known missing) and maybe even missing launchpad features
> agreed and implemented.

I like the general idea of this, but please please PLEASE do not
mandate the use of hardware-backed keys. Not all developers can
actually obtain such keys (cost restrictions), some developers may
reasonably distrust such keys (vulnerabilities in the embedded
hardware of Yubikeys have been found before), and there are other ways
to store a GPG key in a highly secure fashion, for instance by using
an airgapped system, or (as I plan to do in the future) a Qubes OS
machine with an airgapped vault VM.

I do very much like the idea of giving a good set of recommendations
for key management, and making those recommendations mandatory doesn't
seem like a bad idea to me, but if and when the recommendations become
mandatory, they cannot include a hardware key requirement.

Just my 2 cents as a MOTU. :)

--
Aaron

> ...
>
> P.P.S.
> I've also called the TB, because to truly land this I think I eventually
> need them to either say "Approved by TB" or "Debated, OK,
> but does not need our deep review and approval".
>
> --
> 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

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

PGP key recommendations for Ubuntu Development

Hi Ubuntu Developers of the past, the present, and the future!

For a while I'm working on an improvement to how Ubuntu
developers set up and handle their PGP keys. Without any
offense, up to now it mostly is an undocumented:
"Create a key, and somehow try to handle it safely".
But throughout the population of developers I've seen
various different interpretations of "safely" :-)

Most of those that take it rather seriously have settled on a setup
that utilizes hardware keys and I was collecting their input and
experience for a while. I think it is time to drive a public policy
about what we would recommend.

After some internal rounds with early adopters as well as internal
stakeholders on my draft, I've recently opened it up as a
public PR to the project docs [1] and already got quite good feedback
which is integrated by now. The intention is now to reach out
further, by pointing all of you to the PR [1].

[1]: https://github.com/ubuntu/ubuntu-project-docs/pull/182

P.S. I know there is more that can be done as subsequent steps in the future,
but I'm intentionally trying to not let future perfection be the
blocker of this helpful step today, like:

- Testing and documenting exact steps to do that setup. For that I'd
want to get an agreement on the policy first, then distribute such
keys among some of our folks and ensure we polish any rough edges by
using them the way the policy says.

- There are related aspects like the Launchpad API not yet having
such capabilities, we are pushing for that feature and we'd
adopt the policy here once available. I allude to that in the
presented PR, but until the capability exists I can't do much more.

- It is considered to one day make some of this mandatory, at least for
roles with highly elevated permissions or e.g. within Canonical. But for
that we need to have the policy and steps (above), the way to set up
and use it (known missing) and maybe even missing launchpad features
agreed and implemented.

...

P.P.S.
I've also called the TB, because to truly land this I think I eventually
need them to either say "Approved by TB" or "Debated, OK,
but does not need our deep review and approval".

--
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

Re: First Questing Quokka test rebuild

On Wed, Sep 17, 2025 at 11:51 AM Graham Inggs <ginggs@ubuntu.com> wrote:
> The first test rebuild of Questing Quokka was started on September 10,
> 2025 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.

The rebuild is now finished for the main component on all
architectures, and finished for universe and multiverse on all
architectures except riscv64, with about 17K packages to go, and
s390x, with about 8K packages to go.

Again there are a large number of build failures without logs, these
are indicated with '!Log' on the report. These will be retried from
time to time.

If you do notice any other build failures which are not reproducible,
e.g. due to transient conditions, or fixed by the migration of another
package, please ping me to schedule a retry.

> Results (please also look at the superseded builds) can be found at:
>
> https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20250910-questing-questing.html

Please remember to 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

Monday, 22 September 2025

Re: PSA/RFC: apparmor profiles and coreutils

So the plan[1] was to "c) update affected packages to use the new
macro/alias, and Breaks: apparmor << version-that-does-not-have-it".

Turns out the Breaks doesn't work so well for us in this case[2]:

Unpacking apparmor (5.0.0~alpha1-0ubuntu7) over (5.0.0~alpha1-0ubuntu4) ...
Preparing to unpack .../cups-browsed_2.1.1-0ubuntu2~ppa1_amd64.deb ...
Unpacking cups-browsed (2.1.1-0ubuntu2~ppa1) over (2.1.1-0ubuntu1) ...
Setting up cups-browsed (2.1.1-0ubuntu2~ppa1) ...
Installing new version of config file /etc/apparmor.d/usr.sbin.cups-browsed ...
Failed to find declaration for: @{coreutil_dirs}
ERROR expanding variables for profile /usr/sbin/cups-browsed, failed to load
Setting up apparmor (5.0.0~alpha1-0ubuntu7) ...
Installing new version of config file /etc/apparmor.d/abstractions/bash ...
(...)
Installing new version of config file /etc/apparmor.d/tunables/global ...
(...)
Removing obsolete conffile /etc/apparmor.d/free ...
Removing obsolete conffile /etc/apparmor.d/curl ...
Reloading AppArmor profiles

Apparmor is unpacked before cups-browsed (who has the Breaks: apparmor
(<< 5.0.0~alpha1-0ubuntu7), but the file that contains the new
@{coreutil_dirs} definition is only installed later, in apparmor's
postinst (/etc/apparmor.d/tunables/global). The assumption was that it
would be available after apparmor was unpacked, but I guess due to the
config file management, that's not the case.

Also note that due to the way the apparmor profiles are loaded in most
(all?) postinsts, a failure there will not fail the package
installation, leaving the currently loaded profile intact. And in the
end, apparmor itself will reload the profiles.

Bottom line, the Breaks didn't help here, and it's debatable it will
help at all. It also introduces risk in the sense that the package
installation order will be changed.

Given that:
a) there is risk in introducing the Breaks this late in the game
(changes package installation ordering, forcing apparmor to be one of
the first)
b) failed postinst actions that reload the apparmor profile will not
fail the package installation
c) failed postinst to reload the apparmor profile will not touch the
already loaded profile, i.e., the confinement, whatever it was, stays
put
d) at some point, apparmor itself will reload all profiles, and at
that point the new variable definition will be in place
e) this change is happening during the development cycle still
f) users will get these new profiles via a release upgrade, or fresh
install, and both cases demand a reboot

I think that the Breaks addition should be skipped, unless we have a
clear bug where it is needed.

Thoughts?


Because of that risk, and the

1. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870/comments/7
2. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870/comments/17

On Fri, Sep 19, 2025 at 5:01 PM Andreas Hasenack
<andreas.hasenack@canonical.com> wrote:
>
> Hi,
>
> this is about LP: #2123870[1]. TL;DR is in comment #1[2]. We basically
> need to replace any reference to a coreutils binary in existing
> apparmor profiles to an expanded path list to cope with the different
> ways this binary can be called in questing.
>
> If using gnu-coreutils, we have a symlink /usr/bin/<tool> -> gnu<tool>
>
> If using rust coreutils, we have a symlink /usr/bin/<tool> ->
> /usr/lib/cargo/bin/coreutils/<tool>
>
> Since apparmor cares about the target, we have multiple possibilities
> for a rule that references, for example, /usr/bin/echo.
>
> In apparmor 5.0.0~alpha1-0ubuntu7[3], a variable was added to cope
> with these possibilities: @{coreutil_dirs}. See [4].
>
> We are now going over the list of affected profiles, and using that
> bug[1] to track the effort.
>
> At this time, this is NOT a call for help: this is a PSA/RFC. We might
> be touching a package you maintain and don't want uploaded now, or
> something else. These are all being done via git ubuntu PRs in
> launchpad. I expect some uploads will start happening early next week.
>
> Please reply if you have any comments, suggestions,
> zomg-please-dont-touch-my-package, etc.
>
>
> 1. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870
> 2. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870/comments/1
> 3. https://launchpad.net/ubuntu/+source/apparmor/5.0.0~alpha1-0ubuntu7
> 4. https://git.launchpad.net/ubuntu/+source/apparmor/commit/?id=e636b645358a49ec0845012a620061e203ab2cff

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

Re: Ubuntu 25.10 Beta Snap Problems

Hello Luna,

You are perhaps experiencing this bug:

Please take a look, and add any relevant details.

Thanks!
Tim Andersson

On Mon, Sep 22, 2025 at 4:03 PM Luna Jernberg <droidbittin@gmail.com> wrote:
Hey!

more people then me that have problem with snapd in Ubuntu 25.10 Beta?

running sudo snapd refresh in a terminal removes all installed snaps
and breaks snapd

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


--
Canonical-20th-anniversary
Tim Andersson

Software Engineer (Canonical Ubuntu Release Management)

Email:

tim.andersson@canonical.com

Location:

United Kingdom

canonical.com

ubuntu.com

Friday, 19 September 2025

PSA/RFC: apparmor profiles and coreutils

Hi,

this is about LP: #2123870[1]. TL;DR is in comment #1[2]. We basically
need to replace any reference to a coreutils binary in existing
apparmor profiles to an expanded path list to cope with the different
ways this binary can be called in questing.

If using gnu-coreutils, we have a symlink /usr/bin/<tool> -> gnu<tool>

If using rust coreutils, we have a symlink /usr/bin/<tool> ->
/usr/lib/cargo/bin/coreutils/<tool>

Since apparmor cares about the target, we have multiple possibilities
for a rule that references, for example, /usr/bin/echo.

In apparmor 5.0.0~alpha1-0ubuntu7[3], a variable was added to cope
with these possibilities: @{coreutil_dirs}. See [4].

We are now going over the list of affected profiles, and using that
bug[1] to track the effort.

At this time, this is NOT a call for help: this is a PSA/RFC. We might
be touching a package you maintain and don't want uploaded now, or
something else. These are all being done via git ubuntu PRs in
launchpad. I expect some uploads will start happening early next week.

Please reply if you have any comments, suggestions,
zomg-please-dont-touch-my-package, etc.


1. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870
2. https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2123870/comments/1
3. https://launchpad.net/ubuntu/+source/apparmor/5.0.0~alpha1-0ubuntu7
4. https://git.launchpad.net/ubuntu/+source/apparmor/commit/?id=e636b645358a49ec0845012a620061e203ab2cff

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

Thursday, 18 September 2025

Ubuntu 25.10 (Questing Quokka) Beta released

The Ubuntu Release team is pleased to announce the Beta release of the
Ubuntu 25.10 Desktop, Server, WSL, and Cloud products.

Ubuntu 25.10, codenamed Questing Quokka, continues Ubuntu's proud tradition
of integrating the latest and greatest open source technologies into a
high-quality, easy-to-use Linux distribution. The team has been hard at
work through this cycle, introducing new features and fixing bugs.

This Beta release includes images from not only the Ubuntu Desktop,
Server, WSL, and Cloud products, but also the Edubuntu, Kubuntu, Lubuntu,
Ubuntu Budgie, Ubuntu Cinnamon, UbuntuKylin, Ubuntu Studio, Ubuntu Unity,
and Xubuntu flavours.

The Beta images are known to be reasonably free of showstopper image
build or installer bugs, while representing a very recent snapshot of
25.10 that should be representative of the features intended to ship
with the final release expected on October 09, 2025.

Ubuntu, Ubuntu Server, Ubuntu WSL, Cloud Images:
Questing Beta includes updated versions of most of our core set of
packages, including a current 6.17 (rc) kernel, and much more.

To upgrade to Ubuntu 25.10 Beta from Ubuntu 25.04, follow these
instructions:

https://help.ubuntu.com/community/QuestingUpgrades

The Ubuntu 25.10 Beta images can be downloaded at:

https://releases.ubuntu.com/25.10/ (Ubuntu, Ubuntu Server, and WSL on x86)

This Ubuntu Server image features the next generation Subiquity server
installer, bringing the comfortable live session and speedy install of
the Ubuntu Desktop to server users.

Additional images can be found at the following links:

https://cloud-images.ubuntu.com/daily/server/questing/current/ (Cloud Images)
https://cdimage.ubuntu.com/releases/25.10/beta/ (Non-x86)

As fixes will be included in new images between now and release, any
daily cloud image from today or later (i.e. a serial of 20250903 or

higher) should be considered a Beta image. Bugs found should be filed
against the appropriate packages or, failing that, the cloud-images
project in Launchpad.

The full release notes for Ubuntu 25.10 Beta can be found at:

https://discourse.ubuntu.com/t/questing-quokka-release-notes/59220

Kubuntu:
Kubuntu is the KDE based flavour of Ubuntu. It uses the Plasma desktop
and includes a wide selection of tools from the KDE project.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/kubuntu/releases/25.10/beta/

Lubuntu:
Lubuntu is a flavor of Ubuntu which uses the Lightweight Qt Desktop
Environment (LXQt). The project's goal is to provide a lightweight
yet functional Linux distribution based on a rock-solid Ubuntu base.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/lubuntu/releases/25.10/beta/

Ubuntu Budgie:
Ubuntu Budgie is community developed desktop, integrating Budgie
Desktop Environment with Ubuntu at its core.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/ubuntu-budgie/releases/25.10/beta/

UbuntuKylin:
UbuntuKylin is a flavor of Ubuntu that is more suitable for Chinese
users.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/ubuntukylin/releases/25.10/beta/

Ubuntu Studio:
Ubuntu Studio is a flavor of Ubuntu that provides a full range of
multimedia content creation applications for each key workflow: audio,
graphics, video, photography and publishing.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/ubuntustudio/releases/25.10/beta/

Ubuntu Unity:
Ubuntu Unity is a flavor of Ubuntu featuring the Unity7 desktop
environment.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/ubuntu-unity/releases/25.10/beta/

Xubuntu:
Xubuntu is a flavor of Ubuntu that comes with Xfce, which is a stable,
light and configurable desktop environment.

The Beta images can be downloaded at:
https://cdimage.ubuntu.com/xubuntu/releases/25.10/beta/

Regular daily images for Ubuntu, and all flavours, can be found at:
https://cdimage.ubuntu.com

Ubuntu is a full-featured Linux distribution for clients, servers and
clouds, with a fast and easy installation and regular releases. A
tightly-integrated selection of excellent applications is included, and
an incredible variety of add-on software is just a few clicks away.

Professional technical support is available from Canonical Limited and
hundreds of other companies around the world. For more information
about support, visit https://ubuntu.com/support

If you would like to help shape Ubuntu, take a look at the list of ways
you can participate at:
https://ubuntu.com/community/participate

Your comments, bug reports, patches and suggestions really help us to
improve this and future releases of Ubuntu. Instructions can be found
at:
https://help.ubuntu.com/community/ReportingBugs

You can find out more about Ubuntu and about this Beta release on our
website, Matrix channel and Discourse.

To sign up for future Ubuntu announcements, please subscribe to Ubuntu's
very low volume announcement list at:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce


On behalf of the Ubuntu Release Team,
Utkarsh Gupta

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