FreeBSD The Power to Serve

FreeBSD Status Report Fourth Quarter 2024

Here is the fourth and last 2024 status report, with 44 entries.

It shows: 2024 has been a tremendously successful and busy year. Usually, one would expect the final months in a year to be less busy, with people leaving for holidays and New Years celebration. We still managed to deliver and see great progress on so many things!

Collecting and compiling this report took longer than planned, but it was worth the wait.

Thank you to the whole community for your amazing work and an especially big thanks to those who contributed updates to this report!

Enjoy the read!

Chris Moerz, on behalf of the Status Team.



FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the Administration Page.


FreeBSD Core Team

Contact: FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team is the governing body of FreeBSD.

Following up with the FreeBSD Foundation

Core had a video conference with the FreeBSD Foundation on 2024-12-12 to follow-up on their in-person meeting held in Dublin during EuroBSDCon. Core and the Foundation continue discussing how to improve the collaboration and how to support developers and contributors:

  • The next round of community survey

  • Identifying projects where core would like help from the Foundation

  • Work on the technical roadmap with the Foundation

Work in Progress

Core is currently working on the following items:

  • Policy on generative AI created code and documentation


FreeBSD Foundation

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to advancing FreeBSD through technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters. The following report covers just some of the ways we supported FreeBSD in Q4.

Deb Goodkin here. On behalf of the Foundation, I want to start out by saying thank you to this amazing community! Your financial contributions have allowed us to step up and take on some significant projects, including large, multi-phase software development work, greater security improvements, and important infrastructure improvements that will continue through 2025. We also increased our FreeBSD advocacy efforts over many different technical and social media platforms, including creating more content to promote and advocate for FreeBSD. You’ll find more information about all of this work below. For a more in-depth look at our efforts in 2024, be sure to check out the year-end blog posts and my year-end reflections in the advocacy section below.

We are hiring! Check out our jobs page here for our Solutions Specialist and Technical Marketing Manager job postings. Plus, we are looking for part-time technical writers and will be opening up another position soon, so keep an eye on this page https://freebsdfoundation.org/open-positions/.

We are still finalizing our 2024 fundraising numbers, but at this writing, we have raised around $1,324,000. You might be thinking, why do not we have a final tally now that it is 2025? First, we have not yet received all the checks postmarked 2024 . We are also waiting on a few payments from invoices issued last year. We will have a final report in the next quarterly status report.

Thank you to the individuals and organizations that made a financial contribution in Q4! We received 325 donations from individuals totaling $120,841 and six financial contributions from organizations totaling $326,000. We also received a grant from the Silicon Valley Community Fund.

I would also like to send a shoutout to the anonymous donor who wanted us to help get Framework laptops into developers' hands. Pietro Cerutti has been coordinating that effort, and we are close to finalizing the process with Framework so developers can place their orders directly with them.

We also funded almost $5,000 worth of AV equipment for the BSDCon AV team to minimize the amount of equipment needed to rent at each of the two main BSD conferences.

Now, back to our financials. We will be publishing 2024 financial documents and reports in Q1. Our updated Q1-Q3 2024 Financial reports will be published by the end of January and will better match the budget format. The Final 2024 financial reports will be published in early Q2. Going forward, our budget and financial reports will provide more details on how funding is allocated to the major software development projects. For example, we will include how much was spent on the laptop project each quarter. We are working with our accountant to improve our accounting systems to be more transparent on how we spend our money.

We are excited about the opportunities for FreeBSD in 2025 and beyond, and are growing our team to help support the work needed to take advantage of these opportunities. However, we need your help to sustain this. Our investments will only carry on this work for a year or two at most. If your company is invested in the long-term sustainability of FreeBSD, please consider giving a financial contribution so we can ensure it stays the secure, reliable, and innovative platform you depend on. Not sure how to go about asking? Please reach out. We can help you navigate the process.

Please go here to make a donation: https://freebsdfoundation.org/donate/. To find out more about our Partnership Program, go here: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/.

Advocacy

During the 4th quarter of 2024, we continued to raise awareness, advocate for the project, showcase users, while also providing educational content to the FreeBSD community. Here are some highlights of those efforts.

OS Improvements

During the fourth quarter of 2024, 382 src, 135 ports, and 17 doc tree commits identified The FreeBSD Foundation as a sponsor.

The Foundation and its investment partners supported four major projects:

Other projects:

Other members of the Foundation’s development team contributed to FreeBSD development efforts. For example:

Continuous Integration and Workflow Improvement

As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.

Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you!


FreeBSD Release Engineering Team

Contact: FreeBSD Release Engineering Team, <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

The Team managed 14.2-RELEASE, leading to the official RELEASE build and announcement in December. Planning has started for the upcoming 13.5-RELEASE cycle, which is expected to be the final release from the legacy stable/13 branch; as such it will include updates to "contrib" code and some bug fixes, but is not expected to have any significant new features.

In addition to previously shipped release artifacts (ISO and memory stick images, VM images, cloud offerings, etc.) the Team is now also providing OCI compatible container images.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches.


Cluster Administration Team

Contact: Cluster Administration Team <clusteradm@FreeBSD.org>

FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications.

In this quarter, the team has worked on the following:

  • Regular support for FreeBSD.org user accounts.

  • Regular disk and parts support (and replacement) for all physical hosts and mirrors.

  • Cluster software refresh.

  • Moving more cluster services to Chicago.

  • Supporting the Grimoirelab dashboard effort.

Cluster software refresh

Except for the package builders and developer-facing ("dogfood") machines, the FreeBSD cluster mostly tracks stable/X branches.

At the time of this writing, there are 131 physical machines in the cluster. We have 54 machines on current, 61 on stable/14 and 14 on stable/13. Work continues to upgrade the remaining stable/13 machines to stable/14. The stable/12 machines have been slated for decommissioning for a while; they do not run production workloads. The remaining machines are slated for upgrading or decommissioning in the near future.

Of the 297 jails in the cluster, 222 are now on stable/14.

 12.x: Regular   2, Jails   7
 13.x: Regular  14, Jails  59
 14.x: Regular  61, Jails 222
>15.x: Regular  54, Jails   9
Total: Regular 131, Jails 297
Total installations: 428
Running -RELEASE|{-p*}: 0
Total geographic sites: 15

Moving cluster services to Chicago

Earlier this year, we started building up our new site in Chicago. This quarter, we began decommissioning older machines in New Jersey and moving services to the newer machines in Chicago. Our long-term goal is for Chicago to become our primary location. This work will take several more months to complete.

FreeBSD Official Mirrors Overview

Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror site), United States of America — California, Chicago, New Jersey (primary site), and Washington.

Our mirror site in Taiwan is experiencing an extended outage. We hope to have it back online during the first quarter of 2025.

Also during the first quarter of 2025, we expect a second mirror site in California, generously hosted by Sonic.

