Cup o' Go

Creators & Guests

Host
Adelina Simion
Education Engineer at Spectro. She is an organiser of London Gophers and Women Who Go London. She has been a Gopher since 2018.
Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Editor
Filippo Valvassori Bolgรจ
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Adelina:

This show is sponsored by you. This is Cup o' Go for March 8 2024. Keep up to date with the important happenings in the Go community in 15 minutes per week. I'm Adelina.

Jonathan:

And I'm Jonathan. Good morning, Adelina.

Adelina:

And this is Cup of Go.

Jonathan:

It is.

Jonathan:

Yay. Welcome to the show.

Adelina:

Thanks for inviting me. I'm excited to be back.

Jonathan:

Shai, came down with a a head cold or something this morning. So, unfortunately, he's not here. But the timing couldn't have been better, I guess, if it's gonna happen to have a woman cohost on International Women's Day, which we'll be talking about pretty soon. So I know you're excited to talk about that.

Adelina:

It was happy International Women's Day to everyone.

Jonathan:

Before we talk about that, let's get out of the way the 2 topics we promised to talk about on the last episode, which were the new releases that just came out. So we preannounced last week or we we reported a pre announcement last week. I've got 122.1 and 121.8, which are now out. These are mostly security fixes. Some of them are kind of important.

Jonathan:

Crypto stuff, crypto x509, certificate verification stuff can break. The stuff that's most likely to to matter to most of you are HTTP related things. It's possible to exhaust your memory with a maliciously formed multipart request. There's some bugs, in the way cookies are handled. It can do some insecure forwarding of cookie headers.

Jonathan:

And HTML template, the usual suspects as always. Crypto, HTTP, and HTML template. HTML template does some incorrect, escaping of JSON in some cases. And I can't forget there's something in net mail. Comments in display names are incorrectly handled.

Jonathan:

I don't know how how serious of a security vulnerability that is, but it is something. TLDR upgrade and do it soon if you,

Adelina:

don't like DOS attacks. Yeah. Definitely the net HTTP fixes caught my eye because I think a lot of people will be handling huge payloads that they don't fully control. So I think that'll be very useful to make sure you don't, like, end up in a memory leak situation.

Jonathan:

Exactly. Yeah. And closely related, there was a security update to the protobuf family of packages, which solves a problem with, unmarshalling getting stuck in an infinite loop on some invalid inputs. So if you use protobuf, update the protobuf packages as well. That means protobuf, gRPC, or any of those family of things that that use protobuf under the hood, update those.

Jonathan:

That's the dry boring news. Update your your stuff. Doesn't really need to be said that often. Like, you should update your stuff.

Adelina:

I feel like golfers are pretty good with updating.

Jonathan:

I hope so. Yeah.

Adelina:

As opposed to like because I have a I've as I've said before, I come from Java. Like, I just know I just know that there is someone out there still running. I don't know what version of Java.

Jonathan:

I have a client still using Node 8.

Adelina:

Oh. And and

Jonathan:

and they can't update because, of backward compatibility problems. You know, that's probably you don't have with Go. If you jump into a client that's still using Go 1.2, you could probably update fairly easily. There'll be a few things. Like, you have to add modules and stuff like that.

Jonathan:

But for the most part, the language is is gonna be backward compatible, so that's really nice. Let's talk about International Women's Day, though.

Adelina:

Oh, my favorite topic.

Jonathan:

Is it?

Adelina:

So, no. Just joking. It is today Okay. My favorite topic. So, yeah, International Women's Day, March 8th.

Adelina:

And, are you wondering maybe, when we started celebrating it?

Jonathan:

Yeah. What tell me about this history. I mean, women have been around for a really long time, and nations have been around for a long time, so you would expect.

Adelina:

You won't be surprised when I tell you that it started as, a movement from the labor parties around the world. And the first time it was celebrated was in 19 0 9, and it was actually in New York. So they're the first ones that celebrated it and then it caught on over in Europe who were obviously like also having a huge labor movement throughout the continent. What I think is also quite interesting is that the UN, marks every year with a different initiative towards helping gender equality. And this year, their campaign is called Invest in Her, and it's all about helping women and other marginalized people achieve gender equality through public funding and public policy.

Adelina:

Mhmm. And you can read more about what the UN is saying that we need huge discrepancies in wealth as we know, especially because women work in the care industries. So, yeah, that's all I've got for you for International Women's Day. One other thing I would mention is that in tech in general, for inter throughout March, we share our stories in one way or another. And I really love the devdot 2, also known as the practical dev campaign, which has this year been called We Code It.

Adelina:

So we're gonna provide a link to that so you can check it out. On the Practical Dev Dev 2, there's a special tag called we code it so you can read what other people have contributed and this runs throughout the month. And it's all about people who are sharing their stories, recommendations, what they think needs changing. And I think it's really lovely when you look back at the collection of material that people write around this time, mostly around women sharing their stories. So have a look at these things.

Jonathan:

Now on on a related note, you are heavily involved in Women Who Go also. Right?

Adelina:

Yeah. So Women Who Go is all about giving women, like, golfers, women that right goal, giving them a space to discuss and to speak, and for us to put forward women role models. What's really interesting is that, sorry if I'm taking up too much time, one of the things that I'm really passionate about when we go to events, because we have in person events in London, is that everyone asks questions because loads of the time, a lot of the time, we want to be invisible. We don't wanna say I don't understand something. So I always take time and I ask questions and the speakers feel engaged, and I always want to foster this kind of discussion.

Adelina:

So I it feels a bit strange like I'm forcing it in the beginning, but people get really into it. So, yeah, that would be my other thing.

Jonathan:

Let's talk about meetups. I wanna mention 1, for Shai. I will he's not here. Do you have any, meetups in your area coming up, either for Women Who Go or Go in general?

Adelina:

Yeah. So I live in London, so I'm very, like, UK oriented. And with London Gophers meets this month on 20th of, of March and we can leave a link on where to register on Meetup. And I also wanted to mention that the call for papers for Gofer Con UK, is open. It opened on March 1st and will close on 17th May, but get your papers in early.

Adelina:

So GopherCon UK is a lovely conference. About 500 gophers gather and it's in Central London. I really like the event as you can tell and it's happening from August 14th to August 16th this year. It's always in August. So going forward, cancel all August holidays.

Adelina:

You gotta be ready.

Jonathan:

Does anybody ever have an August holiday? Like, that's the most boring month when it comes to holidays usually.

Adelina:

I think it is my most popular month, state holidays.

Jonathan:

On the, meetup front, Shay is not here today, but the Israel Go meetup is happening this coming week on Tuesday. So if you're in the Tel Aviv area and wanna go meet Shai, get wish him a happy recovery. Hope hopefully, he's recovered by then. Don't miss that event. And I'm sure we'll hear from Shai next week how it went.

Jonathan:

Let's talk about, I I was gonna say some proposals, but really really just one I wanna talk about. Well, it's actually a group of proposals, so I guess technically it's some. But we just saw the news, and and actually we're gonna talk about this in the interview that's coming up. Sorry, Adelina. You weren't in that interview, but Shay and I had an interview with Filippo Vasorda, who does a lot of crypto work on the, Go project as a freelancer.

Jonathan:

And he mentions in the interview that they're trying to move a lot of the xcrypto packages into the center library. Well, that has officially been accepted now. It wasn't at the time of recording, but now it has been. So there's a whole bunch of the crypto packages that are previously under golang. I think it's golang.org/x/crypto.

Jonathan:

I I don't know if they're all being moved, but a large number of them are being moved into the Standard Library. So I think that's pretty cool. It it means that they'll sort of get a little bit more attention. They've already kind of been treated as though they were the Standard Library anyway even though they weren't in the Standard Library. So it's it's more of just a recognition of the current state of affairs rather than a meaningful change, but I still think it's useful and and and nice to see.

Adelina:

So when is this happening?

Jonathan:

So I don't think that that has been, defined yet. I I think I I would expect very soon, probably for Go 1.23 because it's mostly just moving things around, as far as I know. There may be some API changes that happen too, but I suspect anything that has any major API changes will be delayed. So anything that's more or less ready to copy and paste to the center library probably will happen fairly quickly. And I would expect to see a large number of new crypto packages in the center library for 123.

