NetBSD Blog

NetBSD 11.0 RC5 available!

martin — Wed, 17 Jun 2026 16:21:41 +0000

The NetBSD project is pleased to announce the fifth (and this time hopefully final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Please note that various ISO images have been split into small ones for CD/R media and full featured DVD ones. If you are not restricted by the size limits of a CD/R medium, make sure to pick the image with "-dvd.iso" in the name.

A lot of recent security updates in third party software bundled in NetBSD happened after the previous release candidate. This includes OpenSSL, unbound, expat and more.

If you want to test 11.0 RC5 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Annual General Meeting 2026

Nia Alarie — Sat, 6 Jun 2026 16:01:52 +0000

Today, the NetBSD Foundation had an open annual general meeting in a public IRC channel. It began with presentations, and was followed by a Q&A session where we took questions from the public. Here's the full log.

<leot> OK, we are about to start... sorry for the delay!
-!- mode/#netbsd-agm [+m] by leot
-!- mode/#netbsd-agm [+o Cryo] by leot
-!- mode/#netbsd-agm [+v Cryo] by leot
 * Cryo turns the lights down
<leot> Hello everyone!
<Cryo> I'll start off by thanking you for coming.
<Cryo> and handing it to leot!
<leot> Thanks Cryo and thanks for coming!
<leot> .
<leot> Welcome to The NetBSD Foundation Annual General Meeting 2026!
<leot> .
<leot> In the agenda we will have reports from:
<leot> .
<leot> - board (<billc>)
<leot> - core (<kre>)
<leot> - admins (<spz>)
<leot> - finance-exec (<riastradh>)
<leot> - membership-exec (<martin>)
<leot> - releng (<martin>)
<leot> - security-team (<martin>)
<leot> - pkgsrc-pmc (<wiz>)
<leot> - pkgsrc-security (<tm>)
<leot> .
<leot> If there are any last-minute additions please /msg me!
<leot> .
<leot> The Q&A session will be at the end of all the presentations.
<leot> .
<leot> When Q&A begins please /msg me with "I have question for <team>" or
<leot> "I have question for <nick>" and I will give you voice when it is
<leot> your turn.
<leot> .

<leot> Next presentation is prepared by <billc> and board@ for board!
<leot> I will present on <billc> behalf
<leot> .

<leot> Welcome to the 24th Annual General Meeting of The NetBSD Foundation.
<leot> .
<leot> 2025 progress:
<leot> - Recent stable releases include NetBSD 10.1 (Dec 2024), 9.4, and 9.3
<leot> - Development is currently focused on the imminent transition to NetBSD-11 [RC4]
<leot> .
<leot> We are preparing for:
<leot> - BSDcan in Ottawa, Canada
<leot> - The ISF Common Good Cyber Fund (CGCG) application window, which runs
<leot>   from June 23 to August 4, 2026.
<leot> .
<leot> We recognize that different avenues may well be available to us regarding grants
<leot> and funding, and we are looking for volunteers to help us investigate, apply,
<leot> and deliver for the programs available. This includes, but is not limited to,
<leot> potential opportunities from the Internet Society, the Linux Foundation through
<leot> Alpha-Omega, Germany's Sovereign Tech Agency and Prototype Fund, or grants from
<leot> the European Union through NLnet.
<leot> .
<leot> The NetBSD Foundation Board of Directors presents a consolidated list
<leot> of the relevant and major actions that occurred since last AGM.
<leot> Quite a few discussions, actions, and follow-ups crossed multiple meetings.
<leot> Very few meetings resulted in not reaching quorum.
<leot> During this period, new director(s) were elected by the members and
<leot> officers were renewed or installed.
<leot> We continued with our Bronze level sponsorship support of BSDcan,
<leot> AsiaBSDcon, and EuroBSDcon to improve our representation at conferences
<leot> and developer summits.
<leot> .
<leot> We participated in the Google Summer of Code for 2025 and we attended
<leot> the Google Summer of Code Mentor Summit in Munich, Germany.
<leot> We are currently participating in GSoC this year with 5 students!
<leot> .
<leot> For 2025, these are the projects that passed:
<leot> - Asynchronous I/O Framework
<leot> - Using bubblewrap to add sandboxing to NetBSD
<leot> - Enhancing Support for NAT64 Protocol Translation in NetBSD
<leot> .
<leot> For 2026, these projects have been chosen:
<leot> - Improving and Stabilizing the racoon2 IKE Daemon in NetBSD
<leot> - Port the Enlightenment desktop environment to NetBSD
<leot> - improving RAIDframe
<leot> - Testing Compat Linux: Syscall testing
<leot> - Convert a Wi-Fi driver to the new Wi-Fi stack
<leot> .
<leot> We continued to improve our interaction and relationships with
<leot> vendors, as well as participating in industry PSIRT/CSIRT
<leot> with commercial vendors and other open-source projects.
<leot> .
<leot> We successfully completed the large-scale migration of our repository
<leot> infrastructure from CVS to a Git/Mercurial ecosystem, including the
<leot> launch of live hgweb and gitweb test environments.
<leot> .
<leot> We also advanced our security and compliance posture by initiating CNA (CVE Numbering
<leot> Authority) onboarding with MITRE and ensure readiness for the EU Cyber
<leot> Resilience Act (CRA).
<leot> .
<leot> We also implemented "Anti-Slop" protocols to protect codebase integrity
<leot> against code not written by humans.
<leot> .
<leot> The funded contracts continued for:
<leot> - improvements in release engineering
<leot> .
<leot> We are 12% through a fundraising campaign. *Please* consider
<leot> donating, as we are a US IRS 501(c)3 charitable organization.
<leot> .
-!- mode/#netbsd-agm [+v krelz] by leot
<leot> EOF

<leot> Next in the agenda we have... core@ presentation by <kre>! krelz, please go ahead!

<krelz> Hi everyone, before I begin, any other core members who want to add something
<krelz> to what I am about to present, msg leot and I'm sure you can be snuck in when I
<krelz> am done, which won't take long...
<krelz> .
<krelz> Report from core for 2026 NetBSD AGM
<krelz> .
<krelz> core is tasked with technical management of the NetBSD project.
<krelz> .
<krelz> The current members of core are:
<krelz> .
<krelz>         Christos Zoulas         christos@
<krelz>         Chuck Silvers           chs@
<krelz>         Robert Elz              kre@
<krelz>         Martin Husemann         martin@
<krelz>         Matthew Green           mrg@
<krelz>         Taylor R Campbell       riastradh@
<krelz>         Rin Okuyama             rin@
<krelz> .
<krelz> Actual technical management is difficult in a volunteer project,
<krelz> as developers work on whatever interests them.   One aspect
<krelz> which is sometimes important is in settling disputes between
<krelz> developers.   Fortunately there was only one such dispute in
<krelz> the past year, which was easily amicably settled.
<krelz> .
<krelz> Core doesn't hold regular formal meetings, issues are discussed
<krelz> when they arise, otherwise we're mostly fairly dormant.
<krelz> .
<krelz> core, as a group, can be reached at core@netbsd.org
<krelz> .
<krelz> That's it for me, for this year's core report, I will be here for questions later
<krelz> .

-!- mode/#netbsd-agm [-v krelz] by leot
<leot> Thank you kre!
<leot> Next in the agenda... we have the admins@ presentation from spz! Please go ahead!
-!- mode/#netbsd-agm [+v spz] by leot

<spz> good localtime() all
<spz> ,
<spz> admins is the following people:
<spz> christos, dogcow, kim, mspo, phil, riastradh, riz, seb, soda, spz, tls
<spz> ,
<spz> Statistics:
<spz> - admins runs the following TNF systems:
<spz> @ TastyLime
<spz> + 8 hardware systems, 6 'regular' Xen guests and 3 repotest Xen guests
<spz> = 1 earmv7hf, the rest amd64
<spz> - public services, the repo(s), sundry
<spz> @ AOA
<spz> + 6 hardware systems
<spz> = all amd64
<spz> - the NetBSD build farm
<spz> @ Washington University
<spz> + 7 hardware systems
<spz> = 2 aarch64 and the rest amd64
<spz> - two pkg builders, the repo conversion and a CI system, sundry
<spz> @ Regensburg
<spz> + 2 hardware systems, one of them with 2 Xen guests
<spz> = all amd64 (+ a sparc64 serving consoles)
<spz> - the offsite backup, archive, wip.pkgsrc.org and a CI system
<spz> ,
<spz> - CDN services donated by Fastly
<spz> - Housing donated by TastyLime, Two Sigma, WWU, and spz
<spz> ,
<spz> NetBSD versions in use:
<spz> 6   10.0_STABLE (1 earmv7hf, 1 aarch, 4 amd64)
<spz> 6   10.1 (5 amd64)
<spz> 13  10.1_STABLE (13 amd64)
<spz> 1   11.0_RC3 (amd64)
<spz> 2   11.0_RC4 (aarch64, amd64)
<spz> ,
<spz> Changes:
<spz> Riastradh spent even more time on the mail system so we can still send
<spz> mail to Google mail accounts.
<spz> Also Riastradh has been developping the future reposerver setup.
<spz> ,
<spz> Notable issues:
<spz> - spam suppression by technical means, which makes life hard(er) for
<spz>   legitimate mailing lists and hasn't stopped spammers (or phishing) yet.
<spz> - LLM scraping. Anti-social "all your resources are belong to us",
<spz>   total disregard for robots.txt, and backed by lots of money
<spz>   so they can buy all the shady "residential proxies" they want,
<spz>   so IP blacklists aren't feasible. Their capacity to scrape
<spz>   vastly outnumbers our capacity to serve, they are very aggressive,
<spz>   so the chance of a human getting to use the wip.pkgsrc.org website
<spz>   is slim. And to add insult to injury they could just download the repo
<spz>   instead of diffing every possible version of every file against every
<spz>   other version via the web interface:
<spz>   the point is they don't want to use resources carefully, because that
<spz>   would require thought and LLMs are all about not expending that.
<spz>   (if you detect some foaming at the mouth here: yes. aarrrggghhh!)
<spz> ,
<spz>   We are very sorry but we'll have to add countermeasures like for
<spz>   archive.NetBSD.org, if possibly not the same, or shut the
<spz>   web interface down like we did with the cvsweb access to wikisrc.
<spz> ,
<spz>   The other NetBSD web sites survive thanks to having a limited
<spz>   number of links (the scrapers only visit each one twice a day),
<spz>   and CDN caching.
<spz> - hardware aging at TastyLime, both the TNF servers and the network
<spz>   equipment. The latter is being dealt with, there will be a downtime
<spz>   for sometime soon. The former suffers from requiring half a week time
<spz>   on-site and roughly two weeks from off-site to get anything working
<spz>   properly again, and the activation energy required to do that is a lot.
<spz> - the perennially full /pub/pkgsrc/packages on ftp.NetBSD.org.
<spz>   we have a plan, it "just" needs implementing.
<spz> ,
<spz> We often get asked:
<spz> - why don't you use a Cloud provider or rent servers instead:
<spz>         + did that with the offsite backup server, the provider ceased
<spz>         operations and just shut everything off: our data? sucks to be us.
<spz>         If we own the server it might get switched off, but we could get
<spz>         it (and thus our data) back
<spz>         + but you could have backups: having 50TB in total backed up and
<spz>         not paying an arm and a leg for retrieval and making certain the
<spz>         backup provider isn't going funny is either expensive or difficult
<spz>         + in the long run renting servers is not cheaper if they actually
<spz>         are busy all the time
<spz>         + we should always consider if this (whatever this) is a good use
<spz>         of TNF funds.
<spz> - we could sponsor you a server
<spz>         Thanks, kind of you to offer. However:
<spz>         If it's just one server we couldn't do OS updates. Having IPMI
<spz>         on the open Internet for console access is not a good security
<spz>         stance. Thus we are at a server and a console server, and having
<spz>         a console server and several servers just scales better.
<spz>         Plus we'd like to have at least one member of admins in viable
<spz>         site visit distance and an expectation of duration: site moves
<spz>         aren't much less work than hardware renewals.
<spz> ,
<spz> Thanks to riz, tls and phil for their resources, time
<spz> and blood sacrifices, too. :}
<spz> ,
<spz> Back to moderator.

-!- mode/#netbsd-agm [-v spz] by leot
<leot> Thank you very much spz!
<leot> Next in the agenda we have... Riastradh with the finance-exec@ presentation!
-!- mode/#netbsd-agm [+v Riastradh] by leot

<Riastradh> Hi, folks!
<Riastradh> Finance-exec hoards the cash, keeps the books, sends
<Riastradh> thank-you notes to donors, and pays out contracts and
<Riastradh> reimbursements.
<Riastradh> .
<Riastradh> We are:
<Riastradh> - christos (Christos Zoulas)
<Riastradh> - reed (Jeremy C Reed)
<Riastradh> - riastradh (Taylor R Campbell)
<Riastradh> .
<Riastradh> The NetBSD Foundation's public 2025 financial report is at:
<Riastradh> https://www.NetBSD.org/foundation/reports/financial/2025.html
<Riastradh> We produce this from an internal ledger maintained with
<Riastradh> ledger(1) <https://www.ledger-cli.org/>.
<Riastradh> .
<Riastradh> Highlights:
<Riastradh> - We have net assets of a little over 400k USD as of today
<Riastradh>   (we received a large donation in 2026).
<Riastradh> - In 2025, we received about 80k USD -- far surpassing our
<Riastradh>   usual donation target of 50k USD!
<Riastradh> - We spent 21k USD, mainly on:
<Riastradh>   o supporting conferences and sending developers to them
<Riastradh>   o release engineering
<Riastradh> .
<Riastradh> That was a lot more income and a lot less expenses than we
<Riastradh> usually have.  But forecasting:
<Riastradh> - We expect to purchase some more hardware replacements this
<Riastradh>   year, and components like RAM have gotten much more
<Riastradh>   expensive recently.
<Riastradh> - We have more funds for funded projects now, and while core
<Riastradh>   or pkgsrc-pmc directs the funds, they're really driven by
<Riastradh>   the developer proposals that are available -- so if you
<Riastradh>   want to work on a funded project, send a proposal!
<Riastradh> .
<Riastradh> Happy to answer any questions about what finance-exec does,
<Riastradh> or swap notes on using ledger(1)!
<Riastradh> Thanks,
<Riastradh> -Riastradh, on behalf of finance-exec