The hardware and network connection have been generously provided by:

New official mirrors are always welcome. We have noted the benefits of hosting single mirrors at Internet Exchange Points globally, as evidenced by our existing mirrors in Australia, Brazil, and South Africa. If you are affiliated with or know of any organizations willing to sponsor a single mirror server, please contact us. We are particularly interested in locations on the United States West Coast and throughout Europe.

See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site.

Sponsors: The FreeBSD Foundation


Continuous Integration

Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

In the fourth quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD.

Important completed tasks:

  • Update main and stable/14 build environment to 14.2-RELEASE

  • Update stable/13 build environment to 13.4-RELEASE

  • Fixed an old but not revealed bug about pw(1) usage in jail setup.

Work in progress tasks:

  • Designing and implementing pre-commit CI building and testing and pull/merge-request based system (to support the workflow working group)

  • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Redesigning the hardware test lab and adding more hardware for testing

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort!

Sponsor: The FreeBSD Foundation


Ports Collection

Contact: Tobias C. Berner <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter.

In the last quarter, we welcomed Xavier Beaudouin (kiwi@) as a new ports committer.

According to INDEX, there are currently 36,332 (down from 36,504) ports in the Ports Collection. There are currently about 3,368 (down from 3,379) open ports PRs, of which 809 are unassigned.

The last quarter saw 10,640 commits (down from 11,594) by 155 committers (one less) on the main branch and 733 commits (down from 832) by 61 committers (down from 78) on the 2024Q4 branch.

The number of ports also decreased (down from 36,504).

The most active committers to main were:

A lot has happened in the ports tree in the last three months, an excerpt of the major software upgrades are:

  • Default version of Lazarus switched to 3.6.0

  • Default version of PHP switched to 8.3

  • Chromium 131.0.6778.204

  • Electron 33.3.0

  • Firefox 134.0

  • Firefox-esr 128.6.0

  • KDE Frameworks 6.9.0

  • KDE Plasma 6.2.4

  • Qt6 6.8.1

  • Python 3.9.21

  • Python 3.10.16

  • Python 3.11.11

  • Ruby 3.2.6

  • Ruby 3.3.6

  • Rust 1.83.0

  • SDL 2.30.10

  • SDL 3.1.6

  • Sway 1.10

Three new USES were introduced:

  • cl to provide support for Common Lisp ports.

  • java to provide support for Java.

  • sbrk to handle ports requiring sbrk()

During the last quarter, pkgmgr@ ran 14 exp-runs to test various ports upgrades and changes to bsd.port.mk.


Bugmeister Team

Contact: Bugmeister <bugmeister@FreeBSD.org>

In this quarter we came even closer to steady-state; we are dealing with incoming PRs more quickly these days. For reference:

The overall number of PRs came down from slightly over 11,600 to right at 11,000. This was due to work from several people to go over entire groups of PRs (see below).

Mark Linimon attended several video calls with various src committers. They are doing some experimentation to learn what kind of effort is sustainable. The most recent effort was to evaluate the latest incoming src PRs; you will note that many of them from the past few weeks have been marked as requesting feedback.

Bugmeister folks also did some passes through the database to clean up metadata:

  • reassigned bugs away from committers who had had their commit bits safekept over the last year.

  • cleaned up bugs for Product: Base System Status: In Progress. A number of these were not being actively worked on. The count is down to 184.

    • In particular, Mark Linimon believes "assigned to mailing list" means "it is not really In Progress". Perhaps it has been discussed, but we do not really have a state for that. (We can make an argument that that itself is a bug.)

    • We are now down to only a handful of the above, from "too many". The concept is to make sure In Progress has some real meaning.

  • evaluated PRs for mfc-stableN. In particular, any having mfc-stable12 had that flag cleared.

    • The concept is to make sure these metadata have some real meaning as well: e.g. "a commit has been made and should be evaluated for MFCs".

    • There are now a much smaller number of these.

  • closed numerous PRs as "Overcome By Events":

    • (old version) + (contains the string "boot")

    • (old version) + (contains the strings "alpha" or "beta")

  • evaluated "PR shows a commit" (possibly via Phabricator)" and "there was no trailing discussion".

    • In a few cases of the above we simply assigned them and made sure that mfc-stable[13|14] was set, if it seemed appropriate.

    • This does leave many that have a commit and then have trailing discussion. I think we will need more volunteers to go through those.

  • removed many of the 'patch' keywords from PRs. In the optimal case these should now be imputed by metadata in each attachment. In a few cases where patches are submitted inline instead of as an attachment, the keyword stays. There may be a few of these left over from the GNATS conversion. The use of inline patches should be discouraged, as automation has no way to detect them. Thanks to our triagers, especially Alexander Ziaee.

There were various discussions about bug futures that came up in various video chats. One is that there is a (supported) successor to Phabricator, which itself is now no longer developed. Multiple groups will need to coordinate to evaluate it.

Jan Bramkamp has volunteered to help with the task "automate harvesting PRs and evaluating whether they still apply". Mark Linimon to collaborate.

Clusteradm@ helped us fend off yet another crawler site. While that was ongoing, bugzilla was nearly unusable due to timeouts, as were other services hosted on the same machine (wiki and cgit among others).

We also welcomed our newest Triage member, Lexi (aka 'ivy' on Discord).

Finally, glebius was added to bugmeister@ alias as core.13 liaison.


New srcmgr team

Contact: srcmgr <srcmgr@FreeBSD.org>

A new source management team has been ratified by core@ to handle management of the FreeBSD src tree, akin to portmgr@ and doceng@ for the ports and docs trees, respectively. The initial members are Ed Maste, Mark Johnston, John Baldwin, and Warner Losh. srcmgr@ is currently focused on finding ways to make src developers more productive, and to try and manage the large numbers of bug reports and pull requests that we receive. The team meets every two weeks to discuss src-related issues and spend time triaging bug reports and pull requests. Meeting minutes are available on GitHub. The srcmgr@ team has a charter and is working on developing and documenting policies to help manage the src tree.

In December, srcmgr@ ran an online bug-busting session, attended by 15 developers. We spent time going through recent bug reports, plus a list of older ones with patches. The team plans to host monthly sessions of this type, and aims to open them to a wider audience in the future.

The team plans to develop a lurker program similar to portmgr@'s in the first half of 2025.


Projects

Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.


Infrastructure Modernization

Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Alice Sowerby <alice@freebsdfoundation.org>

The project started in Q3 of 2024 and was commissioned by the Sovereign Tech Agency with a budget of $745,000, to be spent over about one year. The main goals are to improve security tools for the base system, ports, and packages, update the project’s infrastructure to speed up development, enhance build security, and make it easier for new developers to get started.