Adelina:

Can I ask a silly question?

Jonathan:

Of course. There are no silly questions.

Adelina:

So let's say that I've got code that's importing xcrypto.

Jonathan:

Mhmm.

Adelina:

And now they've moved it to the new place Mhmm. What happens then? Do I have to, like, update my code if I update go? Or how does that work?

Jonathan:

My I was wondering the same thing, actually. My guess, based on how they've handled other x packages that moved, and the big one I'm thinking of is when it was x net context. And then I think it was go 1.7. It just became context. You had to change the import path.

Jonathan:

But the API was more or less the same, so it was just updated the import path. I would expect the same to happen here. It's possible that they could put stubs in in place. Could, you know, go added the, alias type long long ago. So you could, in theory, move everything to the standard library and then have the x packages reference the standard library in in a in a backward compatible way.

Jonathan:

So either one would kind of do the same thing. But I haven't seen them do that in this in in the standard library. I think that's mostly used for internal projects. So I would expect you'll have to update your import path to to take advantage of that.

Adelina:

Wonderful. Well, I it's my favorite way to produce random numbers. Yes.

Jonathan:

Well, so you can use I learned actually in the interview that we'll be listening to here in a few minutes. I learned that the new math rand is actually much more secure than the old math rand. So if you're lazy, like I pretend to be sometimes, and just use math rand, You use mathrandv2, you probably get basically crypto quality random numbers anyway without even trying. But, you should still use crypto, crypto, rand instead.

Adelina:

Oh, I'm sure they've been they've done improvements. But, like, when it was when we I don't know, a couple of years ago, everyone was, like, screaming at you, no, don't use MathRand.

Jonathan:

The old mathrand was very insecure by default, I think, because it didn't seed the random number generator, if I recall. Let's shift gears a little bit. We have a couple of articles, that have been running around on the interwebs. One of them made hacker news has the, the delightful title of go enums suck. This comes through your

Adelina:

And the the subtitle is well, not the subtitle. The what's it called? Like, the under.

Jonathan:

Yeah. Subtitle is fair, I think. Yeah.

Adelina:

Yeah. And the subtitle is, let's make them suck less.

Jonathan:

So this this article is brought to my attention, actually, by one of my, mentoring students, one of I'm mentoring, with his Go. He's learning Go, and I'm helping him, learn that. And he was getting ready to implement an enum or or something similar in some of his code and was asking, should I do it this way? Have you read the article, Adelina?

Adelina:

I skimmed it just now. Yeah? It definitely is one of the things I struggled a lot with when I was starting out with Go as well.

Jonathan:

Yeah. That's something I struggle with too, and a lot of people do. This gets a lot of attention. There have been various proposals to try to solve this problem. I imagine one day we'll have a proposal that that gets accepted.

Jonathan:

But if you're not familiar, if you're new to Go or you haven't experienced this yet, the the tldr is Go doesn't actually have enums. It gives you the ability to create constants, and they can be sort of, like, numerically ordered. But then what if you need a string representation of that? And what if you need to map from the string to the to the number and the number to the string? Then you have, like, 2 different maps plus your list of e, of not enums, of of of constants numbers.

Jonathan:

It's kind of a mess. And then you end up creating helper functions. And so that's what that article does. It kinda walks you through. Like, here's here's what Go gives you and here's the problems it doesn't solve.

Jonathan:

And then, like, that keeps building up and you have, like, 3 or 4 levels of problems. And then what if you need to marshal and unmarshal that to Jason or or protobuf or whatever, you know. All these different things come up. And and then his conclusion is a small library he wrote to try to make some of this easier for you. Have have you ever had to to do some of this yourself, when you're you have a list of 20 things and

Adelina:

Yeah. Especially with, like, databases. Right? So, like, the database might, like, return state to 0, and you gotta map it to not file. I don't know.

Adelina:

Whatever. Yeah. Whatever string you need. The thing that really upsets me, fundamentally about enums is like, so for example, in Stephen's example, he uses the type operation, which is, which has an underlying type of int. Right?

Adelina:

There's nothing really even though you declare these constants and you take an operation as a parameter, there's nothing really for stopping someone to make an operation that is, like, actually not one of the support supported constants. So I can cast, like, a whole other int, and then pass that, and then it compiles. And one another gripe that I have with enums is that I didn't know this. Perhaps everyone around me is a genius and they did know, but they are dynamically allocated in the const block.

Filippo:

Mhmm.

Adelina:

So if you if someone comes and inserts, like, 2 more lines further up, then the values change. Yes. They are dynamic values, but I think this is a very unintuitive way to, like, allocate the cordless block and what then happens. Yeah. So those are my two problems that I have.

Jonathan:

And that last one is the reason I have come to decide that I hate iota, and I wish it wasn't a feature in the language. I would just rather I mean, I I honestly don't know why it exists because Go is such a has such a ideology of against magic. And yet there's this magic IOTA. And it only has one very specific use case, and it's easy to do it wrong.

Adelina:

So And it's only you only see when you click on the documentation, the documentation for IOTA is, like, super long, like the the comments. And then only somewhere written in is is the dynamic allocation that we were talking about.

Jonathan:

Yep.

Adelina:

Yeah. And then the mapping back and forth is so brittle. Right? Like, if you have to maintain 2 maps, and then if if you do pass an unknown value, you again have to, like, wrap the whole thing with another function that checks whether that value is found. So, yeah, it's quite messy.

Jonathan:

So the the the two maps, I sometimes solve by creating one map and then having an init function that generates the second map. But that's also really ugly because I had to use an init function and increase the startup cost. And, And, you know, it's there there's not a good answer to any of this, really. So, you know, it's it's hard to criticize his library because although it doesn't make all the choices I would make, none of the choices I would make are necessarily correct all the time either. So please go team.

Jonathan:

Let's let's have some enum types added, in the future, please. We really we really would, the entire community would thank you.

Adelina:

Oh, yeah. Definitely. And especially the newbies because the newbie I believe I was confused.

Jonathan:

Definitely. Well, thanks, Steven, for the article about that. Let's talk about another one here. This isn't really an article. It's a discussion on Reddit.

Jonathan:

And, it has another amazing title. Why does go have so many traps? And so the the poster asks, he he's actually reading a book, 100 go mistakes and how to avoid them, which we've talked about on the show in the past. And he's just surprised that going through this book, all these little, as he calls them, traps that you can run into in the Go language. And why does Go have so many?

Jonathan:

What do you think, Adelina?

Adelina:

Yeah. I think just fundamentally because we there's not really anyone that starts learning it, and I've spoken about this before. We all come from another language, and we come with our other language opinions.

Jonathan:

Mhmm.

Adelina:

And then go just, like, maybe just can't just can't do that. But I think the linter has gotten better, and I think the tools have gotten better. And, it's, like, helped you know, Go Please has gotten better with, like, figuring out like what's how to guide people. One of the things that I've done a lot in the past before the linter flagged it is if you're going a for loop that uses an index and then you run that in parallel inside the for loop, then the index is the last value because of the parallelization happening underneath. You know what I'm talking about?

Adelina:

The shadowing. And now the linter, like, has the linter tells you, like, hey. Remember to use a variable that, like, takes this. That saves the value of the index inside your go routine or whatever you're running. And I've done that.

Adelina:

I know for sure I've done that a bunch of times in the past, didn't know, and probably left some bugs with Adelina on it, you know, in whatever code base I would have written.

Jonathan:

Mhmm. So the good news on that point is that particular foot gun is essentially solved in go 122. Although, you reminded me of another article. I wasn't gonna mention this on the show today, but I will now. It was shared in our Cup of Go channel on Slack.

Jonathan:

It's an article called for loop semantic changes in Go 1.22, be aware of the impact. And it talks about, this change and how there are some cases, although I don't think they're common cases. I think the article overstates the cases, where it has some surprising impact. So, let's talk about that in just a moment. Let's finish the discussion on, Go Foot Guns and Traps.

