El cliente de correo de software libre Thunderbird para equipos de escritorio sigue su desarrollo para extender su software a sistemas Android uniéndose al cliente K9 mail

Como usuario de Thunderbird en mi sistema GNU/Linux y K9mail en mi dispositivo móvil, me gusta seguir de cerca las novedades de la fusión de ambos proyectos para llegar a tener Thunderbird en dispositivos Android.

Por eso quiero difundir en el blog las novedades que han realizado en este pasado mes de marzo de 2024.

Para K-9 Mail, las nuevas versiones estables suelen incluir muchos cambios. K-9 Mail 6.800 no fue la excepción. Eso significa que hay muchas posibilidades para introducir accidentalmente nuevos errores.

Se prueban de varias maneras esas nuevas versiones, pero nadie está exento de cometer errores y normalmente se dedican un par de semanas después de una nueva versión importante para corregir los errores reportados.

Así se han corregido varios errores, como por ejemplo:

• Dejar de usar mayúsculas en las direcciones de correo electrónico
• Saltos de línea en entradas de texto de una sola línea
• ¿DNSSEC? ¿Alguien está usando eso?
• Mensaje de error extraño sobre un fallo de OAuth 2.0
• Fallo al descargar un archivo adjunto
• No escribas novelas en la línea de asunto

Pero aún así también se trabaja no solo en solucionar errores nuevos o errores que llevan en el software desde 2017 si no que también se prepara la nueva versión para K9 mail, la que será K9mail 6.802.

• Metadatos en F-Droid
• Push no funciona debido a que falta el permiso

Estos son solo los «titulares», tenéis toda la información detallada en su blog oficial.

A lot has been written about the XZ Backdoor in the last few weeks, so it is time to look forward. Before doing so, we share a bit about what happened with regards to openSUSE.

Behind the scenes

A few days before the public disclosure of the XZ backdoor, the SUSE product security team was getting a hint that there is something odd with the XZ 5.6.x releases. I am the SUSE employee and openSUSE packager that was updating and including this version into openSUSE Tumbleweed, so I got involved in this quite early. By that time, no context and information that was shared publically in the initial public disclosure was available to us. However, that hint was all the information that was needed. It changed the way we looked at an established, central open-source project. Without that, the odd small diff in the “configure” stage of the build system would have been easily disregarded.

One day before disclosure, on Thursday evening, SUSE product security received a longer and detailed report from Andres Freund via the shared distros security disclosure list. The distros list is an encrypted mailing list where distributors collaborate and coordinate on coordinated disclosures of security issues. This report brought the new knowledge that the xz backdoor specifically targeting openssh, which is one of the network facing parts of nearly every Linux system. This even further increased our threat level to be of a remote access backdoor and caused also to widen our planned communication efforts.

The SUSE security team and I started analyzing. SUSE product security is a member of various private security forums, like the distros list and CERT VINCE and others, which allow us the coordinate fixes between software vendors and have updates ready on the disclosure dates. With initial information that there is something suspicious, it was relatively easy to find more suspicious things in no particular order:

• openSUSE and SUSE is tracking release artifact signatures with a keyring of trusted signatures. We noticed that the key that the artifacts were signed with changed some time ago, so we had to update our trusted keyring for the XZ project. We validated that there was a maintainer handover and that the new maintainer has direct commit access as well as the ability to sign releases and publish them. The web of trust of this new signing key was not well connected, which could have raised an alert, but it was signed by the previous maintainer and that was sufficient for us.

• Looking at the commit history, there was a flurry of commits between the last 5.5 beta and the 5.6.0 release in a short time window by only one committer; not coming via a Pull Request and no obvious review or discussion on it. This was immediately concerning. Normally projects do not do that just before a major new release. Reviewing every single commit immediately showed odd test files being committed and updated in 5.6.1, and that did not have corresponding updates in the test framework or in the project code, so these were “unused”. Normally test files are committed alongside a code fix in the same commit, or with a reference to a prior issue, or a commit that the test case is addressing. For an experienced maintainer of an upstream project, this seemed like a big oversight. The commit messages were sort of plausible but not really making sense, especially when comparing the (small) differences between 5.6.0 and 5.6.1.

Further investigation lead to finding the “stage zero” embedded in the build system and with that we were able to step through the layers of obfuscation to untangle the second and third stage. Within minutes, it became clear to us that very significant effort was spent on developing it. It wasn’t the work of a single developer on a rainy Sunday afternoon. Also, the second stage hinted that this was a backdoor that was specifically targetting for only specific environments, Debian or RPM package builds using GCC and glibc. A normal user building from source, either the backdoored tarball or from git would have never been affected. This raised the alarm bells. So before we went further with the reverse engineering, we assessed the impact.

For a while, openSUSE has not been using xz for compression of our distribution rpm packages. we switched to Zstd a while ago. However, xz is very widely used in the distribution, amongst many other things for uncompressing the sources of our GCC compiler that we use to build everything else in the distribution. We checked and saw that the suspected malicous XZ release was being used for building our active openSUSE GCC compiler, which is used in every other build of the distribution. The worst case scenario to think of here is that the unpacking of the GCC compiler build sources was being modified by the malicious xz and we have a system compiler that was no longer trustworthy. Although we do have signature checks on the sources (and have secured copies of every source input we ever used anywhere in a trusted lookaside store), we have no checks whether the unpacked sources are actually the sources that were signature checked prior unpacking.

