Hey folks, welcome to another episode of The Security Table. This is Chris Romeo. I'm joined by my friends Izar Tarandach and Matt Coles. The crowd goes wild. Our one fan in Australia goes wild. Whoever you are out there, we're just sending a shout out
and that guy at the gym. Who And that guy at the gym.
Yeah, the guy at the gym
The guy at the gym, yeah, don't forget the guy at the gym.
yeah. We're really moving though, we've got, you know, two fans now, so.
But hey, interesting thing, interesting, I learned about Australia this, uh, this week. So apparently there is a, uh, a contest every year. Dance your PhD. So, like, people who get their doctorates, they're supposed to make a video clip of them doing some kind of dance PhD. And this year's winner, this year's winner is a guy from Australia that actually worked on finding out that every kangaroo has different personalities and that leads their social behavior and whatnot.
And the clip, I swear you have to see this thing. So go look for
send it, we'll put it in the show notes here so that people can tune in to this
I kind of wanna, I want, I kind of wanna see what somebody who did a PhD in cyber, in cybersecurity would look like. Jumping through holes. Uh, attacking, attacking people.
No, they'd be laying on the ground crying, that's, that would be their
I think it's called the Swan Lake. And it has the one where all the swans die in the end or something like that?
Hey, dude, spoiler alert! I haven't seen Swan Lake yet!
or, or Nutcracker or the Nutcracker.
Uh,
cracker!
I never, I'm never willing to go watch that just based on the title. I haven't really researched it, but I'm
Way too personal.
what that, what actually that entails. Well, we should probably talk about something in the realm of cybersecurity. here comes the awkward transition back to the building blocks, a path towards secure and measurable software. So this is a, uh, document that was released, uh, around the end of February, 2024. And it's a statement of support for software measurability, which I don't really know what that means, and memory safety, which I feel like I know what that means.
And so let's, let's explore this topic a little bit and see what, uh, we might have to, that's good measurability right there. So, we can deal with the easy one first. I think we can all agree that there are more risks and more threats on the internet each and every day. And, bloody blossom, we can skip over any introductory material. And we can even skip over the history lesson where they talked about the Morris worm.
I remember that one like it was yesterday because I was in middle school when that happened. I don't remember it at all. Slammer Worm, I do remember that one, 2003. I was working incident response at the time. And that was a, that was a challenging couple of days, let's put it that way. And then even Heartbleed, which we all lived through. They said Heartbleed in 2014? No way.
Oh, no way.
that? Fact checking. Heartbleed was way before 2014, wasn't it? Before
feel like it was like, yesterday. Let me see, I was at EMC, so yeah, that sounds like it.
Yeah, maybe it's right. I don't know. All right, let's talk about memory safe programming languages. So that's one of their, their guidance things that they're providing for us here is that, um, we should, we should use memory safe programming languages. And I'm just looking for a definition. Unfortunately, didn't give one of what a memory safe programming language is. Uh, but when you guys think memory safe programming languages, Matt, you have a definition.
You always have a definition for me when I'm in peril here in the middle of an episode.
Yeah, so, so memory safe, memory safety in general is, uh, a computing, a part of a computing system that is, has certain guarantees about when it comes to memory, memory management and buffers. And so memory safe languages. are things that enforce boundaries on, uh, on buffers such that, for example, let's take a example, a good example here is C versus C I'll say, I'll go out on a limb here, C is a memory unsafe language.
Uh, I probably could use Java as the safe language too, but I'd rather use C for now. It's not, it's close, close enough for this purpose. So C is, well, for the most part, so C is, is memory unsafe. When you allocate a, when you allocate a buffer in C, you get a pointer, and that pointer points to memory, and you're expected to know how big that memory is, and what your bounds are, and how to do pointer math, right?
And when you write strings to it, There are, there are string functions that, like getS, that will just randomly or just arbitrarily put data into, into that buffer and it will overflow, if you allow it, as opposed to something like, uh, the standard template library for C which has a string function, or a string object, which, which we call C which knows how big the memory buffer is and puts boundaries in your way, uh, in theory, right? In our way.
Still break that, of course, but because you can get ultimately get to the C string underneath, but, but the, the, the library itself gives you guardrails. Right? We like to use that term guardrails, uh, so that you, as a developer, don't have to worry about and don't have to, don't fall into the trap of, um, putting too much memory, put too much, putting too much data into a buffer that doesn't have memory for it.
And so the theory is that a memory safe language would have a natural construct, meaning it would have a type, say, of string, that was automatically doing that bounce checking for you, you wouldn't have to use a library function, like in C and that the compiler, or the framework, or interpreter, or whatever, would treat all of that for you, and take care of that, so you can avoid memory exceptions, memory faults, and the whatnot. So that's, that's the general gist of a memory safe language.
So what are those, what are those, what do we consider memory safe languages today then
Yeah, so the NSA, the NSA has a list, I think, that they've been working on. Um, the big ones, I think, are, are, um, the big ones, with some caveats, I believe, are things like Rust, Go, Java, Python, Ruby, uh, and, and like I said, C can be Can include memory safety. Again, these are all with caveats because many of them still will allow for direct memory access and have certain things that can allow the violation of memory safety.
But some of them have better boundaries, better guardrails than others.
And I, and I think I think something we can, we can draw a parallel to as we're facing these memory safety issues that just came to mind is when I think about SQL injection. Right? We've known about SQL injection for a long time, and we've only recently gotten to the point where frameworks are doing good things to make SQL injection harder to add to your code. It's hard to add a SQL injection function, but there are ways, even with ORMs, Object Relational Managers, to
Object relational mappings.
mappings, I
Mark Mappers or something like that. Ha ha
thank you. Thank you. I'm always I always want to give it its own its own special name That just I call it but the point is you can X you can still execute raw sequel Most ORMs have that capability. So it's like you have, but you have to choose to do it. And so it's not, I wouldn't say that using like ORMs are secure by default. They're secure by, they're almost secure by default.
But once again, you have that, you have that need to use the functionality that sometimes you have to execute raw SQL because the ORM is just too slow to make the request.
Right. And the same with memory safety, right? The whole reason why C is still a popular language is because you need to be able to do memory, you know, memory manipulation. You know, say if you're on an embedded processor, for instance, and you have limited function capability, limited memory and processing power, you may need to do that manipulation yourself.
The memory safety, I don't know the statistics on this, but just thinking about how languages work, I imagine memory safe languages add overhead.
Okay,
They have
parenthesis here. Can I call bullshit in this whole thing?
Beep! Oh, oh, I forgot to hit the beep, sorry.
Because, listen,
you can.
I, yeah, I, I, I, I was born inside of C, right? I, I, I, I, I was, I, I, I came to the world of computing with a C compiler in my hand. And back in those dark ages. There was already Libsafe, Valgrind, Mem God, I forgot already how many different ways there was to go and attack the memory problem. Because everybody Purify came later and became other things that we use today. But everybody knew that that was like the thing. It wasn't even the skeleton in the closet.
It was the corpse sitting by your side as you wrote code. Right? So people knew all that.
I still have a copy of the Ten Commandments of C programming, and one of them is you'll not poke
play with the no pointer! Yeah, but my point here is that exactly what Matt said. All these languages, that they are like memory safe, and yes, as languages they are memory safe, but many of them let you play with the byte codes that they create themselves, as part of the language. An obscure part, but they let you do that. Then you went to C and you said, well there are libraries that make it memory safe. Yes, there are, but C also has libraries that make it
Yeah, but people didn't ever use them.
No, no, wait, wait, wait, wait, wait, wait, wait, wait. But then I go back to your, to your example of the, the ORM, and when you need to go and do the, the raw query. These memory safe, uh, uh, languages, most of them, and I think that's fair to say that today, still, sometimes they are too slow for what they need to do. And that's when people get smart and they go one level lower, and lo and behold, memory problems are there too.
Not to mention that the whole framework that they're built on, the compilers, interpreters, whatnot, at some point it's written in C, so as those things keep being developed, or C C, the problems are going to keep appearing. I don't remember which CVE it is, but there was a buffer overflow in a Java interpreter not, not, not a long time ago,
But that's infrastructure, like, you can, you can separate that into infrastructure. used to build the software versus the final product that
But wait, wait, the point, the point that I was trying to make is, is this really important? with all the other stuff that we have many levels above the memory corruption. Is this really where we need the White House putting their fingers in?
so, on that front. So let's just unpack this just a little bit. So, first off. Should the White House be getting in the middle of what, what often is a religious warfare among, among developers about what language to use,
It won't be the first time they get in the middle of religious warfare, so they have the expertise.
So, so, but I mean, should, should the, should the government be it? So I guess on the one hand, this is a recommendation, not a requirement, but it's a strong recommendation to Do something different, right? Here, industry, we recognize there's a problem. Do something different. Here's a way to do that. Is that, is that the right thing to do? That's, that's number one, right? Maybe let's answer
Here's a bucket,
Well,
if, I mean, what do you, it'd be one thing if we could disagree with the guidance that they're giving as, as multi decade security professionals, all of us sitting here, it's one thing, but there, there is, there, there's really not a lot to disagree with here. Like, I mean, do we, outside of the political issue of, should they be in this lane? Do we fundamentally agree or disagree with the guidance they're giving, which is, which is move towards memory safe languages for new stuff,
so I'll just point out that they stopped a little short. Right? They said use memory safe languages when you can and then provide an alternative if you can't, right? Moving to memory safe hardware and something called formal methods. Now, memory safe hardware Right is taking what the software could do and make and enforcing it on chip, right? Such that you have a controller, physical controller, hardware controller, that handles memory,
which we have some of that, right? Like there's, there, there's been some innovation in the last 20 years with like, uh, the no execute bit in CPUs, right? You can mark parts of memory as no execute so that technically you could have a hardware protection. And so I
you don't have ASLR, you don't have ASLR in hardware, I don't believe.
Yeah, but the MX is like a processor instruction though. Like it's, it, it, you can, you can carve out areas of memory that you specifically say cannot, you can't
Your heap memory, your heap memory more
And so, but like things like that are
You, you mark them in software, wait, you mark them in software, but you check them in hardware. The problem is that they
Hardware enforces, you set the policy in software and hardware enforces the policy
So the moment that you've set the policy in software, in theory, you can intercept, intercept and change the policy before it reaches the, the hardware where it's checked. So it's, it's not 100 percent
But at that, I
best of my memory.
at that point, the, you know, the, the, the figure from the horror movie is already inside the house.
So that's exactly my point. Here, when, when
call is coming from inside
Yeah, the calls coming from inside the house. That's what I'm saying. If you're, if you already have that level of access to an executable to the running, a running process in memory, I don't need to worry about the policy. I'm already inside. And so, but my point is that protection is at the gate. So if you've hurdled the gate, there's, there's nothing else. I mean, then, then we got a lots of other problems. There's lots of other ways you can hurdle the gate.
but, but my problem, my problem is different. You, you, you look at the depth of the thing. I'm trying to look at the breadth, perhaps apart from math. Do you know many people on your day to day interaction with developers that write C C No,
Apart from Matt. You said apart from Matt.
I know what he works with.
Yeah.
Yeah.
I know. I know. I do not. I do now. Now, granted, I used, I spent 11 years of my career at Cisco. And in those days I would say, yes, I know
Yeah, totally. Yeah, of course.
that.
But again, it's the same thing with the people that Matt works with, right? They're writing close to the metal. Last I know, what was it? I don't remember the last time I saw a chip that could interpret Java, but I know that such a thing exists.
Uh, they exist on smart cards
Yeah, true.
we know how smart those cards are. But But my point is, when I'm trying to educate developers in stuff that happens closer to where users interact with systems, uh, in threat modeling, in, uh, uh, interactions between systems, all that good stuff. I can count in the fingers of one short fingered hand the number of people who would even consider memory problems.
because you're in a high level language that doesn't have, that naturally addresses
high level world.
Yeah. But that's the whole point. That's the whole point of this is why not just give developers those, those newer, newer style high level languages that already provide the memory protection
We already did. We are not even teaching people C anymore. We are already in this world where 90 whatever percent of developers already live in this world where they
Well, we live in a web world. We live in a web world, right? Most development is being written in JavaScript these days, using various frameworks, like we're not, we're not interacting with metal. Some people are, but the, the, the vast majority of the 30 million developers on earth are not writing C or C plus
And so this actually brings up an interesting, sorry, so this actually brings up an interesting point. So there was a, there was an article that somebody wrote in response. Uh, they posted on Hackaday, uh, where they talked about this being a red herring insecurity.
And for that exact point that Izar raised, you look at the, if you look at the top CVEs, like the, if you look at all the CVEs that are getting created, and you look at the weaknesses that those CVEs are coming from, a very, very, very, very small percentage are memory safety problems. They are mostly broken authentication, broken authorization, web related issues, SQL injection.
Yeah, well OWASP top 10 or CWE top 25, with the exception of the buffer related items, there are still those because they do happen. And when they happen, they are really severe,
Yeah.
right?
let's revert that question. Will this solve any of the OWASP top 10 problems?
probably not the OWASP top 10, but certainly the top 20, CWE top 25.
Well, I mean, there are, you can write web applications in Go and Rust. People
Yeah, but when was the last time that you saw someone say, hmm, I'm going to write a web application? Int main open char asterisk asterisk argv. It doesn't happen anymore.
It's possible, but
Well, but, but, but also, but also what, I mean, when was the last time you saw memory safety or memory corruption as a, as a problem in a web application?
I can't remember. Oh, I was skipping this one for the whole podcast. Okay, so
So,
No, seriously, I can't remember.
so there was a quote, there was a quote in the White House article that they, or sorry, there was a quote in the NSA, there was a follow up article from the NSA talking about memory safe languages, like what are memory safe languages, and they, they provided some, some statistics that Microsoft and Google were reporting that memory safety was something like 70 percent of their issues.
Now, those are not translating to CVEs, those are translating to, obviously, if you run static code analysis across a code base, you're going to get a ton of stuff. that hopefully never makes it out in the light of day. So is this addressing publicly reported vulnerabilities or is this reducing developer effort and workload? By moving to memory safety.
I would say that it's reducing possible future CVs, again, I posit that there are exactly three people in the whole country who read this thing and went, Whoa, that makes sense. We should stop using C C
Nah, I disagree. I'm going to disagree violently. So,
Okay.
not violently, but just, I'm just going to disagree. So, but when you think about CISA and the White House, what are the, what are the categories of technology that they're most concerned with? Is it web applications? Is that what keeps them up at night? No, it's critical infrastructure and it's ICS,
take me there,
but it's
ICS and OT,
what is ICS, what, what is most of the code for ICS developed, the products that are running our power grids,
and assembly,
they're written in C and C today. And so,
assembly
the way, is memory safe.
Okay, but then also think about this, okay? If you're driving a Tesla or any automobile, what is the bulk of the code that's running the safety systems in a car built, you know, that was, that you bought this year? Is that, you're not writing that safety code in, in Java. Heck no, I don't
just explain,
I'm hit my
just explain why I'm not driving a Tesla.
Yeah, but I hit my, if you wrote all my safety software in Java, it would be so slow. I hit the brakes and nothing would happen for 10 seconds while I plow into a tree. And then it pops up a message that says you got to upload your J or update your JD, J, whatever the JRE
Java, Java has Java has real time, has a real time extension, right? I mean,
Would you put your safety, we could run an experiment where we run a car controlled by Java with real time enabled driving towards you and we'll hit the brakes at a certain point and you can decide whether you want to. Test that, uh,
I mean seriously, it is primarily going to be, I would imagine, I don't know for sure, but I would imagine it's a lot of C and C code, right? But it could also be Go, it could also be Haskell, it could also be Rust. We don't know, but something that's performance
but I think we got to get out of the web world. I think, I think we're kind of, we're putting web blinders on for a second. And I don't think that's what they're, I don't think that's what they're focused in on is the
Yeah,
They're focused on the things that they care about the most.
Rust and Linux kernel. I don't know a lot about it, about the details. It's been a
It's, it's recently introduced.
but it's recently
Yep.
and apparently it's making a big splash. Apparently
Good. In a good way, right?
yeah, yeah, yeah. Apparently you can even write drivers in it. So that issue of like memory mapped and shared and all that good stuff and things that you could overflow all over the kernel, uh, might go away. And I hear that people are very, very enthusiastic about it.
So, that is a move that, first, I wholeheartedly support, even not knowing all the details, but the little I know already makes sense, but, uh, do we need a White House memorandum to do that, or we just needed a bunch of smart people who decided this thing in a kernel and said, hey, this is a good, good thing to do, let's do it.
I can't believe I'm arguing on behalf of the white house at this point. Like what's happened to my life where I'm like taking the side of, I mean, but it's, it's a, it's about just spreading the word at this point. Right? Like we've had so many of the same problems that have existed. These class of bugs is what took out the, was what the Morisworm, right?
So next week we're going to, to have a memorandum saying don't write raw SQL queries?
That'd be nice. I'd, I'd read it. I'd be happy about it.
No, I mean, where do you go from here? Are we You see where I'm going? Like, is the White House now competing with OWASP?
Somebody's smoke alarm going off.
that's mine. Keep going.
Uh, do you need us to call 911 for you?
Now I have somebody upstairs who's working in the kitchen who I hope is on top of it. So.
I think somebody heard your comment about the White House. But For our
And we're clear. We've
we love
level. Safety level zero has been reachieved in the house here.
So, so Izar, are you saying, so I guess, are you saying on the point of should the White House, should the White House or the government in general be driving this behavior? Sure.
No, no, no, no. I'm cool with them driving this behavior. I'm I'm just asking for is this the right behavior to be driving? Like, shouldn't we go way, way, way, way, way above?
well, so, I mean, if you take, if you take Chris's view, which I agree with, right, that their focus is critical infrastructure and military systems and, you know, national defense and national security, the water supply and the electrical grid and these sort of things, and these are all written in low level languages today, right? They have to be performance, real time performance, correct, you know, fully functional, and Fail safe and fail resistant or fault tolerant, right?
And so that's their focus primarily, right? And in that regard, they're putting a position out there and others can take advantage of that information as the technology has become better. Right? If anything, the government has always been in a position of driving innovation and R& D that trickles down to the commercial sector,
If anything, the government used to be more involved in the security side the seventies and
With DARPA and NIST
far as pushing the envelope, that's where a lot of guidance really came from in the early days of our industry. We don't, we don't often look back on that and reflect on it, but that's where the bulk of our guidance came from.
right? That and partnerships with universities,
Yeah, true.
let's take a peek at that for a second. Let's, let's say that the, the reason behind this, this move here was infrastructure. You guys know that the life cycle of infrastructure is way, way, way longer
This is a 50 year
normal software. So, okay, so we're going to, we're going to reap the benefits of this in 20 years, while for the next 20 years we still live with infrastructure that we know it's completely
I got, I got a little hung up on that too, but yeah, but, but I mean, so like, that's kind of a,
and I'm willing to, I'm willing to bet, I'm willing to bet that the new versions of hardware and software that are coming in the market now. that are candidates to substitute the infrastructure, the broken infrastructure, that's in place, already come with enough guardrails and safeguards to be at a much better space than, oh my god, somebody's sending me a packet, uh, a ping of death.
yeah. I mean, but at this point, like, we can't look at it and go, Oh, you know what? It's, you know, it's, it's, we can't take the Eeyore approach. We're like, Oh, everything's terrible and there's no solution. So let's just, let's just sit here and do nothing. right? We got to do something. Is it, does it solve, but yeah, does it solve the problem today? No, I don't, this doesn't do, this doesn't solve the problem today. It doesn't solve the problem in five years from now.
The hope is that by 10 years from now, this shift in policy, as far as what languages people are using, are causing products to make their way towards memory safety and maybe you draw a line at some point in the future, like 10 years from now and say, 10 years from now, we're going to replace all of this crap. So if you don't have new products that do this now, okay, maybe that's what should have been in here. Maybe, maybe
I would feel much better if they said, you guys have five, five years to rip everything out and put everything that's memory safe in place. Then I would sleep much better.
who's going to write the check for trillions of dollars to pay for the, the replacement of all of our critical infrastructure technology stacks.
Don't you have a printer at home?
Your print money. Yeah,
don't, I don't want the treasury department showing up at my door.
Again?
they already show up enough. Um, yeah, so I mean that, but, but I, I would say we don't, in my mind, we don't not do something just because it's going to take a long time. Like we got to get this ball moving in the right direction,
that, that, that's true. But what, what, what, okay. As a mitigation, what makes more sense? To go back to the infrastructure, the broken infrastructure that's in place today, look at that black box that controls the flow of water from the reservoir. and ask yourself, hmm, does that thing need really to be publicly accessible? Perhaps I can use some other network that, uh, perhaps most of people can't get into,
most of that
or rewrite it from zero.
It's not publicly accessible today at this
boy, we hope
Then what's the problem?
I mean, attackers, I, I have known to enter systems and move laterally and make their way through, especially nation state attackers that are highly
If it's laterally, then it's accessible at some point.
Well, everything's accessible at some point. That's
no, you could say, you could say the internal, the internal threat, and I would wholeheartedly agree with you, right? But if
Which, uh,
for, uh, for centrifuges is
yeah, yeah, it was the
Oh, Stuxnet!
Yeah.
stuck snap. There was, but it was malware that was, that broke the air gap on a USB. Cause somebody made a bad decision and plug something in. And so like we know as security professionals, there is no such thing as secure. There is no, it doesn't matter unless you, unless you disconnect it from the internet and bury it in your backyard. Without a Wi Fi and power like you bury it in the backyard with no internet connection Then you can tell me that thing is secure. But other than
but also,
it's
but also is
going to unbury it and get it, but the point is that
but is there your, yeah, go ahead. No, you finished your thought. Are you finished?
that would be addressed internally by the government. It's between them and their providers. This is out in the public for everybody to consume. Sorry,
I, I, I, no, no, you're making, you're making an interesting point. I think that one thing to consider is this, of course, should not be read in a vacuum, right? Put this with the, with the executive order, you know, when it was a 14508 or whatever that, whatever the number was, right? Where, and, and things like CISA secure by design, secure by default guidance, which, you know, they're all starting to synergize now.
But they're up here, but they're meant to be looked at as a comprehensive part, right? And so, memory safety is one of those building blocks that you add when you So you do threat modeling, and you figure out what your attack surface is, you make sure you have authentication, and then when you get to the core critical function that's
You put a parachute and you dive all the way down to memory safe? That's what you do?
So, so what you're suggesting is that the White House maybe jumped into the pit before that they, uh, addressed the latter?
in a threat model do you catch yourself saying, oh wait, you guys are sending this big, uh, a string? Are you sure that you are checking for length? Because, you know, at some point there might be a buffer. When was the last time that you raised a buffer overflow in the threat model?
I do.
don't count. I told you that you don't count,
design sits above the threat model, right? Threat modeling. So this is, this is one of the things I've seen people, I'm not saying you're struggling with it, but I've seen the industry struggle with this. And that is that secure by design, they equate secure by design and threat modeling. That's the same thing. And I say, threat modeling is a, is a vehicle, is a supporting mechanism of Secure by Design, but it is not, you cannot say, I do threat modeling, so I am Secure by Design.
Remember, like, choosing a language is an architectural choice. which should happen at a certain, certain degree of threat model. If you're talking, if we're going into the room, the three of us with an engineering team, and they're building a brand new product from scratch, we are going to ask that question in some of the early meetings before we even draw a picture, we're going to be asking about what language direction you think you're going in. Oh, we're going to write this and see,
Well, even if, even if we're doing threat modeling, even if we're doing threat modeling, I always ask, what language is this written in, because it can change across a, across a system, right?
But not, not only that, but when we go into that, we are exactly looking at eliminating the class of vulnerabilities or flaws that's called memory management, right? Yeah. and lo and behold we've been doing this for years and years and years without a memo from the White House.
So you're not
incorporated this into what
not arguing with the memory safety. You're just saying you don't think we need a, you didn't, we didn't need a memo to draw our attention to it.
Yeah, I'm just saying, hey, we are up here in security by design, all of a sudden now you're talking to me about memory management, and what's the next one that I can look forward to?
Well, so the counter argument,
But, uh,
Oh my god, let's go back to Tempest from 50 years ago? But anyway,
Which by the way, actually, if you, if you could look at it, you could look at the latest work they've been doing about, uh, EMF from CPUs and stuff, and even the parallel memory reading, we're back at Tempest. So yeah,
I don't disagree with you, yeah, I, I mean, the, the argument back to you might be, who, who in the industry would have, would have launched this, this, um, this discussion around memory safety, and why hasn't happened before, right? And because it, but it, but it has on a per, on a per, like the individual companies have
no, that's why we have so many tools that deal with this stuff.
Yeah, but we've, I mean, there's been conversations about memory safety. This isn't the first time anybody's kind of raised their hand and said we should use memory safe languages. This has been happening for the last couple of years as Go and Rust have matured and people have started to say this is a good alternative.
am I
in the IETF, if you look at IETF and ISO, do you see, do you see calls for memory safety?
What would IETF, what would either of those organizations
IETF at low level protocols, if you're dealing with actual packets and buffers and like doing, you know, pulling bits off of the wire.
but they don't prescribe. They, they, they don't, they don't prescribe how you build implementations in an IETF standard. They,
But they
it, what it has to do, well that's
they could, but they don't,
that's a whole
wait, wait, but even, even the move that we had way back when that we had XPC and RPC, and it would create these nifty stubs and pass data from one side to another. That was still open to memory, uh, to memory issues, but then came Protobuf, Protobuf.
Protobuf.
And everybody jumped into that N-G-R-P-C and they have implementations for CN, for c plus plus. So that thing is there already use. Use the right function parallel. Use the RRM and you. You got shielded right.
All right. We gotta, we have to wrap this conversation up for today. It's been, uh, it's been feisty, which has been good. So hopefully our audience has enjoyed, uh, our back and forth debate. Uh, but this is a great, it's a great issue. It's, it's going to be fun to watch how this progresses over time. Thanks for listening to The Security Table.