New Kernel Uploaders

Today, the Kernel Uploaders Team[1] had an ad-hoc Matrix meeting on
#kernel:ubuntu.com with the following people in attendence:

Team Members:
Andy Whitcroft ~apw @apw:ubuntu.com
Benjamin Wheeler ~benjaminwheeler @bentel_inside:matrix.org
Bethany Jamison ~bjamison @bjamison:matrix.org
Edoardo Canepa ~ecanepa @ecanepa:matrix.org
Emil Renner Berthing ~esmil @esmil:matrix.org
Hui Wang ~hui.wang @hui.wang:matrix.org
Ian Whitfield ~ijwhitfield @ijwhitfield:ubuntu.com
Jacob Martin ~jacobmartin @jacobmartin:ubuntu.com
Jian Hui Lee ~jianhuilee @jianhuilee:matrix.org
Kevin Becker ~kevinbecker @kevinbecker:ubuntu.com
Kleber Sacilotto de Souza ~kleber-souza @kleber-souza:ubuntu.com
Kuan-Ying Lee ~kyyc0426 @kyyc0426:ubuntu.com
Kuba Pawlak ~kuba-t-pawlak @kuba-t-pawlak:matrix.org
Magali Lemes do Sacramento ~magalilemes @magalilemes:ubuntu.com
Manuel Diewald ~diewald @diewald:ubuntu.com
Mehmet Basaran ~mehmetbasaran @mehmetbasaran:ubuntu.com
Noah Wager ~nwager @nwager:ubuntu.com
Stefan Bader ~smb @esembee:matrix.org
Thibault Ferrante ~thibf @thibf:matrix.org
Tim Whisonant ~tswhison @tswhison:ubuntu.com
Timo Aaltonen ~tjaalton @tjaalton:ubuntu.com
Vinicius Peixoto ~vpeixoto @nukelet:nukelet.dev

Applicants:
Abdur Rahman ~maskedarray @maskedarray:ubuntu.com
Guoqing Jiang ~guoqingjiang @guoqingjiang:ubuntu.com
Massimiliano Pellizzer ~mpellizzer @mpellizzer:ubuntu.com

Observers:
Anthony Wong ~anthonywong @anthonywong:ubuntu.com
John Cabaj ~john-cabaj @john-cabaj:matrix.org

[1] https://launchpad.net/~ubuntu-kernel-uploaders

We reviewed the application[2] by Abdur Rahman (~maskedarray)[3] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Edoardo Canepa +1
Emil Renner Berthing +1
Hui Wang +1
Ian Whitfield +1
Jacob Martin +1
Kevin Becker +1
Kleber Sacilotto de Souza +1
Kuan-Ying Lee +1
Kuba Pawlak +1
Mehmet Basaran +1
Noah Wager +1
Stefan Bader +1
Thibault Ferrante +1
Timo Aaltonen +1
Vinicius Peixoto +1

The application was unanimously approved; congratulations to Abdur
Rahman.

[2] https://wiki.ubuntu.com/maskedarray/KernelUploadRightsApplication
[3] https://launchpad.net/~maskedarray

We reviewed the application[4] by Massimiliano Pellizzer
(~mpellizzer)[5] for Kernel Upload Rights. After representations by
the applicant and their sponsors a vote was held as below:

Edoardo Canepa +1
Hui Wang +1
Ian Whitfield +1
Jacob Martin +1
Kevin Becker +1
Kleber Sacilotto de Souza +1
Kuan-Ying Lee +1
Mehmet Basaran +1
Noah Wager +1
Stefan Bader +1
Thibault Ferrante +1
Tim Whisonant +1
Timo Aaltonen +1
Vinicius Peixoto +1

The application was unanimously approved; congratulations to
Massimiliano Pellizzer.

[4] https://wiki.ubuntu.com/MassimilianoPellizzer/KernelUploadApplication
[5] https://launchpad.net/~mpellizzer