So even without any information further about the backdoor, we understood that the impact worst case could be disastrous. So we started identifying affected projects, products and distributions. Fortunately that list turned out to be fairly small. An ad hoc team was formed to handle the removal of the backdoor.

Initial Removal of the Backdoor for our users

openSUSE Tumbleweed ships an emergency update channel that we can use to recover from fatal regressions in the regular Tumbleweed snapshots. These are extremely rare thanks to our automated testing pipeline, but they do happen. We injected a downgrade of xz into that emergency update channel and started building an interim openSUSE snapshot release that had the malicious xz update removed. However, due to the unknown nature of the obfuscated backdoor, we were planning with the worst assumption. We started collecting how many packages have been built and released with the build of the suspect GCC compiler within the build environment. It was a very large list. Also, making sense of the reversing of the malicious backdoor object code in Ghidra would take us another couple of hours. After a short sync, we decided to go for the safe route and throw away every package that was built with the potentially malicious xz/GCC and started rebuilding all of them with only packages that were coming from a safe backup, to restore integrity of our distribution as quickly as possible. openSUSE is regularly testing this “bootstrap mode” as part of our distribution development and relies on the rebuild automation provided by the Open Build Service, so this wasn’t a lot of human work. It was just a lot of load for our build cluster. We had a couple of hours of waiting in front of us, which allowed further analyzing the backdoor.

Analysis of the backdoor

Analysis of the object code turned out to be time intensive. While the second stage that checked for the right build conditions (is it a distribution build, does it have the expected compiler environment etc) was easy to decode and helped us understand the potential impact, initially it wasn’t really clear to us what the obfuscated object code that was injected during the build was doing.

By using Ghidra, we were able to get somewhat readable C code back from the injected machine code, so we started trying to decipher the puzzle of code. Spotting the entry point in the _get_cpuid function that was part of the IFUNC handling was one of the first findings. Just googling these combination of words led to an upstream discussion, to the disablement of ifunc in the oss fuzz project and an interesting bug report in the Fedora community where valgrind issues were reported with XZ 5.6.0 and apparently the upstream was fixing those by updating unrelated things including “the test files” in the repository. There was not only commits in the repository but also misleading communication around the issue directly related to those commits, which made it obvious that we were not finding an unfortunate accident by an innocent maintainer who might have been hacked, but a planned action by the current upstream maintainer. Just in case the alarm bells weren’t loud enough already, this doubled their noise level.

Preparing for the Public Disclosure

Combining all of what we learned so far, the picture became clearer. Somebody has spent years of preparation to lay down the ground work, build up a good maintainer reputation, take over the project and then chose a point in time that was a critical time window for several distribution projects and in the middle of Lunar New Year as well as other holidays to release a new release with new features and an obfuscated backdoor that was well crafted to target only specific distributions, namely those using GCC, Binutils, Glibc with RPM or Debian build processes on x86_64.

With all of that in mind, we realized that there is going to be a lot of public coverage on this. It will be in the news for days to weeks. So we started a new workstream to prepare for that with the comms teams.

Public Disclosure

By the time of the public disclosure, all workstreams had already completed. We identified the list of affected products, and had already released all updates for all affected ones. Communication was ready to be put online and sent out to the relevant parties. All of that was possible because many people went above and beyond, put everything else aside to react timely and with a lot of engagement to ensure we haven’t missed anything or overlooked anything; all this while a long public holidays weekend had already started. Kudos to everyone who was working around the clock on preparing for this.

Hero of the story

That nothing worse happened is only thanks to Andres Freund, a developer in the PostgreSQL community that was not skipping over an odd performance regression of ssh logins to his recently upgraded debian unstable installation. Another testiment that not letting go on something that everyone else likely would have ignored for the next months to years is what makes a hero a hero.

However, relying on heroes is not a sustainable and reliable strategy. So for the future, we all need to learn from what happened and need to become a large team of small heroes.

Time to look forward and learn from the mistakes

Many words have been written on what happened. Timelines have been written, actors named. The backdoor has been reversed and the understanding of the purpose of the code has been published in a lot of detail.

It’s time to look forward. Linux distributions were abused to deliver a backdoor to their users. What the exact purpose of the backdoor was is still speculation. It could be all from an individual who wanted to sell access to abundant compute power via public cloud hosted virtual machines that have a vulnerable ssh port open to the public. Which is the rather unlikely, but still possible, one end of the spectrum. The other end of the spectrum is a company that sells backdoors to state actors that make use of those to remotely and covertly access any Linux machine. Although mistakes were made, it almost achieved that goal. Where is the truth? Further evidence needs to be identified and analyzed for that.

Linus Law and the distributions

“Given enough eyeballs, all bugs are shallow”. In Open Source communities, this is cited a lot as a reason for why open source can be trusted. For open-source projects that are attracting enough attention from sufficiently skilled contributors, this “law” probably has at least some weight. However, we learned for example from Heartbleed that these preconditions are not universally fulfilled. There are are many projects that are absolutely essential and yet are considered boring and fail to attract a lot of maintainers or contributors, and those who are on the project are buried under a pile of work already and can’t really spend significant effort on ramping up new joiners.