Q4 update

  • Work Package A: Technical Debt reduction. The Foundation collaborated with the Source Management team to commission and deploy a number of dashboards that characterize the bug backlog for the FreeBSD Project. These were created to the team’s specifications by our project partner, Bitergia, who used an open source tool called GrimoireLab to create the dashboards. Foundation staff have hosted the dashboards on a FreeBSD deployment and they can be seen at https://grimoire.freebsd.org/. More information about the dashboards can be found at https://github.com/freebsd/grimoire.

    The Source Management team has also used these dashboards to support their new, evolving approach to bug triage and it has been included as a key tool for collaborative bug-squashing events.

  • Work Package B: Zero Trust Builds, and Work Package C: CI/CD Automation. The Foundation collaborated with various key management and administration teams within the FreeBSD Project to co-create the details of the scope for these two projects. They are scheduled to start in January and will conclude in Q2/3.

  • Work Package D: Security Controls in Ports and Packages, and Work Package E: Improve Software Bill of Materials (SBOM). These have not started yet as they are scheduled for February and March starts respectively.

Commissioning body: Sovereign Tech Agency


Laptop Support and Usability Improvements Project

Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Alice Sowerby <alice@freebsdfoundation.org>

The project began in Q4 of 2024 and is funded by the FreeBSD Foundation and Quantum Leap Research. It has a budget of $750,000, which will be used over one to two years. The goal is to improve key features like WiFi, audio usability, suspend and resume functions, graphics, and Bluetooth. The team will also create clear documentation and step-by-step guides to help people use the new features.

Q4 Update

Sponsor: The FreeBSD Foundation
Sponsor: Quantum Leap Research


Security engineering at the FreeBSD Foundation

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

My tasks at the FreeBSD Foundation continue to revolve around Security Engineering for the FreeBSD Project.

First, we keep working on the outcome of the source code audit on bhyve and Capsicum, documenting and researching how to prevent and mitigate similar issues from occurring again in the future. This includes the processes relevant for contributions to the FreeBSD Project, as well as the preparation of a joint presentation with Alpha-Omega at the BSD Devroom during the coming FOSDEM conference in 2025.

At the same time, I am liaising with the Open Regulatory Compliance Working Group (ORC WG), where an FAQ is being elaborated jointly by a number of stakeholders on the European Union’s newly introduced Cyber Resilience Act (CRA). This is all related to our ongoing collaboration with OpenSSF, notably the self-assessment initiative; note that the FreeBSD Foundation can provide assistance in this regard for projects deploying FreeBSD.

Finally, possibilities around the integration of OSV tooling into the FreeBSD ecosystem are under investigation as well.

Sponsored by: The FreeBSD Foundation


Security Audits

Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Alice Sowerby<alice@freebsdfoundation.org>

The project began in Q2 of 2024 and was funded by Alpha Omega with a budget of $137,500, which was used over about six months and is now complete. The focus was on conducting a code audit for key subsystems, bhyve and Capsicum, as well as performing a security audit of the development process. The funds were used to hire a specialist offensive security firm to perform the code audit, to contract developers to address issues found, and for Foundation staff’s work on both audits.

Q4 update
The project is complete.

The Code Audit and subsequent reports were released after the related Security Advisories were published.

The Process Audit is complete. It was created by FreeBSD Foundation staff who ran an outreach exercise to gather information about the current FreeBSD development process. The teams consulted were: Security Team, Source Management Team, Cluster Administrators, Release Engineering Team.

Information was gathered through an online long-form survey which was structured around existing frameworks for analysing security in software development. Teams were asked to describe current development processes and appraise the current security practices, as well as to make suggestions for improvements.

The responses were collated and synthesised into the report by Foundation staff. The report was reviewed for accuracy by the original respondents.

The report will now be made available to the Security Team and other teams previously mentioned, as well as to the Foundation executive team. This will be a useful tool in identifying areas for investment and prioritisation going forward as more security projects are planned and funded.

The report is intended primarily for FreeBSD Project and Foundation planning purposes and as such there is no plan to promote it to an external audience. Interested readers should contact the Security Team to request a copy of the report.

To learn about the project, and to see historical monthly updates visit: https://github.com/ossf/alpha-omega/tree/main/alpha/engagements/2024/FreeBSD.


Framework Laptop support

Contact: Daniel Schaefer <dhs@frame.work>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: Sheng-Yi Hong <aokblast@FreeBSD.org>

For a long time, Framework Laptop Inc is friendly to the FreeBSD project in many aspects, including providing engineering samples to Foundation for testing and working on support.

Since 2024 summer, there are several small hackathons in Framework’s Taipei office on testing FreeBSD on different models of Framework laptop, and the peripheral devices.

Sheng-Yi is using the laptop provided by Framework Computer to add more device support, e.g. d3b05d0ea10a: Add smbus and i2c device IDs for Meteor Lake.

Daniel from Framework Computer Inc started a repository under Framework Computer’s GitHub organization to keep the notes of installation and miscellaneous information. He fixed fingerprint readers (libfprint) not just for Framework, but in general on FreeBSD. And working on the support and fix to many related drivers on FreeBSD.

In November, Foundation people and some FreeBSD developers visited Framework’s San Francisco office and had a meeting for checking the current FreeBSD support status and discussing the possible future collaboration plans.

Foundation will continue working on improving the general laptop support and using Framework as one of the target platforms for the Laptop Support and Usability Project.

Sponsor: The FreeBSD Foundation for Li-Wen’s work
Sponsor: Framework Computer Inc for Daniel’s work, hardware and space support


Userland

Changes affecting the base system and programs in it.


PkgBase-motivated improvements to pkg

Contact: Isaac Freund <ifreund@freebsdfoundation.org>

Some problems blocking progress on the PkgBase project are caused by shortcomings of pkg(8). The primary goal of my work on pkg is to unblock PkgBase progress. However, all users of pkg will benefit even if they do not use PkgBase.

The scheduler for pkg’s install/upgrade/delete jobs has been rewritten, motivated by solving PR259785. The new scheduler models the scheduling problem as a directed graph and splits upgrade jobs into delete/install halves only when necessary to break a cycle in the graph. This formal model gives strong guarantees about ordering that the old scheduler was not able to provide and prevents unnecessary splitting of upgrade jobs. It also fixes longstanding bugs where the old scheduler would bail out and cause the entire upgrade to fail. The new scheduler is included in pkg version 1.21.99.3 (pkg-devel).

The rest of my work this quarter has been related to pkg’s automatic tracking of shared library dependencies, which PkgBase heavily relies on. The initial motivating problem was PR265061 but it was necessary to make more fundamental changes to how pkg tracks shlibs before cleanly solving that problem became possible.

When a package is created with pkg-create(8), pkg scans the included files and generates shlibs_provided/shlibs_required lists based on the executables/shared libraries found. Before my changes, pkg would use the elf hints file of the host system as an input to pkg-create in order to filter out shlibs provided by the base system from the generated shlibs_required list. An ALLOW_BASE_SHLIBS option disabled this filtering for the purpose of building PkgBase packages.