Jonathan:

Then we'll talk about that article briefly before we close out the show. So the author of the book actually chimed in. He has the top voted response on on Reddit. And his response is that many of the sections aren't traps per se, but mistakes we could make. So he makes a distinction between traps and just, like, garden variety mistakes, I guess.

Jonathan:

You know, some of the things are are they're not you're not gonna hurt yourself if you do it the quote wrong way. You just might not have the greatest performance or or whatever. So not everything you know, there's not 100 traps to avoid and go. It's 100 mistakes. Mistakes.

Jonathan:

Right? I would add to it that very similar to what you said, Adelina. I think, I think most languages have traps. The second most voted, comment says, I guess you haven't ever used JavaScript. 80% of that language

Adelina:

is traps. What the I was gonna say 3 equal signs.

Jonathan:

Yeah. So yeah. I I don't know if it's, a 100% fair to if the question is a 100% fair, like, why does Go have so many traps? Okay. Maybe it does in an objective sense, but it it may have more or less than other languages unless we're comparing it to something else.

Jonathan:

It's really hard to say if it's better or worse. In my experience, it has fewer traps. There are still some. IOTA, as we just talked about, is one that I wish wasn't there. But it's a good discussion, and it's surprisingly not, toxic, at least the parts I've read.

Jonathan:

For for Reddit, it's pretty civil conversation. So we'll have a link to that in the show notes.

Adelina:

But, definitely, I just wanna give a shout out to the gold team because I stand by my point that a lot of the gold drilling has gotten better. And, you know, it helps. It does guide you a lot in, like, what code isn't working and how to write it.

Jonathan:

Absolutely. So let's talk briefly about this article I just mentioned, 4 of semantic changes in Go 122. Be aware of the impact. This comes to you from go 101.org. I don't know the author's name, but go 101.org.

Jonathan:

Thanks for sharing this. It starts the first half of the article is is a summary of problem and the change in 122 to solve the problem, which we just talked about. And we talked about at length on the show before. But then it it actually pointed out something I hadn't thought about. There are some places where the new, syntax could be surprising.

Jonathan:

And so I'll just walk through one example. Let's suppose you have 4 n colon equals 0 and then some condition. And then let's say that you, call a function within that for loop, just as you were talking about and you pass and and and in that in that closure you access n, the thing that is incremented with the for loop. That n value is reset every time the for loop is executed, which might seem obvious because that's the whole point. Right?

Jonathan:

But in that particular syntax, the for n colon equals 0 semicolon on the other things, it kind of looks like you're setting n once and then you'd update it through that's the thing, but you don't. You're actually resetting that value every time the the loop goes through, and that can have some surprising impacts depending on how you use that value. And that's the point of the article. Now I've never actually written a a for loop that used that. And the examples he uses look contrived to me.

Jonathan:

So I don't think this is as serious of a problem as the article makes out, but it might be for someone. I'm I'm really curious if somebody, go read the article if you're listening. And if you agree with the author that this is a problem, come share it on the, the Capaco channel on Slack. I'd love to hear from you. Russ Cox didn't think it was a serious problem.

Jonathan:

I mean and and he did some serious, investigation into Go code in the wild and didn't find this to be a problem. But, it is a little bit surprising at the very least.

Adelina:

I'm just excited about having shorter loops, to be honest. Yeah.

Jonathan:

Yeah.

Adelina:

But I do think it's always important to know the edge cases.

Jonathan:

Indeed.

Adelina:

And while I do agree with you that some of the comp the examples are a bit complex, I'm sure that, you know, as gold grows, it's gonna be maybe it'll happen.

Jonathan:

It could happen. It could happen. Yeah. Alright. Well, Adelina, thanks for joining today.

Jonathan:

It's been a pleasure to see your smiling face again.

Adelina:

As always, thanks for having me. I had a great time.

Jonathan:

Sorry. Our listeners can't see her smiling face. You'll just have to listen to the smile on her voice. Stick around till, after the ad break when we have an interview with Filippo Valzorda, and you'll hear Shay's lovely voice again as we talk about open source contribution and security on the Go project.

Adelina:

Thank you.

Jonathan:

Thank you for listening to today's episode. If you're a new listener, thanks for joining us.

Filippo:

If you

Jonathan:

enjoy the show, we'd love to have a rating and or review from you on Spotify, on Itunes, wherever you listen to your podcast. Share it with a friend, share it with a colleague, share it on your work Slack or your Teams. Does any do gophers use Teams? I suppose someone does. Someone's forced to.

Jonathan:

Wherever you chat with your colleagues, share it. And, come talk to us. We'd love to get your feedback, directly as well. You can talk to us on Slack. We're on the gopher Slack in the Cupogo channel.

Jonathan:

That's cup dashodashgo kebab case. We haven't convinced anybody just to do camel case yet, so we're still doing kebab case. We have how many? We have 333 people on the channel now. So, it's a popular place to be, and share your news articles there.

Jonathan:

Some of the stuff we talked about in today's show, I learned about on the channel. So, come share your your Go news. What else can I say? Oh, you can be you can support us as a Patreon member. If you're not already, We will do a shout out.

Jonathan:

We'll shout your name out on the show. I'm not doing that today because I don't know who's joined us because Shai is the keeper of our Patreon, and he's not here today. So next week, we'll have a backlog of new Patreon members. Go to cupago.dev. That's our website.

Jonathan:

You can find all back episodes. You can become a Patreon member there, and you can buy swag. You can buy a cup like the one I'm drinking my coffee out of right now that has Brewster, our little logo. You could buy a t shirt. You could you could be the first one to buy the overpriced wireless phone charger that has Brewster on it.

Jonathan:

I don't remember how much it costs. $300 or $80 or something. It's it's way overpriced, but if you first of all, we'll shout your name out on the show as well.

Adelina:

The gopher with the cup of with the coffee cup is super, super cute. So definitely check it

Jonathan:

out. The stickers I I took a 150 stickers to Fozdam, and they were sold out in about 10 minutes. It was really popular. I don't know if anybody listens to the show, but they like the logo anyway. So anyway, thanks, Adelina, for coming on today.

Jonathan:

Thanks for stepping in.

Adelina:

Thank you for having me, and have a lovely, lovely day. I hope we hope you enjoyed this episode.

Jonathan:

Absolutely. Stick around for the interview with Filippo.

Shay:

So, Jonathan, what's your password?

Jonathan:

A b c 123.

Shay:

I'm sorry. That does not include a special character.

Jonathan:

Sometimes I add an exclamation point at the end.

Shay:

Oh, you got it. So I want to recommend, something called password game. It's in a site called Neil, dot fun, which we need more sites like that anyway. But if you wanna spend like 2 hours and get really really frustrated but be super proud at the end, you should try a password game. It's like a lot of rules trying to, you know, you start typing the password and it's like include an uppercase letter, include a special character, the digits in your password must add up to 25 and it gets, progressively worse from there.

Shay:

Must include a month of the year so you're like write May and then you have to include a sponsor so you write Pepsi, and then the roman numerals in your password must multiply to 35. So you lowercase the m in may because m is 500. You're like, okay, x x x v. And like, good. And then you need to fill in a capture and then you need the word all answer.

Shay:

And it gets worse and worse. It's a really fun game. Like, I don't think it's really the way to do cryptography right. You know what I mean? It's just too difficult.

Jonathan:

I don't know. Cryptography is confusing. I just do whatever is easy. I usually use MathRand.

Filippo:

Nah. Well, we got him.

Shay:

We got him. Hey, Filippo. Why don't you tell us why that's bad?

Filippo:

Well, here's the thing. I know that people like you do that. So in go 122, the the last one. Yeah. It's it's it's always hard because we're always thinking about the next release and then the one that got released, we are everybody gets decide about the one that we stopped working on a month ago and where it's always a bit confusing.

Filippo:

Anyway, go 122, actually switches the default of, Mafram, that the new Mafram v 2 package to a cryptographically secured random number generator. Now does that mean you should go and use mafram for, security relevant things? No. Please don't. Also because if you still do the new search source method, that one has to say stay the same for compatibility reasons.

