FLOSS Weekly

It's the OG podcast about Free, Libre, and Open Source Software, FLOSS Weekly! Join us each Wednesday as Jonathan Bennett and the posse of Co-hosts interview big names of Free Software, cover utterly fascinating Open Source Projects you may have never heard of, and cover the news about software you use every day without even realizing it.

FLOSS Weekly is a technology podcast hosted by Hackaday, with 239 episodes on record and a Required Pod Score of 80.

Hackaday hosts FLOSS Weekly, a technology show with 239 episodes published.

Our AI reads these to draft pitches. Use them as grounding for a pitch that cites a real guest and a specific topic.

• 

  FLOSS Weekly

  Episode 882 transcript

  Sep 16, 2026—

  2026-09-15 Jonathan: [00:00:00] time for Floss Weekly. That's the show about free Libre and open-source software. I'm your host, Jonathan Bennett, and today we're talking about, well, open-source, of course. We're talking open-source automation and some experts in that field. I've got Jan Altenberg with me, and he is, I discovered during the pre-show, a German engineer working on, well, a lot of different things, all the way from the pre-empt real-time kernels to being around computers since the 1980s. He started with a Commodore VC-20, the ever-present VIC-20, one of, I don't, I think the Commodore 64 actually holds the record, but the VIC-20 has to be one of the most popular computers ever sold. But yeah, we're talking open-source, we're talking automation, and let's bring the man himself on. Jan, welcome to the show. Jan: Thanks for having me. Great to be here. Great. Looking forward to talk about open source [00:01:00] today. As you mentioned, I've been working with computers for quite some years. Actually, I have to admit that I was not working with Commodore. This was my colleague I'm working with at OSADEL. But actually, for me, it's even more than, I would say, I've spent 35 years with computers. The drawback was that my first computer was running proprietary software, which was pretty sad, but I think I'm with open source since 30 years now. Jonathan: Yeah, yeah, that's a long time. Yeah, I see now that it was Alex, your colleague, that started with the Commodore VIC-20, but still, you've been around, you've been doing this for a while. We were talking before the show about how this interview came together, and I'm pretty sure that it's from where I was at Embedded World earlier in the year. And I took one of the days, and I went to the software wing, because they have like five different halls at Embedded World, because it's a huge show. And I went to the software wing, and I just walked around, and I looked for anything [00:02:00] that had "open source" in the title or that I knew was an open source project. I'm like, "Here's my business card. You should come be on the podcast." And so we finally made this one work, talking about the Open Source Automation Developer Lab. Now, what is open source automation in this context? Are we going to be a very AI-heavy episode again today? Is that the sort of automation that we're talking about? Jan: Oh, well. So, AI is everywhere these days, but maybe it's a bit different for us. So, what is the Open Source Automation Development Lab? As the name says, we do a lot of with open source and automation. So, we are around since a bit more than 20 years, actually. What is interesting for you to know is, I mean, as you mentioned at Embedded World, there's many different companies, right, doing software, doing open source. So, we actually, we do not have the legal form of a company, actually. [00:03:00] So, we are a registered German cooperative. Jonathan: Okay. Jan: So, that works a bit different. So, it's actually that we are owned by our members, So, we do not have a single owner, and we don't really primarily operate profit-oriented, so the thing what people do is, with a cooperative, they gather in a place and put some budget together to do something useful in common interest, right? So, in Central Europe, this is pretty common, for example, for small wine producers, so you might have everything to do the wine, but you do not, cannot maintain as a small company all the infrastructure to sell the wine and do all the production and the bottling and that stuff, and that's why wine producers gather in a cooperative, so they could finance that infrastructure together. And what happens at OSADL is that our members do the very same for open source in industrial products. So, our members [00:04:00] have the interest of using open source in industrial products, mainly in automation, but in other products as well, right? And the reason why we were founded roughly 20 years ago was basically real-time Linux. Which was around at that time, in the early 2000s, and it was proven to work. So, it became of interest for German machine producers, so it rang the interest of many engineers in Germany. But the question for the deciders was: this is a young project, right? So, will the maintainers continue that work? Who can help us with quality assurance, and who to ask, right? And this is why these companies founded OSADEL back then, to, like, provide funding to the real-time maintainers and to do commonly funded quality assurance for real-time Linux. So, this was the main idea. With 10 members back then, so today we have more than 100, and, of course, over the last [00:05:00] 20 years, the interest of our members grew into a different direction, and yes, AI as well. But many different topics, like even licensing topics, that are of common interest, are covered by our community. So, just to sum it briefly up, we're pretty much a community that supports its members in using open source in their products. Jonathan: Gotcha. The story with Realtime Linux has been pretty interesting, too, over the years, because that was a pretty big change to the Linux kernel, and it's something I've been watching and been sort of excited about for a long time, mainly because I do some Realtime Audio stuff. Jan: Yes. Jonathan: And, you know, I remember way back in the day trying to, you know, I was doing crazy things like running live sound through a Linux machine to be able to use plug-ins on the live sound, and it's like, you've got to get your latency down as low as possible, and, you know, we were trying to pull out all the stops and figure out how to do that, and the Realtime kernel [00:06:00] was one of the ways to do it. And I remember trying it one time, and it immediately crashed the machine, because we had to use the NVIDIA driver on that machine. They just, they did not work. They just, they did not play nicely together at all. We've come quite a ways now that, I mean, it's landed in the upstream kernel and everything. Jan: Exactly. Yes. Jonathan: Yeah, how much of that story were you involved in? Jan: Pretty much the whole story, actually, pretty much the whole story, because that was the topic that really got me into open source, right? Jonathan: Huh? Jan: So, I got my first Linux installation when I was 15, but that was just like out of interest, wanted to try things out, and the cool stuff about open source was that I could look into stuff and figure out how it was working. But what happened in my studies is that back then I was working for a machine producer and doing my thesis, and they were evaluating Linux as the next generation operating system, and I was in charge to look into real-time Linux. So, back then in 2004, [00:07:00] I started doing my thesis on real-time Linux and porting machine controllers to real-time Linux, and since then I've been following the whole history. of real-time Linux supporting people using real-time, helping people with testing, evaluating new use cases. So all over these 20 years, this was a big topic for me. It was always a pleasure for me to present on conferences about real-time Linux. So at some point I really got passionate about that. So really one of my favorite topics. And you can imagine that the very day when the pull request got merged, enabling preempt RT in the mainline kernel was a very, very special moment for me. And it actually happened pretty much exactly 20 years after I submitted my thesis for review. So it was quite some time. Jonathan: Ha-ha-ha-ha-ha-ha-ha! Jan: So I really still, I think the maintainers can be really proud. It was a very [00:08:00] big change. And I think you mentioned a very interesting aspect because I mean, having this in the mainline kernel is great, but just look at all the things that happened over these 20 years because, Like you mentioned, you enable real-time and drivers start crashing. Because you didn't have proper locking or something, some serialization did not work, but, I mean, you immediately discover that when you have full preemption, right? So, I think there was a big quality jump for many drivers in the Linux kernel with real-time, and apart from that, I mean, just look at the tracing infrastructure, the high-resolution timers, generic interrupt handling, and so on, and so on. All these nice features, threaded interrupts, all these features are there because they came from the real-time development, and I think it's, for me, it's always a very good example on which synergies you can have with open source, right? Because people develop the real-time for a specific [00:09:00] use case or specific use cases, but they made Linux better for each and anyone, right? I think it's one of the best examples you could have on how open source works. really helps you saving efforts. Jonathan: Yeah. There's a sort of parallel, something that I just became aware of here recently. So, the real-time effort, is it fair to say that part of the reason for that was to be able to use Linux in automotive cases? Jan: Partly, partly. So, I think the first heavy use cases was automation, was even big server machines that did high-speed trading and stuff, so they had to do deterministic calculations and stuff, so these were the first early use cases on that, and that maybe was the enabler to slowly push it also towards automotive. Jonathan: So, I was at a talk in London, and I think it was [00:10:00] an NVIDIA engineer, interestingly enough, but he was looking at the question about using Linux and automotive and doing safety engineering around the Linux kernel. Jan: Yes, yes, that's a big topic, yeah. Jonathan: And the things that he was describing that would have to be changed in the Linux kernel, I was sitting there going, "my goodness, this is a lot of work for, you know, just to..." Jan: Yep, yes. Jonathan: I am always a little skeptical, this is just me, but I'm always a little skeptical of some of these, like, engineering-proof things, like, we can make the kernel safe by doing this, and I'm like, I mean, it's kind of like moving code to Rust, right? Like, yes, you can fix this class of memory bugs, but you also have this other class of bugs that Rust doesn't help you with at all, and so I was sitting here listening to this presentation going, "This doesn't necessarily guarantee that it's not going to crash." But all that to say, I see an interesting parallel between the 20 [00:11:00] years that it took to get real-time into the kernel, and now this sort of growing interest in getting Memory safety, but also, like, you know, big iron engineering safety, or I forget even the term that they use, but the amount of changes that that would take to land that in the kernel. Is that something you guys are involved in at all? Jan: Yes, actually, so we're still following that. Jonathan: I'm not surprised. Jan: We do that for 20 years now. Actually, we've been actively involved in safety efforts for the Linux kernel. So, we did run quite some time ago, we ran a project which was called CO2LinuxMP, which was actually looking into what could be proper strategies to get safety certification for Linux-based systems. So, we built some know-how in that area, and as you say, this is maybe still a different story than real-time, because that effort is definitely huge. [00:12:00] And we're still a bit involved in the ongoing efforts. For example, there's the ELISA project going on. People still look into methodologies. So, the interesting part of all the efforts that are still around there is not that someone is looking into getting specifically a certification, right? The thing is, what would be the proper mindset? What might be the tools and strategies? Because if you take an operating system like Linux, right, it hasn't been developed following a specific process, right? So, it hasn't been developed following a safety standard. So, what routes you could take, you need to see what route to take Using something existing and prove that you can make it safe, right? And this is pretty much what all these people are these days looking into. How can you adjust the development process? How can you prove that things are good? How can you improve? How can you do documentation so that in future it might [00:13:00] be easier to get that kind of certification? Because I'm quite sure, or I am sure, I'm aware that certified open source systems are around on the market, right? The question is just, in this case, it was always very individual effort, but can we make this the common case? And I think this is the next big step for industry. So, the first big round for industry was, okay, they need real time, and the next big question is, can you get safety certification? Jonathan: interesting to watch. Do you think it's going to take another 20 years? Jan: Well, I gave up doing estimations, right? I did do quite a few estimations for real-time Linux, right, and at some point, we always kept saying next year because there's, of course, always a next year, right? Jonathan: Right, right, right. Jan: So, I don't want to do estimation there. I can say I am confident that this [00:14:00] can happen because so many companies are looking into that way. And open source became of interest for many different industries because they are independent in their decisions, and maybe also for security reasons because the software they have is just open and transparent. Jonathan: Mm-hmm. Jan: So, I am confident that there will be ways, but it's hard to estimate how long that will take. It will definitely be a way bigger effort than just getting real-time into Linux. Jonathan: Sure. Europe is kind of making a move as a whole, even due to some regulatory pressure, I think, towards open source solutions, specifically away from Closed source solutions coming from U.S. companies. I think that's part of it, but I see it as sort of a bigger trend just away from proprietary solutions and towards open source solutions, which I love. I think that's great, and [00:15:00] I think every country should be thinking about that. It absolutely makes sense to me. Jan: Yeah, I think there's two aspects on that. So, definitely, there's a European strategy on getting more independent when it comes to software, so there's a European strategy in looking into open source and trying also to push countries to move open source. So, this is an effort I really appreciate. There was actually recently also the possibility to submit ideas and arguments to the European Commission on what do we need for European open source strategy. So, even the European Commission is looking for feedback, so each and anyone was possible to submit. So, this is one thing. So, there is a strategy there. If you look into that from an engineering perspective, I think, this is something that arrived on the market quite earlier, [00:16:00] before we had that strategy coming up from regulatory side. It's like that, I mean, sooner or later, you realize that, I mean, just imagine you're building So, what happens with proprietary software very regularly, and I've been through that, you need to do updates because Well, you don't get support anymore for the old version, so you need to rework a lot of stuff without any real need, right? So, this is a pressure and a burden you basically don't have with open source, so you have way more flexibility. It's basically up to you what you use. Of course, you need to update, you need to maintain. But, I mean, you can look into the software, you can do it on your own, and you can decide who can support you, right? There's [00:17:00] so many brilliant minds, so the thing is you're not bound to a single entity, right? So, it's still work to do, but you become way more independent, so this is one aspect to avoid these. There are artificial release cycles that you don't really need, right? So, and the other thing is just when you debug real-time topics. So, when you're with proprietary systems, you usually always get to the point where you see, okay, data is going in and gets back too late. So, you can open a ticket and that's it. Jonathan: It's difficult to try to troubleshoot the inside of the black box. Jan: So, if you're using real-time Linux or anything else, or Zephyr or something that is open source, you can just see what happens, right? Exactly, exactly. Jonathan: In the past, probably 10 years, I've had a couple of times now, people have come to me with, in one case, it was a Windows 3.1 machine, [00:18:00] in the other case, it was a Windows 3.1, I think one Windows 95, and one Windows 98 machine, and they've all come to me and gone, "This is incredibly important for our business use case. Please make it continue to work." DOSBox to the rescue, by the way, is an incredible piece of software for making that happen, but yeah, it's ridiculous. Jan: Yes. Jonathan: You see these businesses that are locked into their old solution, whether it be for hardware or for some old piece of software that nobody has the source code to anymore. It's incredible, and I've seen it several times, yeah. Jan: That's it, yeah. And I think that was a very good example, because the fun fact here is, in many cases, open source emulators save proprietary software, right? Because you can still run it, [00:19:00] right? Jonathan: Mm-hmm. One more time that this happened to me, it was a doctor's office, and they had their old back-office system running on an old SCO Unix box. And they were like, we need to be able to fix this, keep it working, and get backups from it. And this has been, again, probably 10 years ago. And I said, okay, I can do that. And I did Fedora install and set up QEMU and virtualized their old SCO UNIX box and got it working. Which is interesting, because the SCO UNIX lawsuit was in the news one more time in the past couple of weeks, which is what brought that to mind. Jan: *laughter* Jonathan: But yeah, it's a problem all over the place of people getting themselves locked into these ancient systems. Jan: Exactly, but I think people started to learn from that once again. I think that message arrived, and people start rethinking, so we can see that over the last 20 years, now after 20 years of using open source, I was at the position where I thought, okay, now all industries should be aware about open source. There's still nowadays, still industries, still now switching from proprietary systems to open source. [00:20:00] Even these days. Jonathan: Yeah. What are some of the other projects that the lab is involved in? We've talked about real-time Linux and the safety-critical stuff, but I'm sure there's some other things that you guys have your hands in. Jan: Of course, there's many. So, we could talk days. Now that Alex wasn't able to join us, I should briefly mention Alex's work, which is closely related to real-time Linux, but not only just related. So, I mentioned that one of the reasons why Ozan was founded was quality assurance. So, what we do is, we do run quality assurance for more than 200 embedded systems in our lab. So, these boards do come from our members, or we choose them on our own, but basically they do come from our members, and they want to see how stable are these boards operating 24/7. Of course, real-time behavior is one topic we look into there, because the [00:21:00] thing is basically that with operating systems like Linux running on modern processes, It's not that easy to prove the real-time behavior. In the good old times, you just did a code path analysis, and with old processes like M68K, you exactly knew, "I have this number of assembly instructions, and it will take that time to execute." Now, estimating the execution time on a modern processor is close to impossible. So, you have at least two or three caching levels. You have branch prediction. You have SMIs. You have microcode patches, and so on, and so on. So, the only thing what you could do is to evaluate and to colle

  ListenShow Notes