After my changes, pkg-create no longer reads the elf hints file of the host system and base system shlibs are included in the generated shlibs_required list. When pkg-install(8)/pkg-upgrade(8)/etc. invoke the solver on an non-PkgBase system, pkg generates a list of shlibs provided by the base system as an input to the solver by scanning /lib and /usr/lib. On a PkgBase system, the PkgBase packages provide all base system shlibs.

This allows the ALLOW_BASE_SHLIBS option to be eliminated. It also gives better integration between the ports packages and PkgBase packages as shlib dependencies of ports packages on PkgBase packages are now tracked rather than ignored. Finally, this change significantly simplifies the pkg codebase and improves portability. This change was implemented in https://github.com/freebsd/pkg/pull/2386 and is not yet included in a pkg release.

With that change and other internal improvements I was able to add support for tracking lib32 and Linuxulator shlibs, which should resolve the problem that originally motivated my work on pkg’s shlib handling (PR265061). This support is implemented in https://github.com/freebsd/pkg/pull/2387 and is not yet included in a pkg release.

Sponsor: The FreeBSD Foundation


Progress on the FreeBSD installer

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

As part of 2024’s GSoC Project on the FreeBSD installer, I had the pleasure to mentor Chun Cheng Yeh (aka "Leaf") with his implementation of additional capabilities. The aim was to add support for repairing or updating an existing installation of FreeBSD, as well as allowing packages to be installed in the Live environment. This work has been consolidated into three distinct pull-requests, available on GitHub. While some aspects probably still require additional polishing before a possible merge, the possibility to significantly extend the installer images into a potentially life-saving tool is within reach.

This is particularly relevant given the ongoing efforts to improve support for laptop and desktop use of FreeBSD. In this context, I am currently resuming work on the graphical version of the installer. The most immediate challenge includes shaping it suitably for integration into the next major release.

Combining the two initiatives above should help FreeBSD close some gaps with its competition amongst other modern Operating Systems, for the enterprise as well as for laptop and desktop use.

Sponsored by: The FreeBSD Foundation


Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.


Audio Stack Improvements

Contact: Christos Margiolis <christos@FreeBSD.org>

The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature.

Important work since last report:

Future work includes:

  • More bug fixes, optimizations and general improvements.

  • Implement a generic MIDI layer, similar to pcm/, and improve/modernize the MIDI codebase in general.

  • Implement a bluetooth device management utility.

  • virtual_oss patches and improvements.

  • Attempt to automate snd_hda(4) pin-patching.

  • Investigate SOF/DMIC support.

You can also follow the development process in freebsd-multimedia@, where I post regular reports.

Sponsor: The FreeBSD Foundation


mac_do(4), setcred(2), mdo(1)

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr>
Contact: Baptiste Daroussin <bapt@FreeBSD.org>

This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework. For an overall presentation, we refer the reader to the previous quarter’s report. As this is a progress report, we only recall the outline here.

In a nutshell, this project comprises two components:

  • mac_do(4) is the kernel module that checks credentials transition requests and authorizes those that match rules configured by the administrator.

  • mdo(1) is the userland program playing the role of a mediator between processes wanting to launch other processes with changed credentials and mac_do(4), whose function is to authorize only specific such changes. setcred(2) is the new system call at the interface between them. It enables userland to request various credentials changes atomically, allowing mac_do(4) to base its decision on the transition between the initial and desired final credentials.

Both prerequisite commits and changes in MAC/do proper have been reviewed and all commits have finally been pushed to FreeBSD’s main branch, including documentation in the form of a new manual page for setcred(2) and changes to the mac_do(4) one to match the new sysctl(8) knobs and rules syntax.

Rules can now express finely which groups are allowed in the resulting credentials for a given UID or GID, notably making it possible to specify which target primary and supplementary groups the final credentials can, or must, or must not include. Please consult mac_do(4) for a description of the new syntax and examples.

Future work, in no particular order and timeframe, may include:

  • For the mac_do(4) component:

    • Currently, it can only grant credentials transitions for processes spawned from the /usr/bin/mdo executable. The possibility to tweak this path may be interesting for custom thin jail layouts. The ability to have several such paths is one of the missing pieces to be able to use mac_do(4) in conjunction with other credentials-granting programs such as sudo(1) and doas(1).

    • mac_do(4) currently can only grant new credentials if they are requested via the new setcred(2), as it needs to see the current and desired final credentials to make a decision. However, each call to traditional and standard credentials-changing functions, such as setuid(2), seteuid(2), etc., can be considered as a (limited) full transition on its own, which mac_do(4) could decide upon. This functionality could allow to more finely control transitions to root and, combined with that of the previous point, to install and use credentials-granting programs without the "setuid" bit. However, the full power of this new mac_do(4) module version cannot be harnessed without modifying these programs to use setcred(2).

  • For the mdo(1) component:

    • The credentials transitions that can be requested are fairly limited compared to what mac_do(4)'s rules can allow. It would be useful to make it possible to:

      • Specify any list of target groups (primary or supplementary), possibly based on user names (with the implicit list coming from the contents of /etc/passwd and /etc/group) but allowing some tweaks (such as excluding a particular group in the final credentials).

      • Allow changes of groups only.

      • Request a password before calling setcred(2) in certain cases. This weakens the security paradigm of the mac_do(4)/mdo(1) combination, as it would now rely on userland for part of the gating process, but seems acceptable in many cases.

      • Grow a mode producing the target part of rules corresponding to the contents of the password and group databases for some users.

We welcome any feedback on this new version and the future-work list above.

Sponsor: The FreeBSD Foundation
Sponsor: Kumacom SARL


Suspend/Resume Improvements

Contact: obiwac <obiwac@freebsd.org>

Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD.

This will allow modern Intel and AMD laptops (e.g. AMD and newer Intel Framework laptops), some of which do not support ACPI S3 sleep, to enter low power states to increase battery life.

Ben Widawsky from Intel started working on this in 2018 but his work was never finished and is now outdated. His work has now been picked up and the first goal is to get suspend/resume working on the Framework 13 AMD Ryzen 7040 series by end of January. There are plans for presenting initial results at a talk at FOSDEM.

Currently, all device power constraints on AMD can already be parsed to enter a system’s low power states.

Sponsor: The FreeBSD Foundation


umb(4) driver for MBIM USB 4G/5G modems

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

The Mobile Broadband Interface Model (MBIM) is a protocol for communication with network USB devices, transmitting packet data over mobile broadband networks. Implementing this protocol adds support for a whole range of USB devices providing connectivity to mobile networks, such as 4G, 5G, and their subsequent technological evolutions.

A first implementation for this protocol was performed for OpenBSD in 2016, under the name umb(4). I have ported it myself to NetBSD under the same name, back in 2019. I was then contracted to make it work with OPNSense, and authorized to publish it as Open Source in 2022. Unfortunately, by this time, some changes in FreeBSD effectively broke the driver, and it could not be merged until fixed.

