Hello everyone!

I’d like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will currently offer you Base, GNOME, and KDE.

Users can get our new Agama install images from get.opensuse.org/leap/16.0. The installer will currently offer you Base, GNOME, and KDE installation.

Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.

We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they’re used to from previous releases.

Further details are available on our roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.

Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.

There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS.

Who should get it?

This is a pre-alpha product that is not intended to be installed as your daily driver. I highly recommend starting with the installation in a virtual machine and becoming familiar with the online installer Agama.

The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware.

For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025.

How to report bugs?

I’d like to kindly ask you to check our Known bugs wikipage before reporting a new issue. If you find a new issue that is likely to affect users, please feel free to add it to the page.

Specifically for Agama I highly recommend using github.com/agama-project and collaborating with the YaST team on suggestions and incorporating any changes.

For the rest of the components, the workflow isn’t changing; just select version 16.0 for bug submissions.

Feature requests

All changes to packages inherited from SLES 16 need to be requested via a feature request.

Feature requests will be reviewed every Monday at a feature review meeting where we’ll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable.

The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running osc ls SUSE:SLFO:1.1:Build.

Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X. SLFO was previously known as Adaptable Linux Platform (ALP).

I highly recommend using code-o-o to co-ordinate larger community efforts such as Xfce enablement, where will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article.

Where to submit packages, how is it built, and where is it tested?

Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can mirror SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.

For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group. Later, we plan to rework the existing Leap 16.0 Images job group for testing the remaining appliance images.

The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).

Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers poo#164141 Leap 16.0 enablement and poo#166562 upgrade from 15.6.

Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we’d like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.

Involvement in branding and marketing efforts

I’m very proud to announce fresh branding efforts and want to thank all the people who helped give Leap and Tumbleweed a new look. We plan to publish an article or a video about the changes, and further plans as we still have a surprise or two in our pocket.

Do you want to help us on this front? Spread the news and feel free to join the openSUSE Marketing Team in our Telegram channel.

Many thanks to all who helped us to reach this point.

Lubos Kocman
on behalf of the openSUSE Release team

以前から告知しています通り、 2024/11/2〜3 に openSUSE.Asia Summit 2024 は東京で開催されます！
参加登録は Connpass からお願いします。

LT発表者募集

さて、今回の openSUSE.Asia summit 2024 も前回東京開催時と同様、LT＝Lightning Talkも行います。
発表時間は１人５分！　２日目、11/3 の全セッション終了後に枠を用意しています。
openSUSE や OSS に関わる内容であれば、どのような内容でも構いません。
限られた時間の中で、openSUSE やその他 Linux に関する熱い想い（？）を是非語り尽くしてください！

LT発表募集はこちらの Googleフォームからお願いします。
発表申込締切は、 10/26(sat) です！
アジアから多くの参加者が見込まれますので、スライドは英語にてお願いします。
※発表は日本語でもかまいません

openSUSE.Asia Summit 2024 への参加登録、及びLT発表を心よりお待ちしております！

Como ya sabréis, el 14 de octubre nos vamos de aniversario. Se están organizando eventos presenciales para celebrarlo, fiestas por el 28 aniversario KDE. ¿Te interesaría ver y escuchar a desarrolladores destacados del proyecto? Sigue leyendo.

Fiestas por el 28 aniversario KDE

Cada ciertos años la Comunidad KDE decide que es un buen momento para reunirse de forma local para celebrar que su proyecto cumple años. Se hizo un gran evento por el 25 aniversario, saliendo de la pandemia, y se ha ido replicando con otras excusas, como el megalanzamiento de Plasma 6.

Es hora de retomar la sana costumbre de reunirnos y ya s está empezando a organizar alguna cosa.De momento, se tienen previstas las siguientes actividades:

• Kochi, en la India.
• Berlín, en Alemania
• Budapest, en Hungría

En España estamos esperando que alguien se anime, así que estad atentos. A ver si los clásicos de Málaga, Valencia, Barcelona o A Coruña dan el paso.

Más información: KDE

Nacimiento del proyecto KDE

En la mesa que podemos ver en la imagen inferior Matthias Ettrich y Martin Konold hablaron sobre la creación de un proyecto que iba a ser parte fundamental del Software Libre y de la vida de cientos de desarrolladores.