• 

  Episode #882

  Episode 882 - Better Together

  Sep 16, 20261h 10mS4

  This week Jonathan chats with Jan Altenberg of the Open Source Automation Development Lab, a cooperative of nerds that care about Linux and Open Source! Jan and OSADL helped push Real Time Linux across the finish line, are looking at safety critical hardening, and general cooperating to make Open Source and Industry work better together. You can join the conversation in the Hackaday Discord , watch live or get the video version of the show on Youtube , as well as getting the full story and show links from Hackaday . Oh, and follow the official Mastadon account ! Theme music: "Newer Wave" Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 4.0 License http://creativecommons.org/licenses/by/4.0/

  ListenShow Notes
• 

  FLOSS Weekly

  Episode 881 transcript

  Sep 9, 2026—

  FLOSS-881 Jonathan: [00:00:00] It's time for Floss Weekly. That's the show about free Libre and open-source software. I'm your host, Jonathan Bennett, and today we're updating. In fact, this is a topic that was not on my radar, but one of our listeners, thank you to everyone out there, said, "Hey, you guys really need to talk about Update CLI." And I said, "I don't know what that is, but we'll send the email." And so we emailed Olivier Vernon, who is our guest for today, and we said, "Hey, we would love to talk to you about this." And he said, "Sure." And so we've got him on the show. Olivier is the guy behind Update CLI, and unfortunately, I just got logged out of my email address that has his bio. Let's see if I can get back into that. We're doing it live, as they say. But let's go ahead and bring him on, and then I'll get back to the bio. Olivier, welcome to the show. Glad to have you here. Olivier: Thanks for having me on the show here. Yeah, I was really [00:01:00] glad to hear that you would contact me. So, I've been following what you did here for a few years, so that's really nice to hear. For the BIOS, quickly to talk about me, so I'm working, so I've been working on open source software for the past 10 years, both professionally and on the side as well. Jonathan: Mm-hmm. Olivier: I've been contributing to open source conferences and so on, so the biggest one is probably the FOSDEM for those people who know what FOSDEM is about. And so, the reason why I'm Jonathan: Oh, okay. Mm-hmm. Olivier: here today is because I was interested to talk about that side project that I've been maintaining for five years, which is all about updating your Git repositories, and so, yeah, that's why I'm here. I don't know if, yeah, the project is named Update CLI, so for people who are not familiar with this, it's kind of interesting because there is no, like, similar project, but it's a CLI. I mean, you can guess based on the name. That allows you to automatically update your Git repositories based on [00:02:00] manifest that tells you how to update those Git repositories. So the purpose is really to help you on the maintenance of your projects, and so you stop monitoring third information coming from the web. You just define, okay, you have a Git repository. What would be the latest information, URL, version, whatever? So, people usually, when they think about Update.cli, think about Renovate or Dependabot, which is kind of the closest, I would say, project for what it does, and otherwise, it's just bash scripts, Python scripts, and so on, so it's kind of a seed between the two worlds. Jonathan: It's amazing to me to see, like, how much of the world is run by nothing more than a pile of Bash scripts. Olivier: Yeah, exactly. And it's like, yeah, Bash is really awesome, until you reach some limitation. Jonathan: Oh yeah, absolutely. there are elements of it that drive me crazy um and in fact there is a uh several years ago we interviewed another project called amber that they were like [00:03:00] we love bash except for this set of things that's terrible about it so we made our own scripting language that compiles down to bash code it's like well that's cool um okay so what's what is this what does this problem look like like at what point does someone reach for update cli what where in like an open source project or just you know your your homebrew whatever it is you're doing what what does the problem look like Olivier: So, the problem was, back then, like five years ago, when I started working on a project, I was working at the time on the Jenkins project. We had a lot of Git repositories, Java libraries, and so on, and one of the projects which is still running today is the infrastructure where we run the Jenkins, where we test Jenkins, and so on, and so all that infrastructure is managed by infrastructure as code, like Puppet, Kubernetes, and so on, and one of the Jonathan: Mm-hmm. Olivier: problems I was facing back then was, quite regularly, someone would build a new application, and then I would forget to update that application on [00:04:00] the Puppet infrastructure, or Kubernetes Jonathan: Gotcha. Mm-hmm. Olivier: infrastructure, and so on, and the thing is, back then, I was already using tools like Dependabot, or Renovate, but the challenge is, those tools can understand a file that is well-structured. Like, if you think about, I don't know what language you're most familiar with, but let's say you think about GitHub. GoLang has those GoMod files where you specify the list of dependencies. That's a file which is pretty easy to understand because you can have a tool that runs automatically there and bump those versions. That's where Renovate, for example, shines. But the problem is, quite often, you have those bash scripts, for example, where you define a version, a variable with version set to something, and it's just impossible to automatically update that bash script because you have some meanings. I mean, you know the purpose of the bash script because you wrote it, and now you need to maintain it over time, and the problem is, quite often, you have a lot of pieces of information hidden [00:05:00] everywhere and you need to coordinate, and so, instead of having, like, Dependabot to bump one PR, what I do is I say, okay, I'm monitoring this application version. That's exactly how it started. I'm monitoring this application version, let's say the account app, which is a custom application, and now, based on that information, what I want to do is I want to update my Puppet infrastructure, but only if there is a Docker image matching this tag. And I also want to open one PR for the Kubernetes manifest at one time. So, I don't want to have, like, three different PRs. I just want to have, like, one PR that I shoot at once. And so, that's how everything started. So, the idea was really to say, to define what my update strategy looks like is I say, here is information that I'm looking for, like sources, and then you have, like, different kind of source, but the source is where the information is coming from. That could be a version, a random string somewhere in the internet, whatever. That's the information you need to reuse. And then you have the condition that needs to pass, like, do we have a Docker image? Do we have a file, a Docker file with [00:06:00] that information? Do we have README, whatever it is? And then do we have a target? The target is what you want to update. And so, once you have this manifest that tells you, here is what my ideal update scenario is, then each time you run update scenario, which is a command line tool, it's idempotent. The result is always the same. You run it from a CI, for example. And then every time it runs, it will fetch all the latest information, verify that your Git repositories are up to date, and if it's not, then you just open a PR, and then you can run it. Review this, and then the lifecycle of your project keeps working. So, the challenge is really about how to maintain a lot of Git repositories without having to remind yourself to go fetch all those information. And when you think about this problem, it's something that is a really huge problem. Jonathan: Mm-hmm. Oh, sure. Yeah, because a lot of open-source projects, they do, they define, you know, their various libraries and their various dependencies inside [00:07:00] of their build scripts or, you know, various places. Sure, yeah, it's something that I deal with in some of my projects as well. I think we use Renovate for this, which works most of the time. Most of the time, it works 99% of the time, right? Yeah, so what did, did Renovate not, no, you said Renovated existed. What was the, what was the big differentiator? What did, like, Renovate lack that you really wanted to solve? Olivier: So for me, the biggest limitation was having the flexibility to really say, first, to run the tool whenever I need it. That's one thing. And the second one, to really be able to say, here is a complex pipeline. And when I say complex pipeline, I can, for example, provide another example. Jonathan: Mm-hmm. Olivier: When I build the update CLI, I create a new release of update CLI. Let's say version 0.1.0. The way it works is I use a super cool project, which is GoReleaser. GoReleaser is responsible to create the packages and [00:08:00] so on to publish that information somewhere. And then at the end of this, I use GitHub Action that sends notification to other Git repositories. And those other Git repositories, for example, one, for example, contains the handshots, if you're familiar with Kubernetes. One contains the documentation, if you're familiar with running Yugo and your websites. And so the way it works is on those repositories, I trigger update CLI. Based on a hook. And then update CLI will automatically retrieve the latest version of my application, update the documentation, update the Docker image, update the handshot, literally update everything, and then start other processes. And so it just allows you to run, like, to monitor information, run shell commands, and in a specific order that really allows you to just think about whatever ecosystem you want to work on. Jonathan: I'm curious: have you thought about or run into the the git tag problem? And this is sort of a security issue [00:09:00] that we're seeing in a lot of different cases. The idea there being that If, you know, if someone malicious takes over a remote repository, they can delete and then replace a git tag really, really easily, and so I've seen people start to recommend that instead of, you know, include this git tag as your dependency, you should instead say include this git hash as your dependency. And I get it on, like, the security side, that makes a lot of sense. It seems really cumbersome, though, to work with. Is that something that you've thought about as part of UpdateCLI? Is there a solution there, maybe? Olivier: So, that's definitely something I thought about many times, and we experimented different things. So, before I go into that specific, so we can better understand this, Update.cli is like plugin-based. Like, you can interact with a lot of different plugins, and so, for example, you have a plugin for git commits, like you mentioned, and then you can say "please monitor the latest git commit", or you can [00:10:00] say, like, "please monitor the latest docker image tag", for example. And specifically for the git commit, but that's the same thing that would happen, for example, to any OCR artifacts, like docker images. Usually, it's recommended to use Digest, but the real issue with Digest is, as a human, Digest are just impossible to review. Like, you receive a PR, you have, like, a bunch of Digests, and then you just merge blindly, and in the end, from a security perspective, you're not really reviewing anything anymore, because you're just, like, trusting the automation, which is something you should never do, anyway. And that's why we try to use both. So, for example, usually I like to specify the digest, because at least I'm sure what version I'm using, or what piece of information I'm using. I also like to use the commands that specify "this digest corresponds to this information". So, for example, in GitHub Action, for example, you can specify both information, and then me, as a human, I can just quickly check if the version [00:11:00] really matches the commits. And then you have tools that also allow you to verify these things. Like, I don't know if you're familiar with the project Zsmore, if you're familiar with GitHub Action. So, Zsmore is a kind of a linter that you could use for GitHub Actions, and then it allows you to verify if your GitHub Actions are well configured. And one of the things that it checks is: does the version you specified in the command correspond to the git commit? To be sure that you don't have a malicious actor that just tells you that it's a version 1.0. that just tells you that it's a version 1.0. And in the end, it just pushes a random commit. So, yeah, the digest is something very tricky. I usually recommend to use digest, but also try to provide as much information as I can to allow humans to verify this, because in the end, otherwise, it's meaningless. Jonathan: Yeah, it all seems like the the best solution here is going to be to add some metadata, maybe as a comment, or, you know, it's hard to say exactly where, it's going to depend upon the language you're working with. But, you know, your metadata would be, here's the tag, [00:12:00] here's the version we think it is, and then the real thing that you go out and you grab is the hash itself. That way, you know it's not going to change if somebody doesn't update, but then you have also got that tag information, so where you can watch and, you know, "Hey, you're running v1.1.1 based on the metadata, v1.1.2 is now available, do you want to update your corresponding hash to match?" Yeah, that seems like the best of both worlds, and if you're running a plug-in system, probably that's something that could be managed fairly easily. Olivier: Yeah, yeah. And there is another concept which has become quite popular over the last years, I don't know if you heard about this, it's the idea of cooldown dependencies. So, the idea is, instead of always updating to the latest version, you should specify your small threshold, like one week, three days, it depends on the ecosystem and how often you want to be up to date. But the idea behind the cooldown dependencies is, if a malicious actor gets access to one of your dependencies, it's going to take a few days, maybe a few weeks, for the community to realize that something [00:13:00] wrong is happening here. And so, instead of updating to the latest version as soon as possible, then you need to get the, maybe wait one week. This also comes with limitations, and that's one of the things that is very interesting to work on in this field is, you need to fit to every ecosystem. Every ecosystem comes with different APIs, they expose different metadata, they sort information in a different way, which means that having a tool like Dependabot that just works in most of the case, the reality does not Jonathan: Mm-hmm. Olivier: because it will probably catch only a few of the scenarios. And sometimes you need to be able to specify and say like, okay, I need to update at this frequency with all those information altogether, opening one PR. I also know that I would like to add additional information because for this specific scenario, I'm getting like a changelog coming from this endpoint, which is not a standard behavior, but that's everything. Jonathan: like, node NPM packages [00:14:00] update very differently than your C or C++ system packages, Olivier: That's all we have, basically. Jonathan: and it's useful to have one tool that sort of speaks both of those languages. Olivier: Yes, and the thing is, and that's a tricky That's another tricky problem here is when you think about one of the early design decisions I made with Update.client because that's something I really want to have is I wanted to have a standalone tool. So I choose Golang because I love Golang ecosystem. I wanted to have a standalone tool. I could run the same command from my machine or from CI. That's my learning from managing CI infrastructure is that you should be able to run the same commands from both locations. The result should always be the same. I didn't want to maintain a state. So I don't have state file like Terraform, for example, because it's a constraint that I put on myself since the beginning. Sometimes that makes things a bit more difficult. But at least if you run the same command as me, the result will be exactly the same. You will open exactly the same PR or [00:15:00] you would open update the same PR. But the thing is, yes, when I'm talking about ecosystem, every ecosystem comes with its own tooling as well, and the purpose is not to reinvent the wheel. And so, the approach that we made is, UpdateCLI is kind of a framework, like you can use, you can write manifest to update your scenario, but sometimes we just shell out to a command, because we don't want to reimplement, like, for example, YARN, or NPM, or C++ tools. So, for example, the way it works is, you can say, here is just a file, like, for example, NPM, it's a JSON file, you update the JSON file, and then at the end, next step is, if the JSON file was modified, then please run these commands, and if the final package of JSON was modified, then open a PR. And so, you can have both of the two scenarios where you can, I mean, you can really have a lot of flexibility in the way you design your pipelines. Jonathan: I know this is tool [00:16:00] abuse, but it comes to mind: can I use Update CLI to keep a system up-to-date through, like, RPM packages? Olivier: That's a good question. I want to say yes and no. Jonathan: Yes, you can, but you shouldn't, is probably the answer. Olivier: Yeah, exactly. The challenge is, what should be the latest, how do you monitor the latest version? Like, for example, for RPMs, you need a database that you need to query. That's a question I've been asked multiple times, because people love immutable Docker images, and they would like to be able to specify and to kind of re-implement the NixOS, where you can just list the dependencies and so on, I know people using FDCLI in that context with NixOS, but yeah, it also comes with limitations. Jonathan: Yeah, so you wrote it in Go, right? What was the thought process behind Go, as opposed to, I don't know, C++, Python, Rust, Bash, any of [00:17:00] the other options? Olivier: The thing is, because I'm working, I've been working in infrastructure for a long time. I've been working with communities for a long time. So Go is kind of the default tools we use in cloud environments. And you also have a lot of libraries. So it's super easy to use. One of the things that I love with Go is you have a lot of conventions. So we all write the same codes. So if I look at someone else's code base, it's pretty easy to read. Today with AI, it works quite well as well because the code it can generate is kind of the standard generated Go codes. So that was easy. And the other thing that I really love is it can generate binaries. I mean, statically linked binaries, but binaries for every distributions. That means that when I work, I mean, you can use a baseline with Mac OS, Linux, Windows. Jonathan: cool. Do you have an idea of how many people are out there using UpdateCLI? Olivier: It just works. Jonathan: [00:18:00] It's very hard to answer most of the time, yeah. Olivier: It's very hard to tell, because the thing is, Update.cli is designed to run in a CI, so I can definitely give you numbers, because those are public. You can see, for example, from So, I think it depends what numbers you look at, but I think I have basic telemetry for Update.CLI, so, for example, when Update.CLI runs, it checks what's the latest version, and for that, it queries a JSON file, so I know, like, how many times Update.CLI created a JSON file, and it's something like probably 600 executions per hour. So, somewhere, somewhere in the world. So, that's the current ratio. It's like, we have six, seven updates in execution every minute. No, yeah, that's probably the best matrix that I have. Otherwise, the number of downloads is really huge. But once again, because it's executed in CI, how [00:19:00] many of them is really human? Like, I think, I like to use, for example, matrix for Darwin, like for macOS, because macOS, You never use Mac OS and CI probably. And so I have something like maybe... Two, three hundred downloads for every version, but for Linux and Windows, it's a lot more, but once again, it's difficult to tell. Jonathan: Yeah, because I mean, we all start with the same CI image on GitHub, and then you install your tools inside of it.

  ListenShow Notes