This quarter I have managed to offer an updated version and confirmed it working (thanks Mike and Zhenlei!). This version is now under review in Phabricator as D48167. The submission is still based on code from 2020, and behind progress made by OpenBSD since that time. As such, it is currently restricted to IPv4. However, I believe it makes sense to keep the review simple and focus on the design decisions and integration, before progressively importing the improvements made upstream since then in OpenBSD (notably IPv6 support).

In its current form, the driver was modified from being out of tree and available as a plug-in for OPNSense, into a kernel module and its companion binary, umbconfig(8). This management binary effectively allows the umb(4) driver to be configured beyond the capabilities of ifconfig(8): the PIN or PUK code, APN, username/password, or roaming parameters can be setup, and the connectivity tracked as well (network provider, speed…​).

Should you want to give it a spin yourself and get hardware supported by this driver, the single most important feature to look for is support for the MBIM specification. The manual page for OpenBSD provides a list of devices that should be compliant; note that some of them require preliminary configuration in order to effectively expose the MBIM interface. The exact procedure is vendor-specific, and can also depend on the model and current configuration of the device. You should refer to the documentation offered for your device for any steps necessary.

Sponsored by: The FreeBSD Foundation


LinuxKPI 802.11 Wireless Update

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

With multiple wireless projects ongoing, this report focuses on the efforts using permissively licensed Linux wireless drivers mostly unmodified on FreeBSD.

Drivers previously committed directly to FreeBSD src.git were retroactively imported in vendor branches and merged to main. This makes maintenance and identifying local changes a lot easier. The iwlwifi(4), rtw88(4), and rtw89(4) drivers got updated in main to match Linux 6.11.

The rtw89(4) driver, which had been ported and in the tree for a while, got connected to the build. Thanks for that goes to the efforts of the community finding two bugs preventing it from working before.

Wireless firmware in ports got updated and a release flavor was added. The release building framework got enhanced to install the firmware packages onto the release media. The installer grew support to run fwget(8) on the installed system to install the firmware. This all together ensures that (wireless) drivers with external firmware can be used from the installer and right away on the installed system without the need for alternate connectivity. With the framework in place for iwlwifi(4), rtw88(4), and rtw89(4) support for more drivers can easily be added in the future. These changes shipped the first time with 14.2-RELEASE.

Having a lot of these requested necessities out of the way, time was spent on HT(802.11n) and VHT(802.11ac) improvements to the LinuxKPI framework synching between driver and net80211. Hardware crypto offload got sorted along with A-MPDU RX/BA offload right at the end of the year. Both were needed towards the goal to achieve higher throughput with iwlwifi(4).

A half-year old bug, which stayed unnoticed preventing packets to be sent beyond scanning with rtw88(4) in main and stable/14, received a patch to fix the situation.

Work for the first quarter of 2025 should include:

  • finishing basic HT and VHT support, and

  • looking at finishing the code for generic LinuxKPI 802.11 suspend/resume support

Sponsor: The FreeBSD Foundation


Wireless Update

Contact: Tom Jones <thj@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

With Support from the FreeBSD Foundation this quarter I started working on porting the iwx WiFi driver from OpenBSD (via Haiku). The iwx driver supports many of the chipsets supported by iwlwifi, but rather than make that driver more complex the OpenBSD developers decided to support these devices in a new driver.

iwx on OpenBSD currently supports running as a station in 80211abgn and ac, it does not yet support ax rates. The goals of this project are to import a maintainable driver from OpenBSD and to gradually increase support until we have a native driver in FreeBSD with support for 80211ac (and potentially 80211ax).

Currently the driver supports 80211a and 80211g and is able to saturate the practical limits of the rates these standards offers (roughly 28Mbit down and 25 Mbit up). The driver is under active development and moving quite quickly.

The plan for the next quarter is to add support for high throughput rates, implement monitor mode and stabilise the driver for a public call for testing.

Once the driver is stable enough a call for testing will be posted to the freebsd-current and freebsd-wireless mailing lists.

Sponsor: The FreeBSD Foundation


Syzkaller Improvement on FreeBSD

Contact: Jian-Lin Li <ljianlin99@gmail.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

Syzkaller is an operating system kernel fuzzer that can look for vulnerabilities in the kernel.

This project aims to improve the support of Syzkaller on FreeBSD. Based on the existing WiFi fuzzer designed for Linux, we drafted a WiFi fuzzer for FreeBSD. We planned to use wtap(4), a virtual wifi driver for testing, in order to support WiFi fuzzing.

Some of the design details include:

  • Introduce a new netlink command to wtap in order to realize frame injection, which is essential for WiFi fuzzing.

  • Initialize wtap devices in Syzkaller before WiFi fuzzing.

We are developing some prototypes and discussing the feasible design plan with some experts. There is not much progress yet. We hope to have more progress on this project in the next few months.

Sponsor: The FreeBSD Foundation


FreeBSD V4L2 & kernel USB Video Class driver

Contact: Alvin Chen <weike_chen@dell.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow v4l2 APIs, so that most of the Linux camera applications can be easily ported to FreeBSD.

The code is still cleaning up and will be submitted to official review system after completing.

The Dell ThinOS team is currently working on MIPI Webcam support, including intel XPU.

Sponsor: Dell Technologies for the development
Sponsor: The FreeBSD Foundation for assistance of upstreaming


Architectures

Updating platform-specific features and bringing in support for new hardware platforms.


Pinephone Pro Support

Contact: Toby Kurien <toby@tobykurien.com>

The project to port FreeBSD over to the Pinephone Pro is progressing. The aim of this project is to step by step support components of the Pinephone Pro in FreeBSD so that the device one day might be usable as a highly mobile FreeBSD device.

In this quarter:

  • A driver for the RK818 power management IC was implemented, enabling the device regulators.

  • A driver for the real-time clock was also implemented, allowing the system to keep time between reboots.

  • A driver for the RK818 battery charger and battery monitor was written to allow the battery to be charged via USB, and to retrieve some battery information like voltage and charging status via sysctl.

  • The code repository has been updated with scripts and documentation on how to compile the custom kernel and device tree, and patch a FreeBSD 15-CURRENT image with them so that it boots on the Pinephone Pro.

The next steps are to enable UEFI-based framebuffer support to enable output to the screen, and to enable USB on-the-go functionality, which might allow for plugging in a USB keyboard and/or Ethernet. Porting the Linux driver for WiFi will also be looked into. Any developers wanting to assist are encouraged to get in touch. Additional feedback and testers are welcome.

Sponsor: Honeyguide Group


Cloud

Updating cloud-specific features and bringing in support for new cloud platforms.


FreeBSD on Microsoft HyperV and Azure

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>, <weh@microsoft.com>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Colin Su <yuas@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