<leot> Thanks a lot Riastradh!
<leot> Next presentation is from <martin> with the membership-exec@ presentation!
-!- mode/#netbsd-agm [+v __martin] by leot

<__martin> thanks
<__martin> The current members of membership-exec are:
<__martin> - Christos Zoulas <christos>
<__martin> - Martin Husemann <martin>
<__martin> - Lex Wennmacher <wennmach>
<__martin> - Thomas Klausner <wiz>, and
<__martin> - Ken Hornstein <kenh> who is on sabbatical.
<__martin>  -
<__martin> Membership-exec is responsible for all aspects of
<__martin> "membership", but in practice the main task is to handle
<__martin> membership applications. The number of active developers
<__martin> (as of 2026-06-06) is 138. Note that this number is a
<__martin> bit outdated, as the membership activity validation process
<__martin> required for the board election has not yet happened.
<__martin>  -
<__martin> Since the last AGM on 2025-05-17 we gained only 5 new
<__martin> developers, which is (again) way too few. We need to invite
<__martin> more people, please help active users and encourage them to
<__martin> apply.
<__martin>  -
<__martin> The difference between developers and active developers
<__martin> is explained in the bylaws - an active developer has
<__martin> actually committed something in the last year, or contributed
<__martin> in an active way, like admins.
<__martin>  -
<__martin> We'd like to emphasize that we appreciate all your replies
<__martin> to our membership RFC e-mails, although we do not usually
<__martin> acknowledge them. Please keep on providing feedback to
<__martin> the RFC mails.
<__martin> thanks, back to moderator

<leot> Thank you Martin!
<leot> Next presentation... again from Martin but this time with the releng@ hat! :) Please go ahead __martin!

<__martin> hi again
<__martin> We are:
<__martin> abs agc bouyer he jdc martin msaitoh phil reed riz
<__martin> sborrill snj
<__martin>    -
<__martin> Since the last meeting, we have:
<__martin>  o Branched netbsd-11.
<__martin>  o Not released any formal release (only four release
<__martin>    candidates for 11.0).
<__martin>  o Processed hundreds of pullup requests.
<__martin>  o Streamlined the process of cutting a release.
<__martin>    -
<__martin> Currently we are about to release the fifth (and
<__martin> this time definitvely last) release candidate for 11.0.
<__martin> 11.0 has had bad luck with security updates of 3rd party
<__martin> components last minute and slow progress on making
<__martin> these components updatable on relelase branches
<__martin> (like libssh moving to /usr/lib/private/).
<__martin>    -
<__martin> We have only two issues open for 11.0:
<__martin>  (1) the missing unbound import (catch-up to current)
<__martin>  (2) a new expat release that has not made it into
<__martin>      -current, but fixes a few security issues
<__martin>    -
<__martin> Volunteers are welcome to help with both - please
<__martin> contact me directly if you have some time to help.
<__martin>    -
<__martin> I hope to cut RC5 later this weekend or early next week,
<__martin> and then the final release maybe 10 days later. If one
<__martin> of the above items does not make it in, so be it.
<__martin>    -
<__martin> We have streamlined the process of actually cutting a
<__martin> release (or release candidate) and admins made it possible
<__martin> to completely stay out of this process now. Only one releng
<__martin> member and one security-office member are needed now.
<__martin>    -
<__martin> A release still takes realistically slightly less than 24h
<__martin> wall clock time, the biggest time consumers are all fully
<__martin> automated: 4h build time, 6h network transfer to ftp, 1h
<__martin> generating hashes. Plus various minor manual things like
<__martin> editing the web page and posting the release annoucement.
<__martin>    -
<__martin> We are still processing a huge amount of pullups.
<__martin> This is only possible because developers take the time
<__martin> to test their changes on the branch and submit a
<__martin> pullup request. We have been pretty good with this,
<__martin> and pulled up lots of security and usability
<__martin> improvements, as well as bug fixes to the various
<__martin> active branches. This is good for our users, thank you
<__martin> to everyone who cared and made it possible.
<__martin>    -
<__martin> The following paragraph is (unfortunately) a verbatim
<__martin> copy from last year - and still valid.
<__martin>    -
<__martin> The biggest current issue is the over-aged netbsd-9 branch.
<__martin> We need to get the NetBSD 11 release out ASAP to be
<__martin> able to move NetBSD 9.x out of support.
<__martin>    -
<__martin> After the 11.0 release (and probably the repository switch)
<__martin> I plan to start a discussion about rules and processes,
<__martin> trying to make the time from branching to first release way
<__martin> smaller. A slow release cycle is not that bad overall (IMO)
<__martin> but a year long delay between branching and first release
<__martin> is clearly wrong.
<__martin>    -
<__martin> That is all from release engineering for this year, we are
<__martin> hoping to have a list of several formal releases in next
<__martin> years report and also be close to the final release of
<__martin> 12.0.

<leot> Thank you Martin!
<leot> Next in the agenda we have... Again Martin, but with the security-team@ hat! Feel free to go ahead __martin!

<__martin> This is a brief report for security-team.
<__martin>  -
<__martin> We are: agc billc cherry christos chs cyber hgutch joerg js
<__martin> kre martin maya mrg riastradh rin shm spz
<__martin>  -
<__martin> Since last AGM we have not published any security
<__martin> advisories. We have fixed (and pulled up) one issue that
<__martin> has an SA pending, but it has not been finalized.
<__martin>  -
<__martin> There have been numerous bug fixes applied to the tree, and
<__martin> pulled up to NetBSD-9, NetBSD-10 and NetBSD-11 release
<__martin> branches. We also have updated lots of 3rd party components
<__martin> in the tree when they had new releases fixing security
<__martin> issues. Right now only the expat library needs an update in
<__martin> -current.
<__martin>  -
<__martin> Most security work goes on "behind the scenes" and we
<__martin> usually concur with request of reporters for a specific
<__martin> publication date.
<__martin>  -
<__martin> Where needed we also involve NetBSD developers outside the
<__martin> team when special expertise is needed. While we try to
<__martin> assess all reported issues timely, we sometimes struggle
<__martin> with doing so. Currently we have (if I did not miscount)
<__martin> two open reports that need to be addressed.
<__martin>  -
<__martin> To improve our own process, becoming more reliable and more
<__martin> transparent we are currently applying to become a CNA (CVE
<__martin> number authority). This will allow us to assign and publish
<__martin> our own CVE records. The process forces us to have public
<__martin> statements of response times and processes for issues
<__martin> reported to us. We might need to introduce a ticket system
<__martin> to help with doing timely responses.
<__martin>  -
<__martin> NetBSD continues to be represented in a product security
<__martin> incident response working group with other operating system
<__martin> vendors, as well as a direct contact team with other BSD
<__martin> projects. This framework allows us to work better with
<__martin> vendors requiring an embargoed and/or coordinated release
<__martin> with other operating systems. We can begin working on
<__martin> issues that affect NetBSD much faster, instead of only
<__martin> being notified after an embargo is lifted. We are expanding
<__martin> the number of vendors as time goes on, as well as
<__martin> participating in FIRST.
<__martin>  -
<__martin> This is teaching us quite a bit of where we need to
<__martin> improve our process, which is currently on-going.
<__martin>  -
<__martin> Thanks to everyone helping with security issues!

-!- mode/#netbsd-agm [-v __martin] by leot
<leot> Thank you very much Martin!
<leot> Next in the agenda we have... pkgsrc-pmc presentation, written by <wiz>!
<leot> Unfortunately <wiz> could not attend the AGM so I will present it

<leot> The pkgsrc team kept thousands of packages in pkgsrc up to date and in
<leot> good working order, and delivered four -- the 87th through 90th --
<leot> stable branches. Great work, and thank you to bsiegert@ and maya@ for
<leot> handling the branches!
<leot> .
<leot> The pkgsrc team has welcomed one new developer, kikadf, who takes good
<leot> care of chromium and wayland.
<leot> .
<leot> The current roster is:
<leot> - agc (emeritus member)
<leot> - dholland (board representative)
<leot> - schmonz
<leot> - wiz
<leot> .
<leot> Thank you for working on pkgsrc!!
<leot> -- wiz, for pkgsrc-pmc
<leot> Thanks!

<leot> Next in the agenda... we have pkgsrc-security@ presentation, prepared by <tm>!
<leot> He's only online via a mobile, so I will present it!

<leot> The mission of the pkgsrc Security Team is to ensure that the ever-growing
<leot> ecosystem of third party software is either safe to use or at least be sure
<leot> people are aware of the known vulnerabilities.
<leot>         -
<leot> Our members monitor publicly available vulnerability feeds, mainly CVE.
<leot>         -
<leot> We aggregate received advisories believed to impact pkgsrc into the pkgsrc
<leot> vulnerability list. When time allows we try to notify individual package
<leot> MAINTAINERs and locate, commit patches to fix the vulnerabilities.
<leot>         -
<leot> Since 2021 our ticket handling crew is currently only 2 people, unfortunately
<leot> pretty understaffed. We are looking and welcome people volunteering to join
<leot> us!
<leot>         -
<leot> Currently handling tickets are:
<leot>  - Leonardo Taccari <leot>
<leot>  - Thomas Merkel <tm>
<leot>         -
<leot> The other current members of the team are:
<leot>  - Thomas Klausner <wiz>
<leot>  - Tobias Nygren <tnn>
<leot>  - Tim Zingelman <tez>
<leot>         -
<leot> The year in numbers:
<leot> In 2024, the vulnerability list had 9482 lines added to it (8967 more than last
<leot> year) for a total of 30231 known vulnerabilities.
<leot> In 2025, the ticket queue received 50050 new advisories (9330 more than last
<leot> year). Of these 50050 new advisories:
<leot>  new:        302 ( 0.6%) (not able to handle in 2025)
<leot>  stalled:      0 ( 0.0%)
<leot>  resolved:  1697 ( 3.4%) (affecting pkgsrc packages)
<leot>  rejected: 48051 (96.0%) (no impact or duplicates)
<leot>         -
<leot> Zafer Aydogan <zafer> also joined pkgsrc-security rotation list for several
<leot> months in 2025 and helped us. Thanks Zafer!
<leot>         -
<leot> The current count of vulnerable packages in pkgsrc-current is 787 (138 more
<leot> than last year), in pkgsrc-stable is 809 (144 more than last year).
<leot> See the periodic email to packages@NetBSD.org for the list.
<leot> But we've 3548 vulnerabilities to review!
<leot> We can always use help locating and committing security patches, in particular
<leot> for the many of these that are maintained by pkgsrc-users.
<leot>         -
<leot> We encourage all developers to help us keep the vulnerability list up-to-date.
<leot> If you become aware of a security issue or perform a security update in pkgsrc
<leot> please edit the list. You don't need any special privilege for this.
<leot> You'll find the list in pkgsrc CVS repository:
<leot>  pkgsrc/doc/pkg-vulnerabilities
<leot>         -
<leot> Please join the pkgsrc Security ticket handling crew, we're pretty understaffed
<leot> at the moment! Feel free to get in touch with us for additional details or an
<leot> introduction.
<leot>         -
<leot> EOF

<leot> Thank you very much <tm>!
<leot> We have another presentation that was not in the agenda!
<leot> There is a gnats@ presentation by <dholland>!
-!- mode/#netbsd-agm [+v nbdholland] by leot
<leot> Feel free to go ahead David!

<nbdholland> (This got held up by a schmozzle yesterday. Thanks to riastradh@ for running my dodgy scripts for me.)
<nbdholland>  
<nbdholland> Here's the bug database report since the last AGM (12 months):
<nbdholland>  
<nbdholland> GNATS statistics for 2025 (as of June  6 2026)
<nbdholland>  
<nbdholland> New PRs this year: 880, of which 578 are still open.
<nbdholland> Closed PRs this year: 445. Net change: +435. 
<nbdholland> Total PRs touched this year: 946.
<nbdholland> Oldest PR touched this year: 5514.
<nbdholland> Oldest open PR: 1677; PR ignored for the longest: 4691.
<nbdholland>  
<nbdholland> Total number open: 7313
<nbdholland>  
<nbdholland> (Recall that this isn't github: in NetBSD "PR" means "problem report",
<nbdholland> not "pull request".)
<nbdholland>  
<nbdholland> This is the weekly plot:
<nbdholland>  
<nbdholland>                                                        * 6900
<nbdholland>                                                   ******
<nbdholland>                                               **********
<nbdholland>                                             ************
<nbdholland>                                       ******************
<nbdholland>                                   **********************
<nbdholland>                 ******** *******************************
<nbdholland>              *******************************************
<nbdholland>       **************************************************
<nbdholland>    ***************************************************** 6360
<nbdholland>  
<nbdholland> If anyone was wondering, the oldest open PR (PR 1677) is about a
<nbdholland> panic in unionfs. This is unfortunately still current. The most
<nbdholland> untouched PR (PR 4691) is about ECC memory handling on sun3.
<nbdholland>  
<nbdholland> Unfortunately, we seem to have reverted to our old pattern of an ever-increasing backlog.
<nbdholland>  
<nbdholland> Anyhow, here are the people who've been fixing the most bugs, as
<nbdholland> counted by commit messages found in PRs closed during the year.
<nbdholland>  
<nbdholland>   10  skrll@netbsd.org
<nbdholland>   14  martin@netbsd.org
<nbdholland>   15  bsiegert@netbsd.org
<nbdholland>   18  gutteridge@netbsd.org
<nbdholland>   23  jkoshy@netbsd.org
<nbdholland>   27  kre@netbsd.org
<nbdholland>   29  dmcmahill@netbsd.org
<nbdholland>   50  nia@netbsd.org
<nbdholland>   53  wiz@netbsd.org
<nbdholland>  105  riastradh@netbsd.org
<nbdholland>  
<nbdholland> This list always has a very long tail, and the difference between
<nbdholland> being on it and not is only one commit. This year there were 55 people
<nbdholland> who fixed or helped fix at least one bug report, down a bit from last
<nbdholland> year. Thanks to one and all.
<nbdholland>  
<nbdholland> And here are those who've been processing pullups for bugs, according
<nbdholland> to the same analysis:
<nbdholland>  
<nbdholland>    1  snj@netbsd.org (releng)
<nbdholland>    2  bsiegert@netbsd.org (releng)
<nbdholland>    2  jdc@netbsd.org (releng)
<nbdholland>    4  bouyer@netbsd.org (releng)
<nbdholland>   16  maya@netbsd.org (releng)
<nbdholland>  127  martin@netbsd.org (releng)
<nbdholland>  
<nbdholland> Note that this reflects pullups specifically linked into gnats, not
<nbdholland> all releng work. Nonetheless, it remains heavily skewed. Many, many,
<nbdholland> many thanks, Martin.
<nbdholland>  
<nbdholland> <eot>
<leot> Thank you very much nbdholland!
-!- mode/#netbsd-agm [-v nbdholland] by leot

