That grumpy BSD guy

Wednesday, August 6, 2025

Elvis is alive! How 'AI' stunts modern mythmaking

A chance followup to an old geek joke reveals how AI creates myths based on severely limited historical inputs

Sometimes LinkedIn discussions run much like informal office banter. Earlier this week, Niall Murphy posted there, saying

Best joke hostnames? I'll go first:

Best joke hostnames? I'll go first:
"switchen" - network equipment close to the fridge
"madwoman" - storage server somewhere up high (guess how high)
"wutheringbytes" - storage server in rural surroundings

This had me respond with

Never forget that it is required for any network with Solaris boxes to have
one host called elvis

Never forget that it is required for any network with Solaris boxes to have one host called elvis

This comes from a fairly widely known and respected part of geek culture, based on the Solaris operating system's implementation of the ping(8) command.

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

If you're a Unix person, you will get the joke immediately after following the link to the ping(8) manual page and reading the first three lines of the DESCRIPTION part.

The cultural background is a reference to Elvis Presley, the "King of Rock'n'Roll", who passed away in August of 1977. Pretty much immediately after the sad news arrived via ordinary channels, speculations started turning up that The King was not actually deceased.

There have been quite a few versions of those rumors in circulation, and if some of those were to be believed, our man had actually arranged a disappearance in order to join some top secret undercover assignment for one or more of the federal three letter agencies of the United States govenment.

Be that as it may, fast forward a few years, and by the time I entered the ranks of Solaris admins, it had become something of a standing joke to put new hires in front of a terminal or simply an Xterm open on a Solaris box and tell them to enter ping elvis and press Enter.

The interaction would then run like this:

$ ping elvis elvis is alive

at this point everybody would have a laugh, and work would go on. Until the next rookie turned up.

That was the joke, repeated almost ad nauseam at all Solaris sites I have been to.

So I was a bit surprised by Niall's followup

Peter Hansteen glad to see Gemini's got it's finger on the pulse:

Peter Hansteen glad to see Gemini's got it's finger on the pulse:
"Bohunt School:
The context of the phrase "Elvis Solaris" comes from a Facebook post from Bohunt School, indicating the school used the dogs to help students with their well-being. "

My immediate reaction was along the lines of that's bulls**t, phrased as

Whatever they fed that one, I don't think I want to know.

ping(1)!

Whatever they fed that one, I don't think I want to know.

ping(1)!

A screenshot of the entire sequence is preserved here.

-- and my impulse here was that this was yet another example of AI hallucination, courtesy of the Gemini assistant tool. After all, what other link between Elvis Presley, King of Rock'n'Roll and the Solaris operating system could conceivably exist? So I just dismissed the thought and went on with my day.

But the next morning I noticed I was still slightly irritated by the whole thing, so I decided to investigate again, using the clues Niall had provided.

Searching with the obvious keywords, it turned up that indeed, a series of Facebook posts existed that showed that in connection with Bohunt School, an outfit calling itself Solaris Healthcare had indeed been involved in a number of events using the name Elvis in the event title, apparently involving one or more Elvis impersonators.

So the reference was real after all.

The thing was not completely made up, but pointing to those Facebook posts about the Elvis themed events as the original context shows very clearly what the language model was trained on. They included social media posts, but apparently did not manage to suck in references to a fairly widely know part of geek or hacker culture.

To my mind at least, this shows that even the latest fad in Artificial intelligence (AI)has been unable to evade one basic truth about information processing systems:

The quality and usefulness of the output from any information system depends critically on the inputs provided for the system to process.

Or as some less kind commentators have uttered, Garbage in, garbage out (GIGO for short).

When the hypemasters of the large language models forget this simple truth about their systems, we all end up poorer for it. The tool acts as if it has absorbed all knowable truth, and presents it with all the confidence of a veteran mansplainer. Whatever was not in the training data set simply falls by the wayside.

If in this way modern myths and folklore stripped away and deleted, only what the robot trainers could be bothered with included, and as a consequence the scope of what will form our future myths and folklore culture becomes narrowed and stunted.

This all echoes the sentiments that I found in a fediverse post that I lost the original reference for, but which I included in my my pinned post,

I just saw a post that referred to ChatGPT as "Mansplaining as a service", and it is so wonderfully correct - instant generation of superficially plausible yet totally fabricated nonsense presented with unflagging confidence, regardless of topic, without concern, regard, or even awareness of the expertise of its audience :D #chatgpt #mansplaining #GenerativeAiIsGoingGreat