We reviewed the application[6] by Guoqing Jiang (~guoqingjiang)[7] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Bethany Jamison +1
Edoardo Canepa +1
Emil Renner Berthing +1
Hui Wang +1
Ian Whitfield +1
Jacob Martin +1
Jian Hui Lee +1
Kevin Becker +1
Kleber Sacilotto de Souza +1
Kuan-Ying Lee +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Mehmet Basaran +1
Stefan Bader +1
Timo Aaltonen +1
Vinicius Peixoto +1

The application was unanimously approved; congratulations to Guoqing
Jiang.

[6] https://wiki.ubuntu.com/guoqingjiang/KernelUploadRightsApplication
[7] https://launchpad.net/~guoqingjiang

Congratulations to all of the successful applicants. Enjoy your new
rights. Andy Whitcroft (~apw) was tasked with adding them to the
~ubuntu-kernel-uploaders team and announcing these results.

-apw (on behalf of the ~ubuntu-kernel-uploaders team)

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

Upgrades to 25.10 (Questing Quokka) are now live!

Hey folks,

We're happy to announce that the upgrades to Ubuntu 25.10 (Questing Quokka) are now live!

This cycle also marks the arrival of amd64v3 as an architecture variant -- shiny, fast, and ready for testing. If you haven't already, I'd encourage reading the Discourse post for the full story:

https://discourse.ubuntu.com/t/introducing-architecture-variants-amd64v3-now-available-in-ubuntu-25-10/71312

Happy upgrading, and may your Quokka quest be bug-free!


On behalf of the Ubuntu Release team,
Utkarsh

SRU and Governance docs: migration complete

Hi all,

As originally suggested and discussed in an earlier thread [1], I have
now been able to migrate both SRU and Technical Board docs to the
all-encompassing Ubuntu Project docs set [2].

Redirects have been set up for both, so all existing links and bookmarks
should work. Still, if you come across any place that you can edit and
update the link there, please do. Also, if you discover a link that's
not being redirected as expected, please report it at [3].

......

Thanks a lot to everyone who helped with this effort. Special thanks to
Robie who stipulated the conditions for the move and subsequent
governance of the migrated content (and had patience as I blundered
along :))

Regards,
Robert

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2025-August/043423.html
[2] https://documentation.ubuntu.com/project/
[3] https://github.com/ubuntu/ubuntu-project-docs/issues

Re: OpenSSL version for Ubuntu 26.04

Hi Ravi,

From the Security Standards (FIPS, et al...) side, we agree that sticking to 3.5

is the best course of action.
Like you said, the timelines align perfectly. We also have the benefit of shipping

a release that has had time to be production hardened and for bugs to be fixed.

Like Athos suggested, we looked into the changes between version 3.5 and 3.6

and we still think it makes sense to keep 3.5. There are some changes that will

need to be included in our FIPS modules but we will handle backporting them.

Cheers,

On Tue, Oct 21, 2025 at 8:44 AM Ravi Kant Sharma <ravi-sharma@ubuntu.com> wrote:

Hi Athos, thanks a lot for your input.

I have added secuity@ubuntu to the thread.

I want to add https://launchpad.net/~canonical-security-certification
as well, I am not sure what is the best way to reach them.

Regards
Ravi

