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 231 episodes on record and a Required Pod Score of 80. PitchCentric scores this show on Booking Probability, Listen Score, and live audience signals refreshed every 24 hours.

Hackaday hosts FLOSS Weekly, a technology show with 231 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 878 transcript

  Aug 5, 2026—

  FLOSS-878 Jonathan Bennett: This week I'm talking with Jonathan Pallant about Rust and primarily in the embedded world, the Raspberry Pi Pico, the Nordic, Espressif, all of your favorite little MCUs. You can run Rust there and partially due to efforts by people like Jonathan. This is Floss Weekly, episode 878, recorded Tuesday, August the 4th. A tool with opinions Hey, folks. It's time for FOSS Weekly. That's the show about free, libre, and open source software. I am your host, Jonathan Bennett, and today, once again, we're gonna get rusty. Whereas last time though, when we talked to someone with Ferrous Systems, we were talking about Rust on the Linux desktop, in user space, Rust on general purpose computers, and today we're talking about Rust somewhere a little different. I've got Jonathan Palant with us today. He is also from Ferrous Systems. In fact, I think his day job is teaching Rust there, and I think also doing some programming work. But let's get him on and ask about all of the places where Rust runs that you may not have thought about. Hey, Jonathan. Welcome to the show. Jonathan Pallant: Great to be here. Thanks for having me. Jonathan Bennett: Yeah, it's good to have you back. Or no, you for the first time. Good to have Ferrous Systems back. The second interview with one of you guys in a couple of months now. All right, so this, this magical thing called Rust it runs on the desktop, it runs on the server, it also runs on the Raspberry Pi Pico? Jonathan Pallant: Yeah. It- So joys of having a systems programming language, right? You get a compiler, source code goes in, machine code comes out, right? So anything that runs the machine code should be able to run it. So yeah, Rust is really interesting in being able to scale from the very, very large. It is the language that powers Amazon Web Services, and Cloudflare, and Google, and a whole bunch of other stuff. But it scales down to, as you talked last time, desktop applications- ... things like Sudo written in Rust. But also scales down to the small, very small. How small is always an interesting question, but- Jonathan Bennett: Yes, it is. Jonathan Pallant: I have run Rust on ST Micro, Microcontroller, Arm Cortex-M4 32K flash, 4K RAM. As modern things go, that's pretty small. I'm not sure I'd be happy squeezing Rust-generated code onto like a Z80 or a 6502. That may be a bit too small, but certainly tens of K of flash, a few K of RAM, I think- ... is quite workable. Jonathan Bennett: I happen to have here the Seeed Studio Xiao board actually their next generation Xiao board. It is a Nordic nRF54. The word Xiao in Chinese means tiny, and it is an appropriate name, as you can see. T- Can we do Rust on a nRF as well, on, on Nordic? Jonathan Pallant: Yeah. So Nordic semi generally use Cortex-M4 M0 in the nRF51, M4 in the nRF52. I did a lot of work with their cellular modules. Don't know if you've ever used a 9160? Jonathan Bennett: I've not, Jonathan Pallant: but- the very small device that does LTE Cat M- ... so the, the IoT version of 4G, and that comes with a Cortex M33 that you get to play with, and then a secret second processor that runs the modem firmware- ... that you are absolutely not allowed to play with because cellular. Jonathan Bennett: Yeah. Okay. So the ... Boy, the, the embedded world is an interesting world. There's a large there's quite the gamut of different things that count as embedded, and sometimes the lines get a little blurred, right? Because you can take the Linux kernel and run it on an ESP32-S3. Now, it's not a fun experience, but you can do it. It'll boot. It can be made to, it can be made to happen. And so i- it's interesting to me that Rust goes all the way down to some of those very, very small targets. How does that work? Is there an operating system that a, a Rust binary is then running on top of? Is there some kind of real time operate OS? Do you guys run on Zephyr, or is, are you literally just writing Rust that runs on the bare metal? Jonathan Pallant: Yeah the output of the, the Rust compiler, it works like a C compiler. Source code goes in, machine code comes out. So the compiler doesn't really care whether- ... you have an operating system or not. You could absolutely be the first code that boots when the system comes out of reset. Jonathan Bennett: But I mean- Where- ... there's like the question of am I making system calls to a kernel? Am I telling the kernel to do, the, the multitasking stuff, or am I just always, is the binary always running on the Jonathan Pallant: CPU? And where that comes in is less in the, the language, but more in Rust's choice of standard library. People say, "Ah, the standard library," as if it's one thing. But as with all good things, it's actually three things in a trench coat. The, the top part of the standard library in Rust is the thing that knows about files and threads and networking, and that's the thing that's gonna be operating system specific. And it's basically the Rust equivalent of hash defines that say, "Hey, if you're on Windows, we're gonna call this Windows function, but if you're on POSIX, we're gonna call, open read and write." Sure. And that's what lib std is doing. It's this operating system abstraction layer. As I said, file system, networking, threading. Below that you've got the heap allocator and all of the heap allocated collections. They actually live in their own separate library. If you're a Windows, Mac, or Linux user, you may not be aware of that because it's hidden, and everything heap-related is all exposed at the top level anyway. But there is this lib alloc, so if you want a heap allocator, it lives there. And then you've got these fundamental Rust types, these things that no Rust program can live without, and that don't actually care about what operating system. If you've used Rust, you'll be familiar with the result and the option types. They're enums, they are generic, they need to be defined in a library somewhere. And things like that go into a library called lib core. So when people write bare metal Rust, so Rust running on a Cortex-M4 or a RISC-V processor with no operating system these people say, "Oh, I'm using Rust as no std." And what they mean is I'm using the Rust standard library, but I've basically switched off the top half and I'm only using lib core. So I'm only using the parts that are operating system agnostic. No file system, no threading, no networking, but you do get Unicode string handling, as I say, result and option types, sort of fundamental properties of integers and floats and things like that. Jonathan Bennett: It, does this work hand-in-hand with a like an SDK the published stuff that the vendor puts out? So like we, we mentioned the Nordic. Obviously Nordic writes... I mean they, they've written Zephyr support. They've also got their oh, I forget what they call it, their little shim libraries, almost like an OS. SoftDevice I think they call it. And so when we're in Arduino land with C and C++, we do a lot with SoftDevice on the Nordic devices. Do, do... When you write Rust, do you use that stuff on this, this sort of a device, or are you f- blaze your own path? Jonathan Pallant: People come at this from different places. I went to a trade show in London recently, and I went round and surveyed all the people there who had the booths down at the show in London, said how do you write embedded firmware?" And honestly, I was surprised at how often Zephyr comes up. A lot of people seem to be really into Zephyr. And if you wanna use Zephyr, absolutely, you can put Rust on top, build your little Rust applications, link them into the Zephyr kernel, and that's all gonna work great. I wouldn't describe myself as a purist- but I'm in this to push what Rust can do. A great analogy came up the other day about about, about AI usage, and it was like sometimes there are heavy things that need to be lifted, and sometimes this is your job, and you should use whatever machine you've got to lift the heavy things. And sometimes it's 'cause you're at the gym- ... and if you bring a forklift truck to the gym, you are defeating the point. You're cheating. When I write Rust, I'm at the gym, and I wanna do it the hard way because I wanna practice my Rust, but also I wanna show what Rust can do- ... and find if there are any corners where Rust doesn't work. 'Cause I wanna know about those- ... and maybe I can go to the Rust project and get them fixed, or, I can educate my customers about areas where Rust doesn't work. So- Yeah ... for me, going bare metal is always more interesting. Jamming random integers into random memory addresses, that's where I'm most comfortable. But if people wanna use like a FreeRTOS or a ThreadX or any number of real-time operating systems that are written in Rust- If that gets the job done, that's great. Jonathan Bennett: Yeah. I think that's actually a really good segue to ask the question of what do- what is your day job? You're not... Are you writing production code, or are you doing the the education thing there at Ferrous? Jonathan Pallant: So my I asked for the words senior embeddage engineer to be written on my business card- Okay ... because it covers a multitude of sins. Technically what I'm doing mostly is teaching. So I teach Rust. I am the lead trainer. I'm responsible for all of our training materials, which are all open source. Anyone listening can just go and find Ferrous Systems Rust training, read all my slides, do all my exercises. It's all creative commons. You can help yourself. But I can't only teach, one, because my head would melt. I did a day of teaching today. I've been teaching eight hours already, so I may- ... yeah, just dribble a little bit. But also, yeah, you need breaks. But also, if I only taught Rust I don't think I would get better at Rust. There is an a need to sharpen the knives and practice the tools. So in between trainings, I'm, like, picking random dev kits and going, "Great, let's do some Rust on this. Let's write some training material about it. Let's pick an entirely new platform nobody's ever written Rust before." I have in my hands a lovely NXP developer kit. S32Z2 for the people who don't have video. This is get this right, eight Cortex-R52 with 20 megs of RAM. Jonathan Bennett: Oh, wow. Jonathan Pallant: As microcontrollers go- It's huge ... this thing is cooking. But it can't run Linux because none of these processors have an MMU. These are all- ... Arm's real-time platform. So a couple years ago I was like, "Can you even do this in Rust?" Probably, but I don't find anyone online who's done it in Rust. So we called in a favor from NXP. We got the board. I would not personally wanna buy one of these out of my own pocket money. It's a little out of my fun budget. Yeah, and we got Rust running on it bare metal, dual-core lop step. We can run asynchronous Rust. We got the interrupt controller going. But I do that because it's interesting and because it ends up useful for customers and useful as training material, yeah, embedded systems engineer, as I said, covers a multitude of sins. Jonathan Bennett: Rust and embed- the embedded world as a whole is really a moving target as places like NXP and STMicro and Microchip, Nordic, and all the rest of Espressif, everybody, they're constantly pushing the envelope, releasing new things, g- gluing new weird chips together that we didn't think we would ever see, and then suddenly- you see it at a trade show or a talk. But it's a moving target, and if all you're doing was education, then, you're, you would get stale, right? So I think it's incredibly useful to stay hands-on with the technology. Jonathan Pallant: No, absolutely, and I try to make it out to Embedded World every year to run the booth, but also just to walk the floor and- go and see what's new and get a sense of how things are training changing. You go to Embedded World three or four years ago- most of the floor didn't know what Rust was. "Do you do Rust?" "No." "What's Rust? Tell me about Rust." And this, they'd never heard of it. And now they're like, "Yeah, no, we've heard of it. It feels like a thing we should be doing." But certainly I think these big silicon vendors are thinking about, "What is my next step? How would I introduce this without alienating all of my existing customers who like the CSDK? Is there a migration path? How... do these things feel the same or do they feel different?" Espressif, I gotta give shout-out to them for being far ahead here. They basically hired all the open source hobbyists who were doing Rust on their chips. Gave them a job and they have their own Rust team. We've seen Rust news out of Infineon as well. Yeah, and I hope we see more out of the other silicon vendors as well because if they don't do it, who will? I mean me, but my time is somewhat limited and there's only so many dev kits I can buy. And it's the open source community. It's random hobbyists who go, "Oh, I've got a random dev kit I got off Adafruit or whatever. Got a chip. Does this have Rust support? I don't know, let's write something. Let's put something together." And we have all this sort of flourishing ecosystem around STMicro, around Nordic, around Raspberry Pi. I personally did the Rust support for the 2350. That was fun 'cause they gave me pre-production chips, so we had Rust support ready to go on launch day. But these are all independent ecosystems with their own thing going on. Which is great if you just wanna get into Rust and have some fun. But if you are- on the hook to design the firmware for a product where you wanna make a million a month, I can see why you may not just want to pick up random packages online, and you may wanna talk to the silicon vendor or someone else- and get a bit more professional support. Jonathan Bennett: Because the way where madness lies, and I know because we've done this ourselves, is you end up coming along and forking about 100 different packages, that you've got your own version of the library because you have some fix, and the upstream library is dead, or you can't get ahold of the maintainer, or this or that. Yeah. Been there, done that. That's my life these days. How similar is it? We've thrown out a lot of different embedded architectures. So again, compare, like, Nordic to the Raspberry Pi Pico. Can you write one Rust program and get it to run on both places? Is there cross-platform driver support? So say I've got a an I2C-connected temperature probe. Can I write one Rust driver for that and run the same code on the Pico and the the, the Nordic? Jonathan Pallant: You can, and this is thanks to the work of a great bunch of people called the Rust Embedded Devices Working Group. So take you back to 2017. I'm just starting to get into Rust. I'm using a random TI Stellaris dev kit that I happened to have lying around, and I'm doing my own thing, and some other people are doing their own thing, and we find each other. And we're like, "We're C developers. We've written a lot of C code." "Rust looks fun, but we're very aware of how-" I describe the C embedded ecosystem as like islands. And these islands are all really quite far apart. Yeah. And if you live in Nordic island, and I don't know, you happen to run out of chips 'cause there's a chip shortage, and you wanna get over to- Jonathan Bennett: That would Jonathan Pallant: never happen ... ST Island, to get over to ST Island, those islands are quite far apart, and it's pretty difficult to write, say, a cross-platform driver that, that works across that. And we looked at that and we said, "What could we do in this fledging fledgling Rust embedded ecosystem to try to, for that not to happen?" And the Rust language mechanism that it offers for that is a thing called a trait. And if you're a C programmer, you can think of it like struct full of function pointers. That's how the Linux kernel does it. That's how the Linux kernel thinks one disk controller looks like another. They both, drivers, provide a struct with a function point of open and a function point of a close, and read block and write block. In Rust we call that a trait. So the Rust embedded working group published some traits, and there's a trait for I2C, and there's a trait for SPI, and a couple of other sort of common peripherals, GPIO- razor pin high or low. And then what someone needs to do is come along and say, "Oh, I would like Rust to be usable on i- my particular chip." NRF 52 for example. So you would write some Rust code, and you would implement the trait. So here's my I2C driver- Yep ... represents this peripheral, and it implements the trait. When I flip to the other side, someone's got- a CO2 sensor. Little I2C device, measure the air quality. I've got- And they just need an Jonathan Bennett: I squared- I've got one of those on the desk behind me waiting for me to either find or write a driver for it. Jonathan Pallant: Fantastic. And you just need an I2C bus to put it on. And what do I2C devices need to do? The driver needs to do a read maybe do a, a write and then a read. There's a couple of fairly basic operations. 7-bit addresses, 10-bit addresses, and that's all encoded in the trait. So if I wanna write a Rust driver for my little CO2 sensor, I am generic over some type T, where I don't care what type T is as long as it implements embedded hal colon I2C- some trait. And then a third person comes along, and they're like, "I may be the first person in the universe to use that CO2 sensor with that microcontroller." And they can compose it together. Yep. And in general, it should just work. You will... There's ef- efficiencies that you will lose because it's a g- sort of a very generic API- that's not very- ... chip specific. But the trade-off is, yeah, here's my random Adafruit LCD screen, here's my CO2 sensor. Plop them all on a board. Here's a, a, what we call a, a HAL implementation someone's written for this chip, and it should all just work together, and generally it does. Jonathan Bennett: Yeah, that's very cool. It's actually similar to the way the the Adafruit excuse me, the Arduino ecosystem has evolved. You've got kind of that, that same idea in mostly C code, some C++, but it's that same idea. We've got an abstraction of here's what a wire bus is going to look like. It's usually what you see it called. And then somebody else can come along and write a driver for it. Was that part of the inspiration? Jonathan Pallant: Yeah, I think we'd the people who formed the Embedded Work Group, we'd obviously used Arduino before, but we'd also used these kind of very vendor-specific SDKs. But you also get the, the classic embedded commercial vendors. They all have their own stacks and their, probably their own in-house operating system. It seems every embedded company's got their own operating system they've had since the '90s- Of course ... and that kind of stuff. So we've seen all of that. And what would a, like a utopian future look like? I'd love anybody to be able to pick up any MCU- and any device and just plug them together. Jonathan Bennett: Do you see vendors actually starting to write the the, that bottom half, that support layer for you guys? Jonathan Pallant: So we have seen Espressif do that. So they publish all of the, the, the drivers you need for their chips. For most of the other vendors, I think we've seen something from Infineon. But for most of the other vendors it's wait and see. Maybe throw the hobbyists a bone, some free hardware occasionally. But that's all mainly hobbyist-driven. I will shout out STMicro, who have done the other side. Surprised me. But if you've got your little STMicro sensors, 'cause obviously they don't just make MCUs- I believe they have all these sensing modules as well. They will give you Rust drivers for the sensors. Jonathan Bennett: Cool. Jonathan Pallant: Which you can just get from STMicro's GitHub and use, and then use those drivers with your other Rust co

  ListenShow Notes