Take "ChatGPT" there as a stand-in for "any large language model system". In the current iteration of what popular culture considers Artificial intelligence, much of the hype we have heard can be condensed to

"but this time around, it is laced with our special large language model magic."

The sceptics among us might be justified in thinking

"actually, this time around its GIGO+M (Garbage in, Garbage out, plus magic)".

I am an old man. I regularly yell at clouds.

Good night and good luck! I welcome your comments.

Bonus note: Niall told me in a message, about the "is alive" reference, he was "wondering if it was sourced anywhere and turned to my favourite search engine to see. And that was the Gemini result placed at the top, which I thought was so beautifully wrong/weird I should share it with you..."

Update 2025-08-07: My colleague Eirik Sangolt decided to put OpenAI GPT-4.1 to the task of explaining.

Here is what happened:

Eirik: Explain the following Tweet: "Never forget that it is required for any network with Solaris boxes to have one host called elvis."

OpenAI:
The Tweet "Never forget that it is required for any network with Solaris boxes to have one host called elvis." is a reference to a long-standing joke in the Unix and Solaris system administration community.

Explanation:

Solaris is a Unix operating system originally developed by Sun Microsystems.

In Solaris, there is a command called ping used to test network connectivity.

If you run the command ping elvis on a Solaris system, the system responds with:
elvis is alive

This is a playful Easter egg built into Solaris. The system is pretending that "elvis" is a host on the network, and the phrase "elvis is alive" is a joke referencing the popular culture myth that Elvis Presley is still alive.

So, the Tweet is a joke:
It suggests that every network with Solaris machines should have a host named "elvis" so that when someone runs ping elvis, they get the amusing response. In reality, it's not a technical requirement-just a bit of fun for system administrators.

If you want more details or examples of other Unix jokes or Easter eggs, let me know!
This response is Al generated and is based only on parts of the available information. Do not use it as a basis for important decisions.

Screenshot preserved here.

I think perhaps the answer provided here could be based on fairly low rated stackoverflow answers.

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

At EuroBSDcon 2025, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon (also here). We are hoping to have physical copies of the book available in time for the conference, and hopefully you will be able to find it in good book stores by then.

Tuesday, August 5, 2025

Those Titles the AI Bot Thought I Had Written

Beware of robots generating your references. They could very well take it upon themselves to lie on your behalf. Testing in 2023, I observed a whopping 25% truth in the result. What is the truth rating in 2024?

Note: This is a field note that was originally intended as a fediverse (mastodon) post, but the text would have overflowed into a thread and would then have become quite cumbersome.

Back in the early days of generative Artificial Intelligence revolution (read: late 2023) I had heard enough of the hype that I did a few minimal experiments (see my earilier notes ChatGPT opines on IPv6 procastination, waxes lyrical over OpenBSD (also prettified, tracked) and I asked ChatGPT to write a pf.conf to spec, 2023-06-07 version (also prettified, tracked)) that had me conclude that for my own purposes at least, the technology as it appeared at the time was unlikely to improve productivity for myself or any of my immediate colleagues.

The TL;DR would be that since the models will only become somewhat useful if they are trained on a sufficient volume of material within the topic of interest, clearly a lot of work needed to be done. Basically, the gaps in the training data seemed to fit essentially most of the field I deal with professionally, beyond of course a few trivial generalities. And those were cracks that could only be papered over at the cost of pulping several good-sized forests.

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

Not easily discouraged, I thought maybe, it just might be, that the data the language model trainers had sucked in from public sources on the Internet would contain enough factual information that the system would be able to cough up a reasonable bibliography of what I had written.

So I opened another session with the same robot and typed

what are the most read articles by Peter N. M. Hansteen?

After a brief pause, the cursor started moving and presented its result:


          As an AI language model, I don't have real-time access to up-to-date information or specific statistics on article readership. Additionally, my training only goes up until September 2021, so I may not be aware of the most recent articles published by Peter N. M. Hansteen. However, I can provide you with some notable articles that Peter N. M. Hansteen has written up until my knowledge cutoff date.

Peter N. M. Hansteen is a well-known author and has written extensively on the topic of networking and computer security, particularly focused on OpenBSD and firewalls. Some of his notable articles include:

"The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall" - This is a comprehensive guide that provides practical information on setting up and configuring firewalls using OpenBSD's PF (Packet Filter) system. It covers topics such as filtering network traffic, NAT (Network Address Translation), and quality of service (QoS).