However, as explained earlier, this backdoor was only targetting distributions. First, by the prechecks that the backdoor executed before unfolding, but also because the conditions necessary for implanting were only existing downstream in these distributions. Debian, as well as the other affected distributions like openSUSE are carrying a significant amount of downstream only patches to essential open-source projects, like in this case openssh. With hindsight, that should be another heartbleed level learning for the work of the distributions. These patches were building the essential steps to embed the backdoor, and have not the scrutiny that they likely would have received by the respective upstream maintainers. Whether you trust Linus Law or not, it was not even given a chance to chime in here. Upstream did not fail on the users, distributions failed on upstream and their users here.

Open source and their communities

Being able to inspecting source code of open-source software gives the community an unbeatable advantage over proprietary single-vendor alternatives. However, auditing source code is time intensive and often needs highly experienced domain and security experts. Commercial distributions should and are playing an important role in this; yet they have not identified this. The XZ project was in that sense the perfect blind spot for how effort is typically allocated for security audits. Very deeply nested and important for every distribution due to non obvious reasons, and in the state of only one maintainer and very few contributors or reviewers for years. It is not the shiny new cloud native or otherwise fancy new open-source project that attracts thousand of developers or security researchers, and yet it is just as important for the integrity and security of modern computing. If anything there is to learn here, is that the selection criterias for where to focus on needs to be adjusted with these learnings.

Furthermore, others have already emphasized that the initial attack vector wasn’t technical. It wasn’t an archaic tarball. The actual initial attack was social engineering and used toxic behavior in communities. This is real and not only in this case affects the existing maintainers of open-source projects. Many stories have been told where maintainer stress or burn out was connected to toxic participants in the project communities. Although I believe the distributions are not part of those activities, we are not set up to prevent these things from happening. The distribution developers are focused on their issues and their users and are, due to the limited time, then risking to neglect the (upstream) open-source communities. This is another thing that we need to keep in mind.

Initiatives like CHAOSS and the Open Source Security Foundation have been founded because otherwise these situations would be too easy to miss. They provide essential service toward analyzing the “bus factor”, or the “collusion factor” of how many actors are needed to subvert a project and thereby allow others to focus on directing help where it matters the most.

The cost of Freedom

FLOSS is not about cost, or about being free to use, but about the freedom to inspect and (re-)use. What is the cost of that freedom? In a proprietary world, software is paid for. In open source, that freedom needs to receive the recognition it deserves and needs to be valued. When somebody refers to the XZ backdoor as a Software Supply Chain Security incident, that is not the full picture. A Software Supply chain would be where there is a supplier at one end. But open-source projects and communities are not suppliers today. They have no legally binding contract with any of their consumers, and there is no exchange of money involved. There exists a community, varying in size, that contributes and assists, either as volunteers or as paid workers. Most projects are not receiving enough of it.

As an open ended thought: Should distributions actively build up and manage their supply chain and treat “their suppliers” as real suppliers with legally binding mutual terms and conditions and agreed upon compensations?

The Secure Web of Trust is the new Supply Chain Security

In this particular incident, signed tarballs were used to publish the launcher of the backdoor. Many things have been said about that. We need to realize that this is a distraction. A trap. In terms of code size, 99.9% of the backdoor was in the source code repository. The launcher in the tarball was to limit the exposure of the backdoor to only the intended victims, not technically needed for anything or by anything. It would have been equally easy to embed and equally hard to spot with the rest of the 0.1% being also committed inside the project code repository, just in a marginally different way.

For most other thinkable attack scenarios, signed release artifacts provide important qualities. They fulfill the expectation to only ship what has been deemed ship-ready. They provide an independently verifiable chain to the origin (the “Supplier”). However, each distribution starts with this verifiable first part of the chain and then adds on top. Often (or meanwhile almost always) with a transparent way to verify those changes as well (in the form of SLSA conformant procedures), however in isolation. How reliable are many short chains disjoint from each other? Currently, distributions ocassionally reuse the same or similar patches on top of upstream project releases, but otherwise for the most part work in isolation and only rarely actively collaborate. The essential piece of downstream patch that activated the backdoor existed for close to 10 years in the distributions, yet has not been seen in upstream.

We recognize that the XZ backdoor is cleverly built. Yet, it had surprising flaws in execution. Whoever is interested in embedding further backdoors has learned from the elaborate public coverage of everything that went wrong. These mistakes have been pointed out, published and learned from. We have given the actors behind this backdoor a free training for the future next attacks. It is time that distributions learn from this as well and also take training lessons. We need to actively collaborate and build a strong, reliable web of trust with the open source projects and each other to be prepared to handle the inevitable future challenges that will come. Let’s build a Secure Web of Trust together!

A lot has been written about the XZ Backdoor in the last few weeks, so it is time to look forward. Before doing so, we share further details about what happened with regards to openSUSE. For an overview how it affected openSUSE users, please refer to the previous post.

Behind the scenes

A few days before the public disclosure of the XZ backdoor, the SUSE product security team got a hint that there is something odd with the XZ 5.6.x releases. I am the SUSE employee and openSUSE packager that was updating and including this version into openSUSE Tumbleweed, so I got involved in this quite early. By that time, no context and information that was shared in the initial public disclosure was available to us. However, that hint was all the information that we needed. It changed the way we looked at an established, central open-source project. Without that, the odd small diff in the “configure” stage of the build system would have been easily disregarded.

