"A 20-year-old Trojan resurfaced recently," reports Dark Reading, "with new variants that target Linux and impersonate a trusted hosted domain to evade detection." Researchers from Palo Alto Networks spotted a new Linux variant of the Bifrost (aka Bifrose) malware that uses a deceptive practice known as typosquatting to mimic a legitimate VMware domain, which allows the malware to fly under the radar. Bifrost is a remote access Trojan (RAT) that's been active since 2004 and gathers sensitive information, such as hostname and IP address, from a compromised system.

There has been a worrying spike in Bifrost Linux variants during the past few months: Palo Alto Networks has detected more than 100 instances of Bifrost samples, which "raises concerns among security experts and organizations," researchers Anmol Murya and Siddharth Sharma wrote in the company's newly published findings.

Moreover, there is evidence that cyberattackers aim to expand Bifrost's attack surface even further, using a malicious IP address associated with a Linux variant hosting an ARM version of Bifrost as well, they said... "As ARM-based devices become more common, cybercriminals will likely change their tactics to include ARM-based malware, making their attacks stronger and able to reach more targets."

"2004 was already an eventful year for Linux," writes ZDNet's Jack Wallen. "As I reported at the time, SCO was trying to drive Linux out of business. Red Hat was abandoning Linux end-user fans for enterprise customers by closing down Red Hat Linux 9 and launching the business-friendly Red Hat Enterprise Linux (RHEL). Oh, and South African tech millionaire and astronaut Mark Shuttleworth [also a Debian Linux developer] launched Canonical, Ubuntu Linux's parent company.

"Little did I — or anyone else — suspect that Canonical would become one of the world's major Linux companies."

Mark Shuttleworth answered questions from Slashdot reader in 2005 and again in 2012. And this year, Canonical celebrates its 20th anniversary. ZDNet reports: Canonical's purpose, from the beginning, was to support and share free software and open-source software... Then, as now, Ubuntu was based on Debian Linux. Unlike Debian, which never met a delivery deadline it couldn't miss, Ubuntu was set to be updated to the latest desktop, kernel, and infrastructure with a new release every six months. Canonical has kept to that cadence — except for the Ubuntu 6.06 release — for 20 years now...

Released in October 2004, Ubuntu Linux quickly became synonymous with ease of use, stability, and security, bridging the gap between the power of Linux and the usability demanded by end users. The early years of Canonical were marked by rapid innovation and community building. The Ubuntu community, a vibrant and passionate group of developers and users, became the heart and soul of the project. Forums, wikis, and IRC channels buzzed with activity as people from all over the world came together to contribute code, report bugs, write documentation, and support each other....

Canonical's influence extends beyond the desktop. Ubuntu Linux, for example, is the number one cloud operating system. Ubuntu started as a community desktop distribution, but it's become a major enterprise Linux power [also widely use as a server and Internet of Things operating system.]
The article notes Canonical's 2011 creation of the Unity desktop. ("While Ubuntu Unity still lives on — open-source projects have nine lives — it's now a sideline. Ubuntu renewed its commitment to the GNOME desktop...")

But the article also argues that "2016, on the other hand, saw the emergence of Ubuntu Snap, a containerized way to install software, which --along with its rival Red Hat's Flatpak — is helping Linux gain some desktop popularity."

Michael Larabel writes via Phoronix: Fedora Workstation has long defaulted to using GNOME's Wayland session by default, but it has continued to install the GNOME X.Org session for fallback purposes or those opting to use it instead. But for the Fedora Workstation 41 release later in the year, there is a newly-approved plan to no longer have that GNOME X.Org session installed by default. Recently there was a Fedora Workstation ticket opened to no longer install the GNOME X.Org session by default. This is just about whether the X.Org session is pre-installed but would continue to live in the repository for those wanting to explicitly install it.

The Fedora Workstation working group decided to go ahead with this change for the Fedora 41 cycle, not the upcoming Fedora 40 release. So pending any obstacles by FESCo, which is unlikely. Fedora Workstation 41 will not be installing the GNOME X.Org session by default. Long live Wayland.