Filippo:

So that one's still not secure. But at least when when people just use the, functions from the top level, of the package, most of the times we're going to save them from, shooting their own foot.

Shay:

So it sounds like you know a lot about Go and, cryptography. Who are you, Filippo? Why don't you introduce yourself?

Filippo:

Hi, everyone. So, I'm Filippo Alsorda. I've been maintaining the Go Cryptography Standard Library since 2018. I've done that first, at Google as the lead of the Go security team. And these days, I'm doing it as a independent open source maintainer.

Filippo:

We can talk about what that means a bit, more later if you want.

Jonathan:

Mhmm.

Jonathan:

Alright. Hopefully, I hope we do get the chance to do that.

Shay:

Yeah. And that's sort of the point.

Jonathan:

So let's start there. So about a year ago, maybe a little more, you announced in a blog post that you were going full time, sort of independently doing open source software. Just briefly, how has that year been for you?

Filippo:

It's gone pretty well. If we had done this a year ago, I would have told you, you know, about all the things that I want from that and why I think it would work. But, really, a year ago, it was an experiment. Mhmm. And I was very much making that as I as I was going.

Filippo:

And, you know, if the clients that signed at that time are listening, thank you for your vote of confidence. But it's it's going well now. I have a fairly stable, client park. I'm there's enough clients that my compensation is comparable with the one, I had with Google. And, I don't say that for bragging or because the most important part is compensation, but because I think that's one of the core parts, of making what I'm doing sustainable as a real option for, open source maintainers.

Jonathan:

Absolutely. Yeah.

Filippo:

The the whole point of doing what I did was not that I couldn't find another way to, be a maintainer on the Go project because I was working Google, on on the team, and they they were, you know, going to keep paying me to do that for Google. But I wanted to test out if it was actually possible to find a model for funding open source maintainers of critical projects like Go, which does not rely neither on volunteerism or on people taking giant pay cuts and doing it out of the goodness of their heart. And at the same time, doesn't have the problem of scale. Like, Google did fantastic, work, for goo for for Go and for the Go ecosystem. It Go simply wouldn't exist without Google funding the team and, and incubating it.

Filippo:

Fundamentally, as Go grows more and more and more, the value of Go to Google doesn't grow as much. Right? And that's not a Google specific thing. That's not a Go specific thing, that, I've heard the same story from dozens of different open source projects at, many different companies. I've heard that from teams at Microsoft.

Filippo:

I've heard it from teams at AWS, at VMware, everywhere. Fundamentally, as the project grows, the amount of effort required to maintain it grows because there's more players that are using it in more in more different ways and, more issues, more contributions, more everything. But there is no good reason for the single company that maintains the whole project to keep adding headcount and headcount and headcount to a team. Right? Because whatever value that company is getting from that project, that's is not directly tied to how many older companies use it in the broader ecosystem.

Filippo:

So that's fundamentally a sustainability issue. And I know that now open source sustainability is kind of older age. You hear the White House talking about it, which gotta say, it's kinda weird. It just confuses me. It used to be my hobby horse.

Filippo:

And and now everybody's talking about, open source sustainability. But when I started talking about this, which is now a year and a half ago, a couple of years ago, it it was I I wanted to experiment with a way to show that it was possible to, to do differently. And everybody said, oh, there's just no way. It's a tragedy of the commons thing. Companies just don't want to pay for what they can get for free.

Filippo:

And I was like, you know, I don't think that's true. I think that if you get a PDF in front of them with word of this right way and you set up a US Bank account and you send invoices and accept checks and all the stuff necessary to read as a professional to the companies. So not, you know, send a link to your GitHub, sponsors, which, companies receivables department has no idea what to do with. And instead, just talk about, you know, this is business risk, and you can reduce your business risk by funding this. And it's a retainer contract, and it's billed, monthly.

Filippo:

And you get to talk to me as an adviser and liaison for the project. I was saying, I think it would work, and I think it would scale better because the more companies use the project, the more the project is successful, the more potential clients there are. So the more money you can make, the more maintainers you can hire. And everybody was like, no. No.

Filippo:

No. We've we've tried. There's just just just no no way to get money out of these damn companies. I was like, have you tried Go?

Shay:

Talking to them.

Filippo:

Not just talking to them, but, like, presenting as a professional. And I understand it's annoying. Like, it's not like I enjoy doing sales. But I've never met a dentist who says, you know, I really like teeth, but this whole thing about setting up a practice and billing clients, I will none of that. If they pay me, great.

Filippo:

Otherwise, it means they just want to keep their, their their teeth falling off. And like

Shay:

Open source then density. Yes.

Filippo:

Yeah. I I want open source maintainer to be just as boring a profession as dentist, a thing that you can start and do and be a, you know, a independent dentist, or you can be with a larger firm, or you can join a a small practice and as a junior and then grow into, you know, a profession.

Shay:

Mhmm. So there's a question here. You mentioned, you know, you get the PDF in front of them and you the value you offer them is lowered business risk or like, you know, meetings and expertise. These are good valuable things, but they are not the usual deliverables you hear from freelancers. Like, oh, I'm gonna do this project for you or you're gonna get x hours a month from me.

Shay:

Which is very different. So how do you when you come to a company that's like trying to pigeon you pigeonhole you into. Okay. He's a go freelancer and you say, no, I'm not a go freelancer. I'm not gonna give you 8 hours a month or or, you know, this project done by, like, April.

Shay:

How does that conversation go?

Filippo:

So that's very important because that's another non scalable, model. If the maintainer has to keep selling hours like a free a freelancer, at some point, the maintainer is not doing any work on the project anymore. And if they have to keep adding features, then they have more maintenance work, not less at the end of it. And that, again, doesn't scale. So how that conversation goes is that I never say the word freelancer.

Filippo:

I Not once in in the conversation. I present myself as depending on what the company like, what where the company takes it. We talk about in terms about of a consultant or in terms of adviser. That's the closest thing. And companies understand advisers, especially the smaller ones.

Filippo:

And companies understand consultants, especially the the the larger ones. And they do engage consultants for things, for areas where they have, critical dependency. For for example, if they know that they are going to have to interact with a certain, municipality to get some permits, They know that they are interacting with an institution, and they want consultants who know how to interact with that institution. And so when they are big enough that they have things that they would like fixed upstream or that they would like, to contribute upstream, they they do understand the value of, somebody who can interact with that with that institution, in this case, the project, and help as a liaison, to do that. I want to be clear.

Filippo:

I don't sell them on governance. I don't tell them, oh, you pay me, and I'm going to go in there and merge your stuff and fix your issues. First, because I don't have the authority to do that. I am not the Go team. Right?

Filippo:

Mhmm. And second, because that's a poor incentive alignment for open source projects. It open source project is a multi stakeholder deal where there are many players and especially cryptography. Half of my job more than half of my job is saying no because if we do add that feature, it will make it harder to maintain the libraries and then there will be bugs and those bugs will be security issues and those security issues will cost everybody else much more than they benefited the the one little, you know, user who needed a weird special mode for for something. So I don't sell them on on governance, but but I do tell explain that if you don't have the expertise in house, it's actually kinda hard to make sure that you present your issue, well, or that you present a proposal structured, like it should be structured, address it to the right group.

Filippo:

For example, many projects prefer a a PR. Right? They say they they some projects even have this practice that I honestly really don't like, which is they close your issue and say, oh, we would take a PR for that, but we're not gonna implement ourselves. And, like, issue trackers are not to do lists. You don't need to close a ticket and close duplicates.

Filippo:

Anyway, each project does whatever works best for them. But Go, in Go, if you open a cl and you don't open an issue, we're not gonna notice it. We are extremely issue driven and we would map at least on the cryptography packages, but I feel like that's true of most of Go. We'd rather do the implementation ourselves. We know the style.

Filippo:

Coding is not the hard part. Mhmm. The hard part is collecting requirements, figuring out what should be done, deciding the API, all of that stuff. You can push a lot forward the process of a contribution to Go by doing that work in an issue while doing the implementation might even slow it down because this review cycles might be slower than somebody on the team just picking it up after all of the investigation has been done and all of the decisions have been taken and just implementing it, getting it reviewed by the other, maintainer and pushing it through. But, you know, this is the sort of thing, clients pay for.

