What has (can) the EU Cyber Resilience Act done (do) for you?

© 2026 Peter N. M. Hansteen

The European Union Cyber Resilience Act (CRA) and its various international analogs are entering fully into force during 2026 and 2027, with new legal requirements that some have found to be perilous or challenging to software developers and possibly for open source developers in particular.

Some have predicted this legislation will be the end of open source software and the end of the world as we know it. In the present article, we will show that this is far from the case.

---

Note: This piece is also available without trackers but classic formatting only here.

---

Yes, It's Later Than You Think

As we have mentioned in several earlier articles and presentations which I will provide links to in a moment,

On December 12 2027, it's already too late. The day before, the European Union Cyber Resilience Act (CRA) will have fully entered into force.

On December 11 2027, the Cyber Resilience Act is fully in force in the European Union member states and associated countries and territories.

From that date onward, suppliers of any "product with digital elements" are required to present those products along with a full overview and insight into all components and dependencies that went into making that product.

If you are a manufacturer or supplier of any "product with digital elements" are required to present those products along with a full overview and insight into all components and dependencies that went into making that product.

Unless, of course, you are a supplier that is fine with being considered at best second rate, or even being ineligible for lucrative contracts. Selling product that has not qualified for the CE mark for its product category will simply not do.

The European timeline for phased implementation of the CRA is outlined here, among other places.

From EU CRA: It's Later Than You Think, Time to Engineer Up! (also here)

If you are interested in what this means in practical terms, for individual developers, for organizations that have taken on the free software steward role, and for other participants in the wider community or ecosystem of the IT industry, read on.

The European Union Sets the Standard From Here On

The European Union Cyber Resilience Act is part of an expanding body of legislation, which includes General Data Protection Regulation (GDPR), Regulation of the Digital Operational Resilience of the Financial Sector (DORA), and Directive on Network and Information Systems (NIS2), that regulates information technology and products with digital elements in the European Union, associated states and territories.

The underlying motivation is to ensure the safety, wellbeing and civil rights of inhabitants of the EU, associated states and territories. It is important to keep this in mind as the basic driver behind the regulation.

One the face of it, initiatives to ensure the safety of individuals and businesses should not be controversial. Development of new technologies lead to changes in society that neither technologists, their customers nor the politicians they elect had been able to anticipate.

We will mention some key incidents in a few moments, but taken together these incidents made it clear that there was a need to come up with well defined legislation and a firm but reasonable enforcement regime.

In the area of cyber security and digital resilience, for a long time the specification and standardization work was fairly well in sync between the European and US efforts for all the obvious reasons.

Early on, the USA was the first to enact formal legislation for the subject area in the form of the US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity (2021), and the EU finally enacted their version of the legislation as the EU Cyber Resilience Act (CRA) in 2024. For both sets of legislation the plan was to have the specific parts enter into force gradually and in sync across the Atlantic.

However, it took the second Trump administration one year and nine days to rescind the US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity leaving the specifications and emerging standards as optional only for projects and procurement under federal authorities of the United states.

The European Union, on the other hand, has not let up its efforts. This means that going forward, it is the European Union Cyber Resilience Act (CRA) that defines the parameters for those of us who develop products with digital elements (PDEs) intended for any international market that includes the European Union and associated states and territories.

Let's move on to what the practical consequences will be for various categories of people and organizations as the legislation enters into force.

We will take the boring parts first, move on to the scary things next, before we finally get to the fun parts.

Manufacturers, Stewards and Developers

Under the CRA, people and organizations that are involved in producing or marketing products with digital elements can be classified into several categories. For contexts where open source software plays a role, the roles that are of the most interest are,

Manufacturers: Businesses that put products on the market to be available in the EU, defined as