According to the latest data from StatCounter, Linux's market share has reached 4.03% -- surging by an additional 1% in the last eight months. What's the reason behind this recent growth? "That's a good question," writes ZDNet's Steven Vaughan-Nichols. "While Windows is the king of the hill with 72.13% and MacOS comes in a distant second at 15.46%, it's clear that Linux is making progress." An anonymous Slashdot reader shares the five reasons why Vaughan-Nichols thinks it's growing: 1. Microsoft isn't that interested in Windows
If you think Microsoft is all about the desktop and Windows, think again. Microsoft's profits these days come from its Azure cloud and Software-as-a-Service (SaaS), Microsoft 365 in particular. Microsoft doesn't want you to buy Windows; the Redmond powerhouse wants you to subscribe to Windows 365 Cloud PC. And, by the way, you can run Windows 365 Cloud PC on Macs, Chromebooks, Android tablets, iPads, and, oh yes, Linux desktops.

2. Linux gaming, thanks to Steam, is also growing
Gaming has never been a strong suit for Linux, but Linux gamers are also a slowly growing group. I suspect that's because Steam, the most popular Linux gaming platform, also has the lion's share of the gaming distribution market

3. Users are finally figuring out that some Linux distros are easy to use
Even now, you'll find people who insist that Linux is hard to master. True, if you want to be a Linux power user, Linux will challenge you. But, if all you want to do is work and play, many Linux distributions are suitable for beginners. For example, Linux Mint is simple to use, and it's a great end-user operating system for everyone and anyone.

4. Finding and installing Linux desktop software is easier than ever
While some Linux purists dislike containerized application installation programs such as Flatpak, Snap, and AppImage, developers love them. Why? They make it simple to write applications for Linux that don't need to be tuned just right for all the numerous Linux distributions. For users, that means they get more programs to choose from, and they don't need to worry about finicky installation details.

5. The Linux desktop is growing in popularity in India
India is now the world's fifth-largest economy, and it's still growing. Do you know what else is growing in India? Desktop Linux. In India, Windows is still the number one operating system with 70.37%, but number two is Linux, with 15.23%. MacOS is way back in fourth place with 3.11%. I suspect this is the case because India's economy is largely based on technology. Where you find serious programmers, you find Linux users.

"Linux gained from 3% to 4% in 8 months," writes longtime Slashdot reader bobdevine. Linuxiac reports: According to the latest data from StatCounter, a leading web traffic analysis tool, Linux's market share has reached 4.03%. At first glance, the number might seem modest, but it represents a significant leap. Let's break it down. It took Linux 30 years to secure a 3% share of desktop operating systems, a milestone reached last June. Impressively, the open-source operating system has surged by an additional 1% in the last eight months.

An anonymous reader shared this post from Phoronix: With Linux 6.8 the kernel's Rust code was brought up to Rust 1.75 while new patches posted this weekend port the code over to Rust 1.76 and then the upcoming Rust 1.77...

With Rust 1.77 they have now stabilized the single-field "offset_of" feature used by the kernel's Rust code. Rust 1.77 also adds a "--check-cfg" option that the Rust kernel code will likely transition to in the future. This follows the Rust for Linux policy of tracking the upstream Rust version upgrades until there is a minimum version that can be declared where all used features are considered stable.

From a blog post by Greg Kroah-Hartman: As was recently announced, the Linux kernel project has been accepted as a CVE Numbering Authority (CNA) for vulnerabilities found in Linux.

This is a trend, of more open source projects taking over the haphazard assignments of CVEs against their project by becoming a CNA so that no other group can assign CVEs without their involvment. Here's the curl project doing much the same thing for the same reasons. I'd like to point out the great work that the Python project has done in supporting this effort, and the OpenSSF project also encouraging it and providing documentation and help for open source projects to accomplish this. I'd also like to thank the cve.org group and board as they all made the application process very smooth for us and provided loads of help in making this all possible.