"Building Firewalls with OpenBSD and PF" - This article discusses the concepts and techniques involved in building firewalls using OpenBSD and its PF system. It provides practical examples and guidance on firewall design and implementation.

"Securing the Edge: A Practical Introduction to OpenBSD Packet Filtering" - This article focuses on the fundamentals of packet filtering using OpenBSD's PF system. It covers topics such as rule syntax, filtering criteria, and advanced filtering techniques.

"So You Want to Be a Firewall Wizard? Part 1" and "Part 2" - These two-part articles provide an introduction to firewall concepts and techniques, with a focus on OpenBSD and PF. They cover topics such as rule sets, network address translation, and handling complex firewall configurations.

Please note that the popularity of articles can vary over time, and it's always best to refer to the author's official website, blog, or other reliable sources for the most up-to-date information on their publications and readership.

(Preserved as text, cut and pasted from the website, here)

My initial reaction when I saw the result was a sound you would associate with something quite unpleasant happening.

I'll take one paragraph at the time.

Though it was probably intended as a disclaimer, the claims in the first paragraph there are, as we shall see, only 25% true, if even that.

The second paragraph has a description of me that is on par for what would turn up in a not terribly specific search using your favorite Internet search engine.

Just how well known an author and what consitutes extensive writing is open for discussion, but at least the paragraph as a whole is not counter-factual.

I did write The Book of PF. The third edition of the book would have been available via that link and a few others at the September 2021 cutoff date, and the description is a valid, if somewhat short of exhaustive, description of the book when it comes to subjects covered.

However, the three titles that follow were not written by me.

I think I have read articles matching those titles at some point, but the actual authors of those pieces would not be terribly pleased to have them attributed to somebody else. I would assume their publishers would like a word there too.

I have mentioned this session a few times to colleagues and friends over refreshments, but I have not really give it much thought since.

But the chatter about how the AI bot herders are heroically fighting their charges' tendency to hallucinate seems to never come to an end.

So my question to you is: Has the situation actually improved since then?

If you have any useful experience to share or other input on the subject, please follow up with a comment in the thread where you found the reference to this note.

A reasonable followup question would be,

Are the efforts that go into (what is currently labeled as) Artificial Intelligence starting to pay off?

followed by

or are we for now better served by having the abbreviation "AI" (perhaps more reasonably) expand to "Artificial Inanity"?

Come to think of it, unless the various bots that scrape the net actually obey my robots.txt directives, publishing even this text here will lead to further confusion over who actually wrote those titles. This is bound to turn up in the AI slop presented to some poor soul looking for valid information.