• 

  Episode #878

  Episode 878 - A Tool With Opinions

  Aug 5, 20261h 1mS4

  This week Jonathan chats with Jonathan Pallant about embedded Rust! Learn about the growing Rust driver library, the different ways to build a Rust stack on an embedded device, and how the opinionated tooling can make you a better programmer! 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 877 transcript

  Jul 29, 2026—

  FLOSS-877 Jonathan: Hey folks, this week we're talking with Francois Proulx about smoked meat, and poutine, and Bagel, a trio of open source security tools that you don't wanna pass up on. This is Floss Weekly, episode 877, recorded Tuesday, July the 28th: RCE as a Service. 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 revisiting a topic that we've talked about in the past, and in fact, revisiting a guest. We've got Francois Proulx of Boost Security. These guys are experts in supply chain security, and really one of the main things that we're talking about with this is GitHub CI, continuous integration. And so a lot of projects will have a CI set up to where you run automated tests on your code changes. Where this can get dangerous is if you allow the outside community, so untrusted people, to make pull requests, and then that CI engine runs against those incoming pull requests. And then you have this kind of strange problem, that you're running untrusted code inside your GitHub repository, and surely that doesn't ever go wrong. Yes, sometimes it goes wrong. We had Francois on the show about two years ago, and we talked about a project then called Poutine, which was a scanner, an automated scanner to take a look at a project's CI runs, and essentially give you an evaluation. Do we think this is safe or not? And in the time since then surely we've fixed this problem and it doesn't exist anymore, right? Unfortunately I don't think that's the case. I'm gonna go ahead and bring Francois on. He's the guy that has the answers, and we're gonna find out. So welcome, sir, to the show. It is great to have you back. Francois: Thank you. Jonathan: Yeah what, w- what, did I get the problem space right? And then what's changed in the last two years? Francois: Ver- very good introduction. Yeah, I think you got the, the takeaway from the last discussion, and I guess you, you did your own homework on your own projects and could actually see why the tool was created. Why I created it, why it's a, it's an issue that especially maintainers... this audience is both consumers, like users of open source, as well as maintainers. Jonathan: Yeah, absolutely. Francois: For the maintainers, I think my message was that they should give the tool a try so that they can protect their own end users, right? Jonathan: Yeah, and I think we're probably gonna pitch this in the context of GitHub, but this is not just a GitHub issue, is it? There's there's GitLab, there's Codeberg, there's glued together CI scripts that run on infrastructure that's not any of those three things. And I imagine you could have problems on any of those contexts, couldn't you? Francois: 100%. So effectively you know- Basically any source control system, be it GitHub, GitLab, or whatever- Yeah ... that can automatically trigger the execution of a CI environment upon the submission of new code changes, just the, you know, triggering on such an event, it they can have the same exact problem. So really the devil's in the details in terms of the configuration of what is the behavior that happens, like the, effectively the secret, or does the execution of the arbitrary code changes get hacks- access to secrets or not? If it's just arbitrary code execution of the new tests, for instance, or the new code potentially it can be done in a way that's perfectly by design and without clear risk. Of course, if you were to reuse the same CI environment, like the same machine is is to be reused across different runs, then there can be pollution across those. But assuming it's an ephemeral run runner environment it can be done safely. But then, yeah, like the, the way it gets configured and the various components that get pulled during execution is really what matters. Jonathan: Yeah. And I think part of the reason why this is such a sticky problem to solve is 'cause on one hand, obviously when you have a pull request from the outside, so like by definition you're talking about untrusted code. It's literally untrusted user-supplied data, and you wanna do a processing run on that. But- Historically, we've not been concerned about, and I'll just make this very generic, we've not been concerned about malicious code inside of make files, or malicious code inside of build scripts, or malicious code in all these various places, even in C and C++ headers, for that matter. You can do some interesting things just with preprocessor directives. And that's been a, historically a blind spot because oh, if you're compiling this code on your machine, surely you already trust it. And then you take this and you put it on the cloud, which is, as we all know, just somebody else's computer, and because it's on the cloud, it has to have access to some sort of, to, to some sort of secrets. It has to have access to your build environment and your accounts in the cloud to one extent or another. And there's multiple ways that this can go wrong, and I've seen firsthand someone will run a build, and part of the build is go grab all of the variables from that you can get ahold of, basically all your environment variables, and then send those off to somebody else's server, and then you lose your secrets, right? But then there's also even other problems, and I think GitLab had an issue here at one point where because you are... You're in this inside the runner you're validated. You can then potentially go and do things to the project, and so there's that danger as well. And this is not just theoretical anymore, is it? There's been real attacks pulled off with these sorts of problems. Francois: Yeah, absolutely. So that, that is exactly how as we publish open source tools, we write articles on the topic, pushing the boundary of the, the research in that area. And I speak at different conferences and, on podcasts and whatnot. But the, the last series of conference talks that I gave, it really starts with this fact that since we last talked, about two years ago- ... the the threat actors the, the bad guys have also been listening to the podcast or my talks- or seeing the ar- re-reading the articles and using the same tools that hopefully you guys, the defenders the, the maintainers- ... have been using, but they effectively flipped it or used defensive tools that were designed for defenders as an offensive tool for them to find zero-days effectively. Because those tools, they can find vulnerabilities in the the attack surface of the, the build pipelines, and then lead to poisoning the the well, poi-poisoning the open source release. And that's what we saw with worms, like in the fall of 2025. I'm sure all of you have heard about the different worms spreading on NPM and PyPI mostly, shyahlood, and there's been a number of iterations of those- Yes ... autonomously propagating malware in, in open source packages. And e-even in the spring of 2026, we saw another wave that was not necessarily using worms, but much more let's say, skilled threat actors that were r- that really understood the benefits that they could get by exploiting effec-effectively large open source projects and have downstream effects in large organizations, right? Jonathan: That's the, the classic supply chain attack, right? Particularly if you can pull that off without being spotted for a while. So then you can you get your tendrils into one project, and that gives you a l- a, a diving board to then get your tendrils somewhere else. And the longer someone can go without being spotted, the more of a mess that they can make. Francois: Yeah. But at the same time even if it's not very long, but everything is automated, they can, achieve the end goal- ... v- so quickly that no one can really stop something like that. Like- Right at best, it can be detected as it happens or as it has already happened. And if in some case we saw them pivoting multiple levels from the initial access vector, the initial point of entry- ... Francois: To steal secrets and then pivot down- downwards in the infrastructure, like cloud infrastructures- of large corporations namely. Jonathan: Yeah, absolutely. And then you, I think sort of tongue in cheek, but it's a point worth following up on. You mentioned the idea that, oh the, the attackers are listening to our podcasts and they're using our defensive tools, and that's the challenge anytime that you build like an auditor or a a red team tool that like, there's not a whole lot of difference between what an auditor does and what an attack tool does. Is that just the nature of the beast? Is that just the way that it works? Francois: Yeah, I think there's no... we're not in the 1990s anymore- ... where we try to keep the precious, elite tools behind the curtain, and we only give them to certain trusted people. The cat's out of the bag. Yeah. The techniques are well-known. And recreating most of those tools is not rocket science. Once you understand what you're looking for, you can probably just use grep, in many cases, it's just configuration mistakes or a couple specific things that you're gonna be looking in this case, in YAML files. For the most part, those CI/CD configuration will be in YAML files in specifically named folders. And yeah the simplest thing you could be using grep and highlight some things that you would then audit manually. So those tools are just doing that more efficiently, but ultimately that's, as you said it's that, that's what we have to wrangle with. The technique is known and by b- both defenders a- and attackers. Jonathan: Yeah, absolutely. We're not in the position where if your CI gets hit, you can just say, "Oh, it must have been a nation state that did it." No, it may have literally been a teenager in a basement. Yeah ... I blame, and again, it's not just a GitHub problem, but GitHub is the, the 800-pound gorilla in the room of of online Git repositories. And I blame GitHub for this, 'cause I've gone down this track a couple of times. You made me... I don't think that was the first time I'd heard of it, but you definitely made me more aware of this when we talked about it last time. And so I've gone and I've looked at some of the projects I've been involved in, and I've gone down the rabbit hole of do we do this right or not? And I've read through the GitHub documentation on things like, just for instance, the, the pull request event versus the pull request target event. And I will read through their documentation and come away with one feeling of "Okay, we need to do it this way." And then I go and read somebody else's blog, and they say no, you need to do it this way." And I still don't know if pull request or pull request target is the safer way to do a CI run. It's... I just, I wish there was a single answer somewhere that I could look to, and it's like, "Don't do this." Okay, I won't do that. Francois: Yeah. The, the s- the simple answer is pull request target is m- let's say- Is if you're to grab something, pull request target, it's not the only one, right? But if you're gonna flag that, like that's a clear thing where you need to stop and audit the rest of the code. It doesn't mean it's not is insecure kind of a Boolean flag, right? You m- you can use this in a safe way. It's just that it's a bit of a foot gun. Like you, you need to really understand how to use it in a safe way because it comes, great power, with great power comes great responsibility. It does grant access to the secrets during the execution of the runner. The big difference between pull request and pull request target, and specifically in the case of GitHub actions, is that one of them will not grant access to secrets, but it will i- it will run the latest version of the pipeline. So basically, this is in the case where you want your contributors to make- ... changes to the build pipeline- ... and you want them to be tested immediately, right? So that is let's say in the scenario of enterprise or like in a private repo or when you have direct maintainer contribution, this is fine because you want to test like directly the, the latest version of the build pipeline changes. But pull request target on the other hand, it effectively locks the version of the CI configuration to the one that's already been merged. So that's the biggest difference, is like one is untrusted build configuration, and the other one is trusted build configuration. But the big difference is that one doesn't have access to secret, the other one has ac- access to secret. If it's a trusted pipeline, it means that as long as there's no vulnerability in that pipeline configuration, everything is okay. Jonathan: But- But if your repo has a Python script in it that gets evaluated and executed during build time, which is quite common by the way, you have a problem all over again. Francois: Yeah, exactly. So in, in fact so much so that y- you were asking did the, is GitHub doing enough? And I would say in the past three, like four, basically since March more or less, there's been a big like... They've been, they've started to really move the needle. And that's in response, direct response to all the big things that happened- Yeah in the spring. So they've made a number of changes that actually in some cases are breaking changes. Like literally they decided to do the very non-Microsoft move of, okay, this is too bad. Too many people don't get it right, so we're gonna completely change the behavior to a more safe by default. Where you really need to explicitly go ahead and say, "Yeah, I know what I'm doing. Let me do it." As opposed to leaving foot go- foot guns, around. And so th- that, that's a pretty major change. Specifically to pull request target, they made a change that was made fully effective as of two weeks ago or so. But it still makes it possible to have the same kind of vulnerability as before, it's just that there's one less way that you're gonna do it, like without even knowing, right? ... It's at least a little bit more explicit on your part. Jonathan: And that's why everybody's CI runs started breaking randomly a couple of weeks ago. That, that solves one mystery. I, I think something that maybe not everybody realizes I have to remind myself of this every once in a while, is obviously Microsoft owns GitHub. GitHub is the owner or the, the trusted source of NPM. And so like all of this stuff comes back to the same group of people getting black eyes from it. And so it's not terribly surprising that they are very motivated to try to fix this. Francois: Yes. The, directly Microsoft for many of the things, like if you're a Azure cloud user, there's a number of components that are directly used in production in Azure, both from the infrastructure side as well as the end user side of their cloud services, like kind of cloud SDK, Azure SDK, and other things, right? That you want to interact with their backend that are hosted on GitHub, open source, and that use GitHub actions. Some of those components are deployed on NPM, so they have vested interest in ah, hardening the path to to Azure, right? Because from commercial perspective, ... Microsoft definitely has- Sure incentive. But it's for the benefit o- of everyone, because a- any, any improvement to this infrastructure is good for open source. Jonathan: Yeah. Absolutely. All right. So that's sort of the background. And last time we talked about Poutine, but now you've got a new tool, Smoked Meat. I just gotta say, I love the carnivore theme going on here. I 100% approve of that. But what is Smoked Meat? What does it bring to the game? Francois: Yeah. Okay. So Poutine was really a scanner. It's meant as a static code analysis scanner. It's meant to basically scan and find all those special YAML files and detect vulnerabilities, like in the misconfiguration in those YAML files. It's gonna say, "Oh, you have pull request target, and then you have X, Y, Z other conditions, preconditions for it to be considered almost certainly vulnerable, almost certainly exploitable." So there's some, caveats to that, like in practice, but it's a scanner and people would ra- run it. Since it was published it's now being used by many large organizations many big open source projects. And it's very lightweight, very easy to run at scale. You can scan a large organization with hundreds of repos thousands of pipelines in just a few seconds, and it's gonna spot those. Then you're responsible for, looking at those results and hopefully fixing the issues, Jonathan: Yeah. There, there's a- ... and Francois: on our side ... Jonathan: it's worth breaking in here and talking about there's a challenge when you run one of these static code analysis tools to then correctly understand the results, make the judgment call of either, "Yes, I think this is a real problem," or, "No, I don't think it is. I think this is a false, false positive." Or even like, "Yes, this could be a real problem, but we mitigate it in other ways." Yes. And so there's a real judgment call to be made there, and sometimes that's really a hard step to take. Francois: Yeah. And exactly, that's, I'll get to Smoked Meat, your, to answer your question in a moment. But a- ab- absolutely as you said, it's it's difficult, and we've been using this tool at scale to scan millions of open source projects. And in the past two years or so, we've made several thousands of coordinated disclosures to many projects like big and small. Like Small, tiny open source projects, as well as things that are maintained by Google, Python Software Foundation Red Hat. And so indeed, like some of those are pretty trivial, fairly easy to point to the bug and to the solution, the way to re-remediate. But other times it can be very difficult to confirm that it's exploitable- ... and then to find the way to address it. In some cases it's more architectural. You need to redesign the whole thing because you, you made like wrong assumptions on how to do that securely, and that's much more painful, right? Jonathan: Absolutely. Francois: But let me get to the answer to your question about Smoked Meat. So Poutine is a scanner, and Smoked Meat is a red team, like offensive tool. So the first one is gonna find the vulnerabilities, and in Smoked Meat I use Poutine as a library. So if you remember, Poutine is a Go, is written in Go. It's a common line tool, but here I just use it as a library, as part of a bigger project called Smoked Meat. Which is really, if you want to simplify it for those of you who may have heard about Metasploit. So Metasploit is an offensive tool, like a red team exploitation tool- Yeah ... where it's gonna scan to find vulnerabilities and then give you automated, like automatic craft payloads to test ex-exploitation and validate that indeed this given vulnerability can be exploited and then you can discover what's behind. Once you achieve remote code execution, you can, in some cases, like find credentials or discover the environment, do further reconnaissance and pivot. Part of Metasploit, there's this plugin called Meterpreter, which is effectively a small shell execution environment that will run remotely. Once you achieve the re-remote code execution, effectively you move from your laptop to somewhere further and you rinse and repeat. Like you execute as if you're sitting on that server observe what's around, and then continue. Smoked meat is this, has the same exact concept, but applied to the context of CI/CD. And the reason why Metasploit would not directly work in the context of CI/CD is because in almost all cases, CI/CD is running ephemeral environments. So the VMs that run your tests, it's typically torn down and completely deleted the minute the tests finish running. Then the next run or maybe parallel run of the test will use new VMs, so it's not like a persistent infrastructure like you would attack a cloud infrastructure typically. So yeah, so that's the gist of it Smoked Meat uses Pou

  ListenShow Notes