One day before disclosure, on Thursday evening, SUSE product security received a longer and detailed report from Andres Freund via the shared distros security disclosure list. The distros list is an encrypted mailing list where distributors collaborate and coordinate on disclosures of security issues. This report brought the new knowledge that the XZ backdoor specifically targeted OpenSSH, which is one of the network-facing parts of nearly every Linux system. This even further increased our threat level to be of a remote access backdoor and also caused us to widen our planned communication efforts.

The SUSE security team and I started analyzing. SUSE product security is a member of various private security forums, like the distros list and CERT VINCE and others, which allow us to coordinate fixes between software vendors and have updates ready on the disclosure dates. With initial information that there is something suspicious, it was relatively easy to find more suspicious things in no particular order:

• openSUSE and SUSE track release artifact signatures with a keyring of trusted signatures. We noticed that the key that the artifacts were signed with changed some time ago, so we had to update our trusted keyring for the XZ project. We validated that there was a maintainer handover and that the new maintainer has direct commit access as well as the ability to sign releases and publish them. The web of trust of this new signing key was not well connected, which could have raised an alert, but it was signed by the previous maintainer and that was sufficient for us.

• Looking at the commit history, there was a flurry of commits between the last 5.5 beta and the 5.6.0 release in a short time window by that new maintainer; not coming via a Pull Request and no obvious review or discussion on it. This was immediately concerning. Normally projects do not do that just before a major new release. Reviewing every single commit immediately showed odd test files being committed and updated in 5.6.1, and that did not have corresponding updates in the test framework or in the project code, so these were “unused”. Normally test files are committed alongside a code fix in the same commit, or with a reference to a prior issue, or a commit that the test case is addressing. For an experienced maintainer of an upstream project, this seemed like a big oversight. The commit messages were sort of plausible but not really making sense, especially when comparing the (small) differences between 5.6.0 and 5.6.1.

Further investigation lead to finding the “stage zero” embedded in the build system and with that we were able to step through the layers of obfuscation to untangle the second and third stage. Within minutes, it became clear to us that very significant effort was spent on developing it. It wasn’t the work of a single developer on a rainy Sunday afternoon. Also, the second stage hinted that this was a backdoor that was specifically targetted at only specific environments, Debian or RPM package builds using GCC and glibc. A normal user building from source, either from the backdoored tarball or from git would have never been affected. This raised alarm bells. So before we went further with the reverse engineering, we assessed the impact.

For a while, openSUSE has not been using XZ for compression of our distribution rpm packages; we switched to Zstd a while ago. However, XZ is very widely used in the distribution, amongst many other things for uncompressing the sources of our GCC compiler that we use to build everything else in the distribution. We checked and saw that the suspected malicous XZ release was being used for building our active openSUSE GCC compiler, which is used in every other build of the distribution. The worst case scenario to think of here is that the unpacking of the GCC compiler build sources was being modified by the malicious XZ and we have a system compiler that was no longer trustworthy. Although we do have signature checks on the sources (and have secured copies of every source input we ever used anywhere in a trusted lookaside store), we have no checks whether the unpacked sources are actually the sources that were signature checked prior to unpacking.

So even without any further information about the backdoor, we understood that the impact worst case could be disastrous. So we started identifying affected projects, products and distributions. Fortunately that list turned out to be fairly small. An ad hoc team was formed to handle the removal of the backdoor.

Initial Removal of the Backdoor for our users

openSUSE Tumbleweed ships an emergency update channel that we can use to recover from fatal regressions in the regular Tumbleweed snapshots. These are extremely rare thanks to our automated testing pipeline, but they do happen. We injected a downgrade of XZ into that emergency update channel and started building an interim openSUSE snapshot release that had the malicious XZ update removed. However, due to the unknown nature of the obfuscated backdoor, we were planning with the worst assumption. We started collecting how many packages have been built and released with the build of the suspect GCC compiler within the build environment. It was a very large list. Also, making sense of the reversing of the malicious backdoor object code in Ghidra would take us another couple of hours. After a short sync, we decided to go for the safe route and throw away every package that was built with the potentially malicious XZ/GCC and started rebuilding all of them with only packages that were coming from a safe backup, to restore integrity of our distribution as quickly as possible. openSUSE regularly tests this “bootstrap mode” as part of our distribution development and relies on the rebuild automation provided by the Open Build Service, so this wasn’t a lot of human work. It was just a lot of load for our build cluster. We had a couple of hours of waiting in front of us, which allowed further analysis of the backdoor.

Analysis of the backdoor

Analysis of the object code turned out to be time intensive. While the second stage that checked for the right build conditions (is it a distribution build, does it have the expected compiler environment etc.) was easy to decode and helped us understand the potential impact, initially it wasn’t really clear to us what the obfuscated object code that was injected during the build was doing.