In this quarter, we have published the 14.2-RELEASE on Azure Marketplace.

Colin Su has presented at the FreeBSD 2024 Fall Summit about Azure DevOps Pipeline.

Souradeep Chakrabarti from Microsoft has added a feature to use hypercalls for TLB shootdown on Hyper-V and Azure.

Wei Hu root-caused an issue on missing CDROM device when booting FreeBSD on the latest Azure v6 VM SKU. V6 type only offers NVMe disks to guest OS. He also continues bug fixing for FreeBSD MANA NIC device.

Work in progress tasks:

Open tasks:

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else


OpenStack on FreeBSD

Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

The OpenStack on FreeBSD project aims to merge the capabilities of the OpenStack cloud infrastructure with the robust features of FreeBSD. Our objective is to harness FreeBSD’s unique features while ensuring compatibility with OpenStack’s operations.

In the fourth quarter, our primary goal was to finalize the tasks promised under milestone 1 by establishing a new environment for a demonstrable Proof of Concept (POC) site. However, the simultaneous aim to set up another deployment based on FreeBSD Jail within the same environment led us to spend considerable time on network design and tuning. Fortunately, we successfully established external network connectivity for guest VMs by the end of this period. The remaining challenge now is to enable guest VMs to automatically acquire IP addresses through cloud-init.

On another note, we attempted to obtain the domain XML of VMs from the Linux-based OpenStack to compare with the XML used for bhyve VMs. These domain XMLs are utilized by Libvirt, defining each virtual machine’s configuration and operational parameters. Comparing the differences between the two will aid in developing the "bhyve serial console over TCP" work.

In the first quarter of the upcoming year, we will continue to conclude the tasks related to milestone 1 of our project. Additionally, we will persist in developing FreeBSD Ports for OpenStack components, further integrating and enhancing the system’s capabilities.

Sponsor: The FreeBSD Foundation


Containers and FreeBSD: Cloud Native Buildpacks

Contact: Robert Gogolok <gogolok@gmail.com>

Cloud Native Buildpacks (CNBs) transform application source code into container images. Those images can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles.

A few weeks ago, I’ve started to look into FreeBSD support for buildpacks. My goal is to have working versions of the tools lifecycle and pack in the next few months.

There were previous attempts to bring support for FreeBSD to buildpacks, for example to lifecycle:

After looking into those changes, I’ve decided to first introduce some general cleanup steps to keep the required changes for FreeBSD small.

This resulted in the following changes that were successfully integrated:

With these steps, it is now possible to compile lifecycle under FreeBSD.

The next steps are:

  • Provide missing FreeBSD functionality to lifecycle.

  • Further investigate FreeBSD as a build target in lifecycle.

  • Investigate and get the tool pack to compile and run under FreeBSD.

  • Provide lifecycle and/or pack via FreeBSD ports.

  • Investigate the idea of FreeBSD buildpacks for some popular languages, similar to paketo buildpacks.


FreeBSD on EC2

Contact: Colin Percival <cperciva@FreeBSD.org>

FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances.

In the past quarter, first boot performance of ZFS AMIs has been significantly improved, e.g. from about 22 seconds to about 11 seconds for 15.0 "base" AMIs on amd64. Graphs of boot performance over time are now being generated and published automatically; typical times are around 9-12 seconds for "base" and "small" AMIs and 14-18 seconds for "cloud-init" AMIs.

On Graviton systems, the EC2 "shutdown" and "reboot" operations now work as intended (starting with FreeBSD 14.2). On Graviton systems, adding new devices (e.g. EBS volumes) while the system is running now works in HEAD and support is expected to be merged in time for FreeBSD 14.3.

Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva


Documentation

Noteworthy changes in the documentation tree, manual pages, or new external books/documents.


Documentation Engineering Team

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter.

Document changes

  • Handbook:

    • Add warning about custom kernel configurations.

    • Mention Rocky Linux 9 userland.

    • Add notes to VMWare related setup guide.

  • Committer’s guide: Document "Discussed with" Improve "Fixes:" metadata.

  • Porter’s Handbook: Document new TCL_ variables.

  • Website: Remove Turkish links.

  • Documentation repository:

    • Added OpenBSD 7.6 manual pages.

    • Updated Debian 11/12 manpages.

FreeBSD Translations on Weblate

Q3 2024 Status
  • 18 team languages

  • 215 registered users

1 new translator joined Weblate:

  • Sean Markham (ES)

Languages
  • Chinese (Simplified) (zh-cn) (progress: 14%)

  • Chinese (Traditional) (zh-tw) (progress: 11%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Greek (el) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 11%)

  • Korean (ko) (progress: 30%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 6%)

  • Polish (progress: 2%)

  • Portuguese (progress: 0%)

  • Portuguese (pt-br) (progress: 31%)

  • Sinhala (progress: 1%)

  • Spanish (es) (progress: 39%)

  • Spanish (Chile) (progress: 0%)

  • Turkish (tr) (progress: 5%)

We want to thank everyone who contributed, translating, or reviewing documents.

And please, help promote this effort on your local user group; we always need more volunteers.

Packages maintained by DocEng

During this quarter the following work was done in packages maintained by doceng@:

  • www/gohugo: update to 0.140.2

  • misc/freebsd-doc-ja: fix build

Open issues

There is 1 open PR in Bugzilla assigned to doceng@:

  • 276923 www/gohugo link error under poudriere


Ports

Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.


Ports Collection Accessibility - Colors Low Vision

Contact: FreeBSD Accessibility mailing list <freebsd-accessibility@FreeBSD.org>
Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

FreeBSD provides the Ports Collection to give users and administrators a simple way to install applications. The collection provides tens of thousands of ports; port configuration is a key feature. It is possible to configure a port before the building and installation. The command "make config" uses a text user interface (TUI) to set up port options interactively.

Recently low vision users (mainly with cataracts) have requested new features to easily change the colors of the TUI. Several features have been implemented to allow changing colors, for example: a new environment variable to set the UI to black and white, or the ability to set colors by reading a configuration file at runtime. All features have been described in portconfig(1) since version 0.6.2.

To note, blind users can refer to PortOptsCLI - Ports Collection Accessibility, Status Report Third Quarter 2023 to use the Ports Collection.

Tips and new ideas are welcome. If possible, send reports to the FreeBSD Accessibility mailing list, to share and to track discussions in a public place.

Sponsored by: The FreeBSD Foundation


Containers and FreeBSD: AppJail, Director, OCI and more

Contact: Jesús Daniel Colmenares Oviedo <DtxdF@disroot.org>

AppJail is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application.

Director is a tool for running multi-jail environments on AppJail using a simple YAML specification. A Director file is used to define how one or more jails that make up your application are configured. Once you have a Director file, you can create and start your application with a single command: appjail-director up.

LittleJet is an open source, easy-to-use orchestrator for managing, deploying, scaling and interconnecting FreeBSD jails anywhere in the world.