On Tue, Oct 21, 2025 at 3:52 AM Athos Ribeiro
<athos.ribeiro@canonical.com> wrote:
>
> On Mon, Oct 20, 2025 at 12:27:41PM +0200, Ravi Kant Sharma wrote:
> >Hello ubuntu-devel,
>
> Hi Ravi,
>
> >I am writing to get your opinion on the version of OpenSSL in Ubuntu 26.04 LTS.
> >
> >OpenSSL 3.5 is the current version in Resolute Raccoon release pocket.
> >From now on, only bug fixes and security patches will be applied to
> >3.5
> >It is an LTS release, it will be supported by upstream until
> >2030-04-08. There is a good overlap with 26.04 End of Standard Support
> >until 2031-04.
> >
> >OpenSSL 3.6 is the current upstream release
> >(https://github.com/openssl/openssl/releases/tag/openssl-3.6.0). It is
> >a Non-LTS release, and it will be full supported for 13 months
> >(2026-11)
> >
> >OpenSSL 4.0 is the next upstream release. It is also a Non-LTS, and It
> >will introduce API/ABI incompatible changes.
> >
> >26.04 Timeline
> >- Oct 1, 2025 OpenSSL 3.6 release
> >- February 19, 2026 Ubuntu Feature Freeze
> >- March 25, 2026 OpenSSL 4.0 Beta release (estimated)
> >- April 7, 2026 OpenSSL 4.0 Final release
> >- April 16, 2026 Ubuntu Final Freeze
> >
> >I am ruling out 4.0 since it will not be Feature Complete before
> >Ubuntu Feature Freeze, there isn't enough time for reverse dependences
> >to adapt to the breaking API/ABI changes, and we want to avoid a major
> >version bump just before an LTS. You can find a preview of 4.0
> >breaking changes under milestone
> >https://github.com/openssl/openssl/milestone/24.
> >
> >My proposal is to stay on 3.5 for 26.04 LTS to take advantage of the
> >upstream LTS, and move to 4.0 directly in 26.10. To make sure we are
> >not falling behind, I plan to do a test rebuild of 3.6 in a PPA.
> >
> >The downside is missing out on latest features from 3.6. Please let me
> >know what you think.
> >
> >References:
> >https://openssl-library.org/policies/releasestrat/index.html
> >https://openssl-library.org/roadmap/index.html
> >https://discourse.ubuntu.com/t/resolute-raccoon-release-schedule/47198
> >
> >Regards
> >Ravi
>
> As it is described in the upstream roadmap in your references
> (https://openssl-library.org/roadmap/index.html), the upstream project
> intends to have "a new [openSSL] LTS version designated at least every
> two years.", which seems to align quite well with our LTS cycles.
>
> In the last couple LTS cycles, I would often check for potential LTS
> releases of packages before merging them. From a maintenance
> perspective, I agree with the path you are proposing, i.e., staying in
> 3.5 so we can benefit from the upstream LTS support.
>
>  From a strategic perspective I would also take a look at why the minor
> version was bumped to 3.6 before deciding to stick to 3.5.
> https://github.com/openssl/openssl/releases/tag/openssl-3.6.0 lists the
> significant changes for openssl 3.6. From that list, they are mostly
> compliance/new features. These are the ones I found to be most relevant:
>
>    Added NIST security categories for PKEY objects.
>
>    Added support for EVP_SKEY opaque symmetric key objects to the key
>    derivation and key exchange provider methods. Added EVP_KDF_CTX_set_SKEY(),
>    EVP_KDF_derive_SKEY(), and EVP_PKEY_derive_SKEY() functions.
>
>    Added LMS signature verification support as per [SP 800-208]..
>    This support is present in both the FIPS and default providers.
>
>    Added support for FIPS 186-5 deterministic ECDSA signature
>    generation to the FIPS provider.
>
> It seems to be fair to stick to 3.5 then? Still, it may be a good idea
> to involve the security team since they would be in a better position to
> weight in from both stand points (providing support for the non LTS vs
> having the new compliance features).
>
> --
> Athos Ribeiro
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--

João Gomes
Linux Cryptography and Security Engineer
Email:	joao.gomes@canonical.com
Location:	Portugal
canonical.com
ubuntu.com

Re: OpenSSL version for Ubuntu 26.04

Hi Athos, thanks a lot for your input.

I have added secuity@ubuntu to the thread.

I want to add https://launchpad.net/~canonical-security-certification
as well, I am not sure what is the best way to reach them.

Regards
Ravi

On Tue, Oct 21, 2025 at 3:52 AM Athos Ribeiro
<athos.ribeiro@canonical.com> wrote:
>
> On Mon, Oct 20, 2025 at 12:27:41PM +0200, Ravi Kant Sharma wrote:
> >Hello ubuntu-devel,
>
> Hi Ravi,
>
> >I am writing to get your opinion on the version of OpenSSL in Ubuntu 26.04 LTS.
> >
> >OpenSSL 3.5 is the current version in Resolute Raccoon release pocket.
> >From now on, only bug fixes and security patches will be applied to
> >3.5
> >It is an LTS release, it will be supported by upstream until
> >2030-04-08. There is a good overlap with 26.04 End of Standard Support
> >until 2031-04.
> >
> >OpenSSL 3.6 is the current upstream release
> >(https://github.com/openssl/openssl/releases/tag/openssl-3.6.0). It is
> >a Non-LTS release, and it will be full supported for 13 months
> >(2026-11)
> >
> >OpenSSL 4.0 is the next upstream release. It is also a Non-LTS, and It
> >will introduce API/ABI incompatible changes.
> >
> >26.04 Timeline
> >- Oct 1, 2025 OpenSSL 3.6 release
> >- February 19, 2026 Ubuntu Feature Freeze
> >- March 25, 2026 OpenSSL 4.0 Beta release (estimated)
> >- April 7, 2026 OpenSSL 4.0 Final release
> >- April 16, 2026 Ubuntu Final Freeze
> >
> >I am ruling out 4.0 since it will not be Feature Complete before
> >Ubuntu Feature Freeze, there isn't enough time for reverse dependences
> >to adapt to the breaking API/ABI changes, and we want to avoid a major
> >version bump just before an LTS. You can find a preview of 4.0
> >breaking changes under milestone
> >https://github.com/openssl/openssl/milestone/24.
> >
> >My proposal is to stay on 3.5 for 26.04 LTS to take advantage of the
> >upstream LTS, and move to 4.0 directly in 26.10. To make sure we are
> >not falling behind, I plan to do a test rebuild of 3.6 in a PPA.
> >
> >The downside is missing out on latest features from 3.6. Please let me
> >know what you think.
> >
> >References:
> >https://openssl-library.org/policies/releasestrat/index.html
> >https://openssl-library.org/roadmap/index.html
> >https://discourse.ubuntu.com/t/resolute-raccoon-release-schedule/47198
> >
> >Regards
> >Ravi
>
> As it is described in the upstream roadmap in your references
> (https://openssl-library.org/roadmap/index.html), the upstream project
> intends to have "a new [openSSL] LTS version designated at least every
> two years.", which seems to align quite well with our LTS cycles.
>
> In the last couple LTS cycles, I would often check for potential LTS
> releases of packages before merging them. From a maintenance
> perspective, I agree with the path you are proposing, i.e., staying in
> 3.5 so we can benefit from the upstream LTS support.
>
> From a strategic perspective I would also take a look at why the minor
> version was bumped to 3.6 before deciding to stick to 3.5.
> https://github.com/openssl/openssl/releases/tag/openssl-3.6.0 lists the
> significant changes for openssl 3.6. From that list, they are mostly
> compliance/new features. These are the ones I found to be most relevant:
>
> Added NIST security categories for PKEY objects.
>
> Added support for EVP_SKEY opaque symmetric key objects to the key
> derivation and key exchange provider methods. Added EVP_KDF_CTX_set_SKEY(),
> EVP_KDF_derive_SKEY(), and EVP_PKEY_derive_SKEY() functions.
>
> Added LMS signature verification support as per [SP 800-208]..
> This support is present in both the FIPS and default providers.
>
> Added support for FIPS 186-5 deterministic ECDSA signature
> generation to the FIPS provider.
>
> It seems to be fair to stick to 3.5 then? Still, it may be a good idea
> to involve the security team since they would be in a better position to
> weight in from both stand points (providing support for the non LTS vs
> having the new compliance features).
>
> --
> Athos Ribeiro
>
> --
> 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

Re: OpenSSL version for Ubuntu 26.04

On Mon, Oct 20, 2025 at 12:27:41PM +0200, Ravi Kant Sharma wrote:
>Hello ubuntu-devel,

Hi Ravi,

>I am writing to get your opinion on the version of OpenSSL in Ubuntu 26.04 LTS.
>
>OpenSSL 3.5 is the current version in Resolute Raccoon release pocket.
>From now on, only bug fixes and security patches will be applied to
>3.5
>It is an LTS release, it will be supported by upstream until
>2030-04-08. There is a good overlap with 26.04 End of Standard Support
>until 2031-04.
>
>OpenSSL 3.6 is the current upstream release
>(https://github.com/openssl/openssl/releases/tag/openssl-3.6.0). It is
>a Non-LTS release, and it will be full supported for 13 months
>(2026-11)
>
>OpenSSL 4.0 is the next upstream release. It is also a Non-LTS, and It
>will introduce API/ABI incompatible changes.
>
>26.04 Timeline
>- Oct 1, 2025 OpenSSL 3.6 release
>- February 19, 2026 Ubuntu Feature Freeze
>- March 25, 2026 OpenSSL 4.0 Beta release (estimated)
>- April 7, 2026 OpenSSL 4.0 Final release
>- April 16, 2026 Ubuntu Final Freeze
>
>I am ruling out 4.0 since it will not be Feature Complete before
>Ubuntu Feature Freeze, there isn't enough time for reverse dependences
>to adapt to the breaking API/ABI changes, and we want to avoid a major
>version bump just before an LTS. You can find a preview of 4.0
>breaking changes under milestone
>https://github.com/openssl/openssl/milestone/24.
>
>My proposal is to stay on 3.5 for 26.04 LTS to take advantage of the
>upstream LTS, and move to 4.0 directly in 26.10. To make sure we are
>not falling behind, I plan to do a test rebuild of 3.6 in a PPA.
>
>The downside is missing out on latest features from 3.6. Please let me
>know what you think.
>
>References:
>https://openssl-library.org/policies/releasestrat/index.html
>https://openssl-library.org/roadmap/index.html
>https://discourse.ubuntu.com/t/resolute-raccoon-release-schedule/47198
>
>Regards
>Ravi

As it is described in the upstream roadmap in your references
(https://openssl-library.org/roadmap/index.html), the upstream project
intends to have "a new [openSSL] LTS version designated at least every
two years.", which seems to align quite well with our LTS cycles.

In the last couple LTS cycles, I would often check for potential LTS
releases of packages before merging them. From a maintenance
perspective, I agree with the path you are proposing, i.e., staying in
3.5 so we can benefit from the upstream LTS support.

From a strategic perspective I would also take a look at why the minor
version was bumped to 3.6 before deciding to stick to 3.5.
https://github.com/openssl/openssl/releases/tag/openssl-3.6.0 lists the
significant changes for openssl 3.6. From that list, they are mostly
compliance/new features. These are the ones I found to be most relevant:

Added NIST security categories for PKEY objects.

Added support for EVP_SKEY opaque symmetric key objects to the key
derivation and key exchange provider methods. Added EVP_KDF_CTX_set_SKEY(),
EVP_KDF_derive_SKEY(), and EVP_PKEY_derive_SKEY() functions.

Added LMS signature verification support as per [SP 800-208]..
This support is present in both the FIPS and default providers.

Added support for FIPS 186-5 deterministic ECDSA signature
generation to the FIPS provider.

It seems to be fair to stick to 3.5 then? Still, it may be a good idea
to involve the security team since they would be in a better position to
weight in from both stand points (providing support for the non LTS vs
having the new compliance features).

--
Athos Ribeiro

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

Resolute Raccoon is now open for development

Hi folks,

We're pleased to announce that Resolute is now open for development.
auto-sync will be enabled at a later date (as we're waiting on a few
toolchains and uploads to settle down a bit). As usual, we expect a
large influx of builds and autopkgtests in this initial period, which
will cause delays. Please help fix any breakage that occurs.

The release schedule can be found at

https://discourse.ubuntu.com/t/r-r-release-schedule/47198

Please see the release schedule page for information about any major
changes and for all milestone dates.

Please check your uploads in a resolute chroot. See [1] or [2] for
details on how to set up such a development chroot.

We're working with some folks to temporarily set up a resolute-changes
mailing list[3]. Once available, you can subscribe to receive the
changelog entry of package uploads to the archive for resolute.

[1] https://wiki.ubuntu.com/SimpleSbuild
[2] https://wiki.ubuntu.com/DebootstrapChroot
[3] https://lists.ubuntu.com/mailman/listinfo/resolute-changes

On behalf of the Release team,
Utkarsh

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