By using Ghidra, we were able to get somewhat readable C code back from the injected machine code, so we started trying to decipher the puzzle. Spotting the entry point in the _get_cpuid function that was part of the IFUNC handling was one of the first findings. Just Googling this combination of words led to an upstream discussion, to the disablement of ifunc in the oss fuzz project and an interesting bug report in the Fedora community where Valgrind issues were reported with XZ 5.6.0 and apparently the upstream was fixing those by updating unrelated things including “the test files” in the repository. There were not only commits in the repository but also misleading communication around the issue directly related to those commits, which made it obvious that we were not finding an unfortunate accident by an innocent maintainer who might have been hacked, but a planned action by the current upstream maintainer. Just in case the alarm bells weren’t loud enough already, this doubled their noise level.

Preparing for the Public Disclosure

Combining all of what we learned so far, the picture became clearer. Somebody had spent years of preparation to lay down the ground work, build up a good maintainer reputation, take over the project and then chose a point in time that was a critical window for several distribution projects and in the middle of Lunar New Year as well as other holidays to release a new version with new features and an obfuscated backdoor that was well-crafted to target only specific distributions, namely those using GCC, Binutils, Glibc with RPM or Debian build processes on x86_64.

With all of that in mind, we realized that there is going to be a lot of public coverage on this. It will be in the news for days to weeks. So we started a new workstream to prepare for that with the communications teams.

Public Disclosure

By the time of the public disclosure, all workstreams had already completed. We identified the list of affected products, and had already released all updates for all affected ones. Communication was ready to be put online and sent out to the relevant parties. All of that was possible because many people went above and beyond, put everything else aside to react timely and with a lot of engagement to ensure we haven’t missed anything or overlooked anything; all this while a long public holiday weekend had already started. Kudos to everyone who was working around the clock on preparing for this.

Hero of the story

That nothing worse happened is only thanks to Andres Freund, a developer in the PostgreSQL community who was not skipping over an odd performance regression of SSH logins to his recently upgraded Debian unstable installation. Another testiment that not letting go on something that everyone else likely would have ignored for the next months to years is what makes a hero a hero.

However, relying on heroes is not a sustainable and reliable strategy. So for the future, we all need to learn from what happened and need to become a large team of small heroes.

TLDR of What Happened

Linux distributions were abused to deliver a backdoor to their users. What the exact purpose of the backdoor was is still speculation. It could be all from an individual who wanted to sell access to abundant compute power via public cloud hosted virtual machines that have a vulnerable ssh port open to the public. Which is the rather unlikely, but still possible, one end of the spectrum. The other end of the spectrum is a company that sells backdoors to state actors that make use of those to remotely and covertly access any Linux machine. Although mistakes were made, it almost achieved that goal. Where is the truth? Further evidence needs to be identified and analyzed for that.

Time to look forward

After this close look behind the curtains of what happened at the end of March, the rest of this post switches gears to looking forward.

Linus Law and the distributions

“Given enough eyeballs, all bugs are shallow”. In open source communities, this is cited a lot as a reason for why open source can be trusted. For open-source projects that are attracting enough attention from sufficiently skilled contributors, this “law” probably has at least some weight. However, we learned for example from Heartbleed that these preconditions are not universally fulfilled. There are are many projects that are absolutely essential and yet are considered boring and fail to attract a lot of maintainers or contributors, and those who are on the project are buried under a pile of work already and can’t really spend significant effort on ramping up new joiners.

The XZ backdoor was designed to only target distributions. First, by the prechecks that the backdoor executed before unfolding, but also because the conditions necessary for implanting were only existing downstream in these distributions. Debian, as well as the other affected distributions like openSUSE are carrying a significant amount of downstream-only patches to essential open-source projects, like in this case OpenSSH. With hindsight, that should be another Heartbleed-level learning for the work of the distributions. These patches built the essential steps to embed the backdoor, and do not have the scrutiny that they likely would have received by the respective upstream maintainers. Whether you trust Linus Law or not, it was not even given a chance to chime in here. Upstream did not fail on the users, distributions failed on upstream and their users here.

Open source and their communities

Being able to inspecting source code of open-source software gives the community an unbeatable advantage over proprietary single-vendor alternatives. However, auditing source code is time intensive and often needs highly experienced domain and security experts. Commercial distributions should and are playing an important role in this; yet they have not identified this. The XZ project was in that sense the perfect blind spot for how effort is typically allocated for security audits. Very deeply nested and important for every distribution due to non-obvious reasons, and in the state of only one maintainer and very few contributors or reviewers for years. It is not the shiny new cloud native or otherwise fancy new open-source project that attracts thousand of developers or security researchers, and yet it is just as important for the integrity and security of modern computing. If anything there is to learn here, is that the selection criterias for where to focus on needs to be adjusted with these learnings.

Furthermore, others have already emphasized that the initial attack vector wasn’t technical. It wasn’t an archaic tarball. The actual initial attack was social engineering and used toxic behavior in communities. This is real and not only in this case affects the existing maintainers of open-source projects. Many stories have been told where maintainer stress or burn out was connected to toxic participants in the project communities. Although I believe the distributions are not part of those activities, we are not set up to prevent these things from happening. The distribution developers are focused on their issues and their users and are, due to their limited time, risking to neglect the (upstream) open-source communities. This is another thing that we need to keep in mind.

Initiatives like CHAOSS and the Open Source Security Foundation have been founded because otherwise these situations would be too easy to miss. They provide essential service toward analyzing the “bus factor”, or the “collusion factor” of how many actors are needed to subvert a project and thereby allow others to focus on directing help where it matters the most.

The cost of Freedom