a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge (from CRA article 3 (13)

Crucially, the context here is that these activities are part of commercial activityCRA Article 3(22).

Open Source Stewards: Organizations that coordinate open source projects, typically foundations (not for profit corporations), defined as

a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products (from CRA article 3 (14) )

Open Source Developers and Maintainers: People who write and maintain open source software. While the CRA does not include a definition in this case, the relevant text is

for the purposes of this Regulation, the development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility. (from CRA recital 18)

As we can see, there are three distinct categories, each with their specific roles and obligations.

Your Duties as an Open Source Developer or Steward

If you are an individual open source developer, I hope by now you are reassured by the quote from CRA recital 18 that you are in fact not under any formal obligation to do anything in particular. You are free make any changes to your workflow you want as a developer, on a completely voluntary basis.

That said, the emerging legal requirements do offer opportunities that may be worth exploring. We will come back to those shortly.

Open Source Stewards, under any reasonable interpretation of CRA article 3 (14) will usually be a not for profit organization or foundation such as the FreeBSD Foundation, which operates with a purpose to support the activities of the project. Such organizations have some measure of responsibility to maintain sufficient infrastructure and organization to support such activites as bug and incident reporting and following up on any security relevant matters raised by manufacturers, the reporting authorities or the general public.

It is useful to look up CRA article 24 and recitals 17, 18 and 19 for more nuance.

On the Other Hand, If You Are a Manufacturer

As you would expect, the practical and financial responsibility for any product placed on the market lies with the manufacturer that produces and markets the product.

The manufacturer is responsible for ensuring that the product is suitable for its intended use, that it conforms with any requirements specified for its product category in the European Union, including any required specifications for its intended use. The CRA somewhat extends the requirements for product information to be made available on request, including a Software Bill of Materials (SBOM) that specifies components of the product and their dependencies.

Once a product is on the market, the manufacturer is responsible for the continued security of the product in operation, including reporting security relevant bugs and incidents to the designated authorty.

The exact parameters of the enforcement regime are still work in progress, but potential sanctions for non-compliant products and manufacturers include, depending on the severity of the matter, mandatory recall of marketed products and fines up to whatever is the greater of 15 million Euros or 2.5 per cent of the manufacturer's worldwide annual turnover for the preceding financial year (see CRA article 64).

But Why? Why Now?

So why was this legislation needed at all? And why does it come into force now?

Explaining why legislation of the Cyber Resilience Act mold was needed means that we will need to look at some history. There is a sequence of events that lead us to where we are, and that shaped how we see ourselves in the context of software security and software quality.

It is worth keeping in mind that during a longish stretch of recent times, software has been poorly understood by the public, generally disregarded as unimportant, or in the cases where it was at least considered not unimportant was considered to be trade secrets by the dominant players in the field, and consequently off limits to any real security or quality inspection.

One very visible consequence is that a large part of what labels itself as IT security or cybersecurity centers around selling tools scanning whatever data they can get their hands on for an ever-increasing set of malware signatures, or in the case of network traffic captures, signs of malicious activity such as probing for common misconfigurations or bugs that are known to be exploitable.

On the other hand, in the open source parts of the industry, where the source code for your system is available for study, it is possible and even encouraged to focus on code quality and code correctness.

With the source code within reach, outside reviews can and will happen if your code is interesting enough to be considered usable in environments that are different from your own.

With source in hand, some projects have even gone to the extra steps of not only improving code quality and correctness, but even creating mechanisms that would make even currently unknown bugs and misfeatures in the code harder to exploit. It is fair to say that the OpenBSD project has been particularly innovative in exploit mitigation and prevention.

The role that code quality plays in making products with digital elements robust and safe has not been lost on the people who have worked to formulate the CRA and the best practices that we are expected to adopt.

We will come back to the best practices, but first, a quick look at some recent history.

Historically, 'Just a bit of typing'

Software is a relatively recent phenomenon. For a long time, you could credibly say most of its existence, software was poorly understood by society and industry at large.

There was a time -- and I am old enough to remember that time -- when software was considered a minor, somewhat irritating but necessary, component in IT deliveries.

On the more extreme end of things, you would occasionally hear that software was not at all important, literally just a bit of typing.

All the while it was ever more clear to developers and practitioners that the software was what made all that expensive hardware useful. But software was all ephemereal to most and in almost all cases the source code was secret, and the customer was expected to just accept whatever came you way as-is.

That perception changed over time, and during recent decades it is no longer in doubt that the software industry is just that, an industry in its own right.

Still, in the pre-Internet age, keeping your source code hidden from the world as a trade secret was seen by large parts of the industry as the key to generating revenue and necessary and even sufficent for an acceptable level of security.

But Then Suddenly Software Turned Important

Then, as some of us still remember, the Internet happened.

Few people realized it at the time, but this was the time in history when two important things happened at roughly the same time.

For one, it became obvious to developers at least that the infrastructure we all have come to rely upon owes its strength and resilience to the fact that it consists mainly of software that was built on standards built on rough consensus and working code, code that was open source.

Instead of 10,000 chimps typing ...

The other thing that happened, was that software products became exposed to the Internet, those products found themselves facing the full force of the entire world banging away at their keyboards.

Some of those keyboards were operated by people who intended to do bad things.

A significant subset of the devices that appeared on the Internet ran software that was clearly not designed for secure operation in a connected environment.

Eventually, bad things started happening.

Over the years, eventually enough episodes piled up that software security, sometimes discussed under other labels, started becoming an issue.

During the twenty-tens and -teens, we had several incidents where software bugs were tickled enough to lead to costly and embarrasing episodes.

Some of these episodes were grave enough that the powers that be (the kind wearing suits) discovered that software was indeed something they needed to care about.

At the time, there were commentators from both camps who seemed surprised to learn that open source and closed source software both demonstrably had exploitable bugs.

Dependencies Became A Thing

In the early days of the Internet age, and to some extent still, we have often been faced with claims that open source software could either never be as secure as proprietary software, or that open source software was inherently more secure than the closed source kind, because "given enough eyes, all bugs are shallow".

Both assertions fail because even without access to source code, it is possible to probe running software for vulnerabilities, and on the other hand the shallowness of bugs depends critically on the eyes looking being attached to people with sufficient competence in the field.

The public reactions to a couple of security incidents during recent years that generated a flurry of largely uninformed punditry, are worth revisiting for the lessons that can be learned.

Some incidents of note are,

The Solarwinds supply chain incident, also known as SUNBURST (2020) - One of the most widely publicized yet mostly quite poorly understood security incidents in recent years emerged when it was revealed that adversaries unknown had been able to compromise the build computers where the binaries for their widely used network management software was built for distribution.

The SANS institute has produced a fairly thorough writeup of the incident, which breaks down as follows:

The first stage of a multi-stage compromise kit was included in binary distribution packages, complete with authentic signatures from the build system, that were largely put directly into production environments by network admins everywhere. The malware then went on to explore the networks they landed in, and through a process that made heavy use of crafted DNS queries and other non-obvious techniques, the miscreants were able to compromise several high security government and enterprise networks.

Several open source component supply chain incidents (2020 onwards) - Soon after the SUNBURST incident several incidents occured where popular open source components that other systems pulled in as dependencies started malfunctioning or were suddenly unavailable, causing complete malfunctions or loss of functionality such as a web service suddenly refusing to interact with specific networks.

The sudden breakage in open source components caused quite a bit of uproar, and predictably the chattering subset of the consulting class set about churning out dire warnings about the risk of using open source of any kind.

Watching from the sidelines it struck many open source oriented professionals, myself included, that the combination of these incidents carry an important lesson. It is obvious in a modern environment we suck in upgrades automatically and frequently, and that no untested code should ever be deployed directly to production.

Blind trust versus the right to read (and educate yourself) and the right to repair - In the case of proprietary, binary-only software, you have no choice but to trust your supplier and that they will address any defects in a timely manner. The upshot is that with proprietary, binary-only you do not have access to two important features of open source software: The right to read and study the code, and the right to repair any defects you find, potentially saving yourself potential service shutdowns or workarounds while the secret parts of your system get fixed elsewhere.

The lesson to be learned is that you need to run quality assurance on your supply chain. You may choose to trust, but you still need to verify. That goes for open source and proprietary software both.

These episodes spurred several things, one being memes like

(XKCD #2347, please also read the explainer), which lead to the common belief that supply chain management and the subtopic dependency management is mainly a problem that concerns open source software.

As we will see, that assertion does not hold. Even with products that are made up of proprietary parts that their manufacturers want to treat as much as possible as trade secrets, we know that no project is an island.

Whether you let others see the code you wrote or not, the software does not exist in isolation.

The XKCD comic struck a chord with open source developers, who at the time were a lot more in tune with the world of software dependencies than most other people.

By the way, this slightly modernized version

is likely more in tune with the day to day experiences of developers and maintainers of products with digital elements (PDEs).

Or you may feel this is more appropriate:

With all this as the backdrop, now let us return to the base starting point of it all: our source code. We will see how this all fits together to make an ideal setting open source as proper engineering.

Upping Your Engineering Game

For individual developers, the question becomes something more along the lines of "Do you know what your code does?", or even "Do you know everything your code does?".

To put it bluntly, whether you answer to either of these is a clear yes or no determines whether you are just a coder or an engineer who codes.

The purpose of this session is to help you move towards becoming the latter. To start you upping your engineering game.

To set the stage for what real engineers (should) do and to keep focus on the importance of doing things right, the anecdote of the Canadian engineers' iron ring is a useful reference.

So let's ask the question,

Dear developer, do you know what your code does?

Your answer is likely to be along the lines of

Sure, I wrote it all. I know what it does.

Unless you vibe coded the thing, that is. But let's leave that particular set of circumstances for another time.

The answer I wrote it all. I know what it does is, however, unlikely to be totally accurate. Unless you are doing extremely low level stuff and your code speaks directly to the hardware, your code more likely than not also pulls in and utilizes dependencies such as system calls and library functions that provide the foundation of functionality that makes the code you wrote work.

Knowing your dependencies and what role they plain in making your code work is a significant part of delivering proper quality.

As I mentioned earlier, no project is an island.

Whether you let others see the code you wrote or not, the software does not exist in isolation.

Summing up so far,

• We write software
• Which depends on other software
• Which interacts with other software
• Which again interacts with other components (hardware, humans)
• To run important stuff
• Nothing exists in actual isolation – No project is an island

So what we do is important. What do we do about that?

Learn From Those Who Build Important Things

One way to handle the situation is to look at what other people who build important things do.

In other fields, the term Bill of Materials, or BOM for short, is a familiar term. The Bill of Materials is a document or set of documents that lists all component parts of a delivery.

This is the kind of document that becomes crucial in contexts where the procuring organization is geared toward accounting for everything and auditing when the supplier least expects it.

One such context could be when your organization has landed a contract to supply a backhoe, an armored personnel carrier or even a ship, and the contract requires you to specify component materials used, down to the nuts and bolts level.

For an example of the scale of things we are talking about, consider this ultra high level view of an item that was delivered to the UK Royal Navy, one aircraft carrier HMS Queen Elizabeth:

Your delivery would not be considered complete without the Bill of Materials or Manifest, even for a thing this size.

In practice, the BOM for the HMS QE and similar-sized projects would be a collection of BOMs with specifications for each of the multitude of component deliveries that make up the whole. Each supplier would be required to come up with a Bill of Materials for their delivery.

A much referenced anecdote has it that one aircraft carrier recently commisioned by the US Navy came with a BOM with more than a million entries, ranging from "(some number of) 1/4 inch bolts" to "1 Nuclear Reactor".

It is likely that the nuclear reactor came with its own Bill of Materials, possibly with somewhat restricted circulation.

For physical deliveries to organizations of some stature, a Bill of Materials has been a standard part of the process across industries as an important part of quality assurance and a fundamental part of maintenance processes.

Software, on the other hand, has traditionally not been subject to that kind of scrutiny.

What Do Engineers Do?

In other fields of engineering, the process runs roughly like this:

You design your product, make detailed plans and descriptions of how to build the thing.

While planning and building, you keep track of all parts and components.

A Bill of Materials (BOM) for a pump that could well be a part of the HMS Queen Elizabeth could look like

Your plans and design documents will likely undergo changes during product development and assembly.

For each delivery, you create a Bill of Materials that is a required and essential part of the delivery.

The Bill of Materials (BOM) lists all component parts, to the detail level required for running maintenance.

The BOM typically also references and serves as reference for maintenance documentation.

As an aside, it is likely worth noting that the US Department of Defense's need for structured text markup in processing inventory information such as bills of materials was one of the more important drivers, albeit not the only one, behind the creation of SGML, the direct precursor to HTML and XML.

Again, for a long time, this kind of engineering practice was not seen as a requirement for software deliveries.

Libre Software Has Package Management Already

Handling dependencies in software is not a new thing. You probably poke around for dependencies yourself when you start looking into a new project.

You will start looking into the source code files in your project, any libraries or tools needed to build the thing would be nice-to-knows. Once you have the thing built, it becomes interesting to know what other things -- libraries, suites of utilities, services that are required to be running or other software frameworks of any kind -- that are required in order to have the thing run.

So basically, any item your code would need comes out as a dependency, and you will find that your code has both build time and run time dependencies.

Those terms will be quite familiar to users and the developers of the package manager systems for the various open source operating systems. The very same items you would recognize from a listing of package dependencies in a package management tool will turn up in our Software Bill of Materials too. Depending on the specific tool and options you use, the SBOM could contain additional information that may not be entirely relevant in a package manager context.

Under any circumstances, with package systems in place, and even vulnerability scanners available to scan for unsecure code at rest or while running, the free and open source software communities were in fact well positioned for the legal requirements when they hit. Even more, the lessons learned from package management came in quite useful in meeting and satisfying the updated requirements.

Every free operating system, and in fact most modern-ish programming languages come with a package system to install software and to track and handle the web of depenencies. You are supposed to use the corresponding package manager for the bulk of maintenance tasks.

So when the security relevant incidents hit, the open source world was fairly well stocked with code that did almost all the things that were needed for producing what became known as Software Bill of Materials, or SBOM for short.

Introducing: A Software Bill of Materials (SBOM)

So what would a Software Bill of Materials even look like?

Obviously nuts and bolts would not be involved, but items such as the source code files in your project, any libraries or tools needed to build the thing would be nice-to-knows. And once you have the thing built, it becomes interesting to know what other things -- libraries, suites of utilities, services that are required to be running or other software frameworks of any kind -- that are required in order to have the thing run.

The information is there in our code, and with development tools and code scanners a developer is well placed to poke around.

The next challenge it to take that information and present it in a way that conforms with the legal specification and is presented in a way that is usable for stakeholders that are not developers.

Thanks in large measure to the open source heritage of the specifications and tools, both of the commonly used SBOM specifications (SPDX and CycloneDX) consider information on licenses used in a file or project as tagging and tracking relevant items.

The tools we describe have some measure of support for tracking and reporting on licenses in use. This can be useful for flagging licenses that may be mutually incompatible or even incompatible with your organization's business goals.

In addition to adding another set of tools to the quality assurance suite, the name of the SBOM game is compliance with the legal requirements set out in the CRA and its analogues. The task here is not only to generate the information -- that's the relatively easy part -- but also to present the information in a way that is understandable and actionable to stakeholders who are not themselves software developers.

We're Real Engineers Now, Sparky! We Have Tools

As I hinted at earlier, there are tools available for all of this. If you want to go on and explore for yourself, I would recommend going to the awesome-sbom site, which offers a curated collection of SBOM resources and tools hosted as a Github repo.

There are a large number of tools available, with varying feature sets. In addition to the free tools you find via that collection, several tool suites exist that are exclusively commercial or with free trial or reduced features set versions out with full features available only to paying customers.

The tool set I found the most accessible for my own poking around was the combination of syft for generating SBOMs and bomber for display and presentation.

Another popular and quite capable tool is cdxgen, which supports a significant number of langages and BOM formats.

The home pages for those tools and numerous others are linked from the awesome-sbom collection.

As you can see from that page, there are several SBOM formats around, with standardization and interoperability efforts in progress.

These efforts have however not reached the point where the competing and to some extent complementary SBOM spesifications (SPDX and CycloneDX) have object definition parity, but for large subsets of possible SBOMs, conversions are possible.

For the most part, more common tools support both specifications.

Your New Build Artifact, the SBOM

If you are a BSD developer or other free software developer, getting started on your CRA compliance journey could be as easy as installing a suitable SBOM generating tool and adding the generating step to your build pipeline.

Unfortunately, more often than not you will find that the best of breed SBOM tools come witout a man page, but tend instead to stick their documentation in web pages somewhere close to their source code repositories.

Your first move to start exploring SBOMs for your code could be as simple as changing to the project directory and running the command

$ cdxgen -t c .

that is, assuming your project is a C language one, and take a peek at the generated bom.json.

The output becomes somewhat more legible if you run it through a pretty printer such as jq.

Once you have studied the results, and possibly gained some new insight into your project, the logical next step is to include a similar command in your build workflow.

Several of my colleagues have noted that when you come to an existing project, just generating an SBOM, especially if the project does not include one alread, gets you more and deeper insight into what the code is about.

In almost all cases, it will also be useful to have your build and deploy setup feed the SBOM to an SBOM management tool such as DependencyTrack.

That tool is one of those rare pieces of free software that is also quite appeling to stakeholders who are not themselves developers.

The Software Bill of Materials as a Tool for Insight and Transparency

The purpose of the CRA and related legislation is to make sure products that are put on the market are safe to use.

The Software Bill of Materials is a key tool, for quality assurance in development, and for any formal certification processes may be needed for some classes of products with digital elements.

As we mentioned earlier, unless your software only interacts directly with the hardware it runs on, even proprietary, trade secret protected products have dependencies. Those dependencies may be for open source and free software or even other proprietary products.

The CRA has language that makes it possible to keep the SBOM information under wraps and available only upon request from stakeholders with a need to know.

For developers, stewards and manufacturers with products that are all or mostly open source, the SBOM, by contrast, is a tool for transparency as well as quality assurance.

It should be fairly obvious that for transparency, open source based products have the clear advantage.

For Manufacturers and Suits, GUI Dependency Tracking Tools

So far we have focused on the background and covered some of the tools that are available for developers who work on creating and maintaining the code.

However, for essentially any product will be relevant for CRA compliance, several parts of the organization with people who are not developers need to be involved, and they will need tools.

One one fairly popular SBOM management tool is DependencyTrack, created and maintained by The OWASP Foundation, available under the Apache 2.0 license. DependencyTrack comes with a web frontend that provides easy overview of uploaded SBOMs, including views such as dependency trees, CVE and known vulnerability listings, all with intuitive color coding schemes. It also interfaces well with various build processes, including common CI/CD systems.

Other tools with similar feature sets may be emerging, but I would recommend setting up a DependencyTrack instance for internal use for all teams who are starting to explore SBOMs and dependency tracking.

The State of Play in the BSD Projects

The state of CRA readiness in open source projects varies. A good chunk of the tools and education work has been done under the Linux Foundation umbrella, and the FreeBSD Foundation is sponsoring CRA readiness activities in their project. For other individual projects it is perhaps most appropriate to say that awareness and readiness is improving.

The traditional development workflow in the BSD projects tends to be that base system components that have their upstream outside the projects are periodically imported into the project source tree as a fork off the origin and integrated with any necessary local changes. In between largely manual code import and review during the development of a specific release, any code in the tree is treated as integral to the self-contained project.

Traditionally, and I think still for all the major BSDs, the principle that all the tools that are required for building, developing and maintaining the operating system itself should be part of the system and preferably in the default install sets.

If you are a part of the OpenBSD community, you will be familiar with the phrase

"/bin is full."

which to some extent applies to all the BSDs. This should be taken to mean that including more items in the base system is a decision that is not taken lightly.

For SBOM tools, this becomes an important barrier, since the majority of the tools available are written in and for the younger languages such as go, java, javascript, python and others, while the Unixlikes are mainly C with a smattering of other languages such as perl and, of course, shellscripts.

Several of the more popular and capable tools such as syft or cdxgen are able to generate SBOMs from C source, and could be set to generate SBOMs for entire operation systems, given sufficent memory resources. However, since the tools are not themselves C code (syft is 98.9% Go, while cdxgen is 95.7% Javascript) it is unlikely that any of these tools will be added to the base system in any BSD.

Perhaps at least partially for those reasons, as far as I am aware, NetBSD and OpenBSD have not announced any specific activity intended to reach CRA compliance.

Manufacturers who base their products on OpenBSD or NetBSD would have the option to generate SBOMs for the base system, or if they make local modifications, generate the data from their variant builds along with data for any third party or locally developed additions.

Among the three major BSD projects, apparently FreeBSD is the one with the more public stance on the legislation. In a blog post dated 25 February 2025, Getting ready for the Cyber Resilience Act, the FreeBSD Foundation outlines the initiatives it sponsors in order to make FreeBSD CRA ready.

Tooling for SBOM generation, NetBSD pkg-config, leveraging existing package management technology, is being prepared for inclusion in the default FreeBSD install. The full toolchain as well as a full SBOM for the system itself is slated to be included in FreeBSD 16, which is expected to be released roughly in time for the CRA enters fully into force.

Yes, the Future Is Bright If You Engineer Up

If you have read this far, you have probably realized that European Union Cyber Resilience Act (CRA) and its various international analogs do not spell the end of free and open source software or the world as we know it.

Rather, the new legislation creates a legal framework that is, at least potentially, extremely beneficial to well engineered free and open source software.

The CRA is a sign that at least in the European Union, software engineering is now treated as a proper branch of engineering.

Software engineers are now considered proper engineers, and we are expected to engineer up and rise to the challenge. Free and open source software engineers are used to and welcome transparency, and the CRA does not place any further burdens on the engineers who offer their work openly and transparently to the world.

The key for BSD developers and other software engineers to make sure we have earned the trust that is afforded to us as proper engineers.

---

I would in particular like to thank Alice Sowerby, Pierre Pronchery and Bjørge Solli for comments with useful input on this article.

---

Resources for Further Study and Development

This is a lightly curated list of resources for further study:

Linux Foundation Training:
Automating Supply Chain Security: SBOMs and Signatures (LFEL1007) a short but information- and reference-filled introduction (free, requires registration, gives you a badge at the end)
Understanding the EU Cyber Resilience Act (CRA) (LFEL1001) Focused on the EU CRA, gives an overview with lots of useful references, nominally a 1 hour course worth taking

Cyber Resilience Act at the official European Union site (full text of the act is here

European Union Cyber Resilience Act (CRA) resources page at the Open Source Security Foundation (OpenSSF)

The Software Bill of Materials home page at NTIA is the mother ship of SBOM documentation

Browse OWASP CycloneDX for all things about the CycloneDX specification and related tools, also their CycloneDX tool center

Browse the System Package Data Exchange specification (SPDX) for all things SPDX (supported by the Linux Foundation), including copious linked reference material

awesome-sbom is a curated list of SBOM tools and resources (mainly for techies and engineers(

Awesome CRA Compliance is a curated list of CRA compliance resources (mainly for management and legal)

Brewing Transparency: How OWASP's TEA Is Revolutionizing Software Supply Chains is a summary of recent work on OWASP Transparency Exchange API (TEA)

SBOM buyer’s guide: 8 top software bill of materials tools to consider is a readable overview of (some) SBOM tools

Olle Johansson's FOSDEM presentations are among several good SBOM talks at that conference (search the site for more)

Peter N. M. Hansteen: Open Source in Enterprise Environments - Where Are We Now and What Is Our Way Forward? (2022, also here) has some insights on how open source software plays a crucial role in enterprise environments and elsewhere

Peter N. M. Hansteen: No Project Is an Island: Why You Need SBOMs and Dependency Management (also here)

Peter N. M. Hansteen: EU CRA: It's Later Than You Think, Time to Engineer Up! (also here)

Peter N. M. Hansteen: EU CRA: It's Later Than You Think, Time to Engineer Up! (slides)

Peter N. M. Hansteen: What has (can) the EU Cyber Resilience Act done (do) for you? (this article) (also here, slides)

---

What has (can) the EU Cyber Resilience Act done (do) for you? is © 2026 Peter N. M. Hansteen (published 2026-06-19)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

OpenSMTPD Is The Mail Server For The Future

Image credit: the OpenSMTPD project

© 2026 Peter N. M. Hansteen

The SMTP mail server for the 21st century and onwards is OpenSMTPD, which is developed as an integral part of OpenBSD, but available in a portable variety too.

It was one of those things that I had fully intended to do years ago, but I only got around to actually doing once there was a definite deadline to get it done.

The time has come, as OpenBSD 7.9 will leave the exim package behind, and exim users will need to find a replacement before upgrading. This article describes my transition to OpenBSD's own OpenSMTPD mail server.

---

OpenBSD 7.9 will leave the exim package behind, and exim users will need to find a replacement.

OpenSMTPD (smtpd) is in the base system.

---

When OpenSMTPD was first introduced in the OpenBSD base system in OpenBSD 4.6 in October 2009, I had already been running a mail service for some years.

At the time I still found it convenient to keep using exim as the real mail server, protected by OpenBSD spamd in the incoming signal path and with a combination of spamassassin and clamav for content filtering.

It seemed quite tempting to me to play around with at the new smtpd at the time, but the initial version of the new mail server was not yet considered quite ready for prime time.

---

Note: This piece is also available without trackers but classic formatting only here.

---

The pace of development was quite hectic in the early years, and by the time smtpd replaced the classic sendmail as the default mail server in OpenBSD with the November 2014 OpenBSD 5.6 release, I had just completed the third edition of The Book of PF and I was interested, but the writing had been quite a drain on my energy.

And of course, the mail server setups I had running for myself and friends I thought of as complex enough that moving to something else would require quite some preparation and testing. So I would leave looking into the new mail server software properly for another day, soon to come, I was sure.

An Old Setup, Maintained With Much Love and Care

There are some hints of what that setup did (and still does) in the 2012 piece In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes In Play - A Full Recipe (also tracked, prettified), but the main features are:

• Two (originally three) separate sites, each with their own domains, where the other site(s) provide secondary MX duty for the other(s), each with a spamd-instrumented OpenBSD machine as the Internet-facing part of the mail setup
• The OpenBSD machines perform spamd greylisting and greytrapping, but also provide content filtering on behalf of another set of domains with their own, not necessarily Internet-exposed, mail servers that receive the filtered mail relayed to them by the Internet-facing mail services.

This setup, with OpenBSD spamd in a greylisting and greytrapping setup in front and content filtering as the second stage before finally relaying to the protected mail hosts, worked well enough that we simply kept the systems running with only routine system and package upgrades and minor adjustments to configurations as needed.

In short, domains to be served came and went, but the spamd, exim and clamav+spamassassin combination stayed, on the ever reliable OpenBSD platform.

Time To Move On, Wait, Then Finally ...

Over the years, there were several episodes with medium to severe security flaws discovered in the exim codebase, but the OpenBSD package was generally well maintained and fixes tended to appear within a reasonable time.

From time to time OpenBSD developers and port maintainers discussed dropping support and removing exim from the package system, but it was only in early 2026 it finally happened.

OpenBSD 7.9 will ship without an official exim package.

So it was finally time for even this holdout to move to something else.

And Of Course, A False Start

Other OpenBSD users had kept telling me how good OpenSMTPD had become, so I decided now was the time, so I dug out some old notes and started experimenting.

Those old notes turned out to be utterly useless, and for a reason: The OpenSMTPD 6.4 release was the result of a major code overhaul that also changed important parts of the smtpd.conf syntax.

Unfortunately a majority of the third party guides out there that turn up early in search results still use the old syntax, and as a consequence, are useless, at least to users on OpenBSD or other platforms that have kept their code reasonably in sync. A useful rule of thumb is, if you find yourself reading an OpenSMTPD guide that is dated before 2020, do yourself a favor and move on to something newer.

---

If you find yourself reading an OpenSMTPD guide is dated before 2020, do yourself a favor and move on to something newer.

---

The Task At Hand: The Analysis

But to the problem at hand. The setup I was setting out to convert, was one that needed to accommodate

• Inbound mail for users in the local domains, where we are the primary mail exchanger
• Inbound mail for users in the domains where we are the secondary mail exchanger
• Inbound mail for the users in the domains where we are the primary public-facing mail exchanger, but where we actually only relay after greylisting and filtering
• Outbound mail from the local domains
• Outbound mail from networks we have chosen to trust enough to relay for

The mail exchanger (MX) records for all domains involved were already in place, as was other relevant DNS information such as SPF, DKIM and DMARC records. TLS certificates and a regime for maintaining them was already in place, using LetsEncrypt tools.

That analysis converted to smtpd.conf logic would be:

• We keep the existing /etc/mail/aliases file, the formats are compatible
• OpenSMTPD conveniently has tables, which can be either simple lists or key-value pairs. Our tables are:
  
  • domains_local lists the domains we receive mail for to handle locally
  • relay_for_domains lists the domains we only filter for, then relay to
  • domain_relays is the list of domains and their final destination mail exchangers as list of key-value pairs
  • relay_from_ips is the list of IP addresses and networks we allow relaying for

Now The Actual Implementation

So I set to work from that specification, and at the end of that afternoon I had reached the conclusion that

• setting up for TLS was the easiest, with simple pki statements
• listen statements actually do the work in very limited space
• routing to local delivery and forwarding is easy with a combination of action and match rules
• for filtering, clamav had not actually been of much use to my users (no Windows users among them), and that the filtering options that made use of spamassassin for the back end were either not functional or I was too dense to make any sense of them.
  I ended up testing a modern alternative, rspamd, which is available via the OpenBSD package system.
• dkimproxy looked like a good candidate for signing outgoing messages, so I tested that for a while, but on the advice of Martijn van Duren, I switched to dkimsign, which is available on OpenBSD as the package opensmtpd-filter-dkimsign.

In addition to smtpd, which is already in base, this configuration requires the packages opensmtpd-filter-dkimsign and opensmtpd-filter-rspamd.

Installing both via pkg_add have the packages pull in all required dependencies.

With the prerequisites in place,

disable and stop exim
doas rcctl disable exim && doas rcctl stop exim

disable and stop clamav
doas rcctl disable clamav && doas clamav stop clamav

disable and stop spamassassin
doas rcctl disable spamassassin && doas rcctl stop spamassassin

At some point, you should remove the packages with

doas pkg_delete packagename

and follow the steps outlined in the package delete message.

Don't remove the exim configuration, though, until you have copied the useful parts across to your new /etc/mail/smtpd.conf.

I ended up with this configuration (lightly edited for brevity)

---- /etc/mail/smtpd.conf
table aliases file:/etc/mail/aliases

table domains_local {
"bsdly.com",
"bsdly.eu",
"bsdly.net",
"bsdly.no",
"bsdly.org",
"bsdly.se",
"nxdomain.no",
# plus a lot of other domains, elided here for brevity
}

table relay_for_domains {
"nuug.no",
"blug.linux.no"
# again more domains in the real smtpd.conf, left out here
}

table domain_relays {
"nuug.no" = "smtp://mx1.nuug.no",
"blug.linux.no" = "smtp://mail.lamasti.net"
# again more domains in the real smtpd.conf, left out here
}

table relay_from_ips {
127.0.0.1
::1
# The rest are fictional, RFC5737 and RFC3849
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
2001:DB8::/32
}

filter "rspamd" proc-exec "filter-rspamd"
filter dkimsign_rsa proc-exec "filter-dkimsign -d bsdly.net -s x -k /etc/mail/dkim/private.rsa.key" user _dkimsign group _dkimsign

pki skapet.bsdly.net cert "/etc/mail/certificate.pem"
pki skapet.bsdly.net key "/etc/mail/privkey.pem"

listen on socket

listen on all port 25 tls pki skapet.bsdly.net filter "rspamd"
listen on all port 465 smtps pki skapet.bsdly.net filter "rspamd"
listen on all port submission tls pki skapet.bsdly.net

action "local_mail" mbox alias <aliases>
action "relay_domain" relay domain <domain_relays> filter "rspamd"
action "outbound" relay filter dkimsign_rsa

match from local for local action local_mail
match from any for domain <domains_local> action local_mail
match from any for domain <relay_for_domains> action relay_domain
match from src <relay_from_ips> for any action outbound
match from local for any action outbound
----

The specific domain names and IP addresses will be different for the secondary site, as it will for any configuration you will set up.

After some logs and messages observation, I also ended up with minor modifications to the rspamd config,

---- /etc/rspamd/local.d/actions.conf
reject = 10; # final reject
discard = 15;
add_header = 6; # mark spam
greylist = null; # do not greylist, we have spamd for that

# Custom action (referenced by force_actions), no own threshold
phishing = {
flags = ["no_threshold"];
}
----

That is the entire configuration. With the somewhat longer list of domains and networks, the net length of my configuration now is

$ grep -vc \# /etc/mail/smtpd.conf
104


104 lines, while the previous exim config with comment lines stripped out ran to

$ grep -vc \# /etc/exim/configure
380


380 lines.

The smtpd.conf configuration is readable on par with pf.conf, with similar readability features.

At any time after installing the packages and disabling the previous services, enable and start the new services.

To (re)enable smtpd as the default mail server after running with exim, run

$ doas /usr/local/sbin/exim-disable

to restore /etc/mailer.conf to its original state.

If all else fails, you can easily retrieve a pristine version from the OpenBSD CVS.

To enable the new services, run

$ doas rcctl enable smptpd && doas rcctl start smtpd
$ doas rcctl enable redis && doas rcctl start redis
$ doas rcctl enable rspamd && doas rcctl start rspamd


You should see activity fairly soon by monitoring /var/log/maillog, such as

$ tail -n 500 -f /var/log/maillog


When you are satisfied that mail flows in and out and is relayed where you want it to, it is safe to remove the exim, clamav and spamassassin packages and follow the instructions in the pkg_delete messages to free up some space.

And yes, considerably more complicated configurations are possible, especially in the filtering department.

But I was pleasantly surprised at both how simple the transistion has proven to be and the prospect for having truly maintenance and enhancement friendly setup going forward.

The transition process has showed me that the OpenSMTPD product is solid, like the wider OpenBSD environment. Making OpenSMTPD the default mail server software was no doubt one of those extremely good decisions the OpenBSD project has made, and even latecomers like myself applaud the decision.

OpenSMTPD and OpenBSD both are characterized by their developers' ability to not only learn from earlier iterations of development of the operating system and the mail server component, but also to come up with new, and some times radically different, approaches to known problems that result in a more secure and more useable product. To my mind, this is the mail server and the operating system for the future.

If you are interested in setting up smtpd with more filters or other ones, quite a few are available, including such things as opensmtpd-filter-dnsbl, which pulls in DNS blocklists from the sources you specify.

OpenSMTPD is available on a wide variety of platforms, including various Linux distributions and BSDs such as FreeBSD via its -portable variety.

I have kept this configuration rather minimal, mostly because in my experience, the greylisting and greytrapping spamd is a very efficient and low maintenance outer shield for any mail service. If you are interested greytrapping, the infrequently updated Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (also tracked, prettified) provides more reading material via its numerous links than you could reasonably take in during even a long evening.

If you would rather have a book that covers more networking topics with OpenBSD and FreeBSD as the platform, and includes a fairly extensive treatment of spamd, The Book of PF, now in its fourth edition, is for you.

Good night and good luck!

I want to thank Martijn van Duren for useful advice while working on this article.

---

OpenSMTPD is the Mail Server for the Future is © 2026 Peter N. M. Hansteen (published 2026-05-15)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

---

The implementation of the Carrier Pigeon Internet Protocol, RFC1149, 25 years later

© 2005, 2026 Peter N. M. Hansteen

Historical note: We implemented the Carrier Pigeon Internet Protocol, RFC1149, with the full scale test performed on April 28, 2001. The following are my lightly edited notes for a talk I gave to the Adelaide Unix user group in October 2005 on the way to participating in the AUUG 2005 conference in Sydney with the first PF tutorial, which in turn is a precursor to The Book of PF (now in its fourth edition).

---

Note: This piece is also available without trackers but classic formatting only here.

---

Good evening. My name is Peter Hansteen. I was part of the project group at the Bergen Linux User Group which was the first, and to my knowledge the only group to implement and test Internet communications via avian carriers as specified in the internet draft standard called RFC 1149.

In fact, my laptop - not this one, but a Toshiba which I used every day for another couple of years after the RFC1149 implementation, is probably the only computer in existence which has been pinged via carrier pigeon.

Now the obvious question is, why would anyone want to do such a thing? Well, the purpose of this talk is among other things to answer that question, but first I think it will be useful to briefly explain what an RFC is, and how the Internet standards process works.

This is a fairly technically oriented audience, so I assume you have seen some RFCs and heard references to these documents. Anyway, the RFCs, actually "Requests for comments" are not formally standards, but quite a lot of them would pass for one. A large number of RFCs are either "Current best practices" or "Recommended standards". The standards, recommendations and best practices codified in the RFCs are created and maintained by the Internet Engineering Task Force, which among other things holds conferences three times a year in locations all over the world and acts as the coordinating force for technical matters related to the Internet. You can read all about it at the IETF web site https://www.ietf.org.

The last time I looked (on October 7th, 2005), there 4234 RFCs in total, the last one dated October 2005, while RFC number 1, written by S. Crocker and entitled "Host Software", is dated April 7th, 1969. Dang, it looks like they missed the April's Fool opportunity that year.

Most RFCs are written simply because they are needed, usually to resolve some particular issue. Taken together, they are a large part of the reason why the Internet works and is usable today. Some supersede others, and yet others may pretty much cancel each other out, but taken together, they form the sum of what the Internet is at the specification level.

As I said in the publicity blurb for this talk, there has been quite a lot of experimental stuff on the net since the earliest days, and in some cases the code which implements a proposed standard is ready to the degree that code ever is before the RFC specification is done. In other cases, it takes years for a specification to be successfully implemented and tested. I don't have the complete statistics, but at some point in the future I'm pretty sure that an Internet historian will be able to generate a really nice graph of the data.

Now I can feel you are dying to ask, why did it take so long for RFC 1149 to join the ranks of implemented, if not recommended standards? The document was issued on April 1st, 1990, and the first full scale test of the first implementation took place on April 28th, 2001. Why did it take so long?

To answer that question, we need to take a look at the document itself, dated April 1st, 1990. The heart of the specification is what you find in the "Frame Format" section which states

"The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. "

and

"Upon receipt, the duct tape is removed and the paper copy of the datagram is optically scanned into a electronically transmittable form."

That sounds easy, doesn't it? Any hacker would have the necessary ingredients, which are

• at least two computers (check)
• at least two printers (check)
• at least two scanners (check)

- and

• enough carrier pigeons homed on where the computers, printers and scanners are located.

The last bit is the tough one. That, and of course, if it isn't already mind-numbingly obvious, it was all a joke. The first clue is the date, April 1st. There are several other RFCs date April 1st in various years, and most them were intended to be serious, but they also include such gems as RFC 3514 from April 1st 2003, which specifies how and when to set the "evil bit" for network packets.

That one, if I remember correctly, was in fact implemented the same day in FreeBSD-current, which could then again boast to be the most RFC compliant operating system out there. Looking at RFC 1149, it is pretty obvious that it is nowhere near having any practical value whatsoever. Almost any other way to transfer network packets you can think of will be faster. But the specification is remarkably clear and well written. I remember reading RFC1149 for the first time as an appendix to some TCP/IP training material i was translating in 1993 or 1994. After a few grins, I remember thinking that it could probably be done.

So it was a fairly famous document when we decided to do an actual implementation. The Bergen Linux User Group had resumed activity in the spring of 2000 with regular meetings scheduled for the last thursday of every month except summer and Christmas break months June, July and December.

The core of organizers have tended to meet at my office for planning activities most Thursdays. We would have a more or less formal meeting, planning the next few meetings, talking about possible activities and speakers, and so on. Just around the corner from where I work was an Irish bar, "The Harp", that is to say Irish themed and stocking Guinness stout as well as the regular Norwegian Ringnes pilsner beer. That's where we would usually go for a few beers after we were done with the planning bit.

The idea of actually implementing RFC 1149 probably first came over beers at The Harp. This was around the time when most of the serious planning activity in BLUG was about Linux kernel uberhacker Alan Cox' visit, which was scheduled for lat April 2001. We thought that Alan would be a major attraction by himself, but we also thought we needed something spectacular in order to attract attention and get people to turn up at the meetings. So somebody mentioned April first RFCs, and since the idea seemed a good one the next morning too, we decided that RFC1149 was the one, if we could only find pigeons. We were surprised how easy that was. Typing "brevduer bergen" into a web search engine (probably google) turned up the web site of a pigeon racing club in Bergen, with enough contact information for us to make contact.

The first RFC1149 Birds of a feather session took place at Svein Arne Rosendal's house in suburban Bergen on the evening of march 6th 2001. The minutes of that session is available on the web. Basically we were three BLUG people, Karl Magnus Kolstø, Vegard Engen who ended up writing the code and myself. We were able to persuade the pigeon people that it would be a great idea to participate in the project, and they went on to list a few likely candidates from among the club members.

The idea was that it would be better if the two pigeon homes were rather close together, simply because a flying time could become a factor. I think it took only a few days before they had located two pigeon racers who lived within reasonable range of each other. I think the "as the bird flies" distance was around three kilometers, across the small mountain Løvstakken. The peak of Løvstakken is 477 meters above sea level, but the most likely flying route for the pigeons would take them from an elevation of roughly 150 meters up to perhaps 300 then down to around 50 meters above sea level for the outgoing packets and of course the other way around for the return traffic.

We set the date and time, and went on to planning the other parts of Alan's visit - these included feeding the penguins at Bergen Aquarium, a fjords sigthseeing day, the Thursday user group meeting with Alan giving a talk, and finally the pigeons test. Vegard wrote pigeonware in late March or early April.

Now for the technical details - Linux kernels version 2.4 and later feature a TUN/TAP device interface which makes it relatively easy create applications such as pigeonware which handles network traffic via a userspace daemon.

The pigeonware README file lists the package requirements:

- Linux kernel v2.4.x with the Universal TUN/TAP Interface as a module.
- GOCR (http://jocr.sourceforge.net)
- Printer supported under Linux
- Scanner supported under Linux
- Pigeons
- Some luck
  

What we used were Vegard's laptop and mine, both Toshibas, and both running Debian GNU/Linux. The printers were HP LaserJet clones, I forget which exact makes, the scanners were Agfa USB scanners which worked flawlessly from the moment they were plugged in. On my machine, I needed to do a dist-upgrade from stable to testing and a more recent kernel than the stock Debian one. I remember some dependencies needed to be resolved by hand, but it did work out in the end.

Now we had had some serious discussion of what kind of traffic we wanted to test with. Would not sending an email message to delivered by pigeon be an appropriate test, for example? Well, to set up a full TCP/IP connection for an SMTP session, with all handshakes and responses, we calculated it would take roughly 25 network packets - that is 25 - pigeons before we start transferring the actual message. So after a bit of discussion we decided that a ping session, all ICMP, would be sufficient to prove that the technique worked. Ping packets are small, too, so we wouldn't need to fiddle with oversize MTUs or anything.

This is one of the actual packets we generated during a test run:

45 00 00 54 00 00 40 00 40 01 20 A7 0A 00 03 02 0A 00 03 01 
08 00 FC 36 84 6B 01 00 CF 15 E7 3A CF 09 06 00 08 09 0A 0B 
0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 
34 35 36 37 
  

This is from the pre-pigeon dry run testing at my office. We tested the setup, by plugging it all in except the pigeons, disconnected the computers from all other networks, ran the setup scripts and then initiating a ping session. It would take a few seconds for the first page to be printed. To simulate real world conditions, one of the other volunteer helpers would take the sheet of paper, circle the table a couple of times before handing it off to be scanned. The packet was scanned at the destination machine, and after a few moments the return packet would be printed.

Some pictures from the preparatory testing (courtesy Vegard Engen)

The man from the pigeon racing club had indicated a filling station which would be a good place to meet at 10:30, giving us a reasonable amount of time to drive people and equipment to the two pigeon homes and set up in time for the test scheduled for 12 noon. While at the filling station, Vegard in vain tried to explain the project to one of the national TV networks. In fact, as the conversation went on, it sounded to us (who heard only one part of course) that the poor soul at the other end grew more frustrated and confused the more information he was given.

Arriving at the first pigeon home (Bråtet Terrasse), at first nobody was home. This lead to a slight anxiety, almost to the point where various plan B options were considered, when the man we had been waiting for turned up. Setting up the main base with Vegard's laptop, a scanner and a printer started almost immediately, and a smaller group headed for Lyngbøveien to set up the satellite base -- the place to be pinged.

Setting up in Lyngbøveien was a matter of only a few minutes, and the satellite crew ran a couple of test packets saved from the night before to check that the setup was still working. Noon passed, and -- OK, it felt a bit like cheating -- we rung the main base via GSM phone to find out if the first packet had been sent. Not yet, we were told, the documenting took a little more time than exptected.

Several more mobile phone calls followed, relaying information about the number of pigeons sent and the rough location of the largish flock they had joined. After a little more than an hour, a pigeon turned up, only to land at the top of the roof (Kjell's house is a three-story affair) and proceeding to clean the odd wing feather.

Kjell made several attempts at getting the bird to find its way to the pigeon den, and finally succeeded. At last, the initial packet had arrived. The tape was rather sticky, and the strip of paper had been rolled, then flattened a bit, making the optical character recognition somewhat unreliable. We were to discover that hand smoothing (say, with the help of a ruler or even the edge of a table), then attaching the strip of paper to a full A4 sheet of paper before placing it on the scanner improved character recognition significantly.

The next four packets arrived simultaneously within minutes of the first one, leading to some congestion in the scanning queue. When the fourth packet had been sent, we were startled to hear intensive flapping of wings.

The two remaining carrier pigeons had managed to escape without being fitted out with a payload, and we unexpectedly found ourselves in a NO CARRIER condition.

Two more packets arrived, but we were unable to respond. Nothing left to do but unplug and start packing. Our ride arrived after a little while, and after thanking our host, we set off to unload the equipment at the office and returning some of it to the owners. The participators headed in different directions for a couple of hours, with a plan to reconvene at Håvard's to help Alan clean out the tax-free quota. Suffice to say, the combined efforts of several people got us most of the way there.

Vegard's rfc1149 writeup was published Sunday afternoon, and a slashdotting made our previously ~200 hits a day web aquainted with the feeling of more than a million hits on the Monday. Number of hits has been tapering off after that, but stayed in the hundreds of thousands per day for the next couple of weeks.

Soon after the event, Eric Raymond's Jargon file's The Meaning of ‘Hack’ section was updated with a description of the event, naming the implementation "a wonderful hack story for the new millennium".

We also got some attention in the IT oriented press internationally and even mainstream media such as the BBC ran stories about the event. My own favorite is still the Salon item. As far as we are aware, no Norwegian language publication of any kind ever carried a story about this somewhat odd innovation.

Vegard went to the Internet Engineering Task Force conference later in the same year, and received a commemorative plaque on behalf of the group:

There were even some art projects that referenced our implementation, and I think even some that reused the pictures that were available on the BLUG RFC1149 web. (An archived copy of the original site can be found here).

---

The notes in full prose form end there. I was likely in a hurry to catch a plane, but I mention (as I do in the slides) that we had at least thought of some followup work:

	
Future developments

* more implementations
       needed to get on the Standards track
* Interspecies handoff protocols - relay runners?
      

---

In 2011, I wrote a short commemorative article, RFC1149: Ten Years of In-Flight Internet (also here) to note the ten year anniversary, where I noted that

The CPIP WG activities have proceeded at a more leisurely pace in recent years. In 2005 I went to the AUUG 2005 conference to do an early version of the PF tutorial, and en route I made a presentation in Adelaide about the project (slides and accompanying notes are still avaliable).

We're still looking for independent, interoperable implementations, though. Preferably on other free operating systems besides Linux. If we can entice our old pigeon partners to participate, we're more than willing to arrange for interoperability tests.

The world needs this to be on the IETF Standards Track.

Soon after the ten years mark, we did some re-enactments, with people (mainly children) acting as packet carriers, but I have been unable to find any resources about these events available on the web.

Again, independent implementations for other free operating systems would be most welcome, and the original implementers are still available and willing to participate in any interoperability tests.

---

The implementation of the Carrier Pigeon Internet Protocol, RFC1149, 25 years later is © 2026 Peter N. M. Hansteen (published 2026-04-25)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

The Book of PF, 4th Edition: It's Here, It's Real

© 2026 Peter N. M. Hansteen

The long wait is over. Fresh copies of The Book of PF, 4th Edition arrived here today. Which means: I'll bring some to upcoming conferences!

When the email message with package tracking information turned up, I thought at first that this was yet another dirty, scammy, spammy phishing thing.

---

Note: This piece is also available without trackers but classic formatting only here.

---

It had been years since the last time I had had a UPS delivery, and since then I had only seen obvious scammy phishing things pretending to delivery messages that all in fact looked very much like the crummy fakes they turned out to be.

But this one looked subtly different, in that it had both my address and my somewhat unusual name correctly spelled.

In addition, the URLs were on close inspection all for actual UPS.com resources.

And finally, the shipment had a total weight of 10.4 kg, which sounded about right for the stack of The Book of PF, 4th Edition author copies I was expecting to receive soon after the print run was ready to ship.

Now, a few days later, I have just taken delivery of package, this time delivered to my door by a delivery man who was very excited to be delivering a box of books to their author. The box was slightly heavier than my regular backpack:

and after taking the box inside, I was able to extract the 15 copies, as expected.

This is me, holding my first physical copy of the fourth edition to come out of the box:

This means that the process that started almost two and a half years ago is finally, tangibly complete. I have the shipment of author copies of The Book of PF, 4th Edition in hand.

Regular readers of this column as well people on relevant mailing lists will be aware, as will my followers on various social media, that people who ordered the book early have already started receiving their copies of the refreshed The Book of PF. And some have posted their (so far only positive as far as I am aware) reactions to their media of choice.

But for one reason or the other, my expected stack of author copies were not among the very early deliveries.

Among the likely reasons are the fact that I am located in Bergen, Norway, which, at roughly 62 degrees North and in The Other West Coast fjords country, is somewhat off the beaten track for high speed deliveries.

And as any good business would do, No Starch Press will put a priority on delivering the product to customers who put in preorders or were on the spot once the thing had been declared ready.

Now I can tell you all yet again, the thing exists, and I am delighted to see the actual physical copies.

I know some readers were expecting there to be an auction for the first signed copy like there was for the third edition.

I have to disappoint you there. Unfortunately, side effects of decisions made by politicians on the other side of the Atlantic have made it impractical to set up an equivalent auction this time around.

Instead, I would encourage readers who can afford to do so to make a direct a donation to the OpenBSD Foundation or to the OpenBSD Project directly, in order to support the OpenBSD project and the immensely valuable work they do for free software.

If you're more of a FreeBSD person, the FreeBSD Foundation will be happy to hear from you as well.

Once you have done the rounds of your favorite free operating system supporting foundation and have your (or your bosses') credit card back in its regular location, you can think forward to one or more of the upcoming regional BSD conferences.

The main ones this year are,

• AsiaBSDCon, March timeframe, alternates between Tokyo (JP) and Taipei (TW). AsiaBSDCon 2026 will be March 19-22, 2026 in Taipei, Taiwan.

  This will include the first scheduled Network Management with the OpenBSD Packet Filter Toolset session of the year, on March 19th, 2026.

• BSDCan, Mid May to mid June, Ottawa (CA). BSDCan 2026 will be June 17-20 in Ottawa, Canada.

  This, too, will have a Network Management with the OpenBSD Packet Filter Toolset session, on June 18th. Details to follow closer to the date of the conference.

• EuroBSDcon, September timeframe, each year in a new European city. EuroBSDCon 2026 will be September 10-13 in Brussels, Belgium. The call for papers is open from March 1st, 2026 and runs until June 20th.

All three conferences will welcome submissions during their Call for Papers period for talks, tutorials and other types of sessions as well as general participation by people regardless of geographic or other origin.

And unless truly unexpected events take place, I will be at all three this year, bringing copies of The Book of PF, 4th edition.

I look forward to seeing you at these events.

If you are interested in coming to a regional BSD conference as a speaker, volunteer or other participant, see What is BSD? Come to a conference to find out! (also here) for some information.

Through all of those events, our resident philosopher took it all with her usual calm:

If you want to get the book, and using the link to buy from No Starch Press is not practical, I would encourage you to support your local bookstore and see if they can order it in.

---

The Book of PF, 4th Edition: It's Here, It's Real is © 2026 Peter N. M. Hansteen (published 2026-03-06)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).