Their goals are to simplify life for sysadmins and developers by providing a unified interface that automates the jail workflow by combining the base FreeBSD tools.

AppJail and all its meta-projects extensively follow The Ephemeral Concept which helps update/upgrade jails more easily as they become disposable. I have used this extensively to deploy my jails with services since this concept was implemented in AppJail.

Although there have been great people working on OCI for a long time, this month the featured topic is OCI, and the advances related to this technology in FreeBSD make it possible to implement it in AppJail. The latest release adds more useful features, improves on existing things and implements OCI.

I’m continually adding more Makejails, a simple text file that automates the deployment of services in jails. There is an organization on GitHub that I call The Centralized Repository if you want to make a contribution. The last improvement was to implement BuildBot as the CI/CD of AppJail images, so any change made to a repository that is tracked by BuildBot will generate a new task to build and deploy an image to the mirrors. And if mirrors are not an option, appjail-reproduce can be used to build images using your own resources.


Improving Common Lisp Infrastructure in FreeBSD Ports

Contact: Joe Mingrone <jrm@FreeBSD.org>

Common Lisp (CL) is a general-purpose, multi-paradigm programming language first conceived in the early 1980s. Although it predates many modern programming languages, it remains a viable option for many different projects. One contemporary example is Grammarly, a widely used grammar engine reportedly implemented in CL and capable of processing over a thousand sentences per second.

The FreeBSD ports tree has provided CL support for many years. The initial work was contributed by Henrik Motakef in 2003, and then enhanced and maintained by Jimmy Olgeni. The infrastructure facilitated building and installing CL libraries using ASDF so that multiple CL implementations could load compiled object code files (fasl) at run-time without conflicts.

However, many issues crept in over the years. Support dwindled to only one CL implementation, SBCL, and users encountered longstanding bugs such as conflicting ASDF versions and write errors when loading libraries outside the ports tree. Also, managing dependencies was cumbersome because most infrastructure code was included as part of the devel/cl-asdf port.

A long overdue update of the FreeBSD CL infrastructure was completed this quarter. The primary outcome is that users can, once again, easily and reliably work with CL on FreeBSD. For example, installing and loading the popular Alexandria library under SBCL requires only a few simple steps.

% pkg install cl-alexandria-sbcl
% sbcl
* (asdf:load-system :alexandria)

Similar steps can be used to load libraries for the other two newly supported implementations: CCL, and CLISP. Most users will likely prefer to work with the fasl ports, although there is no obligation to do so. Because ASDF is now configured to fall back to its default caching mechanism of writing fasl to a cache under ${HOME}, users can also install CL source ports without the associated fasl port or load CL sources from outside of the ports tree.

Other highlights of the update include:

For details, refer to these commit logs:

The tentative plan is to add support for ECL after an ASDF output translation issue is solved and to create ports for other CL libraries. Feedback, testing, and contributions are welcome.

Sponsor: The FreeBSD Foundation


FreeBSD Erlang Ecosystem Ports update

Contact: FreeBSD Erlang mailing list <erlang@FreeBSD.org>

The Erlang runtime system, commonly known as the BEAM, provides a runtime that is used by a number of programming languages and applications in the FreeBSD ports collection.

In the final update for 2024, the Erlang ecosystem team has been busy:

  • Regular updates to all Erlang/OTP releases, to stay current

  • Elixir 1.18.1, Gleam 1.6.3, and RabbitMQ updates

Users of RabbitMQ need to update each quarter to avoid being stuck on an unsupported release of Erlang/OTP + RabbitMQ, without a supported migration path.

Note that as the upstream Erlang OTP team only commit to supporting the two latest major releases, more and more point updates are arriving for OTP26-27, but not for the older Erlang runtime releases, which are now unlikely to get security and bug fixes.

The Erlang team will be updating the default Erlang runtime to OTP26, to lang/erlang, along with the usual dependencies and tooling.

Additional testing and community contributions are welcome; please reach out on the mailing list, especially if you are able to help testing of specific port updates.


Improve OpenJDK on FreeBSD

Contact: Harald Eilertsen <haraldei-fbsd@anduin.net>

The aim of this project is to improve support for Java in FreeBSD, by working with the upstream OpenJDK community, as well as the FreeBSD community in getting the changes and additions needed for fully supporting FreeBSD accepted upstream.

As this is a new project, there is not much to report yet, but here’s what has been achieved so far:

Sponsor: The FreeBSD Foundation


Xfce on FreeBSD

Contact: Xfce team <xfce@FreeBSD.org>
Contact: Guido Falsi <madpilot@FreeBSD.org>

The FreeBSD Xfce team (xfce@) works to ensure the Xfce desktop environment is maintained and fully functional on FreeBSD.

This quarter the Xfce team members are pleased to welcome Xfce 4.20 to the FreeBSD ports tree!

This new release adds many stability improvements and some new functionality.

Upstream work for this release was focused on getting the code base ready for Wayland support.

This release brings experimental Wayland support, although not all components have been migrated, so it may not work for you.

For further details, refer to the Xfce 4.20 Upstream Release Announcement.


LXQt on FreeBSD

Contact: LXQt Team <lxqt@FreeBSD.org>

LXQt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, LXQt also works fine with less powerful machines.

During this quarter, the x11-wm/lxqt metaport was updated to 2.1.0. This update adds initial Wayland support to the LXQt desktop. You can read some release highlights here.

Anyone interested in helping with the project is welcome.

Current version: 2.1.0


GCC on FreeBSD

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

The exp-run to update GCC default version from 13 to 14 is getting forward. As usual, thanks to everyone involved.

If you maintain any of the affected ports or want to give a hand preparing and testing some patches, you can consider trying adding -fpermissive to CFLAGS in affected ports as a temporary solution: GCC 14 has transformed some warnings into errors, which is the cause of many of the failed builds. The -fpermissive flag switches those errors back to warnings. However, it is preferable that upstream updates its code to remove those warnings completely so that -fpermissive is not necessary, possibly with FreeBSD ports maintainers support. If the code is not maintained upstream anymore, the time might have come to deprecate the port.

Work has been done on some bugs too, mainly upstream:

Thanks to everyone who has helped with these issues.


Tor-Browser

Contact: Martin Filla <freebsd@sysctl.cz>

Since the last report, significant progress has been made in building and packaging Tor Browser for FreeBSD. Additionally, the Tor Browser version has been updated to 14.0.3, which is now available from the Tor Browser download page and also from our distribution directory.

This update includes important security updates to Firefox, ensuring that users benefit from enhanced security and privacy features. Expanding FreeBSD compatibility remains a priority to provide seamless and native privacy solutions for the platform.

What is new: Tor Browser version 14.0.3 includes:

  • Rebase to Firefox 128.5.0esr.

  • Backporting of security fixes from Firefox 133.

  • Platform-specific updates such as disabling Microsoft SSO on macOS and updating GeckoView for Android.

  • Updated Go to version 1.22.9 in the build system.