FLOSS is not about cost, or about being free to use, but about the freedom to inspect and (re-)use. What is the cost of that freedom? In the proprietary world, software is paid for. In open source, this freedom needs to receive the recognition it deserves and needs to be valued. When somebody refers to the XZ backdoor as a Software Supply Chain Security incident, that is not the full picture. A Software Supply chain would be where there is a supplier at one end. But open-source projects and communities are not suppliers today. They have no legally binding contract with any of their consumers, and there is no exchange of money involved. There exists a community, varying in size, that contributes and assists, either as volunteers or as paid workers. Most projects are not receiving enough of it.

As an open-ended thought: Should distributions actively build up and manage their supply chain and treat “their suppliers” as real suppliers with legally binding mutual terms and conditions and agreed upon compensations?

The Secure Web of Trust is the new Supply Chain Security

In this particular incident, signed tarballs were used to publish the launcher of the backdoor. Many things have been said about that. We need to realize that this is a distraction. A trap. In terms of code size, 99.9% of the backdoor was in the source code repository. The launcher in the tarball was to limit the exposure of the backdoor to only the intended victims, not technically needed for anything or by anything. It would have been equally easy to embed and equally hard to spot with the rest of the 0.1% being also committed inside the project code repository, just in a marginally different way.

For most other thinkable attack scenarios, signed release artifacts provide important qualities. They fulfil the expectation to only ship what has been deemed ship-ready. They provide an independently verifiable chain to the origin (the “Supplier”). However, each distribution starts with this verifiable first part of the chain and then adds on top. Often (or meanwhile almost always) with a transparent way to verify those changes as well (in the form of SLSA conformant procedures), all in isolation. How reliable are those disjoint chains? Currently, distributions occasionally reuse the same or similar patches on top of upstream project releases, but otherwise for the most part work in isolation and only rarely actively collaborate. The essential piece of downstream patch that activated the backdoor existed for close to 10 years in the distributions, yet has not been seen in upstream.

We recognize that the XZ backdoor is cleverly built. Yet, it had surprising flaws in execution. Whoever is interested in embedding further backdoors has learned from the extensive public coverage of everything that went wrong. These mistakes have been pointed out, published and learned from. We have given the actors behind this backdoor free training for future attacks. It is time that distributions learn from this as well and also take training lessons. We need to actively collaborate and build a strong, reliable web of trust with open-source projects and each other to be prepared to handle the inevitable future challenges that will come. Let’s build a Secure Web of Trust together!

_{^{Picture on this post was taken by Matthias Pastwa and used under CC-BY-ND 2.0 DEED}}

Este año, el encuentro anual de desarrolladores de la Comunidad KDE se va a celebrar en Würzburg de forma presencial y online, concretamente del 7 al 12 de septiembre. Es por ello que es el momento de animaros si pensáis que podéis aportar algo al evento a participar de forma activa:. Así que presenta tu charla para Akademy 2023 y muestra al mundo tu implicación con el Software Libre.

Presenta tu charla para Akademy 2024 de Würzburg

Este año se me ha pasado por alto compartir con vosotros que Akademy 2024 se realizaría en Würzburg del 15 al 21 de julio en una edición que sigue con el formato híbrido ya que sus organizadores ya le han cogido el truco para hacerlo accesible a todo el mundo.

Siguiendo el esquema habitual, las charlas se realizarán el sábado 7 y el domingo 11, dejando el resto de días para el trabajo en pequeños grupos en sala más reservadas pero no privadas, es decir, que no están cerradas sino que todo el que quiera aportar algo está invitado.

Como se ha comentado en anteriores ocasiones, uno de los objetivos de Akademy es aprender y enseñar nuevos conocimientos y compartir entre nosotros la pasión de lo que se hace en KDE.

Para compartir ideas, experiencias o momentos, se reservan talleres específicos en la sede (o se aprovechan los corrillos en los pasillos, las cenas o los momentos de barra), pero para enseñar y compartir detalles técnicos se utilizan las charlas.

Si crees que tienes algo importante que presentar, por favor házselo saber a la organización. Y si crees que alguien debería presentar su ponencia, no dejes de animarlo para que lo haga. Todas las contribuciones son útiles y, si necesitas, inspiración:

• KDE en acción: casos de uso de la tecnología KDE en la vida real; ya sea en dispositivos móviles, implementaciones de escritorio, etc.
• Visión general de lo que está ocurriendo en las distintas áreas de la comunidad KDE.
• Colaboración entre KDE y otros proyectos de Software Libre.
• Publicación, empaquetado y distribución de software por parte de KDE.
• Aumentar nuestro alcance a través de esfuerzos como la accesibilidad, la promoción, la traducción y la localización.
• Mejora de nuestra gobernanza y procesos, construcción de la comunidad.
• Temas relacionados con los objetivos de KDE.
• Innovaciones y mejores prácticas en las bibliotecas y tecnologías utilizadas por el software de KDE, por ejemplo, C++/Qt/Python/KDE Frameworks/etc. o que puedan ser interesantes para su uso futuro, por ejemplo, Rust/C++20, etc.

Para más detalles, mira las líneas generales del Call for Papers. Tienes de plazo para enviar tu propuesta hasta el jueves 14 de mayo 23:59:59 CEST.

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores, ideólogos, etc. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos que se mantendran gracias a las listas de correo, canales irc o Sprints.