As many of you all know, I have talked a lot about CVEs in the past, and yes, I think the system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time. It's also work that it looks like all open source projects might be mandated to do with the recent rules and laws being enacted in different parts of the world, so having this in place with the kernel will allow us to notify all sorts of different CNA-like organizations if needed in the future.
Kroah-Hartman links to his post on the kernel mailing list for "more details about how this is all going to work for the kernel." [D]ue to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team...

No CVEs will be assigned for unfixed security issues in the Linux kernel, assignment will only happen after a fix is available as it can be properly tracked that way by the git commit id of the original fix. No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.
alanw (Slashdot reader #1,822) worries this could overwhelm the CVE infrastructure, pointing to an ongoing discussion at LWN.net.

But reached for a comment, Greg Kroah-Hartman thinks there's been a misunderstanding. He told Slashdot that the CVE group "explicitly asked for this as part of our application... so if they are comfortable with it, why is no one else?"

Some ZFS news from Phoronix this week. "At the end of last year OpenZFS 2.2.2 was released to fix a rare but nasty data corruption issue, but it turns out there are other data corruption bug(s) still lurking in the OpenZFS file-system codebase." A Phoronix reader wrote in today about an OpenZFS data corruption bug when employing native encryption and making use of send/recv support. Making use of zfs send on an encrypted dataset can cause one or more snapshots to report errors. OpenZFS data corruption issues in this area have apparently been known for years.

Since May 2021 there's been this open issue around ZFS corruption related to snapshots on post-2.0 OpenZFS. That issue remains open. A new ticket has been opened for OpenZFS as well in proposing to add warnings against using ZFS native encryption and the send/receive support in production environments.
jd (Slashdot reader #1,658) spotted the news — and adds a positive note. "Bugs, old and new, are being catalogued and addressed much more quickly now that core development is done under Linux, even though it is not mainstreamed in the kernel."

Andrew Cunningham reports via Ars Technica: For around three years now, the team of independent developers behind the Asahi Linux project has worked to support Linux on Apple Silicon Macs, despite Apple's total lack of involvement. Over the years, the project has gone from a "highly unstable experiment" to a "surprisingly functional and usable desktop operating system." Even Linus Torvalds has used it to run Linux on Apple's hardware. The team has been steadily improving its open source, standards-conformant GPU driver for the M1 and M2 since releasing them in December 2022, and today, the team crossed an important symbolic milestone: The Asahi driver's support for the OpenGL and OpenGL ES graphics have officially passed what Apple offers in macOS. The team's latest graphics driver fully conforms with OpenGL version 4.6 and OpenGL ES version 3.2, the most recent version of either API. Apple's support in macOS tops out at OpenGL 4.1, announced in July 2010.

Developer Alyssa Rosenzweig wrote a detailed blog post that announced the new driver, which had to pass "over 100,000 tests" to be deemed officially conformant. The team achieved this milestone despite the fact that Apple's GPUs don't support some features that would have made implementing these APIs more straightforward. "Regrettably, the M1 doesn't map well to any graphics standard newer than OpenGL ES 3.1," writes Rosenzweig. "While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set... Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on."

Now that the Asahi GPU driver supports the latest OpenGL and OpenGL ES standards -- released in 2017 and 2015, respectively -- the work turns to supporting the low-overhead Vulkan API on Apple's hardware. Vulkan support in macOS is limited to translation layers like MoltenVK, which translates Vulkan API calls to Metal ones that the hardware and OS can understand. [...] Rosenzweig's blog post didn't give any specific updates on Vulkan except to say that the team was "well on the road" to supporting it. In addition to supporting native Linux apps, supporting more graphics APIs in Asahi will allow the operating system to take better advantage of software like Valve's Proton, which already has a few games written for x86-based Windows PCs running on Arm-based Apple hardware.

Back in 2006 Slashdot reported on a 50-megabyte "micro" distro called Damn Small Linux. (And in 2012 we wrote that it "rose from the dead" with a new release candidate.)

Now Damn Small Linux has been reborn again, according to its developer's web site: Creating the original DSL, a versatile 50MB distribution, was a lot of fun and one of the things I am most proud of as a personal accomplishment. However, as a concept, it was in the right place at the right time, and the computer industry has changed a lot since then. While it would be possible to make a bootable Xwindows 50MB distribution today, it would be missing many drivers and have only a handful of very rudimentary applications. People would find such a distribution a fun toy or something to build upon, but it would not be usable for the average computer user out of the gate....

The new goal of DSL is to pack as much usable desktop distribution into an image small enough to fit on a single CD, or a hard limit of 700MB. This project is meant to service older computers and have them continue to be useful far into the future. Such a notion sits well with my values. I think of this project as my way of keeping otherwise usable hardware out of landfills.

As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386... a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian.
The blog It's FOSS News describes it as "a unique experience in a sea of Debian-based and Fedora-based distros." It is offered with two window managers, Fluxbox and JWM, with apt being fully enabled by default for easy package installations... At the time of writing, only the Alpha ISOs were made available on the official downloads page. It is only a matter of time before we get a stable release.

Jakub Lewkowicz reports via SD Times: The Linux Foundation has recently launched the Post-Quantum Cryptography Alliance (PQCA), a collaborative effort aimed at advancing and facilitating the adoption of post-quantum cryptography in response to the emerging threats of quantum computing. This alliance assembles diverse stakeholders, including industry leaders, researchers, and developers, focusing on creating high-assurance software implementations of standardized algorithms. The initiative is also dedicated to supporting the development and standardization of new post-quantum cryptographic methods, aligning with U.S. National Security Agency's guidelines to ensure cryptographic security against quantum computing threats.

The PQCA endeavors to serve as a pivotal resource for organizations and open-source projects in search of production-ready libraries and packages, fostering cryptographic agility in anticipation of future quantum computing capabilities. Founding members include AWS, Cisco, Google, IBM, IntellectEU, Keyfactor, Kudelski IoT, NVIDIA, QuSecure, SandboxAQ, and the University of Waterloo. [...] [T]he PQCA plans to launch the PQ Code Package Project aimed at creating high-assurance, production-ready software implementations of upcoming post-quantum cryptography standards, beginning with the ML-KEM algorithm. By inviting organizations and individuals to participate, the PQCA is poised to play a critical role in the transition to and standardization of post-quantum cryptography, ensuring enhanced security measures in the face of advancing quantum computing technology. You can learn more about the PQCA on its website or GitHub.

Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they're hard to detect or remove. ArsTechnica: The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.

The vulnerability, tracked as CVE-2023-40547, is what's known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the the web is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from. "An attacker would need to be able to coerce a system into booting from HTTP if it's not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it," Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. "An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code)."

The non-profit Linux Foundation Energy hopes to develop energy-sector solutions (including standards, specifications, and software) supporting rapid decarbonization by collaborating with industry stakeholders.

And now they're involved in a new partnership with America's Joint Office of Energy — which facilitates collaboration between the federal Department of Energy and its Department of Transportation. The partnership's goal? To "build open-source software tools to support communications between EV charging infrastructure and other systems."

The Buildout reports: The partnership and effort — known as "Project EVerest" — is part of the administration's full-court press to improve the charging experience for EV owners as the industry's nationwide buildout hits full stride. "Project EVerest will be a game changer for reliability and interoperability for EV charging," Gabe Klein, executive director of the administration's Joint Office of Energy and Transportation, said yesterday in a post on social media....

Administration officials said that a key driver of the move to institute broad standards for software is to move beyond an era of unreliable and disparate EV charging services throughout the U.S. Dr. K. Shankari, a principal software architect at the Joint Office of Energy and Transportation, said that local and state governments now working to build out EV charging infrastructure could include a requirement that bidding contractors adhere to Project EVerest standards. That, in turn, could have a profound impact on providers of EV charging stations and services by requiring them to adapt to open source standards or lose the opportunity to bid on public projects. Charging availability and reliability are consistently mentioned as key turnoffs for potential EV buyers who want the infrastructure to be ready, easy, and consistent to use before making the move away from gas cars.

Specifically, the new project will aim to create what's known as an open source reference implementation for EV charging infrastructure — a set of standards that will be open to developers who are building applications and back-end software... And, because the software will be available for any company, organization, or developer to use, it will allow the creation of new EV infrastructure software at all levels without software writers having to start from scratch. "LF Energy exists to build the shared technology investment that the entire industry can build on top of," said Alex Thompson of LF Energy during the web conference. "You don't want to be re-inventing the wheel."
The tools will help communication between charging stations (and adjacent chargers), as well as vehicles and batteries, user interfaces and mobile devices, and even backend payment systems or power grids. An announcement from the Joint Office of Energy and Transportation says this software stack "will reduce instances of incompatibility resulting from proprietary systems, ultimately making charging more reliable for EV drivers." "The Joint Office is paving the way for innovation by partnering with an open-source foundation to address the needs of industry and consumers with technical tools that support reliable, safe and interoperable EV charging," said Sarah Hipel, Standards and Reliability Program Manager at the Joint Office.... With this collaborative development model, EVerest will speed up the adoption of EVs and decarbonization of transportation in the United States by accelerating charger development and deployment, increase customizability, and ensure high levels of security for the nation's growing network.
Linux Foundation Energy adds that reliable charging "is key to ensuring that anyone can confidently choose to ride or drive electric," predicting it will increase customizability for different use cases while offering long-term maintainability, avoiding vendor-lock in, and ensuring high levels of security. This is a pioneering example of the federal government collaborating to deploy code into an open source project...

"The EVerest project has been demonstrated in pilots around the world to make EV charging far more reliable and reduces the friction and frustration EV drivers have experienced when a charger fails to work or is not continually maintained," said LF Energy Executive Director Alex Thornton. "We look forward to partnering with the Joint Office to create a robust firmware stack that will stand the test of time, and be maintained by an active and growing global community to ensure the nation's charging infrastructure meets the needs of a growing fleet of electric vehicles today and into the future."
Thanks to Slashdot reader ElectricVs for sharing the article.

Microsoft's Visual Studio Code editor now includes a voice command that launches GitHub Copilot Chat just by saying "Hey Code."

But one Linux blog notes that the editor has suddenly stopped supporting Ubuntu 18.04 LTS — "a move causing issues for scores of developers." VS Code 1.86 (aka the 'January 2024' update) saw Microsoft bump the minimum build requirements for the text editor's popular remote dev tools to â¥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.

While Ubuntu 18.04 is supported by Canonical until 2028 (through ESM) a major glibc upgrade is unlikely. Thus, this "breaking change" is truly breaking workflows...

It seems affected developers were caught off-guard as this (rather impactful) change was not signposted before, during, or after the VS Code update (which is installed automatically for most, and the update was pushed out to Ubuntu 18.04 machines). Indeed, most only discovered this issue after update was installed, they tried to connect to a remote server, and discovered it failed. The resulting error message does mention deprecation and links to an FAQ on the VS Code website with workarounds (i.e. downgrade).

But as one developer politely put it.... "It could have checked the libc versions and refused the update. Now, many people are screwed in the middle of their work."
The article points out an upgrade to Ubuntu 20.04 LTS will address the problem. On GitHub a Microsoft engineer posted additional options from VS Code's documentation: If you are unable to upgrade your Linux distribution, the recommended alternative is to use our web client. If you would like to use the desktop version, then you can download the VS Code release 1.85. Depending on your platform, make sure to disable updates to stay on that version.
Microsoft then locked the thread on GitHub as "too heated" and limited conversation to just collaborators.

In a related thread someone suggested installing VS Code's Flatpak, which was still on version 1.85 — and then disabling updates. But soon Microsoft had locked that thread as well as "too heated," again limiting conversation to collaborators.

Linus Torvalds had "some robust exchanges" on the Linux kernel mailing list with a contributor from Google. The subject was inodes, notes the Register, "which as Red Hat puts it are each 'a unique identifier for a specific piece of metadata on a given filesystem.'" Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using tar to archive files. Torvalds countered that inodes have had their day. "Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed." But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers...

In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.

"We're not living in the 1970s, and filesystems have changed."