Help Needed: To move forward, assistance is required in the following areas:

Code Review: Ensure patches meet the required coding and security standards. Testing: Volunteers are needed to test Tor Browser 14.0.3 on FreeBSD to identify edge cases. Bug Fixing: Developers familiar with FreeBSD and Firefox’s codebase are encouraged to resolve known issues.

Feedback: If you find a bug or have suggestions for improving this release, please let us know through the GitLab Repository or the provided contact email.


Greenbone Vulnerability Management Community Edition

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

The Greenbone Community Edition (GVM) covers the actual source code of the Greenbone Vulnerability Management software stack, which is also known as OpenVAS scanner, a security feed with more than 160.000 vulnerability tests, a vulnerability management application, and much more.

During this quarter, security/gvm metaport was updated to 24.1.2. This update includes the following:

A quick GVM jail installation to test it can be done using AppJail, makejail, or https://github.com/AppJail-makejails/greenbone-openvas.

Anyone interested in helping with the project or interested in aarch64 device donation for testing is welcome.

Current version: 24.1.2


Wazuh on FreeBSD

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack or OpenSearch Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts.

After a long break, ports has been updated to include Wazuh version 4.9.2. This version of Wazuh uses Python 3.11 instead of 3.10, and it includes some new features:

Also, FreeBSD ports include a custom version of wazuh-dashboard-plugins for a better integration with FreeBSD.

Wazuh can easily be installed in a jail by following the Wazuh AppJail-Makejails tutorial.

Anyone interested in helping with the project or interested in aarch64 device donation for testing/packaging is welcome.

Current version: 4.9.2

TODO

  • Add Wazuh cluster-mode infrastructure AppJail makejails

  • Add vulnerability detection support to FreeBSD Wazuh agent

  • Add FreeBSD as officially supported platform by Wazuh Inc

  • Update FreeBSD SCA Policies to new FreeBSD CIS Benchmark


A bhyve management GUI written in Freepascal/Lazarus

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools mostly installed on base system and some installed from ports/packages. The application is being developed for desktop users to easily and quickly setup and run virtual machines on FreeBSD hosts.

During this quarter, there were many bugfixes and improvements to Bhyvemgr.

These are some new features that were added:

  • Support for Trusted Platform Module (TPM through software via swtpm) on CURRENT

  • Bootvars support

  • Bios, system, board and chassis information can be modified

  • Systray icon support on almost all desktop environment (tested on Plasma, Gnome, Xfce, LXQt and IceWM)

Bhyvemgr supports aarch64 only on 15-CURRENT and amd64 from FreeBSD 13.x to 15-CURRENT. Also bhyvemgr can be

  • compiled and installed from ports,

  • installed as binaries through pkg with gtk2, qt5 or qt6 interface support.

Anyone interested in helping or supporting the project are welcome.

Current version: 1.3.1

TODO

  • Testing on real aarch64 hardware (aarch64 device donation for testing is welcome)

  • Add uart device support


BSD-USER 4 LINUX

Contact: Maksym Sobolyev <sobomax@FreeBSD.org>

The bsd-user-4-linux project ports BSD user-mode emulation for QEMU to Linux. The primary goal is to enable unmodified FreeBSD binaries to run on modern Linux systems. Additionally, the project aims to provide multi-platform container images with a functional FreeBSD environment and ready-to-use GitHub Actions templates.

Current Status:

  • The initial port successfully runs make -jN buildworld.

  • Most command-line tools are working as expected (sh, bash, find, grep, git, clang, etc).

  • A GitHub Actions pipeline builds x86_64 emulation images for:

    • linux/386

    • linux/amd64

    • linux/arm/v5

    • linux/arm64/v8

Next Steps: * Implement container integration.

How You Can Help:

  • Test with your preferred toolchain, report issues, or contribute fixes.

  • Build and test non-x86_64 emulation images (e.g., FreeBSD/arm64 on Linux/x86_64). The code works on BSD but needs testing on Linux.

  • Support us on Patreon.

Sponsor: Sippy Software, Inc.


Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.


Laptop and Desktop Work Group (LDWG)

Contact: Chris Moerz <freebsd@ny-central.org>

October 2024 marked the inception of the Laptop and Desktop Work Group (LDWG), affectionately known as "Ludwig". This initiative provides a collaborative platform for the community to engage in development, testing, knowledge exchange, and advocacy for FreeBSD on laptops and desktops. Everyone is welcome to join, if interested.

Scope of Work:

  • Content Creation: Develop recordings, articles, tutorials, documentation, and system configurations for stakeholders interested in FreeBSD on laptops and desktops.

  • Encouraging Contributions: Invite developers, testers, and industry experts to enhance the usability of FreeBSD on laptops and desktops.

  • Facilitating Collaboration: Promote code contributions, testing initiatives, operational support, and hardware insights.

  • Supporting User Stories and Ongoing Projects: Assist in the creation, validation, prioritization, and delivery of user stories identified in the FreeBSD Foundation’s “Laptop” investment work package.

On November 16, 2024, the LDWG held its inaugural virtual meeting. The strong interest in FreeBSD for laptops and desktops was evident from the diverse group of participants, including developers, contributors, Discord community moderators, users, and FreeBSD Foundation members. Meeting slides, minutes, and recordings are available on the Group’s wiki page.

During the meeting, the group identified prioritized gaps and potential improvements in the following areas:

  • Console

  • Desktop Environment

  • Documentation

  • Hardware

    • Graphics

    • Wireless (WiFi and Bluetooth)

    • USB/Thunderbolt

  • Installer

  • Performance

  • Software and Port Availability

All activities are documented on the Group’s worksheet. The Group encourages anyone interested in contributing to add their name. If there is any planned or ongoing work, please include it in the worksheet.

Alice Sowerby provided an update on the The Foundation’s Laptop project, highlighting the need for volunteers to support testing efforts.

The Group is running an online survey to gather input from non-participants. The survey will remain open until the next call in January, where results will be presented and discussed.

Hope to see you there!


Containers and FreeBSD: Pot, Potluck and Potman

Contact: Luca Pizzamiglio (Pot) <pizzamig@FreeBSD.org>
Contact: Bretton Vine (Potluck) <bv@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>

Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad.

During this quarter, there was no new Pot release. The tool is stable and used in production for quite some time already.

Potluck got a new Netbox image. Additionally, various images have received improvements and bug fixes, e.g. improving their syslog-ng integration.

Last not least, all images have been rebuilt several times: for FreeBSD 14.1, to include security fixes, then again for 14.2 and also for the new quarterly packages.

As always, feedback and patches are welcome.

Sponsors: Nikulipe UAB, Honeyguide Group


Last modified on: February 28, 2025 by Lorenzo Salvadore