Hay que recordar que en España tenemos gran tradición en la celebración de Akademy ya que en 2005 se celebró en Málaga , en 2011 en Gran Canaria, en 2013 en Bilbao, en 2015 en A Coruña y en 2017 en Almería, todos esos años junto con Akademy-es (como este año), y que fue un gran éxito tanto de asistentes, como de ponencias o de resultados. Así que no tienes excusa para asistir ya que por el «precio» de uno este año tienes dos grandísimos eventos a tu alcance.

La entrada Presenta tu charla para Akademy 2024 de Würzburg se publicó primero en KDE Blog.

Este año, el encuentro anual de desarrolladores de la Comunidad KDE se va a celebrar en Würzburg de forma presencial y online, concretamente del 7 al 12 de septiembre. Es por ello que es el momento de animaros si pensáis que podéis aportar algo al evento a participar de forma activa:. Así que presenta tu charla para Akademy 2023 y muestra al mundo tu implicación con el Software Libre.

Presenta tu charla para Akademy 2024 de Würzburg

Este año se me ha pasado por alto compartir con vosotros que Akademy 2024 se realizaría en Würzburg del 7 al 12 de septiembre en una edición que sigue con el formato híbrido ya que sus organizadores ya le han cogido el truco para hacerlo accesible a todo el mundo.

Siguiendo el esquema habitual, las charlas se realizarán el sábado 7 y el domingo 8, dejando el resto de días para el trabajo en pequeños grupos en sala más reservadas pero no privadas, es decir, que no están cerradas sino que todo el que quiera aportar algo está invitado.

Como se ha comentado en anteriores ocasiones, uno de los objetivos de Akademy es aprender y enseñar nuevos conocimientos y compartir entre nosotros la pasión de lo que se hace en KDE.

Para compartir ideas, experiencias o momentos, se reservan talleres específicos en la sede (o se aprovechan los corrillos en los pasillos, las cenas o los momentos de barra), pero para enseñar y compartir detalles técnicos se utilizan las charlas.

Si crees que tienes algo importante que presentar, por favor házselo saber a la organización. Y si crees que alguien debería presentar su ponencia, no dejes de animarlo para que lo haga. Todas las contribuciones son útiles y, si necesitas, inspiración:

• KDE en acción: casos de uso de la tecnología KDE en la vida real; ya sea en dispositivos móviles, implementaciones de escritorio, etc.
• Visión general de lo que está ocurriendo en las distintas áreas de la comunidad KDE.
• Colaboración entre KDE y otros proyectos de Software Libre.
• Publicación, empaquetado y distribución de software por parte de KDE.
• Aumentar nuestro alcance a través de esfuerzos como la accesibilidad, la promoción, la traducción y la localización.
• Mejora de nuestra gobernanza y procesos, construcción de la comunidad.
• Temas relacionados con los objetivos de KDE.
• Innovaciones y mejores prácticas en las bibliotecas y tecnologías utilizadas por el software de KDE, por ejemplo, C++/Qt/Python/KDE Frameworks/etc. o que puedan ser interesantes para su uso futuro, por ejemplo, Rust/C++20, etc.

Para más detalles, mira las líneas generales del Call for Papers. Tienes de plazo para enviar tu propuesta hasta el jueves 14 de mayo 23:59:59 CEST.

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores, ideólogos, etc. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos que se mantendran gracias a las listas de correo, canales irc o Sprints.

La entrada Presenta tu charla para Akademy 2024 de Würzburg, Alemania se publicó primero en KDE Blog.

Plasma 6 no vino solo. Junto al escritorio también apareció KDE Gear 24.02, KDE Frameworks 6 y Plasma Mobile 6, todo un desembarco de novedades que todavía no han tenido tiempo de aparecer en el blog. Es hora de enmendar este error. Ya hice un resumen básico de las cosas nuevas que nos ofrecían y es el momento de hablar de las novedades de Dolphin en KDE Gear 24.02, el explorador de archivos y carpetas de la Comunidad KDE que es una verdadera navaja suiza para cualquier usuario.

Novedades de Dolphin en KDE Gear 24.02

La calidad y cantidad de aplicaciones del ecosistema KDE es asombrosa, creciente y realmente competente. Solo hay que ver la página oficial para ver el catálogo completo de ellas.

En el salto tecnológico del pasado 28 de febrero, KDE Gear 24.02 nos trajo muchas aplicaciones ya migradas a Qt 6 y con un aspecto con menos marcos en su interfaz, con el objetivo de hacerlos más consistentes con Brisa y que tengan un aspecto más moderno.

Dolphin ha recibido una atención especial a la hora de aplicar esas mejoras estéticas pero evidentemente, sus novedades no se acaban ahí. De este modo, las preferencias de configuración del explorador han recibido una atención especial y se han reorganizado para que sea más fácil navegar por ellas.

También hay mejoras de accesibilidad en esta versión. Ahora se puede acceder con el teclado a los botones de la barra de herramientas y al indicador de espacio libre en disco de la barra de estado. Se puede pulsar F10 para abrir el menú principal y Mayúsculas+F10 para abrir menús de contexto. Algunas de estas mejoras se han aplicado también a otras aplicaciones.