<leot> Now we can start the Q&A session.
<leot> I have at least 2 questions already in the queue
<leot> If you have more questions, feel free to /msg me with possible <team> / <nick> that may answer the question and I will voice you when it's your turn
-!- mode/#netbsd-agm [+v racoon] by leot
<leot> racoon has some questions for admins@! racoon, feel free to go ahead!
<leot> (admins@ feel free to /msg me if you can answer their questions!)

<racoon> hello netbsd, hello admins
<racoon> my first question is whether it's possible to whitelist netbsd ftp(1) so that it doesn't need to pass a challenge to download files from archive.netbsd.org. my own experience of AI scrapers would say that's an unusual user agent to scrape, but i don't know how heinous they are. i'd like to do e.g. automated fetches of old distfiles
<racoon> *unusual user agent to fake
<Riastradh> racoon: the captcha in there is a temporary workaround, we might deploy anubis or something in the near future
<spz> if ftp has a recognisable user agent that might actually a great idea
<racoon> my second question is whether it's possible that more hardware might be moved to e.g. germany, japan in the future, so that we're less centralized in the US
<Riastradh> racoon: Some of the hardware is in Germany already!
<spz> it's easier for TNF to buy stuff in the US, typically cheaper too. We'll have to think about it.
<Riastradh> (we are already running anubis on https://hgweb.test.netbsd.org and https://gitweb.test.netbsd.org/, just haven't deployed it or anything comparable on other services yet)
<racoon> thank you
<Riastradh> racoon: We would need a rack to do it, with enough machines to make it worthwhile to maintain there.  If you have a rack to offer, we could arrange that!
<leot> Thanks racoon, spz and Riastradh!

-!- mode/#netbsd-agm [-v racoon] by leot
-!- mode/#netbsd-agm [+v cagney_] by leot
<leot> We have a question from cagney_, probably for admins@ / gnats@!
<leot> cagney_, feel free to go ahead with your question(s)!

<cagney_> leot, tks, yes; and hello all
-!- mode/#netbsd-agm [+v nbdholland] by leot
<cagney_> I'm just wondering if, once NetBSD makes it off CVS, if the next big plan is the bug database? Any plans for that?
<Riastradh> heh
<Riastradh> We have had so many grandiose plans for bug database migration I lost count!
<spz> yes, but it's got goats feet and then some
<spz> since we do not want to lose old info
<nbdholland> This has a long and unfortunate history
<Riastradh> So, yes, it would be nice to migrate off gnats but we don't have a plan.
<spz> otherwise: gnats should die. die die die die already. :-P
<nbdholland> and what spz said.
<Riastradh> But maybe we can start planning after we're done with CVS.
<nbdholland> We've already done a lot of planning. The problem has always been getting any real work done on it
<Riastradh> (Actually we won't quite be _done_ with CVS because there'll still be a read-only CVS front end!)
<cagney_> My only experience is that while it matters to preserve old bugs, it matters less to migrate them to a new system.
<cagney_> anyway, looking forward to movement

<leot> Thanks cagney_, spz, Riastradh and nbdholland!
-!- mode/#netbsd-agm [-v cagney_] by leot
<leot> We have another question, from ktnb... probably for security-team@ / core@ I think!
-!- mode/#netbsd-agm [+v ktnb] by leot

<ktnb> Hello!
<ktnb> it seems like there are endless numbers of bugs and security bugs being around daily nowadays. I'm not sure if these bugs are found mostly by AI or not but is there any consideration on how or if we should do audits to find holes in NetBSD? in other words, how do we plan to 'keep up with the times' in this security bug world?
-!- mode/#netbsd-agm [+v __martin] by leot
<leot> If anyone would like to answer and has not been voiced, feel free to /msg me!
<__martin> I'll try to answer that
<__martin> we currently receive real bug reports at still moderate rates
-!- mode/#netbsd-agm [+v krelz] by leot
<__martin> we see a few "spamish" things that first ask for bug bounty programs and then never come back with real issues
-!- mode/#netbsd-agm [+v nbdholland] by leot
<__martin> so right now I'd say it is still handable w/o additional measures
<nbdholland> In the long run we would also like to use formal verification tools to get ahead of the game
<krelz> I didn't mention it in the core report, as I'm not a finance person and didn't
<krelz> want to commit TNF to spend money, but core can receive proposals for projects
<krelz> which can be funded if they seem worthwhile (at moderate rates)
<krelz> If there are any proposals for how we could do active audits of the code,
<krelz> rather than just waiting for someone else to find bugs and tell us about them,
<krelz> that seems like something which might be worthy of some expenditure
<krelz> .
<ktnb> That was kind of my concern: are we not getting a lot of bugs because of lack of usage or are we just _that_ good
<krelz> It is probably some of both of those, much of our codebase is old, and fairly
<krelz> stable, there aren't a lot of bugs (even less security issues) to find probably,
<Riastradh> Perhaps but we shouldn't get cocky...
<krelz> and most of what does exist, is relatively harmless (unlikely, and not catastrophic)
<krelz> But also, our user base isn't all that huge, compared to other systems, so
<krelz> stray bugs can take longer to be encountered.
<krelz> But that's also (in some respects) a good thing, as finding bugs in NetBSD
<krelz> isn't so profitable for hackers, that they are less likely to bother
<krelz> .
-!- mode/#netbsd-agm [+v khorben] by leot
<khorben> I'd like to add and emphasize on a few things: in NetBSD we rely on third-party components
<khorben> some of these components have a security impact and subject to scrutiny (and CVEs)
<khorben> so regardless of our relevance, we are targets too and should fund efforts ourselves
<khorben> as mentioned earlier in board's summary, we are looking for volunteers to help us do that
<khorben> thanks!
<khorben> .
<krelz> Agreed.   Send proposals to core@
<ktnb> Thank folks!

<leot> Thanks ktnb, __martin, nbdholland, krelz, Riastradh and khorben!
-!- mode/#netbsd-agm [-v ktnb] by leot
-!- mode/#netbsd-agm [-v __martin] by leot
-!- mode/#netbsd-agm [-v nbdholland] by leot
-!- mode/#netbsd-agm [-v krelz] by leot
-!- mode/#netbsd-agm [-v khorben] by leot
-!- mode/#netbsd-agm [-v Riastradh] by leot
<leot> We have another question! From Ltning... probably for some pkgsrc folks! (maybe I can answer it, but if you can answer it, feel free to request voice via /msg me)
-!- mode/#netbsd-agm [+v Ltning] by leot

<Ltning> Hey all, I am a first-ish time pkgsrc patch submitted, specifically 60114
<Ltning> It's a simple patch, of which I'd like to contribute more from time to time, but it seems "stuck"
-!- mode/#netbsd-agm [+v racoon] by leot
<Ltning> I guess my questions are 1) What can I do differently to get it unstuck, and 2) is there documentation on not just how to submit patches but how to "chase" them?
<racoon> Ltning: since mail is a non-live medium, and irc is, my main suggestion would be to poke us on irc
<Ltning> (I realise the pkgsrc team, like all others, are understaffed and overworked, so this is not meant to be criticism :)
<racoon> it's also always helpful to say which platforms you've tested on
<racoon> just because it shows confidence in the patch
<Riastradh> Ltning: One thing that would be helpful is to make sure the `make test' target works, in addition to saying what platforms you've tested it on.
<Ltning> Yeah - I have tried a couple times, but I guess not insistently enough. So perhaps the documentation could mention how-to-poke and also these things.
-!- mode/#netbsd-agm [+v nbdholland] by leot
<nbdholland> Another thing is, as per the discussion above, we all dislike gnats, and one of the reasons is that it's very difficult to find things in it
<Ltning> Roger that - thanks. Will follow up with that.
-!- mode/#netbsd-agm [+v krelz] by leot
<nbdholland> So if you file a patch in a gnats PR, and it doesn't get attention quickly, chances are you need to poke someone about it
<krelz> Also remember that everything in netbsd (incl pkgsrc)
<krelz> is done by volunteers - the best way to get someone to look
<Riastradh> .oO(pokage source)
<krelz> at a patch, is to find a developer with similar interests
<krelz> and convince them to take a look - any developer will do,
<Ltning> Yea. I guess the last comment from me then is - this is useful information, and I wish I didn't have to waste your time in this "call" to get it. 
<krelz> the "pkgsrc team" (I believe) are generally more interested in
<Ltning> Don't forget the impostor syndrome - I may be brave enough to poke randomly on IRC, but not everyone will be ..
<krelz> the workings of pkgsrc itself, rather than individual packages
<krelz> Finally, for an upgrade, which your PR is, it really helps to include
<krelz> info on what has changed, why someone would want the upgrade
<krelz> .
<nbdholland> Stuff like this about prodding people about patches being forgotten does appear on the lists at times
<nbdholland> and it's ok to ask procedural questions there

<leot> Thanks Ltning, racoon, nbdholland Riastradh and krelz!
<leot> We have another question, probably for finance-exec@
-!- mode/#netbsd-agm [-v Ltning] by leot

-!- mode/#netbsd-agm [+v Uilebheist] by leot
<Uilebheist> Hi all, Hi NetBSD
<Uilebheist> You mentioned that you are a US IRS 501(c)3 charitable organization - which is great for US people wanting to make a donation, but do you have or plan anything for people elsewhere?
<Riastradh> We have discussed forming a potential nonprofit organization in Europe.
-!- mode/#netbsd-agm [+v khorben] by leot
<Riastradh> The main question is: How much administrative overhead does this bring on us (recall we're pretty much all volunteers, plus some part-time contracts with TNF)?
<Riastradh> And, is that administrative burden worth the additional fundraising it would bring in?
<spz> specifically, there are EU-wide nonprofits, but that's a lot of red tape
<khorben> I can add to that, we have tried to revive an existing NetBSD structure in Germany to help with this
<khorben> unfortunately it hasn't brought fruition as of now
<Riastradh> And the administrative burden is likely to be more than just the sum of the administrative burden of two organizations separately, because they would have to be notionally independent, and we would have to have to come up with a reasonable governance structure for managing the assets.
<khorben> and indeed there are already broader OSS structures in Europe and elsewhere
<khorben> (and what Riastradh says)
<Uilebheist> Thank you.  I guess for now we might just make a slighly smaller donation and not get tax back!
<Riastradh> For example, you may be familiar with the FSF (Free Software Foundation) and FSFE (Free Software Foundation Europe) -- although they are mostly aligned in goals, they are independent organizations with independent governance structure, and sometimes disagree.
<Uilebheist> Ah yes, noticed these.

<leot> Thanks Uilebheist, spz, Riastradh, nbdholland and khorben!
-!- mode/#netbsd-agm [-v Uilebheist] by leot
<leot> I think the questions queue via my /query is currently empty!
<leot> Any other questions?
<leot> (And/or if I've missed any questions, please /msg them again!)
<Cryo> Alright, thanks everyone for coming.
<leot> Cryo: wait!
<leot> We have another question! :)
-!- mode/#netbsd-agm [+v wiedi] by leot

<wiedi> Hi, is there a status update on the repo migration? (Thanks to everyone working on it!)
<Riastradh> We have infrastructure in place, just requiring tying up some loose ends for deployment, and we need to prepare a clean final conversion.
<krelz> Also, there is the test infrastructure, that not enough developers have been using
<Riastradh> The infrastructure has taken a while because we're doing it a little differently from before, so we can reproducibly generate fresh images to test and deploy, rather than manually tinkering with a long-term server installation, and it took some engineering to get the software in shape for that.
<wiedi> Thank you, looking forward to using it :)
<wiedi> does the test infra also have a pkgsrc repo? I forgot... will have a look
<Riastradh> yes, it does
<wiedi> amazing, thanks for your work and answers :)
<leot> Thanks wiedi, Riastradh and krelz!
-!- mode/#netbsd-agm [-v wiedi] by leot
<leot> Any other questions? :)
<Riastradh> There are currently two test deployments, not all aligned on repository data (will change that soon), which you can test as a developer and anonymously.
<Riastradh> Developer access is at hg.test.n.o or git.test.n.o over ssh, and anonymous access is at anonhg.test.n.o or anongit.test.n.o (or https://hgweb.test.netbsd.org/ or https://gitweb.test.netbsd.org).
<krelz> Please, developers, use that, so you can be familiar with
<Riastradh> and there's a test repsitory called testsrc which is small to mess around with
<krelz> how things will work.  Less issues after the real change happens.
<Riastradh> Notes on usage: https://www.netbsd.org/developers/mercurial/ https://www.netbsd.org/developers/git/
<krelz> Nothing can be :bad: in the tests, you can play safely

<Cryo> Alright, again, thanks for coming. We are excited about the roadmap ahead and look forward to achieving these milestones together. Thank you for your time and your dedication to NetBSD.
<Cryo> See you next year!
<leot> Thank you!
<Riastradh> There's also still read-only CVS access via anoncvs.test.n.o (testsrc only for now, will be everything once deployed) for access on small machines where git and hg have trouble running.
<khorben> thanks @all!
 * Cryo turns up the lights
-!- mode/#netbsd-agm [-m] by leot
<Cryo> o/ have a great rest of your day
<leot> You too! Thanks everyone for attending!
-!- spz changed the topic of #netbsd-agm to: The NetBSD Foundation Annual General Meeting - Next Meeting in 2027
<racoon> thanks everyone, especially Riastradh for working on the repo conversion
<d-ra> thanks @all
<Cryo> Thanks to leot and everyone behind the scenes
<Cryo> Thanks to all of the presenters and people who worked on the presentation

NetBSD 11.0 RC4 available!

martin — Wed, 13 May 2026 06:07:49 +0000

The NetBSD project is pleased to announce the fourth (and this time hopefully final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

Unfortunately the first release candidate had a few defects that we had to fix, including speed enhancements for the ftp(1) client when downloading large files, an updated tmux(1), reliability fixes for blocklistd(8) and fixes for the Mesa library. See the changes document for details.

A lot of recent security updates in third party software bundled in NetBSD happened after the previous release candidate. This includes OpenSSH, OpenSSL, Postfix, bind, xz and more.

If you want to test 11.0 RC4 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Welcome to Google Summer of Code 2026 contributors!

Leonardo Taccari — Thu, 30 Apr 2026 18:07:17 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2026 with 5 projects!

Here the list of the projects and contributors:

From May 1 to May 24 it starts the community bonding period. Contributors will familiarize with the codebase, get in touch with their mentors and the community and work with the mentors to set the deliverables for the project.

Welcome Artem, Dimitris, Emmanuel, Henrique and Vishal!

NetBSD 11.0 RC3 available!

martin — Mon, 6 Apr 2026 14:13:39 +0000

The NetBSD project is pleased to announce the third (and probably final) release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

If you want to test 11.0 RC3 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 11.0 RC2 available!

martin — Fri, 6 Mar 2026 20:58:23 +0000

The NetBSD project is pleased to announce the second release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

If you want to test 11.0 RC2 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

The NetBSD Foundation will participate in Google Summer of Code 2026!

Leonardo Taccari — Mon, 23 Feb 2026 11:32:46 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2026!

Would you like to learn how to contribute to open source? Google Summer of Code is a great chance to contribute to NetBSD and/or pkgsrc!

You can find a list of possible projects at Google Summer of Code project page. Please do not limit yourself to the project list... If have any cool idea/project about NetBSD and/or pkgsrc please also propose your one!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code, please also check the homepage at g.co/gsoc.

Looking forward to a great Summer!

NetBSD 11.0 RC1 available!

martin — Sun, 8 Feb 2026 17:30:05 +0000

The NetBSD project is pleased to announce the first release candidate of the upcoming 11.0 release, please help testing!
See the release announcement for details.

The netbsd-11 release branch is nearly a year old now, so it is high time the 11.0 release makes it to the front stage.

If you want to test 11.0 RC1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-11 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Google Summer of Code 2025 Reports: Using bubblewrap to add sandboxing to NetBSD

Leonardo Taccari — Sat, 8 Nov 2025 15:00:19 +0000

This report was written by Vasyl Lanko as part of Google Summer of Code 2025.

Introduction

As of the time of writing, there is no real sandboxing technique available to NetBSD. There is chroot, which can be considered a weak sandbox because it modifies the root directory of the process, effectively restricting the process' view of the file system, but it doesn't isolate anything else, so all networking, IPC, and mounts inside this restricted file system are the same as of the system, and are accessible.

There has already been some research on implementing kernel-level isolation in NetBSD with tools like gaols, mult and netbsd-sandbox, but they haven't been merged to NetBSD. Other operating systems have their own ways to isolate programs, FreeBSD has jails, and Linux has namespaces.

Project Goals

The goal of this project is to bring a new way of sandboxing to NetBSD. More specifically, we want to implement a mechanism like Linux namespaces. These namespaces allow the isolation of parts of the system from a namespace, or, as the user sees it, from an application.

NetBSD has compat_linux to run Linux binaries on NetBSD systems, and the implementation of namespaces can also be utilized to emulate namespace-related functionality of Linux binaries.

A simple example to visualize our intended result is to consider an application running under an isolated UTS namespace that modifies the hostname. From the system's view, the hostname remains the same old hostname, but from the application's view it sees the modified hostname.

Project Implementation

Linux has 8 namespace types, in this project we will focus on only 2 of them:

UTS namespace, it is the simplest so we can focus on building the general namespace infrastructure with little namespace-specific details
mount namespace, it is a prerequisite to most other namespace types because UNIX follows the philosophy of "everything is a file", so we need a separate mount namespace to have different configuration files on the same location as the system.

Linux creates namespaces via the unshare or clone system calls, and it will also be our way of calling the namespace creation logic.

We setup the base for implementing Linux namespaces in the NetBSD kernel using kauth, the subsystem managing all authorization requests inside the kernel. It associates credentials with objects, and because the namespace lifecycle management is related to the credential lifecycle it handles all the credential inheritance and reference counting for us. (Thanks kauth devs!)

We separate the implementation of each namespace in a different secmodel, resulting in a similar framework to Linux which allows the isolation of a single namespace type. Our implementation also allows users to pick whether they want to have namespace support, and of what kind, via compilation flags, just like in Linux.

UTS namespace

UTS stands for UNIX Timesharing System, because it allows multiple users to share a single computer system. Isolating the utsname can be useful to give users the illusion that they have control over the system's hostname, and also, for example, to give different hostnames to virtual servers.

The UTS namespace stores the namespace's hostname, domain name, and their lengths. To isolate the utsname we need to first create a copy of the current UTS information, plus we need a variable containing the number of credentials referencing this namespace, or, in simpler terms, the reference count of this namespace.

This namespace specific information needs to be saved somewhere, and for that we use the credential's private_data field, so we can use a UTS_key to save and retrieve UTS related information from the secmodel. The key specifies the type of information we want to retrieve from the private_data, hence using a UTS_key for the UTS namespace. The key for each namespace is a fixed value (we don't create a new key for every credential), but the retrieved value for that key from different credentials may be different.

We had to modify kernel code that was directly accessing the hostname and domainname variables, to instead call get_uts(), which retrieves the UTS struct for the namespace of the calling process. We didn't modify occurrences in kernel drivers because drivers are not part of any namespace, so they should still access the system's resources directly.

MNT namespace

The MNT namespace isolates mounts across namespaces. It is used to have different versions of mounted filesystems across namespaces, meaning a user inside a mount namespace can mount and unmount whatever they want without affecting or even breaking the system.

The mount namespace structure in Linux is fairly complicated. To have something similar in NetBSD we need to be able to control the mounts accessed by each namespace, and for that we need to control what is each namespace's mountlist, this is also enough for unmounting file systems, because in practice we can just hide them.

For the mount_namespace, mountlist structure and the number of credentials using the mount namespace are stored in the credential's private data with the MNT_key. Similarly to the UTS namespace, we had to modify kernel code to not directly access the mountlist, but instead go through a wrapper called get_mountlist() which returns the correct mountlist for the namespace the calling process resides in.

Implementation for the mount namespace is immensely more complex than for the UTS namespace, it involves having a good understanding of both Linux and NetBSD behaviour, and I would frequently find myself wondering how to implement something after reading the Linux man pages, which would lead to me looking for it in the Linux source code, understanding it, then going back to NetBSD source code, trying to implement it, and seeing it's too different to implement in the same way.

Project Status

You can find all code written during this project in GitHub at maksymlanko/netbsd-src gsoc-bubblewrap branch. Because I intend to continue this work outside of GSoC, I want to reinforce that this was the last commit still during GSoC on gsoc-bubblewrap branch and this was the last one for the mnt_ns still WIP branch.

The link includes implementation of general namespace code via secmodels, implementation of the UTS namespace and related ATF-tests, and the work-in-progress implementation of mount namespaces.

The mount namespace functionality is not finished as it would require much more work than the time available for this project. To complete it, it would be required invasive and non-trivial changes to the original source code, and, of course, more time.

Future Work

As previously mentioned, Linux has 8 namespace types, it is important to see which of the missing namespaces are considered useful and feasible to implement.

I believe that after mount namespaces it would be interesting to implement PID namespaces as this in combination with mount namespaces would permit process isolation from this sandbox. Afterwards, implementing user namespaces would allow users to get capabilities similar to root in the namespace, giving them sudo permissions while still restricting system-wide actions like shutting down the machine.

A lower hanging fruit is to implement the namespace management functionality, which in Linux is lsns to list existing namespaces, and setns to move the current process to an already existing namespace.

Challenges

Semantics. Did you know the unmount system call with MNT_FORCE flag in Linux (usually) returns EBUSY, and in NetBSD it forces the unmounting? One of them makes it easier to implement mount namespaces.
The behaviour of namespaces is not fully specified in the man pages. If something is not clear from the man pages you need to read the source code.
Unexpected need to learn a lot of VFS concepts and their differences in NetBSD and Linux.
There was a much bigger research component than I anticipated.

In the end, Linux and NetBSD are different operating systems, implemented in different ways. Linux is complex and it is not trivial to port namespaces to NetBSD.

Notes

The project is called "Using bubblewrap to add sandboxing to NetBSD" and was initially projected to emulate the unshare system call into compat_linux, but, seeing that having namespaces could be useful for NetBSD, and that it would be easy to add to compat_linux afterwards, we decided to instead implement namespaces directly in the NetBSD kernel. Implementing other system calls necessary to make the bwrap linux binary work correctly also wouldn't be as satisfying as implementing namespaces directly into NetBSD, so this was why the project was initially called "Using bubblewrap to add sandboxing to NetBSD" but nowadays it would be more accurate to call it "Sandboxing in NetBSD with Linux-like namespaces".

Thanks

I am very grateful to Google for Google Summer of Code, because without it I wouldn't have learned so much this summer, wouldn't have met with smart and interesting people, and for sure wouldn't have tried to contribute to a project like NetBSD, even if I always wanted to write operating systems code... But, the biggest thing I will take with me from this project is the confidence to be able to contribute to NetBSD and other open source projects.

I would also like to thank the members of the NetBSD organization for helping me throughout this project, and more specifically:

Taylor R. Campbell, Harold Gutch and Nia Alarie from IRC, for helping me fix a nasty LD_LIBRARY_PATH bug I had on my system which wouldn't let me finish compiling NetBSD, and general GSoC recomendations.
Emmanuel Dreyfus from tech-kern, with whom I discussed ideas for projects and proposal suggestions, and in the end inspired the namespaces project.
Christoph Badura and Leonardo Taccari who volunteered to be my mentors. They took time to research and answer my questions, anticipated possible problems in my approaches, and always pointed me in the right direction, daily, during all of GSoC's period. This project is from the 3 of us.

Google Summer of Code 2025 Mentor Summit in Munich, Germany: travel notes

Leonardo Taccari — Fri, 31 Oct 2025 11:41:23 +0000

I just came back home from Google Summer of Code 2025 Mentor Summit. We were 185 mentors from 133 organizations and it was amazing!

Google Summer of Code (GSoC) is a program organized by Google with the focus to bring new developers to open source projects.

The NetBSD Foundation has been participating in GSoC since 2005.

After nearly a decade being part of GSoC for The NetBSD Foundation, first as student and then as mentor and org admin, I finally attended my first GSoC Mentor Summit! That was a fantastic, very intense and fun experience! I met with a lot of new folks and learned about a lot of other cool open source projects.

Let's share my travel notes!

Wednesday 22, October 2025: arriving in Munich

Going to Munich is relatively doable by train from my hometown. I departed from Urbisaglia-Sforzacosta at 6:59 in the morning. I had around 25 minutes to wait for the change from Ancona to Bologna. I arrived in Bologna at around 11:30 where I met Andrea, my friend and favorite music pusher since childhood. We had lunch together, eating tasty miso veggie ramen, drank some hot sake and then we had coffee. He then accompanied me back to the station where I had the train to Munich Central Station at 13:50.

The scenery from the train was really nice. Near Trento and Bolzano/Bozen, full of vineyards and apple orchards with mountains in the background. It was cloudy for most of the travel but starting from Bressanone/Brixen I began to see «beautiful blue skies and golden sunshine». After Bressanone the scenery was more uncontaminated with light green grazing lands. Unfortunately when reaching Brennero/Brenner (last Italian city before Austria) it started to get dark and I had not enjoyed the rest of the scenery in Austria and Germany. I arrived in Munich at 20:50 and checked in at my hotel which was around 1km from the station.

For this journey I was not alone! Also Christoph Badura (<bad@>) was a delegate for Google Summer of Code and we had been in touch to get dinner and beers together. Christoph had some train delays but at 21:40 we were able to meet and went for a walk a bit to the south-east to find some places to eat and drink. I had done my homework for the beer places (obviously!) but the place in my TODO list to visit on Wednesday did not have a lot of food so we decided to first go to a restaurant and we found Ha Veggie - Vietnamese Cuisine. I had some Edamame and Bò xào sả ớt, a delicious dish with seitan, vegetables, lemongrass and chili pepper.

We then stopped at Frisches Bier, a bit too late, but the publican was kind enough and she permitted us a last round. I had a pint of a refreshing Hoppebräu Wuide Hehna Session IPA.

We then took a walk back to our hotels, talked a bit and went to sleep.

Thursday 23, October 2025: 1st day of Mentor Summit

Thursday was the first day of the Mentor Summit. The summit was in Munich Marriott Hotel, more in the north of the city, around 5km from the central station.

I checked out of my hotel and walked to the city center in Marienplatz and nearby. I also stopped in a couple of shops to grab some souvenirs for my family and friends and then took a long walk in the direction of Munich Marriott Hotel, to hopefully be there at 13:00 sharp for the start of check-in of GSoC Mentor Summit.

Rear of the Siegestor showing its inscription that can be translated to "Dedicated to victory, destroyed by war, urging peace"

I walked through Ludwigstraße and enjoyed the architecture around me, walking near LMU University and Siegestor. I then proceeded through Leopoldstraße and Ungererstraße and then arrived to the Munich Marriott Hotel.

Chris was already in the lobby and he had already checked in. We talked a bit and then I checked in as well. The room was huge and comfy! I quickly went back down to the lobby. We then checked in for Mentor Summit and I finally met Stephanie, Mary and Lucy, the GSoC Program Admins. I also took with me from home some classical and specialty Italian chocolate (Cioccolato di Modica) for the chocolate room (more about that later!) and left the bars in the chocolate room.

The time from 13:00-17:00 was reserved to actually permit mentors to arrive. At 13:00 there were still not a lot of mentors around so with Chris we decided to have lunch. We had lunch in a trattoria where we had an antipasto of grilled vegetables, penne all'arrabbiata with red wine from Montepulciano.

While eating Chris talked about the Tantris but we were already full. We had not tasted the haute cuisine but walked there to just look at the restaurant building. O:)

Tables full of chocolate and sweets from the chocolate room

When we came back to Munich Marriott Hotel, I went to the chocolate room to taste some chocolate/sweets. In GSoC Mentor Summit it is a tradition to bring great quality chocolate - or other sweets for places where chocolate is less usual - so folks can taste sweets from all over the world. That's a very nice initiative! I was curious more about non-chocolate sweets completely new to me so I had some Laddu and Kaju katli, both delicious!

I spent the rest of the afternoon down at the Champions Bar socializing with other mentors.

We had dinner at around 19:00 with good food accompanied by a couple of glasses of Primitivo.

At 20:15 we had the Opening Session. Stephanie, Mary and Robert warmly welcomed us. They shared the schedule and introduced to the unconference format of the sessions. We then had dessert and played the GSoC 2025 Mentor Summit Scavenger Hunt. The Scavenger Hunt is a game where you can meet and find 25 different folks with something that could be common (e.g. «prefers spaces (not tabs)») to something pretty rare (e.g. «has jumped out of a helicopter»). This game was nice because it was also a great conversation starter. I met a lot of mentors both of open source software that I regularly use but also learned about new interesting open source software and organizations while doing that!

We had time until Friday 12:30 and 10 lucky mentors who completed it (at the end around 60 of 185 were able to complete) got randomly selected and they got special prizes.

I stayed up until probably 1am or so, socializing a bit more in the lobby and then went back to my room to have some sleep, knowing that Friday was completely packed with Lightning talks and sessions!

Friday 24, October 2025: 2nd day of Mentor Summit

I had breakfast around 8:20 at the Green's Restaurant. I sat at a table together with other folks and after a minute I saw a known name in front of me: Lourival Pereira Vieira Neto <lneto@>! I was very happy to meet another NetBSD developer and that was a complete surprise. He was there as a mentor of the LabLua organization.

GSoC Program Admins welcomed us for the day and recapped the schedule for Friday and Saturday.

Lightning talks, round 1

The lightning talks consisted of mentors presenting their best GSoC 2025 projects. The format was fast and fun: a maximum of 3 minutes for the talk and a maximum of 4 slides! We had presentations from 18 different mentors and orgs and all of them were able to stay under 3 minutes!

That was a great occasion also to learn about open source projects, new orgs and the experiences shared were interesting too.

GSoC Feedback Session

After the 1st round of Lightning Talks I attended the GSoC Feedback Session. That was a Q&A session with program admins and org admins/mentors.

Hot topics this year were AI usage and spam applications that were not discussed as part of this session because there were two other separate sessions regarding that later.

If I only have one sentence to summarize this session... I should quote Robert sharing that Google Summer of Code is about the journey for the contributors and mentors to get involved in open source. The coding is only the means to an end.

"Hallway track", lunch and group photo

After the first session I decided to take a break and instead stay in the "hallway track" where I met new folks and socialized a bit. Another funny and at the same time a bit embarrassing for me thing of GSoC is that I often met someone and after a couple of minutes of talk I can associate the face with a name and I figured out that I'm an avid user / pkgsrc MAINTAINER of the software they contribute to! :)

At 12:30 we had lunch at Green's Restaurant and then at 13:40 we had a group photo and it was pretty tricky to put around 200 folks (program admins and mentors) on the stage of the Ballroom! :)

Let's talk about improving diversity + inclusion in FOSS!

In the afternoon I joined the session about improving diversity. In open source unfortunately there are a lot of underrepresented groups and we should fix that.

There were a lot of experiences shared from several orgs, food for thought for me! Only to name few topics: Outreachy, how to know and create safe spaces, importance of localization in software and documentation, be sure to make underrepresented folk as part of key people and also try to take the burden of other tasks off them.

GSoC and AI

Artificial Intelligence (AI), in particular Generative AI (GenAI) has been a hot topic since project proposals opened this year!

Some people consider it a speed-up for researching but at the same time it impedes learning.

In NetBSD - according to our Commit Guidelines - code generated by large language model (LLM) or similar technologies is considered tainted code because such models can be trained on copyrighted materials and such resulting code can then violate copyright.

More than 80% of GSoC contributors who filled an anonymous survey used AI, mainly for code generation, code completion, text generation, debugging and error detection.

Most mentors are usually not happy with the outcomes of AI with code often resulting in buggy/vulnerable and poor quality, violating copyright and some mentors also pointed out that as part of mentoring we should also make contributors aware of environmental/ecological impact of such use.

However, both contributors' and mentors' surveys on AI are relatively small dataset (around 90 mentors and 90 contributors).

Lightning talks, round 2

At 16:00 we had the 2nd and last round of Lightning talks. That was another great opportunity to learn more about more projects and organizations!

Asynchronous I/O by Ethan Miller

Christoph Badura (<bad@>) presenting his lightning talk

Christoph Badura (<bad@>) did a lightning talk too and he presented work done by Ethan Miller. Ethan also blogged about his work, please read Google Summer of Code 2025 Reports: Asynchronous I/O Framework if you missed it!

This code was also imported by Christos Zoulas (<christos@>), thanks Christos!, and is now part of -current and it will be in NetBSD 12.0.

GSoC spammy proposals

After the Lightning talks there was a break and then at 17:30 I joined the session about GSoC spammy proposals.

This year most organizations received many more proposals, mostly due contributors starting to massively use GenAI.

A lot of suggestions and tips were shared to make the mentor review job smooth and easy as possible.

The most important suggestion is that mentors must do a 1:1 conversation with potential contributors before accepting them. The weight of the project proposal is like 2/10 and the actual 8/10 weight is on conversations between mentors and contributor.

Dinner and social event

Around 19:00 we had dinner, desserts and socialized. Stephanie also did a final talk recapping GSoC 2025 and thanking all mentors for making that possible.

We then had drinks and it then started the karaoke session (and there were a lot of pro folks doing that, very nice!).

The karaoke session at Ballroom closed with the waiter singing Closing Time (not the one by Tom Waits that is mostly instrumental, but the one by Semisonics!, I did not know it but that's melancholic as well for me, just smells a little bit less of whisky and cigs compared to the Tom Waits one ;)).

We went downstairs to the Champions Bar, had two rounds of some good Higgins Ale Works IPA and socialized a bit more. Time passed pretty quickly and also the barman there at Champions Bar started singing Closing Time!

We went a bit outside and in the lobby talking with other mentors and then I went back to my room to get some sleep for the last day of the summit.

Saturday 25, October 2025: 3rd day of Mentor Summit

I had breakfast around 8:00, a bit earlier, given that on Saturday the first session started at 9:00.

Porting & Packaging

At 9:00 I joined a session about porting and packaging. We had both FreeBSD porters, pkgsrc maintainers and other package systems maintainers on one side. On the other side there were also a lot of upstreams.

We shared do-s and don't-s on packaging.

How to get students to engage with the community

Christoph Badura (<bad@>) proposed a session to share experiences on how to get contributors to engage with the community and a lot of mentors provided a lot of great suggestions.

One thing that most mentors agreed on and worked well was to invite contributors regular (or less regular, to avoid putting too much pressure on contributors) blog posts / status updates.

Some organizations also did that as part of their weekly / bi-weekly updates that are often video meetings. In that case they reserved a slot for the contributor so that they can share their status updates.

These are great opportunities for the contributor to get in touch with the community.

Open source tools for supply chain security

I then joined a session about open source tools for supply chain security.

We discussed about Software Bill of Materials (SBOM) and its importance in the context of regulations like EU Cyber Resilience Act (CRA).

We also discussed Common Platform Enumeration (CPE) and Package URL (PURL) schemas

We talked about vulnerability management and I shared a bit my experience in pkgsrc-security@ and how often the metadata in CVEs (like vendor, product and versions affected) is not that good. Most package systems have their own workflows and usually add extra metadata only for their vulnerability DB.

I also learned about Vulnerability Exploitability eXchange (VEX) that some package systems use.

There were also mentors from AboutCode and SW360, projects that looks very interesting and I should learn more about them!

Vintage computing

Before lunch I joined the Vintage computing session.

Everyone presented themselves and talked about the most vintage computer they had, how running old machines is both fun and productive and we also talked about old Unix-es and The Unix Heritage Society.

Lunch

I had lunch at Green's Restaurant with other mentors and then socialized a bit outside Ballroom.

Waitlisted Lightning talk and funny stories

At 14:00 we had the last sessions. I went to the waitlisted Lightning talk, that can be considered the Lightning talk, round 3! :)

Mentors from different organizations shared interesting projects.

After the lightning talks several of us shared funny stories/hacks. Like learning languages in interesting ways, taking photographs of garbage to train and realize a robot that cleans it, a sort of Tinder for food... And much more! :)

Closing session

At 15:30 we had the closing session.

Some of us stayed for another 1 or 2 hours and talked, socialized a bit more and said see you soon to each other.

Going near Munich East Station and dinner with Chris

Around 17:00 I left the Munich Marriott hotel to check in to my hotel for Saturday night near Munich East Station. It was raining for most of the morning and afternoon but luckily around 17:00 it stopped and the sky seemed fine. I decided to take a walk - a bit more than 6km - to reach the hotel. Also that time I'm happy that I took a long walk because I was able to stay for most of my walk in the Englischer Garten.

Glass of Camba Island (NEIPA) beer and list of draft beers

I checked in at my hotel and then went to Tap-House where with Christoph we planned to have dinner and a couple of beers. Tap-House had a really huge choice of craft beers with 40 drafts! We had a pinsa marinara, a flatbread similar to pizza and I had a couple of small IPAs from Camba Bavaria and Yankee & Kraut Pure HBC 630, a DNEIPA.

We decided to take a walk and went to BrewsLi for some last good night beers. BrewsLi was a very nice brew pub. We sat at a table and near us there were several board games. Chris took one of this board game Mensch ärgere Dich nicht and explained to me the rules. A lot of aleatory is involved but there is also some strategy and it was funny to play and we probably played for 40 minutes or so because most of our game pieces returned to the "out" section. I took a walk with Chris back to the nearest metro station and I came back to my hotel around 2:00.

Mensch ärgere Dich nicht board game

Sunday 26, October 2025: stop in Bolzano/Bozen

On Sunday I took a train from Munich East Station to Bolzano/Bozen because it was unfeasible to go back home by train to Marche region without a stop somewhere in Italy.

View of Bolzano from St. Oswald Promenade

I went for a walk Passeggiata di Sant'Osvaldo (St. Oswald Promenade) uphill to be able to enjoy a view of the city from the top until sunset.

I had a simple but very tasty onion soup and a Gose (really good, one of the best Gose I've drunk!) and Session IPA at Batzen Häusl.

I was not able to visit anything else in the night because I was pretty tired so I went to sleep earlier.

Monday 27, October 2025: back home

In the morning I took a walk to Walther Square and nearby. I got some souvenirs for the family and then I took the trains back home and spent most of my day on the trains.

Conclusion

Google Summer of Code 2025 Mentor Summit was an amazing experience!

I had the chance to participate in very interesting talks, sessions and discussions. I met a lot of mentors from all over the world and learned about new open source projects and organizations. All the folks were also extremely positive, easy to talk to and I had a lot of fun.

Thanks to program admins and all the mentors who made this possible! Thanks a lot also to Google for organizing it and thanks to The NetBSD Foundation that permitted me to go!

NetBSD hand-written logo on the GSoC guest book

If you are new to open source, consider applying for it! If you are a seasoned open source contributor, consider participating as a mentor! You can learn more about GSoC at Google Summer of Code (GSoC) website.

Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD, part 2

Leonardo Taccari — Mon, 20 Oct 2025 14:19:28 +0000

This report was written by Dennis Onyeka as part of Google Summer of Code 2025.

This is the 2nd blog post about his work. If you have missed the first blog post please read Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD.

Overview

Typical rules looks like:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33
map wm0 algo nat64 plen 96 64:ff9b::8c52:7903 <- 140.82.121.3

This tells NPF to translate outgoing IPv6 packets using the prefix 64:ff9b:2a4::/96, rewriting them to use the IPv4 address 192.0.2.33. When the packet returns and hits NPF, it changes source from GitHub's IPv4 to GitHub's IPv6 address and then it rewrites the header.

When an IPv6 packet from a client hits the NPF machine

The NAT64 translation routine (npf_nat64_rwrheader()) rewrites the IPv6 header to an IPv4 header.
- The source becomes the host's IPv4 address or any pool of IPv4 addresses.
- The destination becomes the IPv4 address of github.com extracted from IPv4 embedded IPv6 address defined in the rule configuration. (e.g. 140.82.121.3 from 64:ff9b::8c52:7903).
TCP/UDP/ICMP checksums are recalculated using in4_cksum() or in6_cksum().
The packet is then routed out to the IPv4 network.

When a reply packet comes back from the IPv4 server

NPF performs the reverse translation, embedding the IPv4 address inside the NAT64 prefix to form a valid IPv6 address using npf_embed_ipv4()
The IPv6 packet is then delivered back to the IPv6 client.

Project Accomplishments

Core Translation Path: Implemented IPv6 -> IPv4 header and reverse rewriting (npf_nat64_rwrheader() routines).
Address Mapping: Added functions for embedding and extracting IPv4 addresses within IPv6 prefixes.
Checksum Recalculation: Integrated checksum updates for IPv4/IPv6 and transport layers.
Rule Parsing: Extended npf.conf(5) syntax and parser to accept NAT64 configuration parameters.
Userland and Kernel Integration: Updated kernel headers, userland utilities, and rule constructors.
Testing: Verified translation with ping, curl and dig, observing packets using tcpdump and Wireshark.

Summary

This project successfully integrates NAT64 along with a separate DNS64 configuration into NPF, enabling IPv6-only clients to reach IPv4-only servers through seamless translation. Although there's a need for additional changes and implementation.

This is indeed the end of my GSoC Program, it was indeed an exciting moment working with system developers and certainly I'd be an active contributor to the NetBSD codebase.

Source code of the Google Summer of Code project can be found at the following branch.

Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD

Leonardo Taccari — Mon, 15 Sep 2025 16:19:01 +0000

This report was written by Dennis Onyeka as part of Google Summer of Code 2025.

Introduction & Description

The goal of the NAT64 project is to implement IPv6-to-IPv4 translation inside NPF (NetBSD Packet Filter). NAT64 enables IPv6-only clients to communicate with IPv4-only servers by embedding/extracting IPv4 addresses in IPv6 addresses as per RFC 6052 and RFC 6145. We are using a 1:1 mapping for now, to implement NAT64 translation. Whereby an IPv6 host will use its IPv4 address to communicate with an IPv4 only server. As an example of IPv4, we will use github.com (140.82.121.3) that supports only IPv4. In order to enable NAT64 on NPF we will have a rule like this:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33

This means we want to use the host IPv4 address associated to wm0 interface 192.0.2.33 to access the public internet in order to communicate with GitHub's IPv4 server. During this process, IPv6 header will be rewritten to IPv4. Part of the IP structure requires source and destination address so our new IPv4 source address will be the Host IPv4 address (which is likely to change during further improvement) and the IPv4 destination address will be gotten from GitHub’s IPv4 embedded IPv6 address i.e. the IPv4 address embedded into IPv6 address (64:ff9b::8c52:7903) gotten from the DNS resolver. Note that NPF is our router so we will have to enable and configure a DNS caching resolver like unbound on the NetBSD machine. The job of the DNS64 is to synthesize AAAA responses from IPv4-only A records using the well-known prefix (64:ff9b::/96), then embed the Github’s IPv4 address (140.82.121.3) into it which will be (64:ff9b::8c52:7903). The hexadecimal values represent Github’s IPv4 address. When the packet is returning from GitHub, it uses the IPv6 interface, so the IPv4 address part will be embedded back into its required position based on the prefix length passed by the user on the configuration. Then it will be sent to the IPv6 interface of the host machine. So far, I’ve been focusing on the core translation path, making sure headers are rewritten correctly and transport checksums are updated. This also requires changes in the userland and kernel.

Current Status

Address Embedding and Extraction: Implemented functions that are responsible to extract IPv4 from IPv6 and embed IPv4 back into IPv6. Supports prefix lengths 32–96, with 96 as default.
IP Header Rewrite: Added a functionality that enables headers rewriting by stripping off the old IP header and creating a new header along with structures.
Rule Parsing: Added keyword support in npf.conf, so users can specify NAT64 prefix length.
Checksum Handling: Integrated checksum recalculation for IPv4, IPv6, and transport layers (TCP/UDP/ICMP).

More functionalities to be added (In the coming weeks)

State Integration: Hooked into NPF’s connection tracking so NAT64 works with stateful packet filtering.
Fine tune the checksum handling

Development Environment & Test Environment

Running NetBSD in a VM (on Windows host) for test implementation
Editing and building code on WSL (Windows Subsystem for Linux).

Testing

Testing traffic with ping, nc (netcat), curl, dig.
Using tcpdump/tshark/Wireshark on NetBSD to inspect packets before/after translation.

Debugging

Building kernel and userland via build.sh with kernel debug logs enabled
Tracing packet flow via ktrace
Incremental testing/unit: Test functions one by one.

Experience, Observation, Impressions

Experience: Working deep inside NetBSD’s kernel networking stack has been challenging but rewarding. It gave me hands-on experience with mbufs, packet parsing, and kernel-level checksums.

Observation

Testing NAT64 also requires real network setups, not just unit tests, since correctness depends on seeing the actual wire-format packets.
Prefix length handling is subtle, user input must be validated and handled gracefully (defaulting to 96).
The separation between userland rule parser and kernel execution path is strict, everything is serialized into structures properly.

Impressions about NetBSD

The codebase is clean and modular, but sometimes well-documented to an extent.
NetBSD’s networking stack is solid and flexible, NPF feels light and extensible.
The build system is stable.

Google Summer of Code 2025 Reports: Asynchronous I/O Framework

Leonardo Taccari — Sat, 30 Aug 2025 17:56:23 +0000

This report was written by Ethan Miller as part of Google Summer of Code 2025.

Introduction

The goal is to improve the capabilities of asynchronous IO within NetBSD. Originally the project espoused a model that pinned a single worker thread to each process. That thread would iterate over pending jobs and complete blocking IO. From this, the logical next step was to support an arbitrary number of worker threads. Each process now has a pool of workers recycled from a freelist, and jobs are grouped per-file so that we do not thrash multiple threads on the same vnode which would inevitably lock. This grouping also opens the door for future optimisations in concurrency. The guiding principle is to keep submission cheap, coalesce work sensibly, and only spawn threads when the kernel would otherwise block.

Project Details and Status

We pin what is referred to as a service pool to each process, with each service pool capable of spawning and managing service threads. When a job is enqueued it is distributed to its respective service thread. For regular files we coalesce jobs that act on the same vnode into one thread. If we fall back to the synchronous IO path within the kernel it would lock anyway, but this approach is prudent because if more advanced concurrency optimisations such as VFS bypass are implemented later this is precisely the model that would be required. At present, since that solution is not yet in place, all IO falls back to the synchronous pipeline. Even so there are performance gains when working with different files, since synchronous IO can still run on separate vnodes at the same time.

Through the traditional VFS read/write path, requests eventually reach bread/bwrite and block upon a cache miss until completion. This kills concurrency. I considered a solution that bypassed the normal vnode read/write path by translating file offsets to device LBAs with VOP_BMAP, constructing block IO at the buffer and device layer, submitting with B_ASYNC, and deferring the wait to the AIO layer with biodone bookkeeping instead of calling biowait at submission. This keeps submission short and releases higher level locks before any device wait. The assumptions are that filesystem metadata is frequently accessed therefore cached so VOP_BMAP usually does not block, that block pointers for an inode mostly remain stable for existing data, and that truncation does not rewrite past data. For the average case this would provide concurrency on the same file. In practice, however, it was exceptionally difficult to implement because the block layer lacks the necessary abstractions.

This is, however, exactly the solution espoused by FreeBSD, and they make it work well because struct bio is an IO token independent of the page and buffer cache. GEOM can split or clone a bio, queue them to devices, collect child completions, and run the parent callback. Record locks are treated as advisory so once a bio is in flight the block layer completes it even if the advisory state changes. NetBSD has no equivalent token. Struct buf is both a cache object and an IO token tied to UBC and drivers through biodone and biowait. For now the implementation of service pools and service threads lays the groundwork for asynchronous IO. Once the BIO layer reaches adequate maturity, integrating a bio-like abstraction will be straightforward and yield immediate improvements for concurrency on the same vnode. The logical next step is to design and port something comparable to FreeBSDs struct bio which would map very cleanly onto the current POSIX AIO framework.

My Development Environment

My development setup is optimised for building and testing quickly. I use scripts to cross-build the kernel and boot it under QEMU with a small FFS root. The kernel boots directly with the QEMU option -kernel without any supporting bootloader. Early on I tested against a custom init dropped onto an FFS image. Now I do the same except init simply launches a shell which allows me to run ATF tests without a full distribution. This makes it possible to compile a new kernel and run tests within seconds.

Lessons

One lesson I have taken away is that progress never happens overnight. It takes enormous effort to get even a few thousand lines of highly multi-threaded race-prone code to behave consistently under all conditions. Precision in implementation is absolutely required. My impression of NetBSD is that it is a fascinating project with an abundance of seemingly low-hanging fruit. In reality none of it is truly low-hanging or simple, but compared to Linux there remains a great deal of work to be done. It is not easy work but the problems are visible and the path forward is clearer.

I also want to note that I intend on providing long term support for this code in the case that any issues may arise.

The code written as part of this project can be found here.

NetBSD 11.0 release process underway

martin — Mon, 4 Aug 2025 09:16:17 +0000

If you have been following source-changes, you may have noticed the creation of the netbsd-11 branch! It comes with a lot of changes that we have been working on:

Install changes

Compatibility support code, like 32bit on 64bit machines, has been separated into special sets, to allow easy installation of machines that do not need to be able to run 32bit code.

Install media for some architectures has been split in small ("CD/R") images (w/o debug and compat sets), and full ("DVD-R") sets. This is also useful on hardware that came with a CD drive (instead of a DVD drive) and can not boot from a USB stick.

Manual pages come in two flavors, html and mandoc. Both have now their own sets, so one or the other can easily be left out of an installation.

All mac68k and macppc ISO images are now bootable.

Kernel changes

x86: PVH boot is now supported on non-XEN platforms (QEMU, Firecracker)
various new drivers for temperature (and other environmental) sensors and fan control
the heartbeat watchdog will detect locking errors that prevent softints from running or the timecounters from making progress on one of the CPUs
lots of enhancements for Linux emulation
new syscall: semtimedop(2)
new riscv port primarily targeting StarFive JH71XX-based devices
various bug fixes

Userland changes

libc and libm enhancements for C23 and POSIX.1-2024 support
userland support for manipulating/querying (U)EFI variables has been added
jemalloc has been updated to version 5.3
various bug fixes to libpthread and making functions signal safe
lots of miscelaneous bug fixes
the in-tree X.org components are all (well, nearly - there are a few minor/unimportant exceptions) up-to-date

3rd party software updates included

gcc for all architectures is now at version 12.5
gdb for all architectures is now at version 15.1
binutils for all architectures is now at version 2.42
OpenSSL got updated to the latest long term support version available: 3.5.1
OpenSSH is at version 10.0
many others updated, including dhcpcd, openresolv, unbound, nsd, ...

And a lot more...

... that we always forget to mention. The list of changes can be found in the beta build, split into changes upto the creation of the branch and changes pulled up to the branch before the 11.0 release.

Things that did not make it in-time for the branch

A few work-in-progress items unfortunately did not make it into this branch and will not be pulled up. The most missed ones are:

the next round of DRM/KMS updates to enhance x86 and arm graphics support
the big WiFi renewal project

These will happen in HEAD now carefully and after stabilization might be a good reason to create the next major branch earlier.

Please help us test this BETA!

We try to test NetBSD as best as we can, but your testing can help to make NetBSD 11.0 a great release. Please test it and let us know of any bugs you find.

Binaries are available on NetBSD daily builds and for various ARM based devices (with board dependent boot setup) on arm install images.

Please test NetBSD 11.0_BETA on your hardware and report any bugs you find!

Tentative schedule

No promises, but we will try to make this one of the shortest release cycles ever...

Ideally we will be in release candidate state at EuroBSDCon late in September, and cut the final release early in October.

New build cluster speeds up daily autobuilds

martin — Thu, 24 Jul 2025 13:09:58 +0000

Saying goodbye

For several years our autobuild cluster at Columbia University has been providing our CI and produced many official release builds.

Over the years, with new compiler versions and more targets to build, the build times (and space requirements) grew. A lot. A few weeks ago the old cluster needed slightly more then nine and a half hours for a full build of -current.

So it was time to replace the hardware. At the same time we moved to another colocation with better network connectivity.

Preparing for the future

But not only did the hardware age, the CI system we use (a bunch of shell scripts) needed a serious overhaul.

As reported in the last AGM, riastradh@ did most of the work to make the scripts able to deal with mercurial instead of cvs.

This is a necessary step in the preparation of our upcoming move away from cvs, which is now completed. While the build cluster currently (again) runs from cvs, we completed a few full builds from mercurial in the last few weeks.

User visible changes

The cvs runs for builds were purely time driven. To deal with latency between cvs.NetBSD.org and anoncvs.NetBSD.org there was a 10-minute lag built into the system, so all timestamps (the names of the build directories) were exact to the minute only and had a trailing zero.

This does not fit well with modern distributed source control systems. For a hg or git build the cluster fetches the repository state from the master repository and updates the checkout directory to the latest state of a branch (or HEAD). So the repository state dictates the time stamp for the build, not vice versa as we did for cvs.

As a result there is a difference between the time a build is started (wall clock) and the time of the last change of the current branch in the repository (build time or reproducible ID). You can see both times in the status page. Just right now it displays:

Currently building tag HEAD-lint, build 2025-07-22 19:19:02 UTC (started at: 2025-07-22 19:26:40 UTC).
No results yet.

And, obviously, we can now easily skip builds when nothing has changed - which happens often on old branches, but also may happen when all HEAD builds are done before anything new has been committed. Hurry up, you lazy developers!

While we are still running from cvs, the process of checking if anything has changed is quite slow (in the order of five minutes). So you may notice a status display like:

Currently searching for source changes...

while the "cvs update" is crawling. When running from hg (or git) this will be lot faster.

The new hardware

The new cluster consists of four build machines, each equipped with a dual 16 core EPYC CPU and 256 GB of RAM. As a "brain" we have an additional controller node with 32 GB RAM and a (somewhat weaker) Intel CPU. The controller node creates all source sets, does repository operations, and distributes sources but does not perform any building itself.

On the build machines we run each 8 builds in parallel, and each build with low parallelism (-j 4). This tries to saturate all cpus during most of the time of the overall build. Individual builds have several phases with little/reduced possibility of parallelism, e.g., initially during configure runs, or while linking llvm components, or near the end when compressing artefacts. The goal is not to run a single (individual) build as fast as possible, but the whole set of them in as little time overall.

The build log summary

The head of the result page create for each build now tries to give all the details necessary to recreate this particular build, e.g.:

From source dated Tue Jul 22 04:45:13 UTC 2025
Reproducible builds timestamp: 1753159513
Repository: src@cvs:HEAD:20250722044513-xsrc@cvs:HEAD:20250720221743

The two timestamps are the same, one in seconds since the Unix epoch, the other human readable.

The repository ID is, for cvs, again based on timestamps. But for hg or git you will see the typical commit hash values here.

Why a custom CI system?

We considered using an off-the-shelf CI system and customizing it to our needs instead of moving the fully custom build system forward. We also talked to FreeBSD release engineering about it and asked for their experience. Overall the work for customizing an off-the-shelf solution looked roughly equivalent to the work needed now to modify the existing working solution, and we saw no huge benefit for the future picking either of them.

What does our build infrastructure provide?

First and foremost, we can quickly verify if all of our supported branches indeed compile. While developers are supposed to commit only tested changes, usually they build at most one branch and architecture. But sometimes changes have unforeseen consequences, for example an install image of an exotic architecture growing more in size than expected.

Then, in theory, no NetBSD user has to waste any CPU cycles in order to install (for example) NetBSD-current or the latest NetBSD 9 tree. Instead you can simply download an image and install from that — no matter if your architecture is amd64 or a slightly more exotic one (but you will of course always be able to download the source tree and build that if that suits you better).

Note that a supported architecture is not just supported at one point in time and then as time progresses might start collecting dust and not compile anymore, making it hard to merge all current changes back into that tree. Instead once an architecture is supported, our CI system will without rest build that architecture as one of the many we support. Take the rather new Wii port as an example. Now that it is supported, you can at least for the foreseeable future download the latest and greatest NetBSD release, populate an SD card with the image and boot it. Now, in half a year, and in 10 years (and even further down the line).

Acknowledgements

We are grateful to Two Sigma Investments, LP for providing the space and connectivity for the new build cluster.

The NetBSD Foundation 2025 Annual General Meeting summary and logs

Leonardo Taccari — Wed, 28 May 2025 17:46:58 +0000

On May 17, 21:00 UTC we had The NetBSD Foundation Annual General Meeting on #netbsd-agm IRC channel on Libera.Chat.

We had presentations from:

board (billc)
secteam (billc)
releng (martin)
core (riastradh)
finance-exec (riastradh)
membership-exec (martin, christos)
pkgsrc-pmc (wiz)
pkgsrc-security (tm, leot)
gnats (dh)

At the end we also had a Q&A session open to anyone.

If you have missed it you can find the IRC logs here.

Welcome to Google Summer of Code 2025 contributors!

Leonardo Taccari — Thu, 8 May 2025 19:09:56 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025 with 3 projects!

Here the list of the projects and contributors:

For the next 3 weeks mentors and contributors will get in touch for the community bonding period. Mentors will help contributors to get started with the project, introduce them to the community and get more familiar with the codebase and adjusting deliverables for the the project.

Welcome Dennis, Ethan and Vasyl!

The NetBSD Foundation will participate in Google Summer of Code 2025!

Leonardo Taccari — Thu, 27 Feb 2025 19:10:49 +0000

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025!

Would you like to contribute to NetBSD and/or pkgsrc in the next months? Google Summer of Code is a great chance for that!

You can find a list of possible projects at Google Summer of Code project page. Of course, you can also propose your own!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code please also check official homepage at g.co/gsoc.

Looking forward to a great Summer!

Google Summer of Code 2024 Reports: Test root device and root file system selection

Leonardo Taccari — Fri, 3 Jan 2025 20:42:15 +0000

This report was written by Diviyam Pat as part of Google Summer of Code 2024.

This summer I worked on NetBSD's kernel test framework to cover root device discovery and root file system selection. This area of the kernel is not very well documented and program flow has to be determined by reading the code.

I would also like to tell you about my early interactions with the project, let me start with project findings.

Why NetBSD?

Google Summer of Code 2024 is not my first time applying to GSoC. My first time was in 2022, in my first year of college. I have been fascinated with newer Windows versions since my Intel Core Duo i3 days as every new Windows version used to bring new changes and features, from Windows XP to Vista to 8.1 and then to 10 (cosmetic only) but was very heavy on my PC's memory usage that was upwards of 60% leaving very little room for applications and games.

My Intel i3 would be enough for it. This experience made me decide I wanted my project to be in the operating system space. I ventured into all OS projects on the Google Summer of Code website. Gentoo, Debian but that didn't turn out well. I then decided to explore BSDs. The community seemed friendlier, more responsive, and active in helping beginners. I started mailing all the mentors about my interests (I realized I should have done a lot more work before mailing them, it shows more dedication towards the project.)

Christoph explained the project in great detail to me, helped me with getting started and guided me through the hard parts of the project.

Project Details

Root device and file-system selection is made during the later stages of the boot process by the kernel. The kernel config file defines candidates for the root device and the kernel selects one after validating those options. If no options are defined, the auto config subroutines handle configuration. Head over to my docs for more details here. This functionality is handled primarily by the function setroot in file kern_subr.c. It also calls specialized functions for a number of cases. Our task was to add ATF tests for this function and some other functions that assist setroot. This part of the kernel works, and it has worked for over 30 years but the code is rather complex to read and there is no documentation. The only way to understand it is to read the code.

At any given stage when any condition fails the fallback option is to ask the user manually for the device. Thus this part of the kernel rarely needs attention. There are some global functions used in conditions inside setroot: rootspec, bootspec, etc. These variables are either set through the config file or through other machine-dependent kernel functions like findroot etc. We need to manually set them in our test cases and also need to stub kernel functions used by setroot and other functions. We wanted to make these test cases use 'vnd' devices, but we ran into bugs, and Christoph was trying to fix them. Therefore we had to resort to stubbing. We validate the global variables. We also test the tftproot_dhcpboot function that loads the contents of a memory disk device from a TFTP server and uses that as root device. Devices are represented by the device_t struct which is populated by the kernel. We mock this behavior through the create_device function and use this in the test programs. User input is handled by stubbing the cngetsn function. Global variables and arguments are set to test values in the body of the test cases and the function being tested is called. The test file is divided into 3 parts: 1) setroot_root, 2) setroot_ask, and 3) tftproot_dhcp. In the file kern_subr.c setroot() calls these functions but here we test them independently

Conclusion

I have worked on enhancing NetBSD's ATF tests to test the root device and file system selection process, testing the setroot function and its dependencies. These tests shall improve coverage of the ATF tests to the setroot function and in general, to root device selection. In the future, contributors can rely on these tests for kern_subr.c's functionality.

NetBSD 10.1 available!

martin — Thu, 19 Dec 2024 11:55:00 +0000

The NetBSD project is pleased to announce the first update of the NetBSD 10 release branch NetBSD 10.1! See the release announcement for details.

This release includes 9 months of bug fixes and a few new features after the 10.0 release in March. It also gives those still using older release a good reason to finally update to the NetBSD 10 release branch, even if they avoid dot-zero releases by all means.

If you want to try NetBSD 10.1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

EuroBSDcon 2024 in Dublin, Ireland: some notes after the conference

Leonardo Taccari — Fri, 4 Oct 2024 13:19:58 +0000

I have not been at EuroBSDCon for a while, unfortunately! My last EuroBSDCon was EuroBSDcon 2017 in Paris, France (and I have also blogged about it)!

I was very excited to come back to EuroBSDCon. Meet again in person with people. Talk in the "hall track"... and, why not!, have some fun and do some shenanigans in the nights! :)

And... definitely it was very nice, instructive and fun!

I have not fully unpacked the bag but it's time to share some notes!

Friday (20/09): arriving in Dublin

I arrived in Dublin on Friday afternoon. After some sightseeing on foot I got lost in the paintings of the National Gallery of Ireland.

I then spent the rest of the evening and night in Porterhouse Temple Bar. I had a tasty soup and garlic bread and several delicious craft beers!

Saturday (21/09): 1st day of conference talks and social event

My hotel was a 40 minutes walk from University College Dublin (UCD). I arrived a bit early for the registration. I then met some other NetBSD folks that I had missed in person since 2018 and met new ones.

View from O'Reilly Hall, University College Dublin.

After the Opening Session that welcomed us, the conference started with the opening keynote Evidence based Policy formation in the EU what Evidence are we Presenting to the EU? by Tom Smyth. Tom Smyth shared his experience on evidence based policy formation in the European Union from a point of a relatively small ISP. EU is open to feedback and as a BSD community we can shape and influence policies.

Flipping Bits: Memory Errors in the Machine, Taylor R Campbell

Taylor talked about bit flips, the memory errors in the machine.

Memory errors caught in the act: corruption of a filename in Riastradh's local machine.

He started sharing a catch of bit flip in a filename corruption on his local machine in NetBSD src repository. A bit flipped and that resulted from external/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc to e\370ternal/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc (In ASCII lower case x is \170 that is 01111000 in binary, while \370 is 11111000, the most significant bit got flipped!).

He also opened several PRs - due to several experienced kernel panics mostly in ZFS - before he realized that it was bad RAM.

As part of the talk a lot of fundamentals concepts and theory behind Error Detection And Correction (EDAC), causes of memory errors, where memory errors can happen, error severity and error persistence were shared.

Taylor then talked and digged in ACPI Platform Error Interface (APEI) that is the standard interface in ACPI that abstract EDAC device registers.

In NetBSD APEI is supported by the apei(4) driver.

The apei(4) driver also exposes a sysctl interface to APEI EINJ (Error INJection) that permit to also inject errors. Using such interface Riastradh live demoed that and trigger a memory error that was corrected and reported by apei(4)!

Riastradh live demoing a memory error using APEI EINJ via apei(4).

The talk was great and super-interesting. Memory errors are also pretty common. Taylor also shared a lot of anecdotes and that make his talk even more fun and interesting!

An introduction to GPIO in RPi3B+ and NetBSD, building a wind-speed logger as an application, Dr. Nicola Mingotti

Dr. Nicola Mingotti talk was a great introduction (and more) to Generalized Pin Input Output (GPIO)!

He started really from the start by populating a uSD card and installing and configuring NetBSD on a Raspberry Pi 3 Model B+.

He then introduced GPIO, how the RPi3B+ pin maps to the GPIO number and then we were ready to get our hands on GPIO!

As first exercises he showed how to set a PIN state (on/off) and read a PIN state via gpioctl(8). This can be used respectively to turn a LED on/off and to read the state of a switch.

The second series of exercises looked on how fast gpioctl can be. This is limited for several applications and so Nicola introduced how to write and read pin states in C via ioctl(2). This is much faster and with that we can go from switches to square waves!

To avoid bit-banging and polling respectively gpiopwm(4) and gpioirq(4) can be used. Nicola shared several applications of them, like blinking LED and loopback. (Another possible application, left as an exercise to the reader is the "daemon toggler". The "daemon toggler" starts/stops a daemon (e.g. ntpd(8)) based on the state of a physical switch!)

He then shared a much bigger application a Wind-Speed Logger (AKA WSL). This was used by Nicola in order to evaluate if wind turbines could be installed or not. He also shared how he adjusted an RPi case and built housing for it (the RPi will be outside, needs to cool off so needs some ventilation but at the same time the housing should block rain!)

Nicola showing the sensor used to build the Wind-Speed Logger (WSL).

He concluded the talk on why he used NetBSD.

The talk was really educational. Nicola did a great job in summarizing and providing a lot of references. If you are more interested I suggest to catch up with the video recordings, slides and try to do the exercises in it!

"Hall track" and preparing for the social event

After Nicola's talk I have spent some time in the "hall track" talking with other people and missed a couple of talks (recording should be available so I will hopefully catch up!).

I have then attended Stefano Marinelli's talk Why (and how) we're migrating many of our servers from Linux to the BSDs.

Stefano shared his more than 2 decades old experience with BSD systems and how he made his passion his profession.

He shared his philosophy, experience with clients and why it is important to focus on solving problems.

During the talk he shared also several interesting stories with clients. In one of them to avoid possible bias on BSD systems he migrated client hosts without informing them. A client called alarmed because he noticed a massive performance boost!

His talk was inspiring and you can find more in his I Solve Problems blog post.

After Stefano's talk we gathered to join the social event and took a DART train (Dublin Area Rapid Transit).

Social event: BrewDog Dublin Outpost

The social event was in BrewDog Dublin Outpost.

We were in an area dedicated to EuroBSDCon participants so that we can eat, drink and talk. There was a buffet and we received tickets to grab beers.

Several folks gifted me an handful and I have definitely had a pretty ample beer tasting experience too! :)

I also had a Vegan Spicy Meaty pizza: a pizza with seitan, mushrooms, chilli flakes, fresh red chilli, tomatoes and vegan mozzarella. My italian-pizza-side is usally pretty orthodox and I usually go for a pizza marinara! :) But overall that was actually pretty nice and I really appreciated the topping!

I have staid with a couple of folks until the closure. With Christoph Badura (<bad@>) we walked in the desperate search of grabbing some more food. However, at the end we ended up in The Temple Bar Pub for "only another beer"! We met with some friendly Swedish and Swiss tourists and we started talking about BSD systems at 2:00 AM! The weather was pretty nice (it was always pretty cloudy but there was no rain for the entire conference) and we decided to continue walking back to our hotels. At the end we have walked for a bit less than 9 kilometers from Temple Bar to nearly Booterstown! That was a great walk though and definitely we had no traces of hangovers in the morning! :)

Sunday (22/09): 2nd day of conference talks

I wake up a bit late on Sunday and arrived in UCD at around 12:00 and staid until lunch in the "hall track".

For lunch the vegetarian dish was a vegetarian curry, pretty tasty!

On Sunday we had a longer lunch break also to take a family photo.

EuroBSDCon 2024 family picture. You can find more EuroBSDCon photographs taken by Ollivier Robert at EuroBSDCon 2024 - Dublin, Ireland album.

After lunch I have attended FreeBSD at 30 Years: Its Secrets to Success by Kirk McKusick. In this talk Kirk looked back at 30 years of FreeBSD history (and also more for BSD years!) and what made its success. He talked about a lot of different topics, including leadership, development, importance of adopting ideas and codes from NetBSD and OpenBSD, communication, documentation and project culture. He also shared several interesting statistics and demographic about FreeBSD.

I have then attended Confidential Computing with OpenBSD by Hans-Jörg Höxer. Hans-Jörg introduced concepts about confidential computing, the threat model that it cover and then digged in AMD Secure Encrypted Virtualization (SEV) and how he is using that in OpenBSD vmm(4).

Then I have attended Building an open native FreeBSD CI system from scratch with lua, C, jails & zfs by Dave Cottlehuber. In this talk Dave shared the design and implementation of a Continuous Integration (CI) system focused on FreeBSD technologies but that can be ported also to other BSDs.

The final talk I have attended was SIMD-enhanced libc string functions: how it's done by Robert Clausecker and Getz Mikalsen. In this talk Robert shared how several libc string functions were reimplemented in other to use SIMD techniques on amd64 and arm64. Getz worked on porting such work on arm64 as part of Google Summer of Code 2024 and he shared his work and challenges in porting that. The talk was interesting and micro-benchmarking showed performance increase by factor of 5 on average!

Then I have joined the Closing Session.

There was a wrap up of the conference and some stats about it.

And *drumrolls* the next EuroBSDCon location was announced! EuroBSDCon 2025 will be in Zagreb, Croatia!

After the Closing Session with other NetBSD folks we met again for one last dinner. We met with Andy Doran (<ad@>) and we had some junk food and several beers.

Conclusion

I had not traveled a lot in the last years and I have missed several EuroBSDCon-s and I really regret that! EuroBSDCon 2024 was great: very interesting talks, friendly folks and it was some time that I did not had so much fun!

Dublin was also really nice. All the locals were also very friendly. I hope to come back to both Dublin and Ireland to do some much more sightseeing in a more relaxed pace. Enjoy food, beers, drinks and more. Talk with locals.

I would like to thanks a lot to all the EuroBSDCon organizers for the amazing conference!

I also would like to thanks The NetBSD Foundation that funded my EuroBSDCon registration.

If you have never been to EuroBSDCon and you are curious about BSDs... I strongly suggest to attend either as participant or speaker! Folks are super-friendly, there are a lot of interesting tutorials and talks and I'm pretty sure you will have fun too!

And... if you are still reading until here... thank you too! :)

Google Summer of Code 2024 Reports: ALTQ refactoring and NPF integration

Leonardo Taccari — Thu, 3 Oct 2024 10:15:26 +0000

This report was written by Emmanuel Nyarko as part of Google Summer of Code 2024.

Alternate Queuing has been of great need in the high Performance Computing space since the continuous records of unfair disruption in network quality due to the buffer bloat problem. The buffer bloat problem still persists and not completely gone but modern active queue managements have been introduced to improve the performance of networks.

ALTQ was refactored to basically improve maintainability. Duplicates were handled, some compile time errors were fixed and also performance has been improved too.

This improves the quality of developer experience on maintaining the ALTQ codebase.

The Controlled Delay (CoDel) active queue management has also been integrated into the netbsd codebase. This introduces improvements made in the area of quality of service in the netbsd operating system. CoDel was a research led collaborative work by Van Jacobness and Kathleen Nichols which was developed to manage queues under control of the minimum delay experienced by packets in the running buffer window.

As it stands now, ALTQ in NetBSD is integrated in PF packet filter. I am currently working to integrate it in the NPF packet filter. The code in NetBSD is on the constant pursuit to produce clean and maintainable code.

I'll also be working to improve quality of service in NetBSD through quality and collaborative research driven by randomness in results. As a research computer scientist, I will be working to propose new active queue managements for the NetBSD operating system to completely defeat the long lasting buffer bloat problem.

More details of the work can be found in my Google Summer of Code 2024 work submission.

NetBSD 8.3 released and end of support for netbsd-8

martin — Tue, 7 May 2024 18:52:08 +0000

The NetBSD Project is pleased to announce NetBSD 8.3, the third and final release from the NetBSD 8 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 8.2 in March 2020, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 8.0.

This also represents the end-of-life for the netbsd-8 release branch. No further security updates will happen. Users running 8.2 or an earlier release are strongly recommended to upgrade to a newer branch, preferably the recent NetBSD 10.0 release.

Pkgsrc has already desupported the netbsd-8 branch.

See the full release announcement (including download links).

X.Org on NetBSD - the state of things

Nia Alarie — Sat, 4 May 2024 12:05:20 +0000

A few years ago, I wrote a "state of things" blog post about Wayland on NetBSD. It's only natural that I should do one about X11, which is used by far more people to get a graphical environment on NetBSD.

There are a lot of differences from how NetBSD and the typical distributor ship X.Org. For one, we ship it as an optional monolithic package rather than separate individual packages. This means every driver is included on every system, rather than as an optional module. Sometimes, this means we need to fine-tune driver selection to ensure the correct drivers are loaded on the correct hardware, since multiple conflicting drivers can claim a video output. We also want sensible fallbacks, since if you're using a GPU from the future with an old OS version, you probably want X to seamlessly fall back to a regular framebuffer.

Secondly, the way our "xsrc" repository is set up, it's effectively functioning as a fork of X.Org that regularly pulls from upstream freedesktop.org (but does not push back). This allows X development to happen as part of NetBSD.

Thirdly, we use our own build system based purely on BSD makefiles, not X.Org's based on GNU autotools. This fits well with our build.sh cross-compilation system.

We have a number of drivers which have not made their way upstream. Perhaps the most ubiquitous of these is xf86-input-ws, a driver which came from OpenBSD, targets an API from NetBSD, and continues to be developed in both. This is a generic input driver that can support any pointing device that the kernel supports. Unlike xf86-input-mouse, it doesn't assume the device is a mouse, and can support advanced touchpad and touchscreen features. Other NetBSD exclusives include xf86-video-pnozz, xf86-video-mgx, and xf86-video-crime. While these all share the "xf86" name inherited from the historical XFree86 distribution, none of them are exclusively for x86.

There are a number of drivers that are accelerated when used in NetBSD, but the acceleration support is missing upstream. This is mostly due to the work of macallan@, who has diligently worked on drivers for accelerators found on SPARC and PowerPC hardware.

X.Org has historically supported two 2D acceleration modes, XAA and EXA. XAA seems complicated - according to the X.Org Foundation it supports accelerating "patterned fills and Bresenham lines" (eh?). XAA was removed from the X.Org server in 2012, and many old drivers were not updated to support the newer and simpler EXA model, except in NetBSD, over a time period of several years.

Did you know that Nvidia used to have an open source graphics driver? It supported 2D acceleration for a range of cards. In NetBSD, it's retained for platforms that included embedded Nvidia chips and aren't capable of (or predate, or don't want) the modern novueau driver. Six years ago, it was updated in NetBSD to support EXA acceleration.

There are a few ways our X integration could be improved. While lots of attention has been paid to the server, less has been paid to clients (programs). Did you know that X includes a text editor, and that text editor supports syntax highlighting and spell checking?

NetBSD includes its own command-line spell checker and associated dictionaries, spell(1), inherited from the BSD UNIX of yore. It's pretty basic, and only supports variations of English. To get spell checking to work in xedit, you need to install ispell (another command-line spell checker) from pkgsrc, install a dictionary, then set some Xresources (or create symlinks) to make sure xedit finds ispell. This could surely be streamlined by teaching xedit about spell.

We also ship every program that has been included with historical X.Org distributions. This includes well-known things like xterm, slightly less well-known things like xbiff(1), and obscurities like bitmap(1) (apparently a 1-bit-per-pixel alternative to MS Paint). A while ago, we removed some libraries which are no longer used by the modern X server, and maybe we should evaluate whether we need all of these programs too. xmh(1) is a frontend for a mail system that isn't included in base. Together, bitmap and xmh are around 300 kilobytes.

We include fonts, bitmaps and scalable, for a wide range of computing devices. In the latest versions of NetBSD, the font size will automatically scale with the screen size to support HiDPI displays as well as small mobile devices. However, we don't ship a scalable cursor theme at the moment. We're also missing high-resolution fonts for Japanese, a shame considering the popularity of NetBSD in Japan. Koruri looks interesting and is suitably small, maybe we should import it.

While we have many useful simple programs by default (a clock, a calculator, an editor, a window manager, a compositor, a terminal emulator...), we're notably missing a screen locking program for X in the default install, although we have lock(1) for the tty.

The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream.

Of course, on NetBSD, you also have the option of trying vanilla modular X.Org from pkgsrc, or using something else entirely.

NetBSD 9.4 released

martin — Tue, 23 Apr 2024 05:14:21 +0000

The NetBSD Project is pleased to announce NetBSD 9.4, the fourth release from the NetBSD 9 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.3 in August 2022, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.3 or an earlier release are strongly recommended to upgrade.

The general NetBSD community is very excited about NetBSD 10.0, the latest NetBSD release, but if for some reason you can not (or do not want to) update to 10.0, it is strongly recommended to update to 9.4. This is especially true for users still using a NetBSD 8.x release as that old release branch will be desupported by the end of April 2024.

Full release notes, including download links

NetBSD 10.0 available!

martin — Sat, 30 Mar 2024 19:55:38 +0000

The NetBSD project is pleased to announce the eighteenth major release of the NetBSD operating system NetBSD 10.0!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

If you want to try NetBSD 10.0 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Statement on backdoor in xz library

Nia Alarie — Sat, 30 Mar 2024 09:09:06 +0000

Recently, a backdoor was discovered in the xz compression library. xz/liblzma are included as a part of NetBSD and used by the project for distribution of new releases and packages.

The version of xz shipped in all stable (and unstable) versions of NetBSD predates any code changes by the author of the backdoor. NetBSD is therefore safe and unaffected by the recent discoveries. It is believed that the attack only targets Linux/glibc, but checking this allowed us to rule out any other attempts at compromising the library by the author.

The version of xz shipped in pkgsrc, however, is affected. Using xz from pkgsrc is a non-default setting on NetBSD, and requires explicit opt-in. Most users of NetBSD will not install xz from pkgsrc because the version from the base system is preferred. However, users of pkgsrc on other platforms will need to take precautions.

Regardless of NetBSD being affected or not, the discovery of the backdoor is a wake-up call and further discussion will be happening internally over how to proceed.

NetBSD 10.0 RC6 available!

martin — Wed, 13 Mar 2024 23:10:11 +0000

The NetBSD project is pleased to announce the sixth release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

Since RC1 there have been numerous changes, including major updates to external software included in the release: Postfix, OpenSSH, and the firmware used for Raspberry PI devices. Various issues with RC1 have been fixed, including installer (sysinst) crashes. Lots of architecture specific fixes happend, e.g. various toolchain changes for VAX (so it is now finaly self-hosting again), and kernel changes for macppc, netwinder, and alpha.

For RC3 only few (relatively) minor changes were made, including https certificate verification in libfetch (which is used by pkg_ad(1)), and also improvements to the EFI bootloader to better deal with booting from CD (or in virtual machines ISO images), plus lots of various bug fixes.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

RC6 fixes a few issues with the new named/bind imported for RC5 plus several minor issues.

Especially on amd64 machines please notes that we got a new DRM/KMS subsystem version, and this may lead to fallout on some hardware. Unfortunately not all known bugs from the release engineering pre-release task list could be fixed in time for this release - we will continue to improve the current state and hope to have more of them solved for the next (10.1) release.

If you want to test 10.0 RC6 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC5 available!

martin — Wed, 28 Feb 2024 19:37:19 +0000

The NetBSD project is pleased to announce the fifth (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

If you want to test 10.0 RC5 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

NetBSD 10.0 RC4 available!

martin — Wed, 7 Feb 2024 15:58:51 +0000

The NetBSD project is pleased to announce the fourth (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

This also caused the release announcement to be one of the longest we ever did.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

If you want to test 10.0 RC4 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.