Filippo:

When they have, an issue, I help them figure out where the issue fits and why, what they can do about it, if they can fix it outside of the standard library, if it makes sense to bring it upstream, how to bring it upstream, and I help them, structure the issue correctly, etcetera.

Shay:

So I think we have a bias here because both, Jonathan and I are also freelancers. I do a bit of freelancing on the side. Jonathan is a, like, full I don't know how to if even that's fair to say. Right, Jonathan? You're a full time freelancer?

Jonathan:

Yeah. I would say so.

Shay:

We can talk about the business side of how to become an open source maintainer for a pretty long time. I have a one question that's that's interesting to me. You talk about it like you wanna make this model sustainable not just for you, like, as a career path. Do you know of anyone other than yourself who managed to, like, set up a business, like or or, you know, go down this path, like yourself?

Filippo:

Yes. So indeed, I'm not doing this because I wanted to set up a business for myself. The the the entire point is to clear a path and and show a way to, to go about it. I've however, the first step was showing it works, myself. So the 1st year or so of it, has been focused on that.

Filippo:

I've started focusing on expanding to older people just recently. And the first, way to expand, Twitter people is, you know, vertically. I've hired, another maintainer, which is, Nicola Morino. He's the maintainer of SFTP Go and, Xscripto SSH, the the standard library, the SSH, package. Well, not quite standard library, but, here's a here's a scoop.

Filippo:

We are probably moving all of, Golang or Gexcrypto into the standard library, at least the non deprecated parts. Because we've always treated it as the same thing. So might as well have them in the same place.

Jonathan:

I know.

Filippo:

Anyway, the SSH package was a very important package. So many DevOps companies were using it, but it was completely maintained.

Jonathan:

Mhmm.

Filippo:

Everybody had their forks, and that was costing companies even more than what it would cost to fund us. Right? So I went to, to Nicole and and told him, hey, I won't pay you to to maintain the s h package. And he's now doing that part time, and the SSH package is doing so much better. Thanks to it.

Filippo:

And then I turned around and I went to my clients and said, hey. I know you use a lot of SSH, well, to prospective clients. And wouldn't you want both me and the maintainer of the SSH package to hang out in a Slack channel with you? Great.

Shay:

So, you

Filippo:

know, first expansion was hiring, people. I might be getting, as, someone to help with the HTML template package. We'll we'll see. Next step, though, is getting order maintainers to to to go and and do the same thing. And I'm starting to set up a bit of a community to, exchange notes and share things like contract language and experiences on what works and what doesn't.

Filippo:

So if anybody listening wants to, try to out on their own and, and do this, this is a very good time to, you know, be. Like, you know, it's super easy to find, to find around.

Shay:

As we usually do on the show, your contact information will be in the show notes. So if you're listening, you're like, damn, I really wanna work on my open source thing full time, and I wanna figure out how to do it and get companies that use it to pay me. You can find Filippo's email in the show notes.

Filippo:

I want to caveat that, with 2 things. First, I think my model works for projects that are critical to at least some companies. I think that's a broader definition than one could think of it right away because it just needs to be critical to some companies. And critical doesn't mean, you know, it's the one thing they built their entire business on. How I communicate to my clients whether something is critical or not, I tell them, okay.

Filippo:

Think about how much would cost you to replace this if it went unmaintained or maintain it yourself if it, went unmaintained. If you if the answer is, like, a couple weeks, 3 weeks, you know, you have my email. If you need, anything, feel free to email. But I don't think this is a good fit. I'm not gonna sell you anything.

Filippo:

If the answer is engineer years, well, I'm cheaper.

Shay:

Mhmm.

Filippo:

Uh-huh. So that if there are some companies to whom you can make this, this argument, I think that's the, that's the first test. The second one is that for now, it's still a bit of a hard sell. So you need a bit of a network, a bit of a personal brand, a way to get in the door. How I get in the door is usually that engineers at companies have worked with me or interacted with me or heard about me or watched my talks or listened to podcasts.

Filippo:

And, and I talk to engineers first, and they tell me, hey. I can't help you. I don't make decisions here. And I tell them, yes. Yes.

Filippo:

But you can, like, make an email intro and explain a bit what is go? Why is it important to the decision makers? And I'll take it from there. I'm hoping that that becomes less and less the case the more we produce resources and by mind share for the model And the more companies have been exposed to this, I'm hoping that over time, companies will even be proactive in wanting this. They will look at their dependencies and say, well, we have 5 critical dependencies, and for 3 of them, we have some kind of, retainer or support contract or something that gives us that kind of advice and stability and business risk mitigation.

Filippo:

And for these 2, we don't. Let's go out there and find people who can help us with that. But that's, you know, down the road. For now, if you want to do this right now, you have to be willing to take some risk and to pull out the the Rolodex. Right?

Filippo:

The the, the the contact cards and go through them and and make some calls. If that sounds like you though, yes.

Jonathan:

One last question on the on the business and pricing side. Just to to make it clear for for our listeners, how does your contract with your clients work? They pay you a fixed monthly fee for access to you. How does that work, broadly speaking?

Filippo:

Yep. That's it. It's a fixed monthly fee. I structured it, at 3 tiers. Mhmm.

Filippo:

And a certain thing that's just broken, because everybody just takes the top tier. Okay. Which hey. Good.

Jonathan:

Yeah. I don't know

Filippo:

if the lower tiers aren't necessary to selling the higher tiers, but I don't think that's it. It's more that when you do enterprise sales, companies don't really care about the difference between numbers in the same graph of magnitude. The hard parts are other things, like Yeah. Legal and

Shay:

You you need to get past the security. Once you're in, you're in. It doesn't matter if you're it's a 100 or a 150.

Filippo:

Correct. Precisely. So, basically, they they all cluster, at that, top tier except basically one client. And

Shay:

And they get code written in Python, like

Jonathan:

they use math brand. Yeah. They they don't they

Shay:

get the cheaper randomness generators. Filippo has has, like, some cables connected to a banana at the back of the room.

Jonathan:

If that client's listening, we this is all a joke, obviously. We know that he's not compromising your security.

Filippo:

The main difference is that, that client doesn't have a a shared Slack channel, which is the the the useful thing like, the the thing that is, came out as most useful to keep contact.

Shay:

You mentioned that the contracts have to be scalable, hours don't work. But I what I'm understanding is if you work on a project and multiple companies use that project and they pay you to maintain it, basically, each of them pays for mindshare. Just some of them share that mindshare and they don't know about it. And that is more scalable than selling, you know, hours to each company to basically fix the same thing 5 times. Exactly.

Shay:

But they do get your attention. Even if it's shared, they get the value of your attention. So that's more scalable.

Filippo:

Yeah. So a friend once that, looked at me after I explained what I was doing and and, like, you know, this friend tends to turn to distance for a sec and then think about it and said and said, neat. You invented double billing but for open source. Great. And honestly, yeah.

Filippo:

But the clients know this. Absolutely. The clients, you know, have the client, like, the client list is public actually. You can go to github.com/lousotil and the list of clients is right there because part of what they get is, marketing. Right?

Filippo:

They get to put some text at the end of my newsletter and and so on and so forth. So they know that, I'm not, you know, focusing on their thing, exclusively, but that's actually in their interest. Because if I start just working on client issues and stop working on the upstream project, that's exactly what they don't want. They want me to keep doing that, and they want me to stay an expert and stay on the ball so that when things are coming up, upstream that I know a client will, will care about, I can tell them and get their feedback from them. And so that when they have a problem, I can answer it alternatively because I've been working on the upstream thing.

Filippo:

If at some point, I just devolve into this client facing account manager that only focuses on client issues, that's actually a failure scenario for the clients because they don't get what they, need anymore, which is a direct line with, a maintainer who is doing spending most of his time on the project. So most of my time is spent on maintenance. Most of my time is spent exactly like I was spending it when Google was the only company paying. And then there's a bit of time that at Google I spent on performance reviews, that here instead I spend on sales and on answering questions on Slack when, when they come up and reaching out to clients when I know it's relevant to them. But here's the thing, that's useful to me even.