Para finaliza comentar que al hacer clic con el botón derecho sobre una carpeta se muestra una opción para abrirla en una vista dividida.

En próximas entradas nos seguiremos con detalles específicos de otras aplicaciones. ¡¿No es asombroso para algo realizado por voluntarios?!

Más información: KDE

La entrada Novedades de Dolphin en KDE Gear 24.02 se publicó primero en KDE Blog.

There are not many new things that really grip my attention but this, with its warm, welcoming beige aesthetic and leanings to the Commodore 64 look and feel along with the modern improvements in mechanical switches is a perfect marriage of traditional look with modern enhancements. At the time of writing, this keyboard is only … Continue reading 8BitDo C64 Edition Mechanical Keyboard →

Plasma 6 no vino solo. Junto al escritorio también apareció KDE Gear 24.02, KDE Frameworks 6 y Plasma Mobile 6, todo un desembarco de novedades que todavía no han tenido tiempo de aparecer en el blog. Es hora de enmendar este error. Ya hice un resumen básico de las cosas nuevas que nos ofrecían y es el momento de hablar de las novedades de Kdenlive en KDE Gear 24.02, el editor de vídeo no lineal de la Comunidad KDE.

Novedades de Kdenlive en KDE Gear 24.02

La calidad y cantidad de aplicaciones del ecosistema KDE es asombrosa, creciente y realmente competente. Solo hay que ver la página oficial para ver el catálogo completo de ellas.

En el salto tecnológico del pasado 28 de febrero, KDE Gear 24.02 nos trajo muchas aplicaciones ya migradas a Qt 6 y con un aspecto con menos marcos en su interfaz, con el objetivo de hacerlos más consistentes con Brisa y que tengan un aspecto más moderno.

Y, además de todo eso, muchas aplicaciones han ganado nuevas funcionalidades, y Kdenlive no es ninguna excepción.

La gran novedad del potente editor de vídeo de KDE es la posibilidad de sustituir el audio o el vídeo de un videoclip en la línea de tiempo. Esta nueva función permite extraer el sonido de un videoclip, modificarlo en otro programa y volver a insertarlo en el videoclip.

Por otra parte, la función de subtítulos de Kdenlive se ha mejorado bastante, y ahora permite incorporar múltiples subtítulos en una misma pista. Esto es especialmente útil para los vídeos que exigen subtítulos en varios idiomas. También dispone de la opción de importar y exportar subtítulos.

Además, ahora Kdenlive nos avisará cuando exista una actualización del programa, incluso sin la necesidad de que exista una conexión a internet.

Para finalizar el monitor de videoclips mostrará todos los que haya abierto recientemente y el diálogo de comprobación de documentos, que se muestra al abrir un proyecto con videoclips ausentes, se ha reescrito completamente.

En próximas entradas nos seguiremos con detalles específicos de otras aplicaciones. ¡¿No es asombroso para algo realizado por voluntarios?!

Más información: KDE

La entrada Novedades de Kdenlive en KDE Gear 24.02 se publicó primero en KDE Blog.

We will be newly using png for the default wallpaper set on openSUSE Tumbleweed and upcoming versions of openSUSE Leap and Leap Micro.

The driver behind the decision is the unification of wallpaper paths with SUSE Linux Enterprise via a compatibility symlink because the format had to be the same. SLES and SLED have been using PNG since the last rebrand in SLE 15 Service Pack 3 and openSUSE has been using JPG up until now.

Using a common default wallpaper path allows applications utilizing wallpaper or similar system branding to be re-run on SLES and openSUSE without a need to be rebuilt.

The small price for using the lossless format is a slight increase in size, however, we do use optipng so it’s within units of megabytes for all wallpapers resolutions combined.

ls -la /usr/share/wallpapers/openSUSEdefault/contents/images/1600x1200.png -rw-r--r-- 1 root root 417791 Apr 5 13:14 /usr/share/wallpapers/openSUSEdefault/contents/images/1600x1200.png

ls -la /usr/share/wallpapers/SLEdefault/contents/images/1600x1200.png -rw-r--r-- 1 root root 417791 Apr 5 13:14 /usr/share/wallpapers/SLEdefault/contents/images/1600x1200.png

ls -la /usr/share/wallpapers/SLEdefault lrwxrwxrwx 1 root root 15 Apr 5 13:15 /usr/share/wallpapers/SLEdefault -> openSUSEdefault

We’ve also supplied new apple-touch-icon, which was part of SUSE Linux Enterprise distribution logos and this was missing on the openSUSE side.

Since this is effectively a change of a default wallpaper we recommend users who use the default wallpaper to log out and log in to avoid any glitches. Please ensure the system was able to re-read /usr/share/wallpapers/openSUSE-default-static.xml

The great news about this is that we plan to come up with a new wallpaper collection for openSUSE Leap 16 as well as openSUSE Tumbleweed, which hasn’t seen a wallpaper change for a while; just view it as a nice little fire drill.

I have a couple of, now older, 4th Generation Intel, Haswell, Dell Latitude E6x40 machines that have discreet AMD GPUs. These laptops are going on 10 years old and truly at end of life in a modern sense but I just can’t let these machines go. They are some of the nicest laptops I have … Continue reading Steam Games Using the Discrete AMD GPU on Haswell Laptop →