Un poco más tarde, Mattias redactó y envió un 14 de octubre de 1996 el correo electrónico que a anunciaba el nacimiento de KDE y pidiendo desarrolladores que se involucraran en él. Seguidamente, creó la primera lista de correo del Proyecto KDE, que fue la principal vía de comunicación de los desarrolladores durante un tiempo.

Desde entonces ha llovido mucho. Y KDE ha pasado ser «The Kool Desktop Environment (KDE)» a ser una Comunidad donde tienen cabida todo tipo de personas con todo tipo de talentos, y no todos necesariamente ligados con la programación.

La entrada Fiestas por el 28 aniversario KDE se publicó primero en KDE Blog.

A pesar de que mayoritariamente el desarrollo del proyecto KDE se realiza mediante voluntarios, el trabajo que se está realizando desde la cabeza de la Comunidad, el KDE eV. posibilita, en ocasiones, utilizar sus fondos económicos para reforzar algunas de las funcionalidades de sus aplicaciones o diferentes frentes. Por ello me complace compartir con vosotros la oferta laboral de KDE e.V. y el equipo de Kdenlive publicada ayer en la página web oficial de la organización sin ánimo de lucro

Oferta laboral de KDE e.V. y el equipo de Kdenlive

Como podemos ver en el anuncio de la oferta laboral:

KDE e.V., la organización sin ánimo de lucro que apoya a la comunidad KDE, y el equipo de Kdenlive buscan contratistas proactivos para implementar algunas funciones en el editor de vídeo Kdenlive. Actualmente hay dos puestos vacantes:

• Integración de OpenTimelineIO: esto requerirá implementar un módulo C++ en Kdenlive para permitir la importación y exportación utilizando este estándar abierto, para permitir el intercambio de archivos de proyecto con otras aplicaciones. Consulte el anuncio de empleo para obtener más detalles sobre esta oportunidad de contratación.
• Integración de Audiowaveform: esto requerirá reescribir el código utilizado para generar y mostrar las formas de onda de audio en Kdenlive utilizando la biblioteca audiowaveform. Esto debería aportar formas de onda más rápidas y precisas en la línea de tiempo. Consulte el anuncio de empleo para obtener más detalles sobre esta oportunidad de contratación. Esperamos su solicitud.

Más información, con los anuncios de empleo detallados en KDE e.V.

¿Qué es KDE e.V.?

Lo cierto es que definir KDE e.V. es muy sencillo (incluso realicé un artículo explicándolo) per nunca está de más volver a explicarlo. Su concepto es algo que tenemos bastante interiorizado desde hace ya bastante tiempo gracias a otras organizaciones como  Oxfam, Cruz Roja o Ayuda en Acción.

Se trata organización sin ánimo de lucro registrada en Alemania que representa el  Proyecto KDE en asuntos legales y financieros. En otras palabras, es la parte que ayuda a la Comunidad KDE a asegurar los derechos de los proyectos KDE y se preocupa de promover el desarrollo de dicho Software.

Como toda organización que se precie tiene sus estatutos, formularios, asambleas e informes cuatrimestrales.

¿Qué es Kdenlive?

Kdenlive (acrónimo del inglés: KDE Non-Linear Video Editor) (?ke?d?n?la?v) es un editor de video no lineal para KDE que soporta todos los formatos de vídeos de codificador FFmpeg (DV, HDV, mpeg, avi, mp4, mov, flv, ogg, wav, mp3, vorbis, …) y los formatos de imágenes  clásicas (gif, png, jpeg, xcf, exr, tiff, svg, …)

Kdenlive se cimenta sobre Qt y la infraestructura (framework) de librerías KDE. Gran parte de los procesamientos de video son efectuados a través de MLT Framework, que se basan a su vez en otros proyectos Open Source tales como FFmpeg, freOr, movit, padspa, sox, etc.

Kdenlive ha sido concebido para responder a las más diversas exigencias de montaje y edición, desde nivel básico hasta los más elaborados niveles de edición profesional. No obstante, está desarrollado por un pequeño grupo de personas y la incorporación de nuevos miembros al equipo será siempre muy bienvenida e invaluablemente apreciada.

Además, tiene las siguientes características:

• Dispone de linea de tiempo con función búsqueda.
• Copiado y pegado de clips.
• Función deshacer completa.
• Captura de por Firewire: DV y HDV
• Captura por Video4Linux
• Exporta en diferentes formatos:  mpeg, avi, dv, flash, mov, …
• Múltiples efectos como: Automask,  Box Blur, Charcoal, etc.

Más información: Kdenlive

La entrada Oferta laboral de KDE e.V. y el equipo de Kdenlive se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2024/10/tumbleweed-review-of-the-week-2024-40/

Esta semana se han publicado un total de 6 nuevas snapshots (0926, 0927, 0929, 0930, 1001, y 1002).

Entre las actualizaciones que han traido estas snapshots se pueden destacar las siguientes:

• Bash 5.2.37
• cURL 8.10.1
• fwupd 1.9.25
• GStreamer 1.24.8
• GTK 4.16.2
• Linux kernel 6.11.0
• openSSH 9.9p1
• systemd 256.6
• TCL 8.6.15
• PostgreSQL 17.0
• LibreOffice 24.8.2.1
• PHP 8.3.12
• Audit 4.0
• timezone 2024b
• Virtualbox 7.1.0
• Cups 2.4.11
• AppArmor 4.0.3
• grub2

Y entre las actualizaciones que se están preparando para próximas snapshots, se pueden destacar las siguientes:

• Libproxy 0.5.9
• KDE Plasma 6.2
• GNOME 47
• Busybox 1.37.0
• XWayland 24.1.3
• LLVM 19
• Mesa 24.2.x

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

We released six snapshots during 2024/40 (0926, 0927, 0929, 0930, 1001, and 1002). Based on personal feelings, the week seemed ‘mixed’ – Requests came in, and requests went out. And a few things seem to hang there for longer again.

Let’s first look at what you have received during the last week, starting on the positive side of things:

• Bash 5.2.37
• cURL 8.10.1
• fwupd 1.9.25
• GStreamer 1.24.8
• GTK 4.16.2
• Linux kernel 6.11.0
• openSSH 9.9p1
• systemd 256.6
• TCL 8.6.15
• PostgreSQL 17.0 (final release)
• LibreOffice 24.8.2.1
• PHP 8.3.12
• Audit 4.0
• timezone 2024b
• Virtualbox 7.1.0
• Cups 2.4.11
• AppArmor 4.0.3
• grub2: introduces a new package, grub2-x86_64-efi-bls, which includes a straightforward grubbls.efi file

On the staging projects, we have some larger changes being worked on by multiple people. Some of the more interesting changes to come are:

• Libproxy 0.5.9
• KDE Plasma 6.2
• GNOME 47: webkit2gtk3 breaks python-wxPython on i586; help appreciated
• Busybox 1.37.0
• XWayland 24.1.3
• LLVM 19
• Mesa 24.2.x: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11840
• Change of the default LSM (opted in at installation) to SELinux. AppArmor is still an option, just not the default. This change only impacts new installations.

Hace mucho tiempo publiqué el mapa generado en Google de los usuarios de KDE. Ese mapa era colaborativo y voluntario pero generado sobre Software Privativo. En varias ocasiones pedí que alguien lo cambiara a OpenStreetMap y mis súplicas fueron escuchadas. Ya casi había olvidado este proyecto pero este agosto lo recuperé, publicitándolo en el grupo de Telegram KDE – Cañas y Bravas y parece que el proyecto ha tomado impulso, así que he decidido seguir ppublicitándolo durante unos meses. Así que bienvenidos a la actualización de octubre_24 del mapa de usuarios KDE que, como vais a ver, se ha llenado un poquito ¡Ya tenemos gente en Castellón y Badajoz (capitales de provincia que antes estaban sin ningún usuario)

Actualización de octubre_24 del mapa de usuarios KDE

Si vais a ver el mapa de la Comunidad KDE de España marzo 2018, podréis ver una imagen estática de los usuarios que se habían puesto voluntariamente , y digo estática, porque alguien borró (queriendo o sin querer) los «pines» del mapa.

Ese incidente fue comentado en el grupo de Telegram KDE – Cañas y Bravas, y un usuario dijo que trabajaría en ello aprovechando que se debía empezar de nuevo el mapa.

Este compañero de grupo era @wakutiteo y creó, utilizando los servicios de uMap sobre OpenStreetMap el nuevo mapa de la usuarios KDE en España en el que podemos empezar a registrarnos.