Again, if you have any useful insigths or experiences you want to share on the subject, please follow up with a comment where you found the link to this piece, or post to this fediverse thread (raw link https://mastodon.social/@pitrh/113612679976829404).

I look forward to reading your comments.

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

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon. The latest information I have is that physical copies will be shipping by the end of January 2026

Friday, July 11, 2025

Yes, The Book of PF, 4th Edition Is Coming Soon

Long rumored and eagerly anticipated by some, the fourth edition of The Book of PF is now available for preorder

This week it was finally time to announce, to the fediverse and to mailing lists, that there is a new edition of The Book of PF in the works, and preordering is now enabled.

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

A few questions immediately pop into readers' minds on hearing this news. The ones I get most often are,

Why now? What took you so long?

which quite frequently combines with

What changed? Are previous editions now useless?

I'll address both after repeating what I said in the email announcements:

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

What happened was, for quite some time after the third edition was finished, there were essentially no user visible changes such as syntax changes in the configuration for OpenBSD PF.

The code was definitely being worked on, developers fixed bugs, introduced optimizations such as network stack wide improvements in multicore support. But user-visible changes other than likely performance improvements did not appear, so I saw no urgent need to make updates to the book.

During the years following the late 2014 publication of third edition, I went on giving talks and tutorials, and at some point I welcomed input and help from my present co-presenters of the Network Management with the OpenBSD Packet Filter Toolset tutorials, Max Stucchi and Tom Smyth.

Over a few revisions, the tutorial sessions became ever more OpenBSD centered, possibly because we were all focusing more on that system than the others. And of course, over time we made tweaks to the material we present at the tutorials in response to our own real world experiences and feedback from attendees and others.

This went on for some years, with the still moderately popular conference sessions each yielding incremental changes to the material. Then, COVID-19 put all physical conference activities on hold for the years 2020 and 2021. EuroBSDCon 2022 in Vienna (originally planned as the 2020 conference), was our first post-lockdown presentation and a well attended one at that.

We went on to do more sessions at BSDCan 2023 and EuroBSDCon 2023. During the post-lockdown period, one question started popping up ever more frequently in email, social media (direct messages, even) and in connection with the sessions themselves,

Are you working on a fourth edition?

more often than not accompanied by

I'd love to get this in a FreeBSD version, can you do that too?

My answers would be roughly, "No tech book writer will ever reveal what their current project is until they have a specific publication date set", and "Sure, I will look into what I can do about that for sometime later"

On my way back from EuroBSDCon 2023 in Coimbra, where these questions had of course come up again, even from the quite small group of attendees at our session, I decided I that after eight years it might be worth at least looking into what, if anything beyond incrementing version numbers, would make sense to do to produce a new edition.

So I set out to assess. The book had seen some light touch updates for its second printing that were not in my pre-production .odt files, so I set out with the freshest .pdf and started making annotations. After a little while the volume of annotations had grown enough that I found it more useful to transfer those annotations to a normal text file. That file was becoming something like an outline of what a fourth edition would look like.

So testing my own 8 year old work against modern OpenBSD and FreeBSD, and poking around for PF material in general, I noticed several things.

Since the third edition was written, NetBSD, prominently featured in that edition, had developed their own NPF packet filter subsystem and deprecated their PF port. While DragonFly BSD still had PF in their tree, it looked like their version was seriously out of date (as far as I could tell equal to roughly OpenBSD 3.6, released in 2004).

So concentrating on the two free systems I was anyway in daily contact with -- OpenBSD and FreeBSD -- made sense.

My notes of things that needed to be done swelled over the next few weeks. The revision notes work became my main activity on evenings and weekends for a while, and by late November I sent off that file as an attachment to a mail message to Bill at No Starch that started with,

Dear Bill,
I think a fourth edition of The Book of PF might have a reason to exist soonish.

I went on to explain that while we had not had major announcements in the packet filtering space during the past few years, quite a few incremental and larger changes had indeed happened. A lot more had happened in user visible PF matters on the FreeBSD side than on the OpenBSD side, but incremental changes had happened there too.

And as you could reasonably expect, the world around us had changed enough that in addition to introducing some new features, existing examples and the way we present the issues to the reader needed a refresh in order to be relevant to anyone working in or starting out with modern TCP/IP networks.

It took some weeks before the yes, we're on board for a fourth edition message came back. It is entirely possible that making an important business pitch just before Thanksgiving weekend is not an optimal thing to do, timing-wise.

But when the go-ahead came, I asked Henning Brauer, who had been very much involved with technical editing for the previous versions, and Kristof Provost, who does the major PF things on the FreeBSD side, to be my tech reviewers. Both accepted immediately.

Over the next few months intense editing and revising followed -- yes, I do make mistakes, and Henning and Kristof proved to be very good at catching them.

Now we are very close to having the final result. The fourth edition of The Book of PF focuses on PF on modern versions of OpenBSD and FreeBSD, with only minor mention of other platforms. The ports to Apple systems and Oracle Solaris are mentioned, but I decided early on to focus on the free systems for all examples. The FreeBSD parts have received significantly more attention than in previous versions, to the extent that we jokingly referred to the fourth edition as the be nice to FreeBSD edition.

NEWS FLASH 2025-12-05: Final proofs done 2025-11-30, the thing is now in production,

The editing process has taken longer than I had anticipated, but we are on track now to have copies in readers' hands some time in the second half of 2025. ~~I hope I will be able to bring physical copies of the fourth edition to~~ Unfortunately physical copies will not be ready for us to bring to EuroBSDcon 2025 in Zagreb in September. There will be a revised and updated version of the Network Management with the OpenBSD Packet Filter Toolset session there, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

So summing up,

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

If you have actually read this far, there is a good chance you might be interested in the book, the tutorial, or both. I welcome your comments and input.

If you found this piece to be useful, informative, annoying or would for some other reason like to contact me or comment, please do.

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

Sunday, June 8, 2025

Should I Stop Caring and Let IP Address Reputation Sort Them Out?

How long does data on misbehaving hosts on the Internet stay relevant in an IP Address Reputation context?

log of pop3 gropers in action, failing of course

My main presence on the Internet also serves, for all practical purposes, as a honeypot, and is seen as mainly that by what appears to be a small but significant number of people who run IP Reputation services (yes, link to SpamHaus because apparently Wikipedia does not have a page dedicated to the topic yet). The article Badness, Enumerated by Robots (also here) describes the data collected by the honeypot, with links to the data as well as to other relevant resources.

But there is a thing about putting something on the Internet for free so anybody at all can download it: People will not necessarily read the instructions.

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

The honeypot service has been collecting and sharing data for years, as will be clear from the articles linked in a previous paragraph. All the lists have their consumers and get downloaded regularly.

Although there are signs that the list data is further processed into various services, including those that provide IP reputation rankings, the only people who seem to care enough to actually contact me about specific entries in the data are people who own one or more IP addresses that have for one reason or other been included in the lists.

Recently I was contacted by somebody who claimed that some of their traffic seemed to be filtered due to IP reputation, and they had tracked down the problem to the POP3 Gropers list we publish. The big one, that is.

I was a bit surprised by this, give that I had provided a fairly clear description of the lists and their expiry times in the published material. That material also clearly stated, in my view at least, that the big POP3 gropers list does not have an expiry set, and should for that reason be used with caution, if at all.

But apparently one or more operators of IP address reputation services did not actually read that far.

I am still pondering what is the correct action here, so I created a fediverse poll,

Post by @pitrh@mastodon.social

View on Mastodon

(For those without working fediverse links, the question posed is "Should I", with the options: "Stop publishing the BIG pop3gropers list", "Stop caring and let IP reputation sort them out", or "No opinion, show results", prepended with a shorter version of the description in the first part of this article) which may of course have run its course when you read this.

If the poll has run its course and you don't get to vote, you are of course welcome to contact me or comment where you find reference to this article.

I am genuinely interested in hearing informed opinions on how to deal with data collected in the context of contributing to IP address reputation context.

In addition to the poll, I added a note to the Badness, Enumerated by Robots (also here) article as well as to the exported text files:

NOTE: The BIG pop3 gropers list is for history only, use the sixweeks one for IP reputation evaluations instead
As stated earlier, the big list of pop3 gropers was intended as a collection of all hosts that had ever tried and failed in guessing passwords (see Password Gropers Take the Spamtrap Bait for background). This means that the list only exists as a historical collection of sorts, and if you are intrerested in seeing when a particular host entered the data set, you can look it up in the pop3 gropers archive directory.

For any reasonably current IP Reputation purposes, you will be better served with the pop3 gropers during the last six weeks list, which conveniently is also archived for those who wish to study developments.

For what it's worth, there is an archive of the greytrapped hosts list available too, along with a separate archive of the SSH bruteforcers list, all kept around for as long as I find it at least a little useful to do so.

For reference on just what triggered the inclusion, see the log extracts preserved in the pop3logs directory, which has entries going back to February of 2024.

I hope at least some of the relevant people -- people running IP address reputation services -- take the time to read that little piece of text and have a think.

For my own part, I will be pondering the ethics and practicalities of blocklists much along the same lines as I wrote about in the 2013 piece Maintaining A Publicly Available Blacklist - Mechanisms And Principles (also here).

If you found this piece to be useful, informative, annoying or would for some other reason like to contact me or comment, please do.

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

Upcoming events:

Ottawa, Canada: BSDCan 2025 has tutorials June 11-12, 2025 and talks June 13-14. A new version of Network Management with the OpenBSD Packet Filter Toolset will go ahead there.

A little later on in 2025, the EuroBSDcon 2025 conference is still accepting submissions for papers and tutorials, so if you have an interesting BSD-related topic you want the world to know about, your submissions will be welcome at the EuroBSDcon submissions system, where the deadline is 2025-06-21, or June 21st, 2025 (full disclosure: I'm on the program committee). This year's conference is set in beautiful Zagreb, Croatia in late September.

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon. We are hoping to have physical copies of the book available in time for the conference, and hopefully you will be able to find it in good book stores by then.

Sunday, May 25, 2025

That Grumpy BSD Guy: A Short Reading List

A collection of pointers to things I have written and that I think may be of value to you too, my fellow geek friend

I was recently (late May of 2025) asked to provide a list of things I have written over the years that would be suited to offer useful insights to someone not familiar with my work or the field(s) I cover.

In addition to the book I wrote and have revised when the time seemed right, I have written the odd blog post over the years, and this is the list I came up with, in roughly reverse chronological order:

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

EU CRA: It's Later Than You Think, Time to Engineer Up! (2025) -- A call for stepping up to real, good engineering practices in software development and maintenance, with a slight emphasis on the fact that by the end of 2027, there will be legislation in force that will in fact compel the industry to act. Expands on the earlier No Project Is an Island: Why You Need SBOMs and Dependency Management (2025) with a view to performing an introductory workshop for working or aspiring developers and devops/sysadmins. And perhaps even their suits-clad managers.

For Upcoming PF Tutorials, We Welcome Your Questions (2025) -- I have been giving PF tutorials for about 20 years, for the last few years in cooperations with Max Stucchi and Tom Smyth. This piece was written to encourage questions and other input while we are preparing for the BSDCan 2025 session, which we are still working on preparing as I write. However, we always welcome your input and we have provided contact information in the piece itself. Also available tracked, prettified.

Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (2025) -- A long-running experiment, started all the way back in 2007, with the intent to make undesired activity less desirable to engage in, reached a milestone of sorts. That event I considered significant enough that I finally wrote that retrospective some of my readers and correspondents had been asking me to do for some time. Also available tracked, prettified.

No Project Is an Island: Why You Need SBOMs and Dependency Management (2025) -- This piece is really about software engineering coming to grips with what real world engineering is all about. The world, or parts of it, finally decided that we could no longer consider software "just a bit of typing", and we are answering the challenge by leveraging lessons learned by working on free software. A further evolved version could turn up at future public events. Also available tracked, prettified.

A Suitably Bizarre Start of the Year 2025 (2025) -- Because, well, the time around the start of the year showed up a few truly bizarre things, a surge in truly nonsensical spamming activity being one item. The number of imaginary friends collected has kept up the pace, see links in the piece itself for up to date information. Also available tracked, prettified.

You Have Installed OpenBSD. Now For The Daily Tasks. (2024) -- I am much indebted to Solène Rapenne for pointing out to me that two earlier pieces I had written about life with OpenBSD were, while not actually wrong, just quite a bit out of date. This piece recitifies that situation, and provides some basic advice for day to day life with our favorite operating system. Also available tracked, prettified.

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (2024) -- Fresh off writing his excellent mail server book, Michael W. Lucas posted a thing on the Mailop list that had me write a short piece on domain-only trapping (linked in this one), and after a quick think, also this piece that offers other minimalist but actually usual configurations. Also available tracked, prettified.

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends? (2022) -- A follow-up to an earlier piece on the embarrasment-based extortion spamming campaigns we had been seeing for some years. This piece makes a hopefully clearer case than the previous one that the potentially embarrasing video material the messages claim exist most likely does not. After all, multiple thousands of addresses that have been known to never have existed are targets of these campaigns, swelling temporarily the list of greytrapped hosts. Also available tracked, prettified.

A Few of My Favorite Things About The OpenBSD Packet Filter Tools (2022) -- The good people at SEMIBUG asked me to give a PF talk for one of their user group meetings. This is the writeup for that talk, with links to slides and other material. Very much colored by my tastes, but hopefully useful. Also available tracked, prettified.

Badness, Enumerated by Robots (2018) -- Way back when, I started setting my systems to collecting IP addresses that were the source of undesirable activity and publishing updated lists at intervals. That activity stayed useful for longer than I had anticipated, and at some point I wrote this summary of what those systems do, with references to other resources, of course. Also available tracked, prettified.

Maintaining A Publicly Available Blacklist - Mechanisms And Principles (2013) After running the greytrap-based blocklist for some years, I felt the need to explain my thinking about the hows and whys. The first paragraph sums it up,

When you publicly assert that somebody sent spam, you need to ensure that your data is accurate. Your process needs to be simple and verifiable, and to compensate for any errors, you want your process to be transparent to the public with clear points of contact and line of responsibility.

-- Also available tracked, prettified.

Yes, You Too Can Be An Evil Network Overlord - On The Cheap With OpenBSD, pflow And nfsen (2014) -- "Have you ever wanted to know what's really going on in your network? Some free tools with surprising origins can help you to an almost frightening degree.". Yes, with tools that are either part of OpenBSD or within easy reach via the package system, you only need to put in rather modest efforts to reveal deep truths about the life on your network. Also available tracked, prettified.

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (2014) -- Originally a BSDCan paper from the late noughties, with emphasis on the exploit mitigation techniques in OpenBSD and how to leverage them in the effort to limit or even get rid of spam and malware. Even after all those years, some aspects of this text are still quite relevant. This piece has seen occasional updates as indicated by the copyright line. Also available tracked, prettified.

The Hail Mary Cloud And The Lessons Learned (2013) -- The Hail Mary Cloud was a widely distributed, low intensity password guessing botnet that targeted Secure Shell (ssh) servers on the public Internet. The first activity may have been as early as 2007, but our first recorded data start in late 2008. This summary article describes the botnet activities and countermeasures as well as offering some more forward-looking statements about Internet security. Also available tracked, prettified.

Those, I said to my correspondent, are likely the more interesting entries.

If you have read this far and found something useful or enlightening by visiting the linked items, that will make me happy to have turned some Sunday afternoon procrastination into something useful to others. And I have this to offer as a bonus for your perseverance:

I have also been a guest blogger at blog.apnic.net:

What every IT person needs to know about OpenBSD (2021) in three parts, starting with What every IT person needs to know about OpenBSD Part 1: How it all started (also the original in one piece, What every IT person needs to know about OpenBSD (tracked, prettified), and

A few of my favourite things about the OpenBSD Packet Filter tools (2022) also ran as a two part series at APNIC, starting with A few of my favourite things about the OpenBSD Packet Filter tools (part 1) and A few more of my favourite things about the OpenBSD Packet Filter tools (part 2)

Upcoming events:

Wednesday, May 7, 2025

For Upcoming PF Tutorials, We Welcome Your Questions

A good tutorial should sound to passersby much like an intense but amicable discussion between colleagues.

In a little over a month, I'll be heading out to Ottawa to attend BSDCan 2025, to help run the conference and to give this year's Network Management with the OpenBSD Packet Filter Toolset tutorial, with my co-presenters Max Stucchi and Tom Smyth.

I've been a regular at BSDCan since 2006, attending every year since except 2008 -- I wanted to go that year too, but other business (actually the business of getting out of a company I'd helped build) kept blocking my preparations even though I had a fresh book out with the first edition of The Book of PF published late 2007. The most recent edition, the ~~third~~ fourth, is available from here and from other good book sources.

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

But I've kept coming back after that, and I've almost always given the PF tutorial at BSDCan, this year again there is a PF tutorial, Network Management with the OpenBSD Packet Filter Toolset, which is likely to follow the format from the previous years.

The format of the session is a sequence of short, intensive lectures interspersed with lab excercises. You can get a reasonable idea of what to expect by looking at the slides from the last sesssion. It can be worth noting that future updated versions of the slides will be available in the same location.

But we're still weeks away from the session, and we are in the period of time when we are making revisions and adjustments. So this is a good time to tell us what topics you would like to see us cover in the next session.

If you have one or more questions or suggestions, please do send them on to us at questions@pftutorial.net, preferably after taking a peek at the slides from the last sesssion.

We will consider each carefully, and if your question or suggestion turns into a new or changed topic, we will give credit where credit is due.

We are looking forward to seeing you in Ottawa in June!

Check out the BSDCan 2025 site for more information on the conference.

If you are unable to attend BSDCan, all is not lost: the EuroBSDcon 2025 conference is still accepting submissions for papers and tutorials, so if you have an interesting BSD-related topic you want the world to know about, your submissions will be welcome at the EuroBSDcon submissions system, where the deadline is 2025-06-21, or June 21st, 2025 (full disclosure: I'm on the program committee). This year's conference is set in beautiful Zagreb, Croatia in late September.

Thursday, March 13, 2025

No Project Is an Island: Why You Need SBOMs and Dependency Management

The system you develop and maintain does not exist in isolation. Providing SBOMs for our work is our way to show we care.

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. 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.

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

What we did not have at all until recently was a set of formal requirements to verifiably show what it is we deliver.

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.

Your delivery would not be considered complete without the Bill of Materials or Manifest.

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.

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.

Until software that made critical infrastructure work broke, that is.

During the twenty-tens and -teens, we had several incidents where software bugs were tickled enough to lead to costly and embarrasing episodes, and the powers that be (the kind wearing suits) discovered that software was indeed something they needed to care about.

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.

This assertion is simply not true, in that no project is an island.

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

All software has dependencies, and in the open source world this fact has been treated as a truth out in the open. 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, and 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.

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, 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 are obvious items of interest.

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, and the lessons learned from package management came in quite useful in meeting and satisfying the updated requirements.

Several pieces of legislation emerged from the at times panic flavored fallout from the security incidents. Which ones are more relevant to you will become clear as we move on.

Depending on what parts of the world you care more about, the emphasis will either be on US Executive Order 14028 of May 12, 2021, Improving the Nation's Cybersecurity and its summaries found at the Software Bill of Materials Home page hosted by the National Telecommunications and Information Administration, or for the EU and our neighborhood, the EU Cyber Resilience Act (CRA) with slightly less hardcore legalese available at the Cyber Resilience Act start page.

So that's our backdrop for now. The name of the SBOM game is compliance with those legal requirements, and to not only 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.

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.

In addition to module or package names and versions, the expected SBOM product will typically include information on any identified security problems such as CVEs and a specification of the licenses that apply to each of the identified dependencies.

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, and 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.

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 poking around was the combination of syft for generating SBOMs and bomber for display and presentation. The home pages for both are linked from the awesome-sbom collection.

As you can see from that page, there are several SBOM formats around, and to some extent standardization and interoperability efforts are under way. But enough of that, let's look at the actual tools in use.

As a first step, it is instructive to point syft at the base directory of your project and see if it can tell you something you did not know already. syft supports a number of output formats, so if XML is the more readable format to you,

$ syft . -s all-layers -o cyclonedx-xml | xq

will give you pretty-printed XML (assuming you have xq installed) output of what syft found out. Do explore the various command line options for extracting various information about your project.

If you prefer JSON over XML, something like

$ syft . -s all-layers -o cyclonedx-json | jq

will give you readable JSON of the same information. Again, there are a number of options to explore.

When you have explored a bit, you may want to look into how you incorporate these tools in your project and make the SBOM a build artifact.

The bomber documentation has this example suggestion for inclusion in a CI/CD pipeline:

# Make sure you include the - character at the end of the command. This triggers bomber to read from STDIN syft packages . -o cyclonedx-json | bomber scan --provider ossindex --output json -

In a real world scenario, I could imagine that non-developers would appreciate it if you supplement that line with one using the --output=html option. The HTML output provides a report that lists licenses involved before listing know vulnerabilites by severity and assigned CVE.

While I was writing this article, a colleague who had been reviewing it told me of an episode that shows that even extremely basic use of the SBOM tools can be useful. A customer had called, saying they needed a complete list of tools and dependencies involved in a project, and right away. As a first step, my colleague cd'ed in to the main directory of one of the subprojects for that customer, and issued the command

$ cdxgen .

and was rewarded with a bom.json file that listed somewhere in excess of three hundred dependencies for that relatively minor subproject alone. The customer was suitably impressed and granted my colleague a more realistic and less immediate time frame for submitting the full dependency tree.

More SBOM-savvy co-stakeholders in your project may even be capable of processing your json or xml formatted SBOMs themselves, using tools of their choice.

Your project and customer may already have chosen a different toolset, or you may find that some other SBOM generating and presentation tool set are better matches for your requirements.

It is in fact conceivable that you have SBOM-capable tools within reach in your environment already. The fairly popular images-and-sundry repository system Harbor supports automatic SBOM generation on image push by hooking in trivy for image scanning duty, should you choose to enable that feature for your Harbor hosted projects.

If you want to explore further, please dive into the resource references at the end here.

For the more Bill of Materials savvy developers who want to explore even more, it may be of interest that the OWASP and SPDX teams are working on more specialized BOM variants, including OBOM (Operating system Bill of Materials), SaaSBOM (Software as a Service Bill of Materials), CBOM (Cryptography Bill of Materials), and several more. Again, see the referenced resources at the end here and follow the breadcrumbs.

SBOM Resources

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

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

EU residents will want to poke around the Cyber Resilience Act site for reference

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

No Project Is an Island: Why You Need SBOMs and Dependency Management is this article (also here)

That grumpy BSD guy

Wednesday, August 6, 2025

Elvis is alive! How 'AI' stunts modern mythmaking

Tuesday, August 5, 2025

Those Titles the AI Bot Thought I Had Written

Friday, July 11, 2025

Yes, The Book of PF, 4th Edition Is Coming Soon

Sunday, June 8, 2025

Should I Stop Caring and Let IP Address Reputation Sort Them Out?

Sunday, May 25, 2025

That Grumpy BSD Guy: A Short Reading List

Wednesday, May 7, 2025

For Upcoming PF Tutorials, We Welcome Your Questions

Thursday, March 13, 2025

No Project Is an Island: Why You Need SBOMs and Dependency Management

SBOM Resources

About Me

Buy The Book of PF

Upcoming Talks

Blog Archive

Links to other nice sites

Popular Posts

Total Pageviews

Wednesday, August 6, 2025

Tuesday, August 5, 2025

Friday, July 11, 2025

Sunday, June 8, 2025

Sunday, May 25, 2025

Wednesday, May 7, 2025

Thursday, March 13, 2025

SBOM Resources

About Me

Buy The Book of PF

Upcoming Talks

Blog Archive

Subscribe To Posts From Here

Links to other nice sites

Popular Posts

Total Pageviews