• 

  Episode #877

  Episode 877 - RCE As a Service

  Jul 29, 20261h 7mS4

  This week Jonathan chats with Francois Proulx about SmokedMeat! That's the third in a trio of Open Source security tools from Boost Security, and this one is the red team tool to demonstrate vulnerabilities. Why are Continuous Integration vulnerabilities such a persistent problem, and what's on the horizon that may help? Listen to find out! 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 876 transcript

  Jul 22, 2026—

  FLOSS-876 Jonathan: Hey folks, this week I talk with Michael Meeks about Collabora. They do a lot of things, but we're talking specifically about their office suite and how they pay the bills doing an open source project. This is Floss Weekly, episode 876, recorded Tuesday, July the 21st. There is no money fairy Hey, folks. It's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and my voice is just a little extra raspy, a little extra bassy today, and that is because I've been at Open Sauce this past weekend. And in the infinite wisdom of the people putting the show together, they put our booth back to back with a guitar amp booth. So I've been speaking loudly to be heard over the sound of sick guitar riffs for about three days now, and my voice definitely took the hit. But that was a lot of fun. I'm back now, back in the saddle. Didn't miss any Floss Weeklies this time around, and we have got something really neat today. We're talking with Michael Meeks of Collabora, and one of our, one of our live listeners before we started the recording said, "Are we talking virtual reality, or are we talking office suites?" I think the answer is office suites, but apparently VR is part of the conversation. We'll get some information about that in here in just a moment. So our guest today, Michael Meeks he is CEO of Collabora, and he is, has served as the director of the Document Foundation. He's done all sorts of stuff over the years, including worked at Novell/SUSE, then part of doing lots and lots of Linux stuff over the years, and a, a whole lot more. Let's go ahead and bring him on. Michael, welcome absolutely to the show. It's good to have you here. Michael: Thanks so much, Jonathan. Pleasure to be here. Jonathan: So w- are we talking virtual reality, or are we talking office suites? Michael: That's a really good question. So Collabora, of course, is two things really. So it's a, a consultancy doing Linux enablement, open source stuff across the stacks- in multimedia, graphics all sorts of kernel enablement hardware stuff to get open source in at the bottom of the stack. So it's the obvious choice. There's always someone there that can help you get your hardware enabled, and so open source comes up from the bottom. And then of course, Collabora is also Collabora Office. It's always coming from the top of the software stack with these very, very leaf node- ... with all these dependencies. And so yeah there's two companies there. But we love to share the same brand and, work, work together. We have a mission, which is to make open source rock, and so we do that. Gotcha. And the hope is that in the end, the bottom and the top guys meet in the middle and shake hands and then everything is open source. That's the long-term plan, basically. But yeah- ... we're getting Jonathan: there. It's when they were digging the ch- the Channel, and they started at both ends, and finally they broke through and, shook hands through the rocks. Michael: Absolutely. Absolutely. H- So yeah, a, a breakthrough. Jonathan: How did it come about that there are these basically two separate companies that are under the same banner? Michael: Yeah, so I did a lot of work as you mentioned at SUSE Novell, as distinguished engineer there. And at some point, SUSE got really good management. And the good management realized that infrastructure software services and office productivity are pro- probably two separate things. All of these people are suffering in the Linux kernel at the bottom, toiling away. And, Linus says, "The interesting stuff's happening in user space. Up there. Go and do those things." And so there we were, writing Android apps and so on and people were a bit, aggrieved. And so fair enough, totally fair. We... They spun us out, they did it in a really good way Niels Brinkmann, Ral- Ralf Flakser. And they even gave us a, a small support contract for the first year or so to support their usage of LibreOffice, at the time. And yeah, just brilliant. So we got spun out, and that just makes decision-making so much easier. And helped me learn a whole load of, things about open source and business that seemed so simple back when I was employed and someone else was doing the selling and so on. And now, yeah, make... I think I was extremely naive, let's say. Yeah. To put it- I- Put it one way or another. I Jonathan: understand. Yeah. You got a very abrupt crash course- ... in herding cats, among Michael: other things. Absolutely. But of course, Collabora was a key part of that. So- ... Michael: I couldn't do it by myself. We took six other people from SUSE, and that's always an exciting ask, isn't it? "Please come and join my company with no customers, no... and no money and whatever." And so I think, Collabora played a really important role there, the parent company, in, in seeding that and providing some of that business experience. And my, my key partners there, Philippe Calaff at the time, Rob McQueen, really helpful- ... in terms of, just advising and providing infrastructure, finance and personnel and contractual basis and so on. So it was really useful. Jonathan: Yeah I had no idea until this very moment that Collabora was spun out of openSUSE. That is absolutely- Yeah, the office piece was- ... n- news to me ... the office piece. Yeah, interesting. Michael: Yeah. Jonathan: The... there's some news that everybody has been talking about this week, and that is that Valve and Collabora have released the official Arch Linux ARM64 port for the Steam Frame Michael: Awesome. Jonathan: And that is- Awesome ... that is something like what you're generally aware of that because you're the CEO- ... but otherwise you're just hands off. "Oh yeah, the guys are doing that. I don't have anything to do with it." Michael: So to be clear, I'm the CEO of the subsidiary that does office pieces. Philippe Calaff is the CEO of the, of the- Okay ... above. And it's a really, it's a great company. I think there's a lot of subsidiarity in those groups. Lots of groups that working, pushing out in their own direction. So yeah, I think sure this group is probably doing the valve bits there. But meanwhile, other people are reverse engineering GPU drivers and maintaining Mizar and improving. We- we're pushing in so many directions. Jonathan: Yeah, Michael: absolutely. So yeah, it's always great to see these things. Jonathan: Okay. Michael: We do so much good stuff, it's nice to be able to talk about it. Jonathan: Absolutely. So I feel like we've placed the landscape now and we kinda know the things out on the periphery that we're not gonna talk so much about. Let's talk about what Collabora, the office suite in Collabora Online is. And how did this come about? So is Collabora a fork of... the granddaddy of all of these is StarOffice, right? Michael: Yes. Ultimately yes. So if we go back to 2000 or before I was working with Sun Microsoft or Zimian. And Zimian, met with Sun and Marco Börries, who was the, the kid who created OpenOffice or StarOffice in his garage, and then built a big business around that in Hamburg. They kinda met together and decided how, to open source this thing and how best to do that. And so I was involved with that, before even it was open source, trying to think about component models and plugging things together. And if you remember component models, but the punchline is you don't need them. Open source is open, and so you don't need to have all of these special contracts. Just, mash the software together, improve it, and work, work together. But either way, back in the day we loved that. And so then OpenOffice, of course, lived for about a decade before LibreOffice came in. And of course, Oracle, the economics for the Oracle division there weren't, I think they say accretive to gross margin or something like that. Meaning you've gotta make an insane amount of profit, otherwise you're not welcome. And that's a great shame. And a lot of those Oracle people were being let go, redeployed in other places And so then LibreOffice came out of that. Jonathan: And Michael: that was great. It was funded by, I guess SUSE or Red Hat with help from Google. And, the Linux desktop was hot back in 2000. There, there were lots of people there, and we had big teams working on this. And yeah, and then of course, over time... So we founded LibreOffice, and over time some of that desktop excitement died away, let's say, or at least reduced in magnitude. And you then end up in a rather different world economically in, in terms of sustainability. And then of course, when SUSE effectively pulled the plug on this and said, we're stopping," that was, would've been devastating to The Document Foundation, LibreOffice. So we yeah, so hence- Gotcha Mortgaged the house, start the company, rescue as much as we can, and then grow up. And now I guess we're about 70, 70 people in the productivity office part of Collabora now. Jonathan: Yeah. There's yet another Office suite out there ONLYOFFICE. Michael: Oh, Jonathan: yeah. And I remember that there was some drama between ONLYOFFICE and Collabora back six months ago, nine months ago, something like that. And my, my comment- ... at the time was the whole story was just bizarre. What and obviously we're not here to throw stones at ONLYOFFICE, but I'm curious from your perspective, what's the what's the overview of all of that? Michael: Yeah. So at least from my perspective, we didn't have a huge amount of drama ourselves with ONLYOFFICE, but I think Nextcloud then took the ONLYOFFICE code base and then created a fork of that called, it's called EuroOffice. And, ... there's a lot of, There's a lot of interaction there that's quite, quite interesting. I, I'm- Jonathan: Entertaining for outsiders. Michael: Yeah, absolutely. There's a popcorn thing going on there. Yes. W- but, from our side, in terms of positive things we can say about, Collabora Office, and I'll just say a whole load of positive things. We have zero Russian comments in our source code. We have clean- ... licensing provenance. We know what our license is and- Absolutely ... have statements from everyone that, that contributed to it. Jonathan: That's Michael: such a huge deal. Jonathan: And we build around our... So- We've had a... I'm sorry to bre- to cut you off, but we've- Michael: No, go Jonathan: for it, yeah we've talked to several projects over the years, and it's like what license are you?" And it's complicated." One project in particular, portions of it were written by US government employees, therefore those portions are in the public domain. And portions of it were written by contractors, and no license was ever assigned to it, which technically means that those are, all rights reserved. And w- and we had the guys on the show, and they're like, "It's open source. We want everybody to use it." And we're like, "How does this work?" And they were "Yeah, it's hard." Oh my good- Yeah. So that is a, that is actually a really big deal that you have clean- Definitely ... provenance on your licensing. Michael: Yeah, completely. And I helped set up the structures there at the Document Foundation, and people would send license statements. Ultimately I think we use the Mozilla Public License, so the MPL 2.0- ... which has a number of advantages and disadvantages. So it's a weak-ish copyleft, right? So it's per module copyleft, and so we can be pretty sure that if you're contributing stuff or reusing that code, then you're accepting the, the MPL 2.0. But beyond that it allows you to ship binaries under whacked out licenses. As long as you don't harm people's rights in the so- source code you can sh- use IBM's proprietary license and ship the binaries under that. So that's really nice. We got a clear source binary split there for the for the code, and it works really quite well, I think. And we share that with LibreOffice and, ... yeah. Yeah. So there was a lot of license collecting and yeah, due diligence and so on there that's really very good, both at LibreOffice and Collabora Office, I think. Jonathan: So Collabora Office, and I'm trying to remember the exact details of this. Obviously your, even your T-shirt that you're wearing says Collabora Online. And I- It is ... I'm trying to remember which direction this went. You guys turned the office suite into a web-based version, and that was your- That's right was that your primary offering for a long time? Michael: That's our primary offering. Yeah. Okay. Has been our primary offering for 10 years now. So we're just about to celebrating the 10th anniversary, and we actually got our release on Thursday of the 26, so four enterprise release of that. So there's a whole load of excitement around that. Yeah. And the team are crazily, fixing and improving and documenting and writing press releases and so on. And I think- Yeah, absolutely ... you've seen some of those. So yeah, so we're super excited about that. And, but of course- We've done a lot of work on the user experience. It's much nicer to use, much more familiar. Lots of research and, study there to, to improve it. And so we thought why don't we bring that to the desktop as well?" And actually, that had already been there, so if you'd had an Android version, you have this responsive UI and it looks like a mobile phone, one-hand touch interface. Great. But were you to plug a big screen in, suddenly it would turn into the, the, the real Office Suite, full fat. Absolutely. And so that's why you could run it on a Chrome OS and you would get real document editing there. And so that was pretty cool. And so we sort, took that and then just brought it to Windows, Mac, and Linux natively, and that's Collabora Office. So yeah. Jonathan: What, what was the decision like back in the day to say, "We're gonna make a web version of this"? And what was the engineering challenge there? Michael: Yeah, so well, the engineering challenge is making it work in the browser is, was quite exciting at the time. Sure. There were a whole load of choices we had to make 10, 10 plus years ago. Jonathan: It was before, WebAssembly came along, made a lot of things easier. Michael: Oh, totally. Totally. Totally. So we still don't use WebAssembly, so still we run a lot of the code on the server side. And there are a lot of reasons for that. I think from a security perspective- ... you wanna enforce policy on the server side. Jonathan: Absolutely. Michael: So if you want a policy like you can't download it, or you can't print it, if the first thing you do is download the whole file to the client- ... and then have your office suite there, You have a problem, right? Yes. From a security perspective. Yes, Jonathan: absolutely. Michael: And of course, if the first thing you do is download eight million lines of JavaScript and then JIT them on your mobile phone, you also have a problem that not only did you lose the document it just, it's ruinously expensive in terms of memory, performance, startup- Absolutely ... user experience and so on. So we try and keep that, that fast rendering in the i- in the server there, and bring it as tiles to the client, and that's really good. And we're starting... We- we in- increasingly moving more and more stuff to the client. So of course, your cursor blinks and there's no network traffic, this is rendered- ... i- in the client. Your selections are overlays rendered on the client. Your objects as you move them have previews. Your dialogues are reconstr- reconstructed on the client using native Java, JavaScript, HTML widgets for accessibility reasons if nothing else, so that you can move through them and screen read and get that rich rich accessibility experience. And now we're gonna be moving what we call turbo layout to the client as well. So there's a whole load of work to move away from what we thought would be super easy, pixel rendering to vector rendering in the in the browser. And actually, it works extremely well. But we think we can do more with vector rendering. We can just render once independent of view zoom, and then have everyone use that. So there's some, there's efficiency wins. But then we can start to do what we call turbo layout. So if you look at how Collabora Office lays out text text layout seems simple. You just nail the next glyph along. What could be wrong, right? But it turns out there's squishing text and justification and hyphenation and balancing columns and footnotes and re- laying out pages, and it's very easy to end up in loops. So there's no space there's... We've got a footnote here. We've fitted the text in, but we can't fit the footnote in as well. So let's get rid of the footnote. Now we can fit more text in. But, and you can end up in these iterative situations where, yeah you just... Anyway, you fail. The grass- So we have- The grass Jonathan: is greener perpetually- ... on the other side of that decision. Michael: Yeah, absolutely. That, that sort of thing. So yeah, you just basically can't win, and at some point you have to give up and try and do your best you can. One of the things that means is that's can be quite a slow process in a large document, so we have a turbo layout where you type and it nails it on the screen as quickly as possible. Like i- in, in the most plausible way, and then it will slightly update it. In many cases, you never notice that or it doesn't really need updating. But we're starting now to look at bringing that into the browser itself so the keystroke latency is exactly nothing. It, a frame, maybe two frames. Then again, at 60 hertz, within two frames you can get, some, some pretty impressive round trik- trips. Frankfurt to, to London is easily, is within one or two frame delays anyway. So yeah, you you don't really have a big problem there. Jonathan: Yeah, interesting. What was the what was the impetus behind back in the day saying "We, we need a web version of this"? Michael: I think collaboration is the key thing. So being able to collaboratively ed- edit documents together is just so useful. And I guess, so not only collaboration, but also deploying this. Ease of deployment. So one of the things we've wrestled with for years is document standards, and, we, we do... A huge amount of our work is making Microsoft documents import and export and round trip beautifully. And actually, we've done tons of work in 2604 for that just to make that better. But turns out URLs are better standardized than Microsoft documents. And the spec you can print out and it doesn't break your back if you try and lift it, you don't need a, a wheelie thing. And so sending a URL to a friend and going, "Hey, what do you think of my document?" A- and then being able to live co-edit that, comment on it, and interact together is just so much richer and so much easier from a standardization perspective. And that then allows us to use open document format and keep your actual raw data in a really, future-proof consensus industry format rather than a, a documented dump of the Microsoft internals. So that's a good thing too. Jonathan: Yeah. So one of the, one of the things that we've talked about, and we've talked with for example, Simon Phipps about this, he's done a lot of work with this over the years- Sure ... is trying to convince particularly European governments not to mandate the use of Microsoft Office document format types. And it seems like some of that is finally taken in the form of what they g- what they're now calling digital sovereignty. Michael: Yeah. Jonathan: And that's obviously, it's something- ... that you guys have to be, like, tracking along with. And I have several questions about this, but first just what... W- where are you in this process and what do you see going on? Michael: Yeah. So I think we're at the, really at the center of the, the drive for digital sovereignty. I'm periodically more or less encouraged about where the open source world is g

  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.