• 

  Episode #881

  Episode 881 - Eating Its Own Tail

  Sep 9, 20261h 5mS4

  This week Jonathan chats with Olivier Vernin of Updatecli, the tool that helps you update everything! Need to roll out dependency updates intelligently? Or even automatically deploy to a server on changes? Updatecli can help! You can join the conversation in the Hackaday Discord , watch live or get the video version of the show on Youtube , as well as getting the full story and show links from Hackaday . Oh, and follow the official Mastadon account ! Theme music: "Newer Wave" Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 4.0 License http://creativecommons.org/licenses/by/4.0/

  ListenShow Notes
• 

  FLOSS Weekly

  Episode 880 transcript

  Sep 2, 2026—

  FLOSS-880 Jonathan: [00:00:00] Hey, folks. This week I talk with Benjamin Samuels of Trail of Bits and we're talking about Patch the Planet. That's the Trail of Bits initiative to help open source projects deal with the absolute tidal wave we're all seeing of pull requests, bug reports, and vulnerability disclosures. This is Floss Weekly, episode 880, recorded Tuesday, September the 1st. The two wolves It's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and today we're talking about something really cool. We've got Benjamin Samuels of Trail of Bits, and he does their boring blockchain thing that we may cover a little bit. But the other thing he's involved in is Patch the Planet, which is all about helping open source projects with security problems. And reading the notes ahead of time, I happen to know that, take a drink, we're gonna talk about AI. But not necessarily the [00:01:00] everybody should using it, but this is causing a problem for some open source projects. Like, how do we deal with that? We'll get into all of that. Let's go ahead and bring him on. Benjamin, hey. I'm super glad that you're here. Welcome to the show. Benjamin: Absolutely. Thank you for having me. Jonathan: Yeah. So tell me... Let's see. Where do we start? You've got a background in electronics. You were telling me before the show started that was your college major. And you found Hackaday way back in the day- Yeah ... looking for I think like a lot of us did, looking for information about what's practical for me to try to tackle in the electronics world? Benjamin: Yeah. Back in the day, back in college, poor college kid it's really hard to figure out, what kind of electronics projects can you actually do on your own that you don't need a whole lot of equipment for? And it was way back before Arduino like you a- if you wanted a microcontroller, you had to buy a pick, and you had to buy a programmer, and just getting into stuff could be like, $500 to $1,000. And the real struggle was, like, looking for projects that, [00:02:00] I could actually tackle. 'Cause, you're learning electronics, you wanna actually do it. But it was a really high barrier for entry, and Hackaday was a s- a source of some of my earliest projects, just trying to reproduce what other people had built. It's a lot of fun. Yeah. I remember I've told them this story ahead, before the show started, w- when I was first trying to run some ethernet and trying to figure out how to terminate ethernet. I think I learned that from Hackaday, and that may have been one of my first exposures to this world that we now all live in. Jonathan: But one of the other really interesting things I did very early was toner transfer method for making PCBs- Yeah ... and that was surprisingly easy for a, I think, t- maybe teenager, either teenager or college student, myself at the time, to get into. It's like, 'cause you could get a magazine and print onto the magazine. S- if you had the right kind of printer that did waterproof toner, and then you could take, and you flip it upside down, and you put it on your PCB board, and you take an iron and iron it, and the toner would transfer. And you could caref- I think you had to use water because you wanted that, you wanted the paper itself to disintegrate and leave the toner [00:03:00] behind. And then you could dump that into a bath of what was it? Hydrochloric and muriatic acid, the mix? Something like that. Yeah. And it would etch the copper, but leave where the toner was. And so that was... I, man, I remember that. I have... I still somewhere around here, I have a device that I built that way. It was a- ... headphone preamp. My, my first foray into playing with tubes as well. Sup- super cool times, man. I hadn't thought about that in a long time. Thank you. Thank you, Hackaday. Benjamin: Thank you, Hackaday. Yes. Jonathan: So you kinda went from the hardware to the software and security, and you're now at Trail of Bits. What do what do you do at Trail of Bits? What's your job there? Benjamin: So I'm the director of engineering of the blockchain practice and we're a part of a larger group called Assurance, which means software assurance, trying to make sure that software is secure and to have all kinds of companies out there that have very high impact software where if there was a dangerous bug in it it could be extremely expensive and have a lot of consequences. And they'll want an external review to understand what have we missed about this? [00:04:00] What do we not know about our software that we should know? What kind of bugs are there?" And they'll come to a company like Trail of Bits, and we have a couple of different practices. So like mine's just blockchain. We have a cryptography pra- practice. We have AppSec, we have AI ML, and we have a lot of these people who are very specialized in what they do in the security field. And we could just pull in whoever we need for whatever type of project. So if you have someone building like end-to-end encrypted software that, runs in a web application, like we could grab an AppSec engineer and a cryptographer and have them all work on it. But yeah it, we mostly review code. We do design reviews, threat models. My day-to-day is helping everyone, figure out what to do. We also spend a lot of time contributing to open source. We only spend about 60, 70% of our time on client work. The rest of the time we spend trying to improve ourselves, contribute to open source build new security tools, and publish those tools. Jonathan: Okay. That's ... i've, I know some other [00:05:00] businesses that do that as like part of their policy, and I always thought that was a really great idea because, as you look through history and some of the places like Bell Labs really springs to mind. And it's like those guys, it's just "Here's a lab, here's a paycheck, go do cool stuff." Yes. And we got Unix out of it and, a whole bunch of other things were developed at Bell Labs. And whenever I hear a company that, that at least gives their workers o- one day a week, it sounds like that's about what you guys are doing, something like that- ... just to go make cool stuff. I think it's great because, you get all these u- unexpected things that come out of it. Benjamin: Yeah. The, and people think of all kinds of crazy ideas. There was this recent hack with OpenAI and Hugging Face, and, these agents that broke out of these containers. And we had an engineer who's really interested in this, and he set up like a, a QEMU container environment- and put GPT-5.6 cyber in there and said, "Break out." And it broke out. It found a bunch- Wow ... of vulnerabilities. I know, [00:06:00] it's crazy. And it's i- if he didn't have the time to, sit down and actually put that together we would have n- never known, there's a lot more of these containerized environments that aren't, able to withstand these frontier cyber models. Jonathan: And so that's... I feel like that's probably the direction we're gonna go with the majority of this talk. And it all ties together because you were talking about this idea of assurance in these commercial projects. All of this commercial stuff is built on top of open source code. Like- ... almost inevitably, there's open source code somewhere in the stack. Yes. And, that's been a... It's been a concern, it's been a concern for some people for a lot of years now. A business may be able to audit their code, but are they actually going to be able to audit all of those open source tools? And, on some of these open source projects, nobody is getting paid professionally to do the work, and so there's these- ... questions about code quality. Now, ironically, I have seen some closed source code bases, and I've looked at a lot of open source code bases, and generally, the open source code bases are a lot prettier and a lot [00:07:00] healthier. So there's some inversions of expectations, but I think it's still an important topic to think through and that, that question in particular about is anybody getting paid to do the maintenance on this in the- ... open source world is a r- really important question. What... how does Trail of Bits fit into this, this whole question about code quality and open source? Benjamin: That's a good question. So our most recent initiative has been... should I go into Patch the Planet? I- 'Cause I feel like that's, like- Take it- ... probably our highest touch area. Jonathan: Take it whichever direction you want to. I think Patch the Planet is where we eventually wanna get, but there's- We'll eventually get there there's cool stuff to talk about. And absolutely. Benjamin: I'm gonna loop back to blockchain, 'cause one of the unique things about blockchain, w- whether you like it or not, something that's interesting about it- ... is that almost everything is open source. Yes. People open source their smart contracts, they open source their node software, they open source all of this stuff. So security engineers or security researchers can look at it all that they want. And w- we've been able to look at these things that get open sourced, and we've been able to look at the [00:08:00] ones that people keep closed source, and there is a quality difference. Because if anyone can look at this open source stuff they can file a bug as long as they actually have established a way to file the bug. They can provide feedback, they can criticize. And there's also a big monetary incentive to do this in blockchain specifically, 'cause blockchain really leans into these bug bounty programs in a way that a lot of the rest of the industry doesn't really use them quite as much. There's even a bug bounty program that pays out $4 million on their top bounties, and it's completely unheard of in the traditional security space. And in my opinion it leads to the s- software being a lot more secure- ... 'cause there's so many more people looking at it, and there is a financial incentive not only just to get those bounties, but also if you're able to hack one of these blockchain things, like you can actually steal money. So there's- Yeah ... really real stakes there. And I'm still definitely a lot more bullish on open source being the way to secure software or [00:09:00] d- open source having more secure software- ... than these closed source approaches. Jonathan: Yep. I g- I gotta tell you my two takes on blockchain real quick. One is pretty serious, and the other one is trolling, but also serious. The first one is blockchain reminds me of the invention of the laser. It's really cool. We're still trying to figure out what to do with it. Yeah. It's the invention looking for solutions to go solve. And then the other one is we already have the killer app for blockchain, and it's Git. Benjamin: I know, right? Jonathan: That technology's already proven its worth. Now, the whole making money out of it, not qui- not quite as sold on that. Benjamin: Exactly. Jonathan: All right. So I think this is probably a good place to transition into Patch the Planet. What, what is that what is that effort from Trail of Bits? Benjamin: So the idea behind Patch the Planet was that I think it was earlier this year, it became very clear that these frontier models their cyber capabilities were starting to get to the point where they might be extremely dangerous. It wasn't until I think earlier this year that we were able to take [00:10:00] a, a frontier model, ask it to find bugs in a code base, and actually have it find meaningful bugs. ... You started to see this a little bit with Anthropic, with Project Glasswing. So what they did is they took Mythos, which was their new model at the time, and they ran it against a bunch of open source stuff and found tons and tons of high severity issues. And there, there was clearly going to be this transition shift or phase shift where if everyone has this powerful cyber capability, anyone can run it on anything and be able to find a bunch of bugs. And so we have this huge installed base of open source software out there. You've got, the Linux kernel, you've got, all these frameworks, you've got all this compression stuff. And all of them are gonna have bugs in it because there's one constant in software security, and s- It's that software has bugs- Yes and you're never gonna be able to change it. Jonathan: Absolutely. Benjamin: So all of a sudden these bugs that previously you had to take a specialist and have that specialist or [00:11:00] security researcher or whoever spend a bunch of time trying to find these bugs and figure out how to exploit them and write up POCs, and that's really expensive to do from a time and money perspective. And when you take the, the cost of that and you reduce it you increase the risk profile to everyone, everywhere. And so the idea behind Patch the Planet was to take OpenAI's latest cyber models and apply them on open source projects to try to find these bugs, patch them, and reduce the risk profile that they have. Another challenge with this is just patching the bugs is almost impossible. Daniel Steinberg has been writing about this with Curl. Earlier this year they were receiving all these bug reports and m- most of them weren't that good. They were like- they were hallucinations Jonathan: were true shields. Benjamin: They were hallucinations. They were terrible. Jonathan: It was some- There was- somebody that, that really w- was... honestly, really smart guys, that were just way ahead of the curve- ... were saying, "Hey, there's this bug bounty program. ChatGPT, find me a CVE and this, so that I can make money off this bug bounty program." And [00:12:00] then they didn't have the chops to test it and figure it out themselves- ... if it was real. And so there were some really low quality CVEs that were getting reported to Curl. And I think, didn't Curl actually close their bug bounty pro- program as a result of this? Yes, they Benjamin: did. Jonathan: Yeah. Benjamin: So there was this kind of like another phase shift where as the model started to get better- the reports started to get better as well. Yes. This mountain of reports that used to be, like, really low quality started to be actually you know, for real bugs- ... that needed to get fixed and I think Daniel shut down the bug bounty program just because they were underwater trying to patch all of these bugs. Yeah. It wasn't just issues that were trivial at that point. These were, like, real bugs- ... in the software that had to be fixed, but it's just too much to fix manually and so part of Patch the Planet is we try to create the patches ourselves as well. It turns out that's actually much, much harder than finding the bugs in the first place, and it's a, a place where we're putting a bunch of research into right now. But we've been doing [00:13:00] this since, I think June and we- I think we've done 50 or 60 projects so far. We've found, thousands of bugs. I th- think we got maybe 200 of them patched so far and things are looking up. I- we've been really happy with the progress so far. Jonathan: I- is Patch the Planet, is it primarily trying to use the AI models to write the bug fixes as well? Benjamin: Yes. Although they're not as good as at doing that. So looking for vulnerability is a relatively closed problem because once, once you find a bug that crashes a program, you can prove, "Hey, this bug crashes this program." Jonathan: Yeah. Benjamin: But w- if you wanna fix that bug, it's a lot more challenging to have an oracle that says, "Hey, you fixed the bug. Good job." Jonathan: The program- Just- ... still does all the things right that it was doing Benjamin: right before All the, all of the things right. And this is especially- Yeah ... a big problem for the Linux kernel because the Linux kernel- ... doesn't have a test suite in the way that most software developers envision having a test suite. A lot of it is this [00:14:00] tribalized knowledge. So if you wanna create a patch for the Linux kernel, there's all this stuff that the LLM has no way of understanding- ... all these hidden requirements, and it basically cannot write a patch on its own. It doesn't have e- enough ways to verify that the behavior of the rest of the program is still correct in the way- that it needs to be correct. Jonathan: Yeah. It's really a challenge. One of the, one of the other challenges that I've seen, and this may just be because of the project that I'm involved in the longtime listeners know is the Meshtastic project, and so we run open source firmware on little tiny IoT boards. And one of the challenges that we see with this, and with human reporters too, by the way, is that there are certain things that from a certain point of view would be a vulnerability, but from the point of view of we're writing embedded software on IoT boards, it's- ... no, that's just a limitation of the platform. And yes, we would love if that were different, but we only have, 120K of RAM or whatever it is on the individual platform. It's just we can't... There's just no fix for that. [00:15:00] And so- ... i'm wondering if you have insight into this, like, how good is... So i- if a program crashes that's generally, that's a bug, it needs to be fixed. Yeah. But there's some other classes of bug, or I guess even in the case of a program crash, there are certain times where it's like that is explicitly trusted input. We don't really care if that causes it to crash. Or- ... something like this is a vulnerability report that we got. There is a inside the... So we can run Meshtastic on a Linux computer and, run the actual firmware as a sort of inside a wrapper on a daemon. And so then it pulls in from a, a YAML config file, and one of the things that you can set is, as part of sending a packet, run this command. I'm simplifying a little bit, but essentially this is what... Run this command, take the output, and set it inside a packet. And someone's like, "Oh, arb- arbitrary code execution inside your config file." And we're like- It says it on the label. That is the feature. What are you... What's wrong with you? And so all of that to [00:16:00] be a, a, a segue into do we still have this problem with the, even the frontier models where they just, they don't understand that part of the context of, "No, that's not a bug. That's the way that's supposed to w- The user is supposed to be able to crash the program by doing this." Benjamin: Absolutely. This is still definitely a very persistent problem, and it's a, something that we've encountered in Patch the Planet and have tried to fix as well. The problem is these models don't really understand the context of the environment that they're working in. They're able to find these bugs but not understand, hey, this bug isn't actually a very big deal because of- ... what you said. Like- May- maybe a bug requires hardware access and that's the end of the world for one threat model, but it's an accepted outcome in another threat model. Yeah, exactly. And so one of the parts of Patch the Planet that we're trying to do is not just find these bugs and patch them, but try to improve this agentic maturity. That- that's the best thing I have to call it right now. It sound, kinda sounds like a buzzword, but- ... the idea here is [00:17:00] we wanna give these models a better way to understand the context of the project that they're running on. So you've got all these security researchers. They're gonna run their models against your code and try and find bugs. The question is, can we change the behavior of their model that they're running to make it so it produces better results? And so the way that we've been trying to do that is with a threatmodel.md file. And this is literally just a file that says here's how this project exists. Here's what its threat model is. Here's what a bad issue is. Here's where the trusted input is. Here's where the untrusted

  ListenShow Notes

Recent guests on FLOSS Weekly. Study who booked and why before you pitch.

Based on semantic analysis of episode topics and host coverage, this show is a strong guest fit for executives in:

Industry fit is computed by PitchCentric using vector embeddings of the show's episode catalog.