November 2021 - devel - lists.apertis.org

New Apertis v2020.7 stable release available
by Walter Lozano 25 Nov '21

25 Nov '21

1 0

Apertis release candidate v2021.3rc1 available for testing
by Walter Lozano 24 Nov '21

24 Nov '21

Hello everyone, I'm glad to announce that Apertis v2021.3rc1 images for all the supported platforms have been published: AMD64 https://images.apertis.org/release/v2021/v2021.3rc1/amd64/ Arm32 public https://images.apertis.org/release/v2021/v2021.3rc1/armhf/ Arm32 internal https://images.apertis.org/internal/release/v2021/v2021.3rc1/armhf/ Arm64 https://images.apertis.org/release/v2021/v2021.3rc1/arm64/ Compared to v2021.2 this release contains: - Security updates from Debian Buster - Backport the changes for the TLS stack [1] from v2022 to avoid licensing issues - New version of glib-networking to properly support OpenSSL backend The test reports are below: * https://lavaphabbridge.apertis.org/report/v2021/20211124.0215/apt * https://lavaphabbridge.apertis.org/report/v2021/20211124.0215/ostree * https://lavaphabbridge.apertis.org/report/v2021/20211124.0215/lxc * https://lavaphabbridge.apertis.org/report/v2021/20211124.0215/nfs The full release schedule is described at https://www.apertis.org/release/v2021.3/release_schedule/ Thanks, Walter [1] https://www.apertis.org/concepts/tls-stack/ -- Walter Lozano Collabora Ltd.

1 0

Apertis release candidate v2020.7rc1 available for testing
by Walter Lozano 17 Nov '21

17 Nov '21

Hello everyone, I'm glad to announce that Apertis v2020.7rc1 images for all the supported platforms have been published: AMD64 https://images.apertis.org/release/v2020/v2020.7rc1/amd64/ Arm32 public https://images.apertis.org/release/v2020/v2020.7rc1/armhf/ Arm32 internal https://images.apertis.org/internal/release/v2020/v2020.7rc1/armhf/ Arm64 https://images.apertis.org/release/v2020/v2020.7rc1/arm64/ Compared to v2020.6 this release contains: - Security updates from Debian Buster - Backport the changes for the TLS stack [1] from v2022 to avoid licensing issues - New version of glib-networking to properly support OpenSSL backend The test reports are below: * https://lavaphabbridge.apertis.org/report/v2020/20211117.0/apt * https://lavaphabbridge.apertis.org/report/v2020/20211117.0/ostree * https://lavaphabbridge.apertis.org/report/v2020/20211117.0/lxc * https://lavaphabbridge.apertis.org/report/v2020/20211117.0/nfs The full release schedule is described at https://www.apertis.org/release/v2020.7/release_schedule/ Thanks, Walter [1] https://www.apertis.org/concepts/tls-stack/ -- Walter Lozano Collabora Ltd.

1 0

Planned maintenance downtime for gitlab.apertis.org
by Emanuele Aina 10 Nov '21

10 Nov '21

Hello all, later today we plan to have some downtime on https://gitlab.apertis.org as it will get moved to a VM with more space for us to chew with our ever increasing set of images and artifacts, om nom nom. Thank you for your patience, we'll keep you updated! -- Emanuele Aina www.collabora.com

1 0

Use of LGPL-3 or GPL-2 dual-licensed Nettle on Apertis v2020 and v2021 images
by Emanuele Aina 08 Nov '21

08 Nov '21

Hello all, the latest source code scan highlighted that the version of Nettle used on Apertis target images for the v2020 and v2021 releases is already subject to the relicensing to LGPL-3 or GPL-2 and it is no longer LGPL- 2.1 licensed as the metadata from the original Debian package sources indicated. This means that any program using libnettle, and by extension libraries like libgnutls, glib-networking and libsoup, has to be licensed under the terms of the GPL-2 or the terms of the LGPL-3 license should be applied to libnettle. This goes against the Apertis licensing expectations[1] therefore we are now working on a fix. The v2022 release channel is not affected thanks to the rework of the TLS stack usage[2] done in that channel. The recent documentation work helped raising the awareness of the issue, identifying its impact and the possible ways to address it. We currently plan to backport the changes from v2022 to v2021, and even v2020. Usage of libnettle and its reverse dependencies like libgnutls will still be subject to the LGPL-3 or GPL-2 dual-license, but libraries like glib-networking and libsoup will be moved to the OpenSSL backend to avoid the issue. Check the document about the TLS stack licensing[2] for further details. In case of any doubt, we are available for any inquiry and clarification about the impact of the issue. Thank you! [1] https://www.apertis.org/policies/license-expectations/ [2] https://www.apertis.org/concepts/tls-stack/ -- Emanuele Aina www.collabora.com

2 1