Filippo:

When I'm working on a new feature, I want to talk to companies that would use it even if they weren't paying me. It's just that it's kinda hard to reach your users sometime in advance. Instead, your users usually upgrade 3 months after the release, find out that the thing doesn't work for them, and now you're talking to them. Yeah.

Shay:

In angry tones.

Filippo:

Exactly. And that's 9 months too late. And that sucks for me and that sucks for them. Can I say sucks?

Shay:

Yeah. Yeah. No worries.

Filippo:

Yeah. And instead, if I had a direct, channel to them, we spoke about it in advance. They told me what I needed to know. The result is better. Everybody's

Shay:

And if they're, like, financially tied to that, issue, you'll get much clearer communication ahead of time because they have, like, vested interest or even, you know, it's sunk sunk cost fallacy. We we paid Filippo for for, like, this month maintenance. He better, put out a really good issue. So in in some weird way, you didn't only invent, like, double billing, you also invented, like, blackmailing them into giving you good issue descriptions.

Filippo:

Yes. I mean Again,

Shay:

no, this is a joke. Filippo's business is super I don't know why we're trying

Jonathan:

to present the board. Like very It doesn't really work for the open source mafia.

Shay:

Yeah. Open source mafia. That could be a good name if you for your community. For the Slack for like Slack channel of all the professionals. Oh.

Shay:

Okay. So other than the business part, the main parts of Go you maintain, are not about HP servers or, you know, compilers. They are about cryptography, which is a topic most developers, you know, are aware of. Maybe they'll learn some basic cryptography cryptography concepts, in their degree. But the main advice most, like, 95% of developers probably say is good is don't mess with cryptography yourself.

Shay:

Someone else is doing it for you. Use the libraries that the language provides. And basically these libraries come from you. Right? So I wanna ask, you know, how did you get into cryptography at first?

Shay:

Like if someone is interested in working on cryptography, how could they do it? And I guess this goes back quite a while. Right?

Filippo:

Yeah. It does. By the way, I want to mention when you say, the, there's me, there's Roland Schumacher, who works at Google, there's Nicola Marino, who would, works, with me and

Shay:

Yeah. There there are many there are many, hacker maintainers that are doing supply chain attacks and, weakening all the cryptography in the change list as well. We wanna shout them out. No.

Filippo:

No. It's fine. We we just don't don't review, most CLs, so there's no way to sneak anything in. But this is actually a bit of a sour joke because there there are a bunch of CLs that are waiting, and we are very review constrained.

Shay:

So You can use this you can definitely use this platform to push, CLs that you wanna get reviewed. I I can be accused. I use the the podcast more than once to get people to look at an issue I wanted. But I do warn you, both issues that I mentioned that way went to the other way that I wanted. I wanted Yamal in the standard library.

Shay:

It was immediately rejected, and I wanted no white space in HTTP. 2 days after the episode came out, the the feature was merged. So it's sort of a monkey's paw podcast. You request, something to happen, the the opposite happens. All the changes will get rejected.

Filippo:

Oh, no. No. No. But, here, really, it's it's more that listeners might be annoyed at listening to this because they are waiting for me to review their thing. And, we are we are now very good at reviewing that.

Filippo:

That's a whole other story. Anyway, your your question was, how did I get into cryptography? I think in high school, the some one of those, you know, extracurricular things that, that you can do like, I was doing some that are related to math. I was convinced that, I was gonna study math in, in university. And in retrospect, I would have hated that.

Filippo:

But, anyway, one of those just has this small chapter on cryptography, and I'm like, oh, that's fun. That's a a bit more of an engineering thing. You you put together these things and you make them, do interesting stuff. It's very applied. Right?

Filippo:

And then I took the, Coursera course, cryptography 1 by Dan Bonnet, which is this, fantastic course. The the joke is that Coursera, the cryptography 2 course, but then by Dan Bone is, is coming in 3 months, and that has been true for the past 10 years. So don't don't actually wait for, cryptography 2 to come out, but cryptography 1 was, is, already an excellent course. And then I stumble upon these things that at the time were called the Matasano crypto challenges. Matasano is now not a thing anymore, got a boat, and the things are now called the CryptoPulse, and Matasami used to use them for hiring.

Filippo:

But now you can just go on cryptopulse.com and and check them out. And there are these very fun challenges which really hit the spot for what I like, which tell you how to, build a broken cryptosystem. Use that. Here's a couple links here suspect, like implement it like that. And then they tell you, great.

Filippo:

If you implement it like that, it's broken. So now attack it. Here's how you attack it. And then you write also the code for the attack. And how it used to run is that, you would do, 8, I think.

Filippo:

And and then you would send the, solutions and they would send you back the next date. And they would start with super, simple stuff like, base 64 encoding and at the end, like, AES. But it was like, you can use AES from from the library. It's okay. Just, you know, encrypt something.

Filippo:

So, like, make the penguin. And then by the time you get to the 6th set, it's like, okay. So here's a paper. That paper broke, SSL, when it came out. Now use the exact same attack against your own broken thing, and now you're implementing papers from, at the time, like, the past couple years.

Filippo:

And they're, and they escalate like that and they, get, more and more into the nitty gritty. And I had so much fun and I kept sending them to them. And I had no idea that this was a hiring thing. And then they get to the end and they're like, great. So and I'm like, so what?

Filippo:

Well, I don't know. When do you want to interview? Oh, I see.

Jonathan:

So this

Filippo:

is a thing you can do professional? Anyways, I didn't actually end up taking the job. They do a lot more penetration. They used to do a lot of me more penetration testing than, I enjoy. I actually enjoy being, you know, library writing and, design making than, breaking stuff.

Filippo:

But after that, there's there was the test that was just a stroke of luck and, then, start working at. And from there, I got involved into in Internet internal protocol design, and then, after that, Google. I was actually about to switch careers after Kalfer. I was gonna become a agent for engineers. You mean

Jonathan:

you mean like a recruiter? Or

Filippo:

I mean, the recruiter works for the company. Right?

Jonathan:

Okay. Oh, an agent for the for the yeah. I I understand.

Filippo:

For the Engineers are paid, you know, US, market rate now that there's a bit of a slump, but, still levels dot FYI will tell you that, engineers will make from 200 to 400 k a a year. That's a lot of money. Most professionals that make that kind of money in a market where there's a shortage of talent have professional figures that help them negotiate.

Jonathan:

Yeah.

Filippo:

And and so on. Right? And engineers that engineer is how do we put this? Not very good at negotiating.

Jonathan:

Integral. Yeah.

Filippo:

He is. So, you know, there's just so much that telling everybody to read Patrick McKenzie can do, which, by the way, will drop in the in the show notes because those those essays make made me so much money. It's really close. But anyway, I I was tempted I was about to start that business and then, Samir, the, the head of the Go team, he recently published a few articles talking about his tenure on the Go team. He called me up and was like, so we are hiring for the open source, team.

Filippo:

And, like, people say that you do, Go and cryptography and Adam Langley is kinda busy. So

Shay:

so basically, you know, what you're saying is if you your way into cryptography was being interested by challenges. By, like, challenges, like, that are akin to a CTF. Like, there's a thing here, break it, play around with it. Yep. Would you recommend anybody, to try and get into the field if they haven't already?

Shay:

Or is that a field that just calls out to people?

Filippo:

No. No. No. I so there was both a component of challenges and also component of actually building stuff. Right?

Filippo:

Because as I was, telling you earlier, I don't enjoy just breaking stuff, just figuring stuff out, but also building a thing so that it's elegant, so that, You know what's very nice of this job? You can be a perfectionist. If on any other job, I spend, 3 weeks rewriting the same 500 lines multiple times trying different APIs for those same 500 lines, writing 2,000 lines of tests for those 500 lines and trying to start a a community project to generate better test vectors for those 500 lines, I would get fired. Mhmm. Like, incorrectly.

Filippo:

And instead in cryptography, then people are just like, oh, great, Filipe is producing test vectors for this and the implementation is very clean, excellent. Right? So I can justify that. So perfectionism is a thing that you you get to just run free with it. But your question was, would I recommend people get into it?

Filippo:

And the thing is yes. And also, I don't think people should, feel as scared by the field as they sometimes are. You know, there's always the there's the famous don't roll your own crypto Mhmm. Thing. And my feelings about it are kind of mixed.

Filippo:

We did a whole podcast episode about don't roll your own crypto, for security cryptography, whatever, with, with Thomas Tacek, who was the founder of Matanzano, which did the crypto pulse. And the thing is it's dangerous because if you get anything wrong you might not know you did. And then it might endanger users if you deploy it to production. But it's also not rocket science. Although, better that rocket science is also a thing that you could just, you know, learn and study and

Shay:

It's it's not rocket surgery is what you're saying.

Adelina:

Right.

Filippo:

It's a thing you can learn. And if you're curious, you should absolutely just follow that curiosity and not get scared of the aura that's around this field. I think the only point of the aura is to stop the the programmer who has no interest in cryptography Right. From saying, oh, I need a thing to encrypt, and Filippo's thing is kinda, slow, and the API asks me for random bytes. I think I can make one that's faster and doesn't require random bytes if I just stitch together these things from Stack Overflow.

Filippo:

And, you know, maybe there was a reason our thing worked like that, and now your users are, are at risk.

Jonathan:

You just reminded me of the person I worked with in the past who is like, bcrypt is too slow. I'm gonna do some do my own implementation.

Filippo:

Right. Right. Right.

Jonathan:

Supposed to be slow. That's the that's part of the design.

Filippo:

Yeah. Exactly. So it's important that if you're not interested in cryptography, you don't venture it, into it by, by mistake. And if you are still learning, you don't present your thing as a thing people should use and rely on. But a version, an alternative to don't roll your own crypto that I like very much is from, Deirdre Connelly, one of the hosts of that podcast, who says instead, don't do cryptography alone.

Filippo:

Do it with somebody, experienced. So you get your stuff reviewed by somebody or, you contributed to a project that has code review. That's sort of how I started. I I remember the the first, cl I sent the go project and was mitigation for the lucky 13 attack, which was this, timing side channel in, TLS. And it was particularly fun because, lucky talking when it came out, it was like, oh, no.

Filippo:

The it's broken and, like, everybody scrambled and, to fix it in open SSL and so on. And then I went into the Go source, and I found a large comment by Adam Langley written years before Lucky 13 was discovered that said, this is probably not constant time, but open SSL does the same thing. So it's so I guess it's fine. So Adam Langley found Lucky 13 years before.

Shay:

Wait. So what you're saying is do do cryptography alone because otherwise you copy other people's mistakes.

Filippo:

I mean, actually copying an established library is not obvious that it's good. You know, open SSL has more resources now, but for a while it was bad, because they didn't have resources at all. And, you know, I I don't think it would be classy for me to mention specifics, but there I do sometimes look at some cryptography toolkits and go like, you know, yeah. I guess you could do it like that. So don't, yeah, Don't always assume that just because something is, out there and widely used in Muse it's, necessarily correct.

Filippo:

But if you can find somebody experienced or a community or, even just a course, it's truly something that you can learn just like everything else.

Shay:

So it's one thing to learn about it, but one thing about cryptography is that the, you know, if you go out and learn UX design and I really appreciate everybody has their job and all the jobs are are meaningful and it's all okay. But if you make a mistake in, UX design, like the worst example I can think of is that Hawaii, missile launch, the test where they had the test button and and the real button next to each other, then everybody in Hawaii got the nuclear missile launch alert. Jonathan, you know what I'm talking about? You're, like, quizzically, I I did. You should you should find that out.

Jonathan:

I think it's really

Shay:

funny. But just everybody got a a message on their phone in the, like, highest level of SMS that you can. Like, nuclear, missile alert, this is not a drill go into shelter, and it was a drill. They they just went to test the system. But because of UX design, the buttons were next to each other.

Shay:

The button jumped when the banner loaded and the guy pressed the wrong thing. But, you know, this is like worst case scenario for, UX design or you lose money for your company or whatever. But the mistakes in cryptography, you know, they they carry a bit more, weight, I think. I I would be a lot more nervous knowing that my cryptography code is running, you know, and securing company's most, secret IP, people's, privacy, you know, private photos, political groups trying to talk, safely to one another in hard situation. Like, this is really real stuff.

Shay:

Privacy is very important, I would say.

Filippo:

You know, I have two answers to that. One is that there are safeguards, and there are ways to do your job in a way that minimizes risk. One of them is, again, doing it together. Like, none of my code goes out as is. So low.

Filippo:

You know? None of my code goes out as is, Go itself. My. Io/libraries, it's a little different, so I'm a little more conservative with those, for example, and they go out to fewer users anyway. There's code review.

Filippo:

Roland or Sophie or somebody with, domain knowledge always reviews my code, so there's there's that. And part of being a good engineer and part of what you learn, or at least what I think one should learn to become a engineer is how to minimize the risk and to assess the risk of, your own implementation. Because the reason I'm confident in my code is not that I think I'm really good, and I looked at it very closely. It's that I rewrote it 3 times to be simpler and simpler and simpler so it's very clear what it does to the reviewers. And if there was something wrong, it would be very clear for the reviewers.

Filippo:

It's that I spent more time thinking about how to test it and writing test vectors for it and deploying the test vectors than I spend, writing the the the code itself. So even if I did get something wrong, they would have been called by that or that or that test, vector. And even I get involved in standardization and specification projects to, advocate for designs that are easier for me to implement so that there is less risk and there's not as much, chance that something will go wrong. So you can mitigate that risk is one one side of the answer. And the other side of the answer is, yeah, it is kind of a, you know, high pressure job, but that that can be part of what, one enjoys about the job.

Filippo:

Right? I would actually argue that emergency medicine is, has fewer ways to mitigate the risk of a wrong decision. If I make a wrong decision today in implementing something, hopefully, the right decisions I made before and after, will will catch that bug or will prevent, security impact from that, from that bug. I am also training as a EMT, and I'm actually way more worried about split second decisions I have to make, on doing that than with, with cryptography. So, you know, there's there's a number of jobs that have, consequences.

Filippo:

And there's high pressure like the emergency medicine and there's large impact. Anything that has political implications like urban zoning. Urban zoning has large impacts on a lot of people and can change their lives, and that can have, you know, very severe consequences on those people's lives and it can affect depending for, you know, at what level you do it, more more people than, cryptography library could.

Shay:

But So so basically what you're saying is, yeah, everybody's stressed actually. Yeah.

Filippo:

I everybody picks the the kind of job that matches their risk tolerance and how they work. Right? I work well under pressure and less well, when, needing to systematically do something, the same way for a long time. Which is why I could, you know, on the medical side, not that I'm trained as doctor, but I could never be a GP, a general practitioner that, you know, follows a number of different patients for a long time and cares for their health long term. I'm much more fit for, being an EMT that, has to perform well under pressure for those 4:4 hours and then can just, you know, space out and, and play video games and forget about, laundry, for 3 days in a row.

Filippo:

Row. And likewise with cryptography, I work better with something that I can, I don't know, hyperfocus for a couple weeks, get get it really well tested and and get it, into the system? But I'm not a good fit for teams that have, like, sprints that need to deliver on customer requests because some weeks I'm just useless. In this job, it's fine because, nobody has a clear, precise timeline for when kyber 768 needs to land in the Go standard library. As long as it's in the next 3 months, it's gonna be fine.

Filippo:

So it's finding a thing that fits for you. And cryptography is an interesting spot in the spectrum of, of jobs. But sometimes it's made out to be this thing that's just sits on another plane of existence. Right? This black magic, sorcerers, clad in, black robes, and not really.

Jonathan:

Do do you own a black robe?

Filippo:

I mean, that that's a personal question, John. Fair enough. Fair enough. For the

Jonathan:

record, he's not wearing it on the call. So if he has one, he's kept it in the closet for now. This has been a very fascinating conversation, very interesting. The business aspect of software is something that fascinates me personally. So I enjoy talking about that.

Jonathan:

We've been talking for a while. Let's let's give some links. Where can people find you and read about your crypto? Because you have a newsletter of your own. What are the best places to go?

Filippo:

So the indeed, the the the thing that I that I, would recommend is the, newsletter is called cryptography dispatchers. And I try to publish it every 2 weeks and see above what we just talked about. It does not come out every 2 weeks. But I try. And, by the way, I always appreciate when people reply to to those emails.

Filippo:

I fight with the ghost configuration, all the time to make sure that the reply to works. And, I appreciate when people tell me the things they would want, to hear about. It's not really about, about what's new. It's about cryptography engineering, cryptography design. Sometimes it's about what I just worked on because that's what's top of mind.

Filippo:

But it's, more of, you know, more of essays than on anything else. If you sign up, to that, there's 2 options that could dispatches and maintain our dispatches. So, basically, if you were only interested in the second half of this podcast, you can untick maintainer dispatches and never hear about the ways I am finding, ways to build my clients. And if you don't care about cryptography, but you do want to follow the, maintainer the professional maintainer part, you unpack cryptography dispatches, and you get the emails about the, the maintainer model. So that's the the two topics are indeed not necessarily overlapping.

Filippo:

And then, you know, we're all shitposting somewhere. And my my spot these days is blue sky, because it very much feels like Twitter did, back when it was fun.

Shay:

As long as it's not changeless.

Filippo:

Yep. So this guy has open registrations now. So and anybody wants to, fold that. I'm easy to find, name and surname is, as far as I know, globally unique.

Jonathan:

Nice. That's that's not something I can say.

Filippo:

It does mean that you have to spell it, every time word by letter by letter because nobody ever got the the first name correct on the on the first try outside of Italy. But, hey.

Shay:

For our listeners, that's gonna be a problem. Right? Because we're gonna have the link in the show notes. We'll then not have to spell anything, especially since people have told me they usually listen to this while driving. So please don't try to type anything in your phone.

Shay:

But especially not Filipolo Valsera's name, which I'm looking at right now. And I believe that if I close my eyes and open them, I cannot spell it. Alright. Well, thanks, Filippo. It was super fun having you.

Shay:

I have to admit that if you found this conversation interesting, you have to go read the blog. There's some super cool stuff there. I'm not like I read the code book when I was like 16, and I enjoyed the challenges in the back where you, like, have to on paper, solve some cryptography stuff. And I never got into it into it proper. But, you know, when Heartbleed came out, I was all into it.

Shay:

It was very interesting, stuff like that. And just looking at the the articles, post quantum cryptography for the Go ecosystem. I mean, come on. How can you not love this shit? So go check out the blog.

Shay:

I I highly recommend it. So anyway, thanks all for coming, Filippo.

Filippo:

Absolutely. Thank you folks for having me.

Jonathan:

Yeah. It's been a lot of fun. We do we do have one last question, that we we ask all of our guests this year. Now you've been you've been doing crypto for a while. I'm a I don't know if you started using Go.

Jonathan:

You started to tell us a story before we recorded. How did you start using Go? And then the the the real question is, were there any big surprises for you in the process?

Filippo:

So, I started using Go back in 2013 when I was doing what's now called the recurse center, which, by the way, strongest possible recommendation for the recurse center. I'm not going to make a an ad out of it, and I'm not, like, affiliated except the fact that it's a fantastic community I'm part of. But, anyway, it's this, let's call it a retreat for programmers, to to learn about programming, get better as as programmers. And the beautiful thing is that you do that with a bunch of people that are there for the same reason. And one of the alumni, Travis, one day comes to, after hours, and, he he tells me, oh, I want to show you a thing.

Filippo:

So to show you a thing. There's this very cool new language. It's called Go, and it compiles to static binaries and use like that. Like and he shows me Go and, like, you know, I I look at it because recourses a lot of this, a lot of people telling you about cool stuff and, and learning from others. But I'm sort of like, yeah.

Filippo:

Alright. That's cool. Moving on. And I proceed to not care about it for the next 3 months, even more. I was only doing Python at the time and other stuff to think about.

Filippo:

Then hardly it comes out, and I want to make a test for it. And, to make a test, for it, I need to modify, TLS stack so that it does something different. And, really, at the time, the the the main option, that meant open SSL. And I open open SSL, and then I close open SSL, and I'm like, no. No.

Filippo:

No. That that's not happening. And I had heard that the Go had its own cryptography, stuff that was written better, that that was maintained by, Adam Langley, that was much shorter, that was simpler to understand. So I I go in there and, you know, 5, 6 lines, and I'm adding support for the heartbeat extension, and I I get it to turn into, into a test. By the way, that that patch was, did not have was not written.

Filippo:

I was using a global channel. Mhmm. So it would only work for one connection at a time. And then at some point, and I was using a Python server that was just calling the binary every for every test, and that was not scaling. So at some point, you know, everything's exploding.

Filippo:

Everything's growing. So I just add goroutines, the school concurrency stuff that Go has. You can see where this is going. Anyway, that's the first time Adam Langley ever heard of me. When I reported about this vulnerability where I was like, oh, some things are crossing between connections, which clearly is a security issue.

Filippo:

Mhmm. And, no, that was my path. Mhmm. So that was me not understanding concurrency. Anyway, whole tangent there.

Filippo:

Sorry. But what did I find surprising of Go? I'm not sure if this is, strictly surprising, but I I think that was definitely a misconception that I had at the beginning and that at some point I had a moment was that concurrency is really not using concurrency is not that big a part of using the language. And when you start with go, you want to use goroutines everywhere. And by the time you have 5, 6 years, under the belt, you want to put goroutines as far as possible from wherever you touch them.

Filippo:

Like, you want to wrap them in our air groups, or you want your libraries to expose a synchronous API and then use Goroutines in the back end to implement those things asynchronously. And really the magic of Go is less the fact that it lets you do more concurrency and more the fact that when you do concurrence, you can't really tell. So using more Goroutine is kinda breaks that spell. So it's actually going against the grain of the language. The the beauty of it is that you don't have to type async.

Filippo:

You don't have to, type await. You don't have to write an event loop. You write your code as if it was not Mhmm. Mhmm. Concurrent code.

Filippo:

And then there's the scheduler and in the back, back end that automatically goes like, oh, you're waiting on a Cisco read. Well, well, I'll block you there, move you off the, processor, put another go routine on the processor, and I'll just deal with that for you. So really, if you if if you manage to use Go without ever noticing the program is concurrent, Go succeeded. And that is having good concurrency support, but when at the beginning you hear good concurrency support, you hear I need to use the go keyword all the time. And by the end you're like, I I shall never use the go keyword.

Jonathan:

When I first was introduced to go, I was all excited about the concurrency and, you know, it's kind of the sexy feature that everybody was talking about. And, yeah, I agree. Like, I it's something I rarely use or at least rarely use directly. And if you use HTTP, server, you're using it, but you don't have to care because it's it's all buried. It's it doesn't matter.

Filippo:

Exactly. And, you know, hopefully, cryptography is a bit of the same. I like to think that Go has very good cryptography support. But what that means is that you never do cryptography or notice that the cryptography is happening. Mhmm.

Filippo:

That cryptography just, you know, is a thing that goes solves for you.

Shay:

And you don't have time to go read about it or wonder in the compilation times. That's one thing too. You don't have to go idly read in the meantime.

Jonathan:

Alright. Well, Filippo, this has been great. Thank you for coming on and talking with us for about an hour.

Filippo:

Thank you, folks.

Jonathan:

Anything that we forgot to ask you about? Anything important you wanna say before we sign off?

Filippo:

I think no. I I think we covered, both, the the business side and, some, technical fun stuff. So yeah. Wonderful. I I got to, pitch the newsletter.

Filippo:

Thank you for that.

Jonathan:

I just signed up. I'm looking forward to it.

Shay:

Thanks a lot, Filippo.

Filippo:

Thank you. Have a good day.