En un principio había poca poca gente apuntada (mirad la entrada de junio de 2018) pero poco a poco se ha ido llenando, a pesar de la poca promoción que ha tenido. A ver si a partir de ahora voy dándole más cancha y el mapa crece . De momento pongo la captura de pantalla de este mes de agosto, la del mes de septiembre y la de este octubre del 2024 para que veamos la evolución, lenta pero constante.

Agosto 2024

Septiembre 2024

Octubre 2024

Como vemos, siguen apareciendo poco a poco más usuarios. Este mes destaco que tras una petición propia en el grupo Telegram de «Cañas y bravas» de KDE España ya tenemos un usuario registrado en Castellón y que justo iba a reclamar que no hubiera nadie en Extremadura y justo me encuentro a alguien en Badajoz.

Ahora bien, ¿no hay nadie en Cáceres? ¿Ni en Lleida? ¿Ni en Cuenca o Salamanca, por poner algunas capitales de provincia? ¡Vamos animaros! Luchemos contra la España Vaciada.

Evidentemente, es voluntario y apuntaros bajo vuestra propia responsabilidad. Os dejo también el mapa incrustado que se irá actualizando poco a poco.

Pincha para ver en pantalla completa

Y también os dejo un vídeo de cómo editar el mapa para poder apuntaros.

¿Qué es Umap?

Básicamente, con uMap puedes crear mapas con capas de OpenStreetMap en un minuto e incrustarlo en tu página web, de código libre. Con uMap puedes realizar las siguientes acciones:

• Elegir las capas de tu mapa
• Añadir PDIs: marcadores, líneas, polígonos…
• Elegir los colores y los iconos de los PDIs
• Gestionar opciones del mapa: mostrar un minimapa, localizar al usuario al cargar…
• Importar por lotes datos geoestructurados (geojson, gpx, kml, osm…)
• Elegir la licencia de tus datos
• Embeber y compartir tu mapa

La entrada Actualización de octubre_24 del mapa de usuarios KDE se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Vulnerability Details
• 3) Embargo Process and Upstream Communication
• 4) SUSE Bugfix
  • Improved version of the Patch after Discussions in the Community
• 5) Upstream Bugfix
• 6) Timeline
• 7) References
• 8) Change History

1) Introduction

oath-toolkit contains libraries and utilities for managing one-time password (OTP) authentication e.g. as a second factor to password authentication. Fellow SUSE engineer Fabian Vogt approached our Security Team about the project’s PAM module. A couple of years ago, the module gained a feature which allows to place the OTP state file (called usersfile) in the home directory of the to-be-authenticated user. Fabian noticed that the PAM module performs unsafe file operations in users’ home directories. Since PAM stacks typically run as root, this can easily cause security issues.

The feature in question has been introduced in oath-toolkit version 2.6.7 (via commit 60d9902b5c). The following report is based on the most recent oath-toolkit release tag for version 2.6.11.

2) Vulnerability Details

The PAM module is typically configured using a PAM stack configuration line like this:

auth [user_unknown=ignore success=ok] pam_oath.so usersfile=${HOME}/user.oath window=20

The expansion logic of the path components ${HOME} or ${USER} is part of the problematic feature that introduced the security issue.

The PAM module invokes a liboath library function called oath_authenticate_usersfile() found in liboath/usersfile.c, which manages all accesses to the usersfile. Privileges are not dropped, and the function is not aware of the special privileged PAM context. All file accesses in the function are naive and follow symlinks. The relevant file operations that are carried out on successful OTP entry are as follows:

• opening of the usersfile via fopen() for reading (usersfile.c:470).
• opening of a lockfile parallel to the usersfile using a filename suffix “.lock” via fopen() for writing (usersfile.c:332)
• locking of the lockfile using POSIX advisory locks via fcntl() (usersfile.c:350)
• creation of a new usersfile parallel to the old usersfile using a filename suffix “.new” via fopen() (usersfile.c:372)
• changing ownership of the new usersfile to the to-be-authenticated user via fchown() (usersfile.c:394)
• renaming of the new usersfile to the old usersfile via rename() (usersfile.c:411)
• unlinking of the previously created lockfile (usersfile.c:423)

If this happens in a PAM stack running as root and the usersfile is located in an unprivileged user’s home directory, then a simple root exploit is possible by placing a symlink like this:

user$ ln -s /etc/shadow $HOME/user.oath.new

This will cause /etc/shadow to be overwritten and its ownership will be changed to the to-be-authenticated user. The to-be-authenticated user can obtain full root privileges. No race condition needs to be won and no pathnames have to be guessed.

3) Embargo Process and Upstream Communication

Fabian Vogt first approached the main upstream author by email. Since we did not get a reaction for several days, we created a private Gitlab issue in the upstream project, offering coordinated disclosure. There was no reaction, thus we decided to handle the embargo and bugfix ourselves, since we needed a fixed pam_oath module for our products. We developed a comprehensive patch, described in Section 4) below.

We requested a CVE from Mitre for this issue and they assigned CVE-2024-47191.

As we were preparing to go public, the upstream author got pinged via private channels and reacted to our report, preparing an upstream bugfix release addressing the issue, described in Section 5) below.

Due to time constraints, we have decided to apply our SUSE bugfix to our products for the time being, until we can evaluate the upstream solution in more depth.

4) SUSE Bugfix

We developed a patch within SUSE to address the issue (note that there is an improved version of the patch available by now). The situation for the bugfix is more complex than it might look at first, because many things are unclear or broken in the current source code:

• the PAM module cannot know for sure if the target usersfile is supposed to be owned by root or by the to-be-authenticated user, or even some unrelated user. The presence of a ${HOME} path element makes it likely that the to-be-authenticated user is supposed to own the file. The presence of a ${USER} element is not that clear, however.
• the locking mechanism used in the current source code is broken:
  • the usersfile is initially opened for reading and parsed without owning the lock (usersfile.c:470). A parallel task can be about to replace this file with a new version, thus a lost update can occur.
  • the lock file is unlinked again after the usersfile has been updated (usersfile.c:423). This breaks when another task is waiting on the now-unlinked lockfile, while a third task arrives, sees no lockfile and creates a new one.
• the lockfile is placed in the user’s home directory, possibly cluttering it. Cases like the home directory being a network file system (NFS, CIFS) would need to be considered. The unprivileged user might also prevent the privileged PAM stack from obtaining the lock, causing a local denial-of-service.

We decided to develop a patch that takes as many use cases as possible into account, securing all operations while maintaining backwards compatibility. With the patch, the usersfile path is safely traversed using the *at family of system calls. Privileges will be dropped to the owner of the usersfile as an additional security measure. The locking mechanism has been fixed to cover all accesses to the usersfile. Instead of creating a separate lockfile, the usersfile itself is used for locking, which avoids cluttering the home directory. Additional sanity checks are added e.g. world-writable directory components are denied. The patch employs Linux specific features (e.g. linking files from /proc/self/fd), thus it no longer works for non-Linux systems. The patch description and code comments contain more hints about the individual decisions taken in this patch.

Improved version of the Patch after Discussions in the Community

After detailed discussions on the oss-security mailing list a few shortcomings of the original SUSE patch have been identified:

• the patch lacks logic to drop supplemental group membership, which typically results in the process retaining root group membership. Since the privilege drop in the patch only serves as a hardening this is not critical.
• the patch does not deal with potential hard link attacks. Hard link attacks are difficult to protect from, which is why on SUSE distributions the kernel sysctl “sys.fs.protected_hardlinks” is active by default. This way the kernel prevents dangerous uses of hardlinks.

For completeness we offer an improved patch that addresses these two aspects. The approach taken in the patch - to accept any ownership of the target file - makes it impossible to fully protect against all hardlink attack scenarios, though. This is outlined by Solar Designer in the thread on the oss-security mailing list.

5) Upstream Bugfix

Upstream developed an alternative solution, designed to be more portable and cross-platform. This does not take into account all aspects that we considered in Section 4), but should be sufficient to fix the specific security issue described in this report.

This fix has been released in version 2.6.12 of oath-toolkit. Upstream has also published an associated Security Advisory.

6) Timeline

7) References

• oath-toolkit repository
• oath-toolkit vulnerable usersfile commit
• oath-toolkit upstream private issue
• SUSE improved bugfix
• SUSE initial bugfix (old version)
• oath-toolkit Security Advisory for CVE-2024-47191

8) Change History