007 - Goatmire, Old Android Phones, and How To Keep a Secret

WEBVTT

00:00.193 --> 00:03.898
All right. Welcome back to another episode of Macro Mayhem. My name's

00:04.398 --> 00:07.329
Peter Ulrich. Today is October 14th,

00:07.361 --> 00:10.865
2026. It is 11:27 AM

00:11.220 --> 00:14.745
Amsterdam time. I'm back in the Netherlands after a very eventful

00:14.794 --> 00:18.593
week at Goatmeier, and I'm joined as always by

00:19.093 --> 00:21.580
my good friend and co-host, Gus Workman. How you doing, Gus?

00:23.179 --> 00:26.424
I'm doing pretty good this morning. How are you? Have you recovered

00:26.924 --> 00:29.325
from your Goatmeier travels? Yes, I'm better now. I mean, after I came back,

00:29.341 --> 00:33.040
I fell sick for the whole week. in plus a few

00:33.540 --> 00:36.493
more days. And yeah, but yesterday I went for my first recovery run and it

00:36.509 --> 00:39.690
didn't feel entirely shitty. So I think I'm, I'm back in,

00:40.364 --> 00:43.785
in the saddle almost 100%. Nice.

00:44.701 --> 00:48.154
Yeah. Uh, let's start with the news. This episode today is a little light

00:48.654 --> 00:51.897
on the discussion part, so we're going to spend some more time on, on news

00:51.993 --> 00:55.832
and blogs. Unfortunately, the first news item of the

00:55.864 --> 00:57.278
week is quite sad.

00:58.657 --> 01:02.487
Margaret Hamilton has died last week. She is

01:02.759 --> 01:06.172
most known as the engineering head

01:06.909 --> 01:11.300
behind the moon landings of NASA in 1969,

01:12.037 --> 01:15.947
and she led the department that programmed

01:16.139 --> 01:18.142
the moon landing software.

01:19.248 --> 01:22.757
Yeah, she died at the ripe old age of 90.

01:23.190 --> 01:26.399
I think that's a pretty good age, but still she will be missed.

01:27.604 --> 01:30.639
Margaret has been exceptional in her work.

01:31.137 --> 01:34.430
She was, yeah, the main reason or one of the

01:34.930 --> 01:38.205
main reasons that the moon landing in '69 actually worked.

01:38.591 --> 01:42.365
She primarily excelled by focusing on

01:42.865 --> 01:46.060
the safety of her software and fault tolerance of her software.

01:46.783 --> 01:49.867
I read the obituary here that we

01:50.367 --> 01:53.836
also linked in the show notes, and it was quite impressive. Because the moon landing

01:54.013 --> 01:58.020
almost crashed. They almost crashed into the moon. But because

01:58.116 --> 02:01.813
the way she designed the software, they could turn off a lot

02:02.313 --> 02:06.292
of the background processes and prioritize the high-priority

02:07.211 --> 02:11.906
procedures that were meant to control

02:12.115 --> 02:15.055
the glider, control the lander to safely land on the moon.

02:15.826 --> 02:18.236
So because they had that option at their disposal,

02:19.066 --> 02:22.528
the moon lander actually landed and didn't crash. I think

02:23.028 --> 02:27.065
that was a very nice story behind this. So we're very sad

02:27.177 --> 02:31.425
for Margaret's departure, but she has been absolutely

02:31.925 --> 02:35.721
outstanding. Also has gotten a lot of rewards and awards

02:35.993 --> 02:39.375
for her excellent work. So she will be missed,

02:39.760 --> 02:42.886
but her memory will live on. Definitely an icon in the

02:43.386 --> 02:47.102
industry and a great female figure in

02:47.198 --> 02:51.353
STEM as well. Exactly. So yeah, moving on

02:52.187 --> 02:55.876
from this sad news, Gus, do you have some better

02:56.376 --> 02:59.983
news for us? Yes. Coming more to the

03:00.769 --> 03:04.426
Beam world, we have some news from the Glean

03:04.522 --> 03:07.891
team. So Glean published

03:07.971 --> 03:11.403
a bit of news recently that the latest version, which is,

03:11.676 --> 03:15.076
I believe, 1.19, .0, uh,

03:15.349 --> 03:20.770
was released, and it now, uh, does not transpile

03:20.898 --> 03:24.667
Gleam code to Erlang source code. So the

03:25.167 --> 03:28.708
title of the blog post is Gleam Doesn't Compile to Erlang Source Anymore, and you

03:28.916 --> 03:32.284
might think that that means it doesn't compile to Erlang at all, or maybe it

03:32.784 --> 03:36.085
compiles to like Beam bytecode, and that's not quite true.

03:36.678 --> 03:40.710
Um, Gleam now compiles to the Beam

03:41.050 --> 03:43.835
abstract form,

03:44.369 --> 03:48.044
which is an intermediate representation that then the Erlang compiler

03:48.837 --> 03:53.228
doesn't have to compile source code files. It compiles the intermediate

03:53.519 --> 03:57.148
format. And this is the same as what Elixir does, from my understanding.

03:57.550 --> 04:01.207
It compiles that intermediate format and then turns that into bytecode. And the reason for

04:01.707 --> 04:05.397
this is that bytecode is part of the Beam. The Beam gets updates once

04:05.897 --> 04:08.573
or twice a year. the major OTP releases,

04:09.154 --> 04:11.964
and that would be a bit of a moving target. So if we can leverage

04:12.061 --> 04:15.598
the existing tooling from Erlang and the OTP team, then you

04:15.630 --> 04:18.780
can get the best of a lot

04:19.280 --> 04:22.732
of worlds. And so this is a really cool update as well, because now

04:23.166 --> 04:27.230
Glean errors and the stack traces will give

04:27.360 --> 04:30.832
you the line numbers for the actual Glean

04:30.929 --> 04:34.601
source code. And before, the errors would

04:34.747 --> 04:38.515
give you the line numbers for the transpiled Erlang

04:38.628 --> 04:42.413
source code. So there's a nice quality

04:42.913 --> 04:45.996
of life improvement there. And the Glean team has also spent some time to make

04:46.061 --> 04:50.805
this performant. So they dropped their standard

04:51.305 --> 04:52.835
compile times by, I don't know, 20, 30%.

04:54.364 --> 04:57.826
They have a few benchmarks in there, but they also are very clear that you

04:58.326 --> 05:01.223
should take those with a grain of salt. So check out the post for more

05:01.723 --> 05:05.106
information, but Gleam got some nice updates and it wasn't just to the Erlang

05:05.202 --> 05:09.099
part. There's a lot of other updates as well, some JavaScript performance

05:09.147 --> 05:12.274
improvements. Um, and yeah,

05:12.498 --> 05:15.112
a whole bunch of stuff. Take a look. Have you used Gleam before?

05:15.465 --> 05:19.009
Uh, I have not used Gleam. I have attended a few talks about Gleam

05:19.509 --> 05:22.633
and I was quite impressed, but, um, yeah, I did not have time to play

05:23.133 --> 05:26.866
around with it yet. I think the coolest thing, and because if you're an Elixir

05:27.366 --> 05:30.475
developer and you haven't played with it yet, is that You think Gleam is just

05:30.975 --> 05:34.006
like a statically typed Elixir, a different syntax, but all

05:34.506 --> 05:38.628
goes down onto OTP. But it's pretty cool because Gleam also

05:38.644 --> 05:42.512
has a compilation target for JavaScript. So you can run your

05:42.833 --> 05:46.364
code on the browser and on the backend on your Beam.

05:47.070 --> 05:50.360
Um, so, right. Take a look. It's pretty cool. Very nice.

05:50.681 --> 05:54.436
I'm always happy to look at them and see that they're making

05:54.629 --> 05:58.195
good progress there. The next item is by

05:58.243 --> 06:01.248
Joseph Alim. He is announcing,

06:01.360 --> 06:05.201
or he has announced, a postdoctoral position in

06:05.474 --> 06:08.832
the type system for Elixir with the IRIF

06:08.929 --> 06:12.367
in Paris. And I believe this is the

06:12.867 --> 06:15.966
extension of the work of Guillaume, right?

06:16.159 --> 06:20.353
The type system Elixir. Guillaume has written his PhD thesis

06:20.853 --> 06:24.504
about it and I guess now doesn't want to continue with the postdoctoral

06:24.553 --> 06:26.196
position, which I can understand.

06:27.582 --> 06:31.279
And José is now looking for a postdoc that wants

06:31.779 --> 06:35.232
to take on the remaining features of the type

06:35.296 --> 06:38.795
system. So if you happen to be a postdoctoral

06:40.635 --> 06:44.123
student, computer science student, and you want to work with the

06:44.656 --> 06:47.878
fine folks in Paris, I'm not sure whether

06:47.894 --> 06:51.705
you need to be in Paris physically, but the position will be in Paris.

06:52.901 --> 06:54.419
Yeah, you can apply to this position.

06:57.468 --> 07:01.881
Next up on the news, Sobolo version 0.16

07:02.477 --> 07:06.213
was released. Sobolo is a static analysis tool for

07:06.666 --> 07:10.764
ensuring that your code is secure. It checks for common security vulnerabilities,

07:11.120 --> 07:14.425
and generally it's a really good tool. You should add it to your projects.

07:15.329 --> 07:19.118
0.16 brings a lot of improvements. The release notes

07:19.618 --> 07:23.076
are very long, very detailed, but take a look

07:23.221 --> 07:27.359
'cause there's a bunch of bug fixes. But the big new

07:27.504 --> 07:31.136
feature that we wanna highlight is that there's now a GitHub output

07:31.636 --> 07:35.474
format for GitHub Actions. And so what

07:35.974 --> 07:39.857
does that even mean? It means that when you run your

07:40.099 --> 07:43.421
Sobolo checks in GitHub, in your GitHub Actions,

07:43.959 --> 07:47.563
it now can output a specific format so that the GitHub

07:48.063 --> 07:52.370
UI can render line by line where your security

07:52.691 --> 07:55.851
issues might occur. And so you can actually look at it. Before,

07:55.899 --> 07:59.733
it kind of spit out this big text chunk

08:00.233 --> 08:03.567
that GitHub would render and show you, but it wasn't like an ideal

08:04.803 --> 08:08.781
workflow to kind of look through it. So now I believe

08:08.974 --> 08:12.583
the main difference, correct me if I'm wrong here, Peter, but the main

08:13.083 --> 08:16.678
difference is that you now have to add a --format GitHub

08:16.823 --> 08:20.031
flag in your CI calls to enable this.

08:21.720 --> 08:25.769
Yeah, I believe so. Yeah. I think previously it was very hard to parse

08:26.269 --> 08:30.011
the Sobolo output in your GitHub CI. So basically you had to rerun it

08:30.511 --> 08:33.776
locally to make sense of it. And this new output format allows

08:33.872 --> 08:37.607
you to have these warning dropdowns

08:38.139 --> 08:41.556
in your log output. So you can see, oh, there's a warning at

08:42.056 --> 08:45.768
this line. Basically. And talking

08:45.800 --> 08:49.811
about SOLO and security in general, we are happy to announce

08:50.311 --> 08:54.498
that we have our first sponsor for the show, and the sponsor is Michael from

08:54.681 --> 08:58.402
praxil.io. And the sponsorship worked

08:58.902 --> 09:02.597
as follows, that Michael paid us a little bit of money, and we interviewed him

09:03.097 --> 09:07.351
a few times to ask his expertise about security questions

09:07.450 --> 09:11.243
that Honestly, I would've asked him also without the money, but don't

09:11.743 --> 09:15.490
tell him that. So in this episode and in the

09:15.555 --> 09:18.823
coming episodes, we will always embed a little snippet of

09:19.000 --> 09:22.510
our interview with Michael, and in each

09:22.558 --> 09:25.643
snippet, we will ask him a question that hopefully is interesting to you.

09:26.355 --> 09:29.377
So this is gonna be the first snippet here. Please enjoy.

09:30.460 --> 09:33.677
And now for the first security question of the week, I would like to introduce

09:33.793 --> 09:37.234
Michael from praxial.io. Michael, I've known you

09:37.266 --> 09:41.002
for quite some years now, and I still don't know what Praxil.io does. Would you

09:41.502 --> 09:44.881
care to elaborate, please? Thank you, Peter. It's great to be

09:45.381 --> 09:48.656
here. So Praxil.io, it's a software product

09:49.156 --> 09:52.464
that companies buy essentially to ensure they don't get hacked.

09:52.994 --> 09:56.887
And it drops right into your Elixir application and implements

09:56.968 --> 10:00.120
several security controls. There's a lot of them that

10:00.620 --> 10:01.219
we can't go into full detail.

10:04.189 --> 10:07.561
Essentially, when a company has to do a SOC 2 audit

10:07.787 --> 10:11.207
or they have a big customer that has a very long security questionnaire,

10:11.780 --> 10:15.508
there's very common security controls and Praxial.io

10:15.733 --> 10:19.043
helps businesses implement those so that

10:19.543 --> 10:22.741
they can finish with the security work, have it running,

10:22.774 --> 10:24.296
and then get back to their real work securely.

10:26.893 --> 10:30.242
That sounds good if I'm a business, but now imagine I'm a person,

10:30.258 --> 10:32.526
an individual developer, or maybe a smaller team.

10:33.290 --> 10:36.388
What can I do to protect myself these days if I

10:36.888 --> 10:40.826
don't want to buy Praxial, but still stay safe in the era of AI

10:41.326 --> 10:44.903
threats? Yeah. And the good news is if you're just starting

10:44.999 --> 10:49.202
out, you don't need to jump to a very powerful solution like

10:49.282 --> 10:52.772
Praxial.io immediately. So for example, if you're an

10:53.272 --> 10:56.501
individual developer, And you're working on a project and you

10:57.001 --> 11:00.059
just want to keep it secure, there's a lot of open source tooling.

11:00.652 --> 11:04.497
For example, I'd recommend Soblo, which is a static analysis tool

11:04.997 --> 11:09.193
for Elixir and Phoenix projects. You can also examine

11:09.305 --> 11:13.215
the security of your dependencies. You can do

11:13.231 --> 11:17.109
that with actually Mix, um, and like the Hex client right now

11:17.397 --> 11:20.507
that's built into the newest release. So just make sure you update. And you'll

11:21.007 --> 11:24.088
actually get that vulnerability intelligence right in your

11:24.200 --> 11:27.750
command line. And another, a big thing I'd actually recommend is

11:28.250 --> 11:31.973
just ensure you have an inventory and list of all of the projects you're working

11:32.005 --> 11:35.426
on so that if, let's say there's some really

11:35.538 --> 11:39.103
big vulnerability that comes out where if your project is exposed to

11:39.152 --> 11:42.540
the public internet and you're running this library, you can very

11:42.604 --> 11:46.282
quickly check and see if you're vulnerable or not, because that

11:46.362 --> 11:49.893
has happened. That's been a constant in security since

11:50.393 --> 11:53.681
the 1990s. And with the way things are going, it seems like that will just

11:54.181 --> 11:57.243
keep happening. So in summary, there's a

11:57.291 --> 12:01.207
lot of things you can do on that side. And then with

12:01.707 --> 12:05.460
the new AI models, you're probably using them to code. They're very good for

12:05.960 --> 12:09.295
scanning your codebase for vulnerabilities.

12:09.793 --> 12:13.115
The challenge is you also need to know a bit about security to use them

12:13.163 --> 12:17.107
effectively. because you can't really just trust the output.

12:17.813 --> 12:20.314
I use them constantly for security assessments,

12:20.859 --> 12:24.674
and they're very effective when you know security, but we're not quite

12:24.802 --> 12:28.281
at the fully autonomous level. There's a lot of discussion about

12:28.329 --> 12:31.744
that right now. So a good source for this is the Erlang

12:31.776 --> 12:34.950
Ecosystem Foundation, the security working group that I'm on.

12:35.383 --> 12:38.717
They put out a lot of material. The Praxil.io blog is

12:38.734 --> 12:42.613
where I publish material on this, so that's a good thing to subscribe

12:42.661 --> 12:46.299
to. If there's a big news story that Elixir

12:46.799 --> 12:49.890
developers need to know about from a security perspective, you know,

12:49.954 --> 12:53.624
I like to use the blog there to communicate it to everyone.

12:54.522 --> 12:57.776
Right. Thank you, Michael. And maybe we will see you next

12:57.824 --> 13:01.911
week on the, well, in 2 weeks on the weekly security question.

13:02.632 --> 13:06.062
See you then. Now, welcome back. I hope

13:06.562 --> 13:09.415
that snippet was interesting to you. And let's continue with the news.

13:10.250 --> 13:13.911
The next news item we have here is about Hologram version

13:14.039 --> 13:18.165
0.12 is released. And that one's interesting because

13:18.278 --> 13:22.019
Hologram really improved their compiler

13:22.597 --> 13:26.017
and the way they compile the Elixir code to be used in the UI.

13:26.161 --> 13:30.287
So Hologram is to write local-first or client-side

13:30.721 --> 13:34.799
UIs in Elixir. And they had that issue that the compiler

13:35.299 --> 13:38.749
was quite slow and there were certain projects they simply couldn't compile because

13:39.249 --> 13:42.493
they were too complex and they would run out of time and memory.

13:43.139 --> 13:47.014
So they spent a lot of time on improving the compiler and they showed

13:47.514 --> 13:53.311
some really big improvements there where they took previously projects

13:53.811 --> 13:56.927
that previously couldn't be compiled and now they could compile them within just a few

13:57.427 --> 14:00.440
seconds. So that was really impressive. And it also tells you a lot about how

14:00.488 --> 14:04.169
you can improve any compilation time if you have some similar problems.

14:04.668 --> 14:06.227
So it's a good blog post to read.

14:09.282 --> 14:13.441
Next up on the news is the release of a library that is kind

14:13.522 --> 14:17.440
of near and dear to my heart, is the work coming from Marc

14:17.537 --> 14:20.829
Lanet, the guy who did

14:21.329 --> 14:24.266
the original ports of Nerves to Android devices.

14:24.699 --> 14:28.875
He's now developed an AI-assisted toolkit to let

14:29.375 --> 14:32.890
your agent have a bunch of tools to help you port Nerves to Android

14:33.390 --> 14:36.903
devices. And so it's called Nerves in Native. And we'll link

14:37.384 --> 14:40.862
the repo in the show notes. But if

14:40.894 --> 14:44.549
you're part of the NERF Discord, you might have seen this past week that

14:44.661 --> 14:47.690
there have been a bunch of people who have reached into their drawers,

14:48.187 --> 14:52.419
found what is essentially e-waste, old phones that they have lying

14:52.691 --> 14:56.314
in those drawers, and they have used this

14:56.522 --> 15:00.289
AI toolkit to port NERFs to those devices. Now, this is like

15:00.385 --> 15:04.649
a kind of complex process. A lot of Android devices are all different.

15:04.697 --> 15:08.881
They run different kernels, they have different security mechanisms. So having the toolkit

15:08.945 --> 15:12.648
is like really cool. And from what I've seen on the Discord,

15:13.289 --> 15:17.329
I think we've probably maybe doubled the number

15:17.377 --> 15:21.016
of Android devices, maybe even tripled the number of Android devices that

15:21.048 --> 15:24.639
now run Nerves these days. Right. It's been really cool seeing people posting,

15:25.296 --> 15:29.720
um, picture after picture of like, hey, I got it running on my whatever.

15:30.282 --> 15:33.364
I saw Samsung, there's some really old phones that are now

15:33.428 --> 15:35.932
running NeRFs, which is pretty cool. Is this going to be the next check?

15:36.141 --> 15:39.432
Like, can it run NeRFs? You know, can it run Doom? Essentially,

15:39.512 --> 15:42.258
can you, can it run NeRFs now? Can it run NeRFs? Yeah.

15:42.884 --> 15:46.223
Very nice. Very cool to see that. Yeah. And I got

15:46.723 --> 15:50.092
to say, I'm still continuing to be impressed by the progress

15:50.108 --> 15:53.094
we are seeing and all the side projects and the scope of the side projects

15:53.594 --> 15:57.011
that people are working on just because they can use an LLM now to point,

15:57.220 --> 16:00.720
You know, with the use of libraries like this one, they point an LLM at

16:00.768 --> 16:03.851
their old Samsung phone and say, hey, you know, install NeRFs on this thing.

16:04.541 --> 16:07.736
And then the LLM goes off and does it. Right. It's not

16:07.768 --> 16:11.830
something that you're likely to spend your own precious free time

16:12.087 --> 16:14.993
on, but when the barrier to entry is lower,

16:15.491 --> 16:18.975
it means that there's a lot more applications that can be done with what is

16:19.023 --> 16:22.251
essentially e-waste. I think people are going to be looking

16:22.363 --> 16:27.835
at making these into like little home dashboards. I saw someone Okay.

16:28.140 --> 16:32.179
He's a little crazy. He strapped an Android phone to

16:32.484 --> 16:35.722
the robotic— he has like the robotic lawnmower

16:35.914 --> 16:38.848
that he took apart. Oh, a robotic lawnmower. Okay.

16:40.098 --> 16:43.320
Yeah. It's like the one that like drives itself around your yard and

16:43.528 --> 16:47.407
chops. He took it apart. He basically just wanted the wheels and the motors

16:47.907 --> 16:51.719
for it. And so he then put the phone, his old Android

16:52.219 --> 16:55.401
phone in as the NERV

16:55.513 --> 16:58.727
controller for the device. And then he made it

16:59.227 --> 17:01.700
into a balance robot. I think he was missing out because he wasn't able to

17:02.200 --> 17:04.943
go to the balance bot workshop at GoatMind.

17:05.576 --> 17:08.044
So now there's a NERV phone driving a balance bot.

17:09.350 --> 17:12.574
But it's a lawnmower. It's like a proper lawnmower that now self-balances.

17:14.810 --> 17:17.107
Kind of. If you change the case for it a little bit to add a

17:17.607 --> 17:21.299
wheel. Wow. There's a very, the picture. I, we're gonna have to link the post

17:21.412 --> 17:23.436
in the show notes because it's,

17:25.035 --> 17:28.319
it's some, it's a thing to behold. It's great. Imagine you would come to his

17:28.351 --> 17:32.037
property and then there's like a, a lawnmower driving towards you,

17:32.070 --> 17:35.241
maybe with a little LCD or like a screen in it and saying,

17:35.837 --> 17:38.350
don't trespass. It's got the phone screen. Yeah.

17:38.559 --> 17:41.394
It's cool. That's funny. Yeah.

17:42.119 --> 17:46.074
So check out Nervsnator if you have old Android devices and extra tokens

17:46.107 --> 17:49.970
to burn. Interesting. All right. And the next item is that

17:50.066 --> 17:53.341
RecLLM 1.27.0 was

17:53.389 --> 17:56.954
released. It is a mostly bug fixes

17:57.949 --> 18:00.550
update, but there are 3 new cool features in here.

18:01.225 --> 18:04.452
And the most interesting one here is that now they

18:04.952 --> 18:07.663
have support for the OpenAI Decisions API.

18:08.450 --> 18:12.191
And that is basically what Jeff is. That's my

18:12.223 --> 18:15.755
understanding. So OpenAI now created their own Jeff-like

18:15.996 --> 18:19.126
decision LLM that is super fast, super cheap,

18:19.687 --> 18:23.010
and that can give you its opinion about

18:24.197 --> 18:27.455
whether something like an image or text is either

18:27.488 --> 18:30.697
true or false. So you can ask it a statement and then

18:31.197 --> 18:34.678
it gives you back it's true or false. It can choose between different

18:34.710 --> 18:38.177
categories. So like choices, and it

18:38.677 --> 18:42.270
can also give you what they say, like a Rubik's API. So a

18:42.770 --> 18:45.196
score against the rubric, whatever that means.

18:46.675 --> 18:49.826
But yeah, so RecLLM now supports that API as well. So if you

18:50.326 --> 18:53.680
want to play around with a Jeff-like model hosted

18:54.180 --> 18:57.083
by OpenAI, you can do that directly through RecLLM now.

19:00.254 --> 19:02.905
Nice. And next up, Jump,

19:04.351 --> 19:07.613
the company, they have a CredoChecks package,

19:07.790 --> 19:10.995
jump.credochecks on Hex, that has a new version.

19:13.964 --> 19:17.625
v0.6.0. This is a minor update with some

19:17.981 --> 19:20.702
bug fixes and some improvements to some of the existing ones,

19:21.220 --> 19:24.629
but I think the big one here is that they added a new Credo check

19:25.182 --> 19:28.387
to avoid modifying structs before they get passed to a

19:28.436 --> 19:32.791
change set. So if you use

19:33.291 --> 19:35.658
these, you might want to update if you want to see the new one.

19:36.882 --> 19:39.821
It's a minor bump, but they're pretty useful. So please take a look. Yes,

19:39.837 --> 19:42.995
very nice. And the last item is something

19:43.075 --> 19:46.586
that probably has been around for a while, but I only learned about it recently,

19:47.259 --> 19:50.641
which is that Hex, our beloved package manager,

19:51.267 --> 19:54.985
they built the Elixir Erlang Docker images for us,

19:55.338 --> 19:58.592
right? So if you run Elixir anywhere,

19:58.608 --> 20:01.638
most likely you use a Dockerfile for it. And that Dockerfile

20:01.686 --> 20:05.458
at the top always has an image tag for your

20:05.474 --> 20:07.929
Elixir version and then the OTP version.

20:08.834 --> 20:12.403
And I don't know how many hours maybe I spent

20:12.903 --> 20:16.376
already on Docker Hub to find the latest image for

20:16.748 --> 20:20.963
the Elixir and the OTP version, because it would then have a timestamp

20:21.463 --> 20:25.920
at the end. So it would be like elixir-otp-debian-slim

20:26.355 --> 20:29.491
and then a timestamp. And just to find that freaking timestamp,

20:30.279 --> 20:33.599
I had to spend so much time on this really, really slow Docker Hub that

20:34.099 --> 20:37.594
just, I don't know why you search for it and it takes 15 seconds to

20:38.094 --> 20:42.085
find, you know, like to do a string match on the Docker tags anyway.

20:43.064 --> 20:46.946
So I found that now HexPM, they expose

20:47.138 --> 20:50.748
their builders and the tags of

20:51.248 --> 20:56.234
the images they create through a very nice URL, which is just bob.hex.pm.

20:57.084 --> 21:00.469
And if you go to bob.hex.pm, you will see that

21:00.597 --> 21:04.607
first of all, you see all the jobs of the current builders. like what

21:05.107 --> 21:07.733
they're building. That's cool if you want to— Live, right? Live, yeah.

21:07.909 --> 21:11.339
It's all, when I loaded it earlier, it was showing some stuff. Exactly. So if

21:11.839 --> 21:15.026
you want to see whether a new Elixir version is already being built, you can

21:15.526 --> 21:19.242
check that here. They also have a tag for artifacts, which are,

21:19.531 --> 21:23.538
I think, binaries that you can download. So you can download a precompiled OTP

21:24.324 --> 21:27.658
version for Ubuntu 26, for example. You can do that right here.

21:28.347 --> 21:32.595
But then most importantly, for me at least, there is a Docker tags tab,

21:32.740 --> 21:35.817
and that allows you to filter by the Elixir version,

21:36.186 --> 21:40.228
and the OTP version and your host OS. So Ubuntu,

21:40.372 --> 21:43.964
Debian, that kind of stuff. And then it will give you the OS version,

21:44.044 --> 21:47.893
which might be, you know, Trixie, and then with the

21:48.393 --> 21:52.592
timestamp behind it. So you can use this website to

21:52.785 --> 21:56.617
quickly find the latest timestamp if you want to upgrade your Docker image

21:56.730 --> 22:00.146
to the latest Elixir version instead of using the Docker Hub one,

22:00.258 --> 22:03.881
which is, I don't know why, Extremely slow. Like you

22:03.929 --> 22:07.697
must, you must want this to be that slow. Like there's no

22:07.713 --> 22:11.560
way that you would have a query that just takes 15 seconds. Like it's engineered

22:12.060 --> 22:15.551
to be slow, I think. Anyway, now we have a better option. I can tell

22:16.051 --> 22:19.302
you're frustrated with it. Yeah, other than hex.pm. Yes, I'm very

22:19.318 --> 22:22.941
frustrated with that. Do you know where the, uh, do you know where the Bob

22:23.262 --> 22:25.442
name comes from? Bob the Builder.

22:26.853 --> 22:31.058
Bob the Builder. Yes. Bob the Builder. So yeah, Bob the Builder at

22:31.237 --> 22:33.989
bob.hacks.pm. Check it out.

22:35.756 --> 22:39.053
And now moving on to the blogs. Gus, what do we have

22:39.086 --> 22:42.367
this week? All right. That wraps up our news.

22:42.626 --> 22:46.668
In the blogs, we have a couple of blogs that were published in the last

22:47.168 --> 22:51.118
week or so. First up is the Goatmire Recap

22:51.134 --> 22:54.500
blogs. These have been a bit of a joy to read, especially because

22:55.251 --> 22:58.728
The 3 that we've linked below come from people who are

22:59.228 --> 23:03.106
involved in the behind the scenes of the conference.

23:03.620 --> 23:07.991
So Lars, who organized the conference, he posted

23:08.491 --> 23:11.511
on his website a very long,

23:12.170 --> 23:15.624
very comprehensive play-by-play

23:16.106 --> 23:20.107
of everything that was going on, including the months leading

23:20.204 --> 23:23.638
up to it. It's a very

23:23.654 --> 23:26.749
comprehensive read. It's a lot of pictures so that if you weren't there,

23:26.990 --> 23:31.068
it's a great way to like get a feel for what the conference

23:31.568 --> 23:35.305
actually was and entailed. I think Galtmeyer has a

23:35.805 --> 23:37.847
certain vibe that is hard to convey with words.

23:39.560 --> 23:42.069
So check out Lars's post there.

23:44.034 --> 23:48.381
In the same vein, Elise, who was one of the ones who Really

23:48.814 --> 23:51.383
was behind the scenes keeping everything on track,

23:52.250 --> 23:56.103
put together. She kind of was the showrunner behind the

23:56.603 --> 24:00.261
curtain, as well as planned a lot of the theatrical

24:01.176 --> 24:05.014
performances with Flora. She wrote

24:05.174 --> 24:09.204
on her personal blog as well about the process of making the music,

24:09.268 --> 24:12.832
helping with the MIDI library that she used for the

24:13.041 --> 24:16.498
Nurse Orchestra. Um, even other things

24:16.596 --> 24:21.524
like the, uh, that she threw in a singing piece

24:21.703 --> 24:24.098
with Sasha, Sasha Urich. Um,

24:25.425 --> 24:29.114
yeah, it's a good read. Uh, I think if you've not

24:29.486 --> 24:32.964
been involved in the planning of a conference, these 2

24:33.464 --> 24:37.201
posts are really gonna help you realize what a tremendous effort that

24:37.250 --> 24:40.145
was on, on so many people.

24:41.717 --> 24:46.027
And then the third one was from the BeamOps

24:47.025 --> 24:50.917
written by Ellie Fairholm. And that

24:51.417 --> 24:55.515
was her recap from more covering some of her favorite

24:56.101 --> 25:00.809
talks, generally what the vibe was there, and also

25:00.907 --> 25:04.766
the workshop that they ran. So take

25:05.266 --> 25:08.276
a look if you missed Goatmire or if you did go to Galtmeyer and you're

25:08.776 --> 25:12.094
already missing it, you can take a look at the recap vlogs that have

25:12.126 --> 25:15.639
been posted already and kind of see

25:16.139 --> 25:19.554
how the event went. Very nice. Yeah. And I also got

25:20.054 --> 25:23.180
to say Pep and Ellie from BeamOps, they're lovely people and they're helping me

25:23.196 --> 25:26.469
with the push-in architecture. So I also know that they are

25:26.969 --> 25:31.185
currently looking for a new contract. So if you have needs of improving

25:31.362 --> 25:35.275
your architecture or operations, DevOps of

25:35.371 --> 25:38.643
your application, give them a shout. Yeah.

25:39.958 --> 25:42.732
And that's what they ran their workshops on at GoMars. Exactly.

25:43.390 --> 25:46.741
Yep. Terraform, Docker, was it a whole bunch of,

25:47.479 --> 25:50.767
yeah, BeamOps. It's, uh, yeah. If you basically, if you,

25:50.783 --> 25:53.894
if you, if your architecture is still point and click,

25:54.295 --> 25:57.678
you know, just give them a shout because they can, they can help

25:58.178 --> 26:02.164
you move everything to a a bit more professional setup with Terraform

26:02.456 --> 26:05.685
and that kind of stuff. All right. Cool. Yeah.

26:05.750 --> 26:08.441
The next blog post is by our returning guest.

26:10.246 --> 26:13.022
I think she writes one blog post a week or two.

26:13.748 --> 26:17.443
So it's Johanna Larsson as always. And she wrote a quite

26:17.943 --> 26:21.739
interesting blog post about how she built her own AT Proto link aggregator.

26:22.758 --> 26:26.507
And Johanna's problem that she tried to solve is that

26:26.572 --> 26:29.804
in Bluesky, that is our new

26:30.285 --> 26:32.966
social media Twitter X competitor.

26:34.122 --> 26:37.622
Johanna sees a lot of articles flying past in her feed. And then

26:38.537 --> 26:41.507
the problem is she wants to read them later or she might not see them

26:41.523 --> 26:45.842
again after a refresh. So she wrote her own little aggregator

26:46.342 --> 26:50.096
that connects through her account to Bluesky and

26:50.596 --> 26:54.077
just saves these links as they fly past. And there's

26:54.126 --> 26:57.717
a very nice overview of the links that have been

26:57.781 --> 27:01.292
flowing in the ecosystem. And you can go

27:01.308 --> 27:05.059
to shelf.cafe, that is the website she built

27:05.075 --> 27:09.115
for this, to see a list of links

27:09.420 --> 27:13.507
to articles mostly that are trending currently

27:13.571 --> 27:17.082
on Bluesky. So it's quite interesting. And in

27:17.114 --> 27:21.410
the blog post, she also wrote in extensive detail about

27:21.426 --> 27:24.745
how she built this aggregator, how she does the algorithm and the

27:25.245 --> 27:27.529
moderation of these links. And so on.

27:28.609 --> 27:32.141
So give it a shout, give it a check. Also, if you just want

27:32.641 --> 27:36.507
to understand how you can connect to the Bluesky ATProto network

27:37.007 --> 27:40.834
to fetch content and information automatically.

27:42.459 --> 27:45.297
Yeah, she's been doing a deep dive on the ATProto ecosystem,

27:47.020 --> 27:50.171
and it's been really cool to see some of these posts coming from

27:50.236 --> 27:53.483
her blog. I, if you go check

27:53.983 --> 27:57.435
out shelf.cafe, I think it's very much similar to a

27:58.463 --> 28:02.737
Hacker News or Lobsters kind of link

28:03.237 --> 28:06.882
aggregator experience. So I'm curious to see where that goes because

28:07.541 --> 28:11.461
even if you, uh, don't use it, it's actually a really cool

28:11.493 --> 28:15.076
implementation of ATProto application

28:15.252 --> 28:19.366
full stack from PDS all the way up to App view

28:19.382 --> 28:21.520
and everything on the beam. Exactly. Um,

28:23.431 --> 28:26.412
yeah. Good. Next up,

28:26.671 --> 28:30.203
we have another returning author, Ryan Zidago,

28:30.928 --> 28:34.020
on using doc tests to understand a feature.

28:34.632 --> 28:38.739
This article is a bit more of an

28:39.340 --> 28:43.108
argument on why you should use not

28:43.157 --> 28:46.420
just docs for your LLMs, not just tests for your

28:46.533 --> 28:50.730
LLMs, but combining them into the single point,

28:50.972 --> 28:54.590
which is the doc tests, which are a cool feature that we have in Elixir.

28:56.590 --> 29:00.815
So he's got a lot of examples on where,

29:01.346 --> 29:03.242
like, there's a lot of code and examples here,

29:04.318 --> 29:07.747
but at the end is that he comes to several conclusions.

29:08.854 --> 29:12.454
There are limitations of this, is the way he ends the article with

29:12.954 --> 29:13.771
some caveats. There are,

29:17.017 --> 29:20.857
like, it increases your module doc sizes, and there's

29:21.452 --> 29:24.760
not always highly observable behaviors encoded

29:25.260 --> 29:28.938
into your specs. But he argues that it does reduce

29:29.438 --> 29:33.171
incorrect answers, and that it makes understanding what the

29:33.301 --> 29:36.796
tests are actually testing a little bit easier because it's embedded with your

29:37.296 --> 29:41.072
docs. So, Yeah, it was a

29:41.572 --> 29:44.132
good article there from Ryan Zitago. Yeah.

29:46.451 --> 29:49.982
And the last blog we have in today's section is

29:49.998 --> 29:53.975
from Alexey Matyushkin, also known as Muda

29:54.217 --> 29:57.418
Sobwa, and he wrote about aggressive regression.

29:59.371 --> 30:03.292
And it's basically a very long article about

30:03.519 --> 30:06.697
his approach to testing. and writing tests

30:06.969 --> 30:10.403
and that he rather goes for regression

30:10.436 --> 30:12.650
tests instead of, well,

30:13.549 --> 30:17.224
he tries to write tests, but then whenever something fails, he goes aggressively

30:17.256 --> 30:20.497
for regression tests to make sure that the test won't fail

30:20.946 --> 30:24.012
again in the future. So yeah,

30:24.220 --> 30:27.542
it's cheaper to write them than to get— than to

30:28.232 --> 30:31.554
have a bug report in the future again that might be because

30:32.054 --> 30:35.389
of the same bug. So he argues a lot about writing your own regression tests,

30:35.774 --> 30:39.049
but the blog is generally a very good introduction

30:39.081 --> 30:42.533
to creating a mindset or shaping your

30:43.033 --> 30:46.499
mindset around which tests to write, how extensive to write them,

30:47.109 --> 30:49.613
and then also which tests are useful and which just aren't.

30:50.159 --> 30:53.852
So I quite enjoyed this blog post because, yeah, it doesn't only focus

30:54.352 --> 30:56.822
on this, like, yeah, you should write regression tests, which is something, you know,

30:56.838 --> 31:00.723
self-evident. But he actually goes through his thinking

31:00.996 --> 31:05.010
about testing and how to build up a test suite that actually helps

31:05.510 --> 31:07.245
you Instead of working against you.

31:09.400 --> 31:13.145
I liked his, uh, also early in the document,

31:13.629 --> 31:17.359
early in the blog post, the argument of what is a regression test

31:17.423 --> 31:21.750
versus a unit test and how unit tests don't

31:21.846 --> 31:25.911
really, um, help you test

31:26.200 --> 31:29.386
too much. It's just asserting that the function does what you think it does.

31:29.501 --> 31:32.834
Yeah. So. It's a good mindset around

31:32.882 --> 31:36.428
testing. It's a good blog post. Very good. And now the

31:37.199 --> 31:41.114
next section, meetups and conferences. We still have, like, every time I think we're

31:41.614 --> 31:45.544
getting a shorter and shorter list here, it kind of extends. So Gus, why don't

31:46.044 --> 31:49.556
you take us through what's up next? All right. So meetups

31:50.056 --> 31:54.017
and conferences. Um, first up, the NURBS Meetup EU is

31:54.113 --> 31:57.259
tonight at 7 PM Central

31:57.759 --> 32:01.415
European Time. So hopefully if you listen to this by the time this goes out,

32:02.398 --> 32:05.275
Later this afternoon, you have a chance to register,

32:05.532 --> 32:08.505
but register for Nervous Meetup EU. Also,

32:08.762 --> 32:12.124
it's recurring, so if you miss tonight, check out for

32:12.624 --> 32:15.440
November. There is also Unconference,

32:15.746 --> 32:19.546
organized by the EEF attached to Codebeam Europe.

32:20.190 --> 32:23.823
Codebeam Europe is October 21st and 22nd. The Unconference

32:24.323 --> 32:26.537
is the day before on the 20th.

32:28.079 --> 32:31.942
If you haven't been to the unconference format before, organized by EF or anywhere else,

32:32.872 --> 32:36.527
you kind of bring your own topics and have

32:36.559 --> 32:41.368
more spontaneous discussions on Beam-related

32:42.570 --> 32:47.187
topics. And then finally, we have the BOB 2027

32:47.363 --> 32:50.906
call for proposals was published. I don't

32:51.406 --> 32:53.679
know too much about this conference, but it's in Berlin in February.

32:54.754 --> 32:58.493
February 26th, 2027. It's more of a functional

32:58.525 --> 33:02.618
programming, data structures, kind of more hardcore computer

33:03.118 --> 33:06.261
science, I would say. And so if you're interested in that

33:06.326 --> 33:09.824
sort of thing, there is a call for proposals due November 2nd,

33:09.840 --> 33:13.131
so about 2 weeks from now. And yeah,

33:13.756 --> 33:17.223
check it out for Berlin in late February. That's all

33:17.723 --> 33:21.047
we have for the meetups and conferences. As usual, if you

33:21.143 --> 33:24.622
have an event, a meetup that you organize and you'd like us to promote it,

33:24.944 --> 33:28.401
reach out to us and let us know. We're happy to put more

33:28.434 --> 33:31.350
stuff in there. Anywho, Peter,

33:32.225 --> 33:35.562
that kind of wraps up the news, the blog posts, the meetups and conferences.

33:36.453 --> 33:39.532
That means it's the audience's least favorite part of

33:40.032 --> 33:44.118
the show, which is your joke. Yeah. All right.

33:44.459 --> 33:47.836
Least favorite. I would say this is the favorite part of the entire podcast.

33:47.885 --> 33:51.174
That's the only reason why people listen to this. That's my opinion on that.

33:51.350 --> 33:55.166
Oh, was that the joke? No, it's not. Actually, I realized I

33:55.342 --> 33:59.254
saved a pretty good joke that I wanted to tell in my Goatmeier talk,

33:59.270 --> 34:02.187
but then I forgot to actually put it in my Goatmeier talk. So now I

34:02.235 --> 34:04.736
still have it here, you know, in the backlog, so to say.

34:05.858 --> 34:09.257
All right. So, you know, put yourself back into

34:09.273 --> 34:12.319
the situation where we were in Sweden, in Varberg,

34:12.639 --> 34:16.318
Goatmeier, you know, Vikings all around. So. The question is,

34:16.985 --> 34:20.447
what do you call a Viking that has lost his boat?

34:22.370 --> 34:22.612
Hiking.

34:26.903 --> 34:30.404
Yep. Very good. Viking ain't going too

34:30.904 --> 34:33.174
far without a boat. Ain't no more sailing.

34:33.993 --> 34:36.869
Hiking. Ain't no more sailing. Very good. Very good.

34:37.865 --> 34:41.875
Well, thank you. That is covering all of the main

34:41.977 --> 34:45.567
content of the of the podcast. We will

34:45.712 --> 34:49.166
start our discussion section now. And this week we're going to talk more

34:49.666 --> 34:54.061
about secrets and how do you keep

34:54.561 --> 34:57.797
stuff secure. So this is kind of a question I posed Peter,

34:59.720 --> 35:04.265
was how do you store your secrets both in production

35:04.491 --> 35:06.772
and in development? How do you,

35:07.726 --> 35:09.720
what's your workflow there? I need a new workflow.

35:11.392 --> 35:12.752
Yeah. Sorry, just to take one step back, we have 2 discussion topics.

35:14.836 --> 35:18.784
added one maybe that Gus hasn't scrolled down to yet. The second

35:19.284 --> 35:21.143
one that I wanted to discuss, if we have the time, is how to run

35:21.191 --> 35:24.722
your own vulnerability scans. Because now that, you know,

35:25.445 --> 35:28.879
the models like Mythos and, yeah, Mythos and

35:29.072 --> 35:32.635
Sol 6.1, like, they're now available

35:32.747 --> 35:36.390
to everyone. Mythos, okay, Mythos 5.1 is not available to

35:36.422 --> 35:40.066
everyone, but if you sign up for their security program, which takes just

35:40.566 --> 35:43.905
an hour, Then you can also get access to Mythos 5.1, even as a

35:43.969 --> 35:47.022
European, non-American. That's the big difference now.

35:47.504 --> 35:50.862
So I wanted to share with you a little bit, you know, now that everyone

35:50.894 --> 35:54.172
has access to these rather powerful models, how can you use

35:54.672 --> 35:57.562
them to scan your own code and libraries and that kind of stuff? So that's

35:58.062 --> 36:01.772
going to be the second discussion topic. First topic is how do you store

36:01.804 --> 36:05.564
your secrets? I have slowly

36:05.596 --> 36:09.228
over time changed more towards keeping everything inside a

36:09.728 --> 36:12.158
password manager, even for local development.

36:12.805 --> 36:16.573
So previously, you know, you would think about 1Password

36:17.073 --> 36:20.896
or similar password managers to keep your production secrets, and somehow

36:21.106 --> 36:25.430
you would then, you know, insert them into your image

36:25.930 --> 36:29.657
that you deploy to production. And actually

36:29.690 --> 36:33.455
this work has, like this change has come through KAML that

36:33.503 --> 36:36.148
I still use to deploy most of my applications.

36:36.792 --> 36:40.275
because they do give you a secrets file, but in the secrets file,

36:40.323 --> 36:44.095
you don't store raw secrets because you can also commit this file to

36:44.595 --> 36:48.749
GitHub. So, but in the secrets

36:49.249 --> 36:53.420
file, what you usually do is you call the password manager CLI

36:53.966 --> 36:55.748
to fetch one particular secret.

36:56.518 --> 37:00.017
And yeah, if you set up 1Password in a certain way,

37:00.081 --> 37:03.645
it will ask you for your permission to fetch all these secrets every

37:03.661 --> 37:07.063
time you deploy. So you actually have kind of like

37:07.529 --> 37:10.978
a check there that, nobody can just call the CLI, but you

37:11.478 --> 37:14.698
have to approve it every time. So. Right. And that's,

37:14.827 --> 37:19.125
that's local on your machine because you're deploying with Kyma, which is basically

37:19.301 --> 37:22.845
SSHing into your server, pushing your release, restarting stuff.

37:23.086 --> 37:26.422
Exactly. But also at that same time, sending the environment variables.

37:26.694 --> 37:30.559
So they're not stored on the server anywhere, right? No, they're only inside

37:31.059 --> 37:33.767
the environment in the Docker container. So there's no,

37:34.409 --> 37:38.246
stored value in the, in the container itself. It's just in the environment.

37:39.209 --> 37:42.308
So yeah, if you get access to the application or the Docker container, you can

37:42.324 --> 37:45.776
obviously still take the environments out, but then I might also have a bigger

37:46.276 --> 37:49.710
issue. Yeah, a little bit. But what

37:50.210 --> 37:54.367
happens if, say, your machine goes down for the

37:54.867 --> 37:57.947
cert, the, the, the data center has maintenance and your machine goes down? Does it

37:57.995 --> 38:01.239
restart and then come back online with those secrets, or do you have to redeploy

38:01.287 --> 38:03.801
manually? That's a good question. I think, I think that, uh,

38:05.954 --> 38:09.373
I think you have to redeploy. Yeah. Because it wouldn't

38:09.873 --> 38:12.139
have the secrets stored anymore. It wouldn't have the secrets. Yeah, I think so.

38:12.237 --> 38:15.580
I haven't tested that one yet. That's a good one. So,

38:16.675 --> 38:20.410
so make sure you have your laptop when you go for vacation

38:20.522 --> 38:23.871
because, uh, yeah, I always have it on me. Data center goes

38:23.984 --> 38:27.359
down. You can't go hiking in the Alps without worrying

38:27.409 --> 38:30.841
about pushing there, Peter. Yeah, it's a good, good point actually. I haven't

38:31.341 --> 38:34.818
thought about that one. Yeah. I mean, but I think that's,

38:35.026 --> 38:38.217
that's what other, um, there are like tools that

38:38.717 --> 38:41.825
do secrets management and, um, like,

38:42.066 --> 38:45.096
was it HashiCorp Vault is one of them that,

38:45.690 --> 38:49.249
and I think those are ones where it can pull the secrets

38:49.442 --> 38:53.050
automatically into your Docker image during the startup of your application.

38:53.707 --> 38:56.978
I don't have that much experience, so I don't know what I'm Fully talking about.

38:57.059 --> 39:00.247
Have you used those before? I have not, but I mean, if you

39:00.457 --> 39:03.678
use something like, um, I mean,

39:04.276 --> 39:07.706
what you mentioned earlier, if your machine goes down and you restart your application,

39:09.225 --> 39:12.827
like if you do bare metal servers, what I'm doing,

39:13.166 --> 39:16.736
you kind of have to manage that yourself, right? You have to restart

39:17.236 --> 39:20.998
your application, inject these environment variables, um, by restarting the application.

39:22.048 --> 39:25.226
If you do a managed server where you just upload your image and then

39:25.275 --> 39:29.031
it gets deployed on a server for you, I think in this situation, I would

39:29.531 --> 39:33.221
also not, I actually had it set up in such a

39:33.721 --> 39:37.250
way for Fly, for example, where you hand over the secret to the provider,

39:37.314 --> 39:40.477
the hosting provider, and they inject it whenever they

39:40.525 --> 39:43.960
start or restart your application. Yeah. And I

39:44.460 --> 39:47.588
think that's a pretty common way for a lot of those managed

39:47.893 --> 39:50.509
hosting services. Yeah. Um,

39:51.264 --> 39:54.425
I, I believe if you're,

39:54.826 --> 39:58.581
if you set some things up properly, you can probably also use

39:59.081 --> 40:01.165
GitHub Actions during your release step to,

40:02.256 --> 40:05.802
uh, use GitHub secrets to inject

40:05.867 --> 40:09.188
into your application as well as it starts up on whatever

40:09.558 --> 40:12.976
hosting provider. I did that too, actually. I have one, one CD where I

40:13.088 --> 40:16.682
use GitHub to deploy through Kamal. And I have my

40:16.698 --> 40:20.356
environments saved as environment variables in the GitHub Actions. So then Kamaal

40:20.468 --> 40:24.575
fetches from the GitHub Action environments to inject

40:25.075 --> 40:28.682
it into the deploy, into the container. But I think the big

40:28.986 --> 40:32.660
point here is just you shouldn't bake the secrets into your

40:33.160 --> 40:35.836
Docker image that you then store on a registry or somewhere.

40:36.927 --> 40:40.504
But this would be the only way that if you restart your Docker image

40:40.617 --> 40:43.954
and have no outside you know, Key Vault or something.

40:44.772 --> 40:47.853
Only this way you could then have the environment secrets in the Docker container,

40:47.917 --> 40:51.094
but I don't think you want that. Yeah. Right.

40:51.351 --> 40:55.507
You want something starting it with the secrets as an

40:55.956 --> 40:59.310
environment for that image when it starts. Yeah, injected. Yeah.

40:59.454 --> 41:03.465
So the secrets should be injected. Yeah. So for local

41:03.965 --> 41:06.241
deployment, I mean, that's what I'm doing most of the time these days with Kamal,

41:06.370 --> 41:10.269
where I have on my local machine, I fetch these secrets from

41:10.542 --> 41:14.293
the password manager, it gets injected as Kamal deploys

41:14.567 --> 41:17.723
the image, and then afterwards the secrets are gone also

41:18.223 --> 41:19.606
from my local environment.

41:22.423 --> 41:25.919
If you want to have a more CD approach, then yeah, either store

41:25.968 --> 41:29.399
them in GitHub Actions and then use them while you deploy from GitHub Actions,

41:30.141 --> 41:33.323
or if you have something where somebody deploys an image for

41:33.388 --> 41:36.702
you, then they most likely will have also a Key

41:37.202 --> 41:40.490
Vault where you can set these environment variables. Fly, for example, they have Fly secrets.

41:40.586 --> 41:44.448
So you can just set them there and then they get injected. I believe,

41:44.640 --> 41:48.038
like, I think maybe on Scaleway, which is what I'm using,

41:48.390 --> 41:51.579
and Hetzner, I also use Hetzner, they might also have

41:52.076 --> 41:55.585
key, like I know on Scaleway, they have key vaults that you can use.

41:56.595 --> 42:00.249
So you can probably put your environment variables into the key

42:00.749 --> 42:04.319
vault of whatever hosting provider you use. And then

42:05.056 --> 42:08.408
give your Docker image just like a temporary token that it could

42:08.440 --> 42:11.358
use, maybe. You know, there could be a way there,

42:11.968 --> 42:14.886
if the Docker image starts up, it has either,

42:15.800 --> 42:19.424
like somehow it will get a temporary token and then it can connect

42:19.924 --> 42:23.513
to the Key Vault to fetch the environment variables from there. So you

42:24.013 --> 42:26.672
might be able to— Something short-lived. You might be able to build what Fly,

42:26.785 --> 42:29.350
for example, does for you yourself,

42:29.767 --> 42:31.499
but you know, you gotta be a bit more careful then.

42:32.894 --> 42:36.599
Right. So, and you were mentioning the password manager.

42:36.663 --> 42:40.720
So when you deploy with Kamal, it's just invoked

42:40.832 --> 42:44.745
with the scripts that then run the

42:45.245 --> 42:48.738
release. But you mentioned to me earlier that, um, you do

42:48.754 --> 42:52.458
have something similar for your local development as well. What does that

42:52.958 --> 42:56.322
look like? Yeah, so I used to have .env files, and in those

42:56.707 --> 43:00.157
.env files, I would store the secrets. I think we have all done that,

43:00.237 --> 43:03.672
you know, maybe still today, or at least a few years ago,

43:03.704 --> 43:05.983
that's the way you set up local development.

43:07.380 --> 43:11.296
I have since switched also to fetching the secrets from the

43:11.796 --> 43:14.394
password manager as I source the .env file.

43:15.261 --> 43:19.178
So in the .env file, if you replace the actual value with

43:19.242 --> 43:22.517
a call to your password manager, so to

43:22.533 --> 43:25.727
the CLI, when you source the .env

43:25.759 --> 43:29.375
file, it will call the password manager and then fetch the environment

43:29.875 --> 43:33.578
variable and inject it into your local environment. But this way

43:34.078 --> 43:38.059
you never have the actual secrets stored in a plain text file in your application,

43:38.124 --> 43:39.562
in your project.

43:41.567 --> 43:45.554
Right. And that just looks like your .env file then has the

43:45.763 --> 43:49.025
exporting the environment variable, but then

43:49.058 --> 43:52.533
you also have the shell interpolation with the dollar sign

43:53.033 --> 43:56.314
parentheses, and then it's calling the CLI of your password manager.

43:56.379 --> 43:59.589
And then When you source it, you get that little popup from your

43:59.622 --> 44:03.137
password manager that says, do you want to authorize this? Something like that. Yeah.

44:03.898 --> 44:07.270
And I also use that for my dev container setups because

44:07.302 --> 44:10.729
I run most of my agents when I code locally,

44:10.842 --> 44:13.738
I run them in a dev container. So that's a Linux container running on my

44:14.238 --> 44:17.552
computer. And I have a GitHub project there.

44:17.861 --> 44:21.443
If you go to pjulbricht/devcontainer, or you can also go at pushin.eu/pjulbricht/get-devcontainer.

44:24.120 --> 44:27.067
I think I migrated it. In there, you will find a devcontainer.json.

44:29.413 --> 44:32.542
And that is the configuration file for the actual dev container.

44:33.168 --> 44:35.880
And in there, I'm setting environment variables,

44:36.410 --> 44:40.053
either secret or public. You know, if they're public, they're just baked into that file.

44:40.550 --> 44:45.108
If they're secret, they pull that environment variable from the

44:45.220 --> 44:48.350
environment of the shell session that you use

44:48.850 --> 44:51.977
to start the dev container. So this way, if I,

44:52.523 --> 44:56.501
because you might not need all the environment variables in your actual

44:56.597 --> 45:00.476
dev container. So you only need maybe 1 or 2, but you have 10 for

45:00.976 --> 45:04.547
your, you know, because locally I need more environment variables to maybe deploy or

45:05.047 --> 45:08.554
do some other CLI work. But in the dev container, I only need 2.

45:08.971 --> 45:12.321
So I can inject them from my local session into the dev container.

45:12.802 --> 45:16.408
And then the agents can work inside that dev container, but they

45:16.472 --> 45:19.597
don't have access to the real environment outside of it. Nice.

45:20.719 --> 45:24.646
Yeah, that makes a lot of sense. And then With

45:25.146 --> 45:28.206
your projects, then you are committing your .env files, presumably?

45:28.431 --> 45:31.558
No, I do not. No. You still don't, even though

45:32.058 --> 45:35.535
it's not including any— Right. I mean, by now I could,

45:35.647 --> 45:39.865
but I usually don't. If I need to share the

45:40.137 --> 45:44.002
.env file with another developer, I'd rather create an example

45:44.210 --> 45:45.958
.env file. And then it has,

45:47.129 --> 45:50.224
it has, you know, like, hey, insert this value here or there. So,

45:50.304 --> 45:54.329
so they, the other developer knows which environment variables they need to set,

45:54.794 --> 45:58.658
but the actual values are not in there. But I just didn't have that situation

45:59.158 --> 46:03.452
yet where I needed to share my .env with another developer. But yeah,

46:04.174 --> 46:08.086
I mean, I just, I don't feel good about committing

46:08.343 --> 46:12.127
.env files because maybe in one situation it has a secret

46:12.627 --> 46:15.735
and then it's, you know, online. So I just don't do it. Fair enough.

46:16.777 --> 46:20.346
Did you add it to your global .gitignore then? Something to make

46:20.846 --> 46:24.103
sure it never gets— Exactly. So I would need to remove my global .gitignore for

46:24.184 --> 46:27.440
.env files, and I just don't want to do that. Fair enough.

46:28.071 --> 46:31.453
I guess old habits die hard, huh? They do. Even if it is safe

46:31.566 --> 46:34.188
now. That's true. But I mean, generally,

46:35.191 --> 46:38.835
like my main suggestion here is just to move everything to a

46:39.335 --> 46:42.885
password manager and then use the CLI that most of them now offer.

46:43.209 --> 46:46.321
I mean, 1Password was already. They had that already a year

46:46.369 --> 46:50.002
or 2 ago, or 3 maybe. I use ProtonPass, and they

46:50.083 --> 46:52.418
also added a pretty good CLI, I think a year ago.

46:53.809 --> 46:56.909
So like, the only thing is I also have my SSH keys in there,

46:57.233 --> 47:00.539
which might be even more important than your local development secrets.

47:01.646 --> 47:04.885
If you keep your SSH keys on disk, even if they're encrypted,

47:05.530 --> 47:10.575
it's not a good idea. Because if you get exploited,

47:12.306 --> 47:16.426
You know, by like, for example, we saw that in the JavaScript ecosystem where

47:17.917 --> 47:21.091
there were packages released or published,

47:21.139 --> 47:24.073
malicious packages. And when you downloaded the package,

47:24.907 --> 47:27.199
they have an after-install script that would run,

47:27.936 --> 47:31.527
and that script would just look at your .ssh folder, take everything

47:31.544 --> 47:35.503
that's in there, and upload it to a command and control server by the

47:36.003 --> 47:39.529
attacker, right? So, within seconds, your SSH keys,

47:39.641 --> 47:43.204
private keys, will be in the hands of the attacker. And then all they

47:43.704 --> 47:46.318
need to do is figure out the IPs to your server and then connect to

47:46.818 --> 47:48.902
it through, with that SSH key.

47:49.849 --> 47:53.829
So that was one of my first things where I moved those to ProtonPass,

47:53.942 --> 47:57.473
to my password manager. And now whenever I SSH

47:57.973 --> 48:01.389
into a server, it gets pulled just in that one call from

48:01.485 --> 48:04.856
the CLI. I wished that

48:05.356 --> 48:08.776
in ProtonPass, it would ask me every time it does it, but it does not.

48:08.969 --> 48:12.551
So that's a little bit, nah, I just don't like it. In 1Password,

48:12.632 --> 48:14.881
I know you can set it up in such a way that it asks you

48:14.961 --> 48:17.306
every single time an SSH key is requested.

48:17.949 --> 48:21.371
So, you know, it might also just be a configuration issue in

48:21.403 --> 48:25.098
my case. Yeah, but this way, even if an attacker

48:25.598 --> 48:28.777
gets access to your local computer, which we kind of think of, oh, it's just

48:29.277 --> 48:32.872
my local machine, it's not production, Yeah, still you have secrets

48:33.372 --> 48:37.255
on there that gets you access to production. And if it's just a database string,

48:37.705 --> 48:41.061
you know, the database URL that you have locally to connect to

48:41.561 --> 48:44.690
your production database, like they can extract that and then connect to it directly.

48:45.717 --> 48:49.266
So yeah, let's just keep everything in a password manager.

48:49.506 --> 48:53.039
It's not 100% secure, but it's more secure than just a plain text

48:53.539 --> 48:56.732
file on your computer. Right, right. And I think

48:57.232 --> 49:01.389
these are really good suggestions because, I mean, especially with the JavaScript ecosystem

49:01.453 --> 49:04.779
thing, this isn't exclusive to JavaScript, but it's just seen there because

49:05.279 --> 49:09.004
it's targeted, either packages, popular packages being compromised and

49:09.743 --> 49:13.342
the new versions being able to steal your

49:13.842 --> 49:17.037
secrets. So you just do your npm update or whatever the command

49:17.117 --> 49:19.640
is, and then boom, you're compromised. Exactly.

49:20.090 --> 49:23.656
Um, but I mean, it's, it's a threat that we could see here

49:23.720 --> 49:26.259
in Elixir as well in the Beam community.

49:28.182 --> 49:31.345
Speaking of that, how is

49:31.845 --> 49:35.395
scanning going, Fedor? What's the, um, if we are

49:36.008 --> 49:39.901
thinking about compromised packages, um, we want

49:40.401 --> 49:43.442
to be able to detect those. If I am a solo

49:43.942 --> 49:47.522
developer and I want to protect myself and scan all of my packages

49:47.700 --> 49:51.270
before I download and install them, how do I go about that?

49:52.056 --> 49:55.742
If you want to scan all your dependencies, you mean? That you pull down.

49:57.216 --> 50:00.390
Well, good luck. I mean, sure.

50:00.583 --> 50:03.917
I'm, this is probably more for the, uh, the enterprise,

50:04.350 --> 50:07.187
uh, know every dependency, get it approved by,

50:08.117 --> 50:12.092
uh, security type of corporate security policies.

50:12.846 --> 50:15.972
As an independent developer, I'm not going to do that, but it might give me

50:16.472 --> 50:19.819
peace of mind to just run it once, once or twice, or to have you

50:20.319 --> 50:22.512
run it every once in a while. Oh yeah. Yeah, yeah, sure. So I run

50:22.720 --> 50:26.311
security scans on my application, like Pushin, which is my main application right

50:26.811 --> 50:30.271
now. I run it every week or two. Like, I run a full,

50:30.719 --> 50:34.214
not full, but like, I focus on subsystems and then I

50:34.791 --> 50:38.638
use Daybreak Blue, which is OpenAI's cyber defense model.

50:39.216 --> 50:42.470
And now I can also use Mythos 5.1, and I just tell it,

50:42.486 --> 50:45.804
hey, go look at the subsystem and find security vulnerabilities in there.

50:46.525 --> 50:50.244
So I found, like, I did that last week with Pushin,

50:50.437 --> 50:53.853
and I found like 50, 60 reports. None of them

50:53.949 --> 50:57.160
were severe. Most of them were like in this particular

50:57.660 --> 51:01.607
situation, yada, yada, yada, you know, somebody can still make a push after

51:02.107 --> 51:05.412
they were blocked, for example. So I fixed them and

51:06.471 --> 51:10.485
I feel, you know, better about doing that. And I hope I'm

51:10.501 --> 51:13.519
going to rescan like in 2 weeks, you know, to see what falls out.

51:14.530 --> 51:18.046
So that's what I'm doing. These models have become good enough,

51:18.191 --> 51:22.333
even if you just use Opus 5.5 or if you use SOL 6.1.

51:23.269 --> 51:26.890
Although I use Opus 5.5 more, they're good

51:27.390 --> 51:30.366
enough to find most of the vulnerabilities, right?

51:31.045 --> 51:35.545
So that's a good approach. Just in OpenAI

51:36.045 --> 51:39.702
and Codex, you have a plugin from Codex Security that you can

51:39.734 --> 51:43.214
install, and that gives you these security

51:43.714 --> 51:47.677
scan and security deep scan skills. I usually

51:47.709 --> 51:50.353
run the security scan one. It's a bit simpler.

51:51.685 --> 51:55.651
So that's what in Codex. In Claude, I think you also have a security review

51:56.807 --> 51:59.906
skill, but there, I'm not sure how good it is,

51:59.938 --> 52:03.326
to be honest. I wrote this blog post a while back

52:03.471 --> 52:07.341
where I also shared my prompt that I'm using when I do these scans.

52:07.405 --> 52:10.568
So you can just use that prompt, give it to Claude and say,

52:10.873 --> 52:14.646
scan this library or this application based on this prompt.

52:15.112 --> 52:19.488
And what I'm doing in my scans is usually I go through the project

52:19.776 --> 52:23.143
file by file, so one file at a time, and you

52:23.191 --> 52:26.734
can write, you know, a 10-line Bash script to do that for you, where you

52:27.234 --> 52:30.966
just fetch the .ex or .exs files or .hex

52:31.466 --> 52:34.636
files. Hex is not that important really, but .ex and .exs files,

52:35.294 --> 52:38.516
and then you feed these files one by one into a new Claude

52:39.016 --> 52:42.283
session, and you just tell it with a prompt, you know, find me some

52:42.783 --> 52:46.130
security stuff, and then write it to a Markdown file with the unique ID so

52:46.630 --> 52:50.122
that you can reference it later. So that is something you can write in like

52:50.622 --> 52:54.113
half an hour. And with Opus 5.5, like you will also not use that many

52:54.145 --> 52:57.511
tokens to do that. So you can just run it while you work

52:58.011 --> 53:01.166
on something else. And if you run that every 2 weeks, once a month,

53:01.663 --> 53:04.901
you know, I guarantee you, you will find and continue to find

53:05.703 --> 53:09.037
severe security vulnerabilities in your application,

53:10.015 --> 53:13.269
but then also bugs, which is nice, you know, to find these kinds of things.

53:13.863 --> 53:17.286
So that's good, but that's— Right.

53:17.576 --> 53:22.307
Yeah. For those skills

53:22.404 --> 53:26.455
that you mentioned from OpenAI and from Anthropic,

53:27.065 --> 53:30.360
they are essentially just an

53:30.860 --> 53:34.137
opinionated set of instructions for how to do

53:34.170 --> 53:38.441
those scans, right? And it's similar to what you were just describing with

53:38.941 --> 53:42.884
your opinionated set of instructions for So have you, have you seen much

53:42.916 --> 53:46.779
benefit between the two? Is it worth it to personalize? Is it

53:47.083 --> 53:49.937
good enough to just go with the built-in skills?

53:50.770 --> 53:54.345
Yeah. So one of the biggest takeaways is

53:54.457 --> 53:57.615
to not just point an LLM at your entire

53:58.609 --> 54:01.078
codebase and say, go find vulnerabilities.

54:01.815 --> 54:05.390
You know, that will find you some vulnerabilities, but certainly not everything.

54:06.175 --> 54:09.494
So what you need to do in any case is to break down

54:09.590 --> 54:12.860
the application into subsystems or into files

54:12.972 --> 54:16.017
as I'm doing most of the time for smaller projects,

54:16.882 --> 54:20.504
and then just have every single file sent to Claude,

54:20.824 --> 54:24.702
but also allow Claude or Codex, but allow these LLMs

54:24.911 --> 54:28.035
to also look for code calling that

54:28.535 --> 54:30.952
module. Right. So not, you know, say only look at this file,

54:31.561 --> 54:34.894
but also say, see where this file is being called from.

54:36.064 --> 54:39.012
So this way it can understand whether It's, you know,

54:39.397 --> 54:43.179
a little function somewhere very deep down the application that nobody else

54:43.243 --> 54:46.464
calls except for one other function that is slightly higher up

54:46.964 --> 54:50.502
the stack, or whether this is a publicly exposed function that everyone can call,

54:50.935 --> 54:53.996
right? Those are very different threat models here.

54:54.717 --> 54:57.762
So, but it does it by itself, really. You know,

54:58.387 --> 55:01.976
the only thing is scope it down to something that is small and then

55:01.992 --> 55:05.903
rather use multiple sessions to iterate through the files

55:06.080 --> 55:09.270
or the subsystems that you have. And all these skills,

55:09.286 --> 55:12.540
they basically do that. So if you also look at the security scan

55:12.653 --> 55:15.875
skill, it will also spin up different subagents that all look at

55:16.375 --> 55:19.402
different parts and so on. So it's all a divide

55:19.902 --> 55:22.416
and conquer approach to finding vulnerabilities.

55:23.714 --> 55:27.498
Right. I guess it sounds like when you start it with a more limited scope,

55:27.514 --> 55:31.153
it'll divide and conquer in smaller pieces that might be able to pick up things

55:31.249 --> 55:34.215
that if you just started it over your entire project, it might not.

55:35.177 --> 55:39.779
Get to that granular level. Yeah. And just a recent

55:40.180 --> 55:44.125
example of this, I used Mythos 5.1

55:44.879 --> 55:47.284
to scan a pretty big library in the space.

55:48.086 --> 55:51.421
And I first gave it kind of like the whole project approach.

55:51.710 --> 55:55.302
So I just pointed Mythos at that project and said, find me

55:55.802 --> 55:59.055
vulnerabilities. And it went off and spent a lot of tokens and it

55:59.071 --> 56:01.059
came back with, I think, 4 vulnerabilities.

56:02.102 --> 56:05.406
And 2 of them were proper vulnerabilities.

56:05.503 --> 56:09.407
2 of them were more bug fixes, slash maybe a vulnerability,

56:09.423 --> 56:13.891
nothing severe. And then I did the same with Opus 5.5,

56:13.923 --> 56:17.695
but I had Opus 5.5 iterate through every single file and just

56:18.195 --> 56:20.654
do it one file at a time. And I still need to review them,

56:20.767 --> 56:24.536
but there were 20 reports instead of 4. Hmm.

56:24.601 --> 56:28.192
So, and I've seen that many times now. So if

56:28.692 --> 56:31.941
you just point an LLM at a project in general and say, go find me

56:31.990 --> 56:35.958
vulnerabilities. Yeah, it will come back with 4, even if it's— because he,

56:36.167 --> 56:39.219
I tried this approach with Mythos because I thought, well,

56:39.235 --> 56:42.657
Mythos is what everyone says, super, like it can, it can contain

56:42.754 --> 56:45.517
a lot of context. It can handle big applications.

56:46.529 --> 56:49.421
And yeah, it didn't do that well, to be honest, you know?

56:50.224 --> 56:53.582
So I think even there, you're better off pointing it at subsystems

56:53.759 --> 56:57.115
or individual files and then have it Uh, find the vulnerabilities.

56:58.505 --> 57:02.529
Right. And how do you feel like in

57:02.545 --> 57:05.628
the confidence level of those 20 Opus

57:06.128 --> 57:09.137
vulnerabilities that it found versus the 4 Mythos?

57:09.894 --> 57:13.886
Like, is it 20 junk or 16

57:13.919 --> 57:17.288
junk ones and it caught the 4 that Mythos also did? Or how do you

57:17.788 --> 57:20.738
feel? Yeah, usually, what was your experience? Usually I have like a 20, 30,

57:20.770 --> 57:24.397
sometimes 40% hit rate. with vulnerabilities. So,

57:24.590 --> 57:27.964
if I take 20, if I have 20 reports, I'm pretty sure out of 20,

57:28.028 --> 57:31.338
there will be like 5 CVEs maybe falling out.

57:31.900 --> 57:36.055
So, that's already more than Mythos, where only 2 out of 4 reports

57:36.653 --> 57:40.063
probably will be a CVE. Right.

57:41.268 --> 57:44.530
Very interesting. And with the access

57:44.643 --> 57:48.226
to Mythos that you now have, I think I heard, or you posted on socials

57:48.259 --> 57:51.932
recently, that you scanned Phoenix. And found no vulnerabilities.

57:52.045 --> 57:56.019
Is that right? Nothing new. Yes. I rescanned Phoenix.

57:56.115 --> 57:59.800
Actually, I have been rescanning Phoenix almost with every new model that comes out,

57:59.881 --> 58:03.903
and time and again, it doesn't find anything severe

58:04.403 --> 58:07.428
critical, right? So I'm still waiting for that day where out of a sudden,

58:07.444 --> 58:10.889
a new model comes out and says, yeah, this is massive, massive vulnerability in

58:10.954 --> 58:13.373
Phoenix that everyone has overlooked so far,

58:14.142 --> 58:17.141
but it just hasn't happened yet. So, Fingers crossed.

58:17.285 --> 58:20.576
Kudos to the Phoenix team for doing that,

58:20.721 --> 58:23.979
but like fingers crossed. I'm hoping,

58:24.573 --> 58:28.250
and I'm sure you're hoping, that we start to see like the tail of

58:28.908 --> 58:31.717
LLM security vulnerabilities. Yes,

58:31.797 --> 58:34.607
they're still going to exist, but they're going to get harder and harder and harder

58:35.107 --> 58:39.021
and harder to find. So let's build

58:39.521 --> 58:42.762
a more secure ecosystem. That's what's happening right now. Yeah.

58:43.598 --> 58:47.504
bigger issue here is breadth versus

58:47.714 --> 58:51.830
depth right now. So I scan a few libraries quite often and

58:51.991 --> 58:56.037
like the biggest ones, I scan them quite often. I don't

58:56.231 --> 59:00.099
find that much anymore. Sometimes like Decimal had a CVE,

59:01.472 --> 59:05.232
you know, so that kind of stuff. But yeah,

59:05.473 --> 59:09.378
now like now I kind of need to go into more the broad aspect.

59:09.426 --> 59:12.825
I need to go down the long tail of libraries, right? Because even if you

59:12.841 --> 59:16.353
use a small library that doesn't have as many downloads as Phoenix,

59:16.401 --> 59:20.090
for example, it might still be very critical to

59:20.590 --> 59:24.035
your stack or to your application, and it might have a vulnerability that

59:24.535 --> 59:28.189
is severe, right? Right. And that's

59:28.689 --> 59:31.845
the case where your recommendations earlier on how to run security scans might be useful

59:31.894 --> 59:35.470
for people listening to the podcast, because if you have those

59:36.128 --> 59:39.961
dependencies that you, in addition to your own applications,

59:40.394 --> 59:43.553
that you want to check for security vulnerabilities, something that hasn't been

59:44.082 --> 59:48.157
On the, what is it, the top 100, top 1,000 packages that

59:48.173 --> 59:51.751
you've scanned on Hex? Yeah, ideally scan

59:51.783 --> 59:55.184
them yourself, especially when they're kind of critical,

59:55.376 --> 59:58.601
when they take external input. You know, if it would be

59:59.162 --> 01:00:02.692
like Ecto, I mean, Ecto is important,

01:00:02.996 --> 01:00:07.232
but it's also very low down in the stack. Like you will almost never give

01:00:07.424 --> 01:00:11.114
a user direct access to any Ecto functions. It always goes through the

01:00:11.178 --> 01:00:14.917
LiveView or Phoenix controller context, whatnot. So you have some

01:00:15.029 --> 01:00:18.851
layers of protection there. Yeah, we also, I didn't find too

01:00:19.351 --> 01:00:22.399
much in there. So, so basically think about your library,

01:00:22.592 --> 01:00:25.867
have it like, just again, point Opus or Codex at it and say,

01:00:25.884 --> 01:00:28.324
find me some vulnerabilities, fix them.

01:00:28.934 --> 01:00:31.969
If there are actual vulnerabilities, you know, if you, if you think people are,

01:00:32.049 --> 01:00:35.469
could be affected by this, send us a Slack message or an email,

01:00:36.063 --> 01:00:39.500
and then we can create a CVE for you so that people get notified about

01:00:39.773 --> 01:00:43.622
this critical change and can upgrade to the fixed

01:00:44.122 --> 01:00:48.695
version, right? But yeah, I think it's just like— Who

01:00:48.711 --> 01:00:52.920
is the us that you're talking about? Oh, that's me and Jonathan. So it's

01:00:53.274 --> 01:00:57.499
2 people. And why

01:00:57.548 --> 01:01:01.598
you 2? What's special about you 2? Well, we are working

01:01:01.630 --> 01:01:05.810
for the EFF to do this. Jonathan is officially the CISO, Chief Information

01:01:06.310 --> 01:01:09.962
Security Officer of the EFF. Um, he works full-time and more than full-time on

01:01:09.995 --> 01:01:13.119
this. I work part-time on it, but yeah, you,

01:01:13.378 --> 01:01:16.063
you, you can contact either of us and we help you further.

01:01:17.252 --> 01:01:21.817
Right. So you two are the point of contact for Erlang

01:01:22.074 --> 01:01:25.679
ecosystem security. Basically. Related questions.

01:01:25.808 --> 01:01:29.490
So you two are, thanks again. I think, I feel like I say this

01:01:29.990 --> 01:01:33.588
every episode, but thanks again to you both for the hard work, 'cause it's not,

01:01:34.322 --> 01:01:37.548
it's, um, I, I remember it was

01:01:37.644 --> 01:01:41.353
after ElixirConf EU and we were sitting in the,

01:01:42.220 --> 01:01:45.479
um, the hacker room, hacker apartment.

01:01:45.688 --> 01:01:49.123
Yeah. The hacker apartment from the Ash folks. And,

01:01:50.167 --> 01:01:53.233
uh, you're just like, hey, I just threw Claude to go

01:01:53.733 --> 01:01:57.022
scan, I think it was Decimal. Yeah. And you're like, Decimal,

01:01:57.086 --> 01:01:59.864
there's actually a vulnerability here. It can crash your system. It's a big one.

01:02:00.137 --> 01:02:03.283
Then you ran it and then it crashed your system. Yeah. It had like 8

01:02:03.331 --> 01:02:04.182
gigabytes of RAM.

01:02:06.383 --> 01:02:09.421
Yeah. But I don't know. I mean, to be honest, I see this whole work

01:02:09.921 --> 01:02:13.359
as one contribution to the ecosystem, right? It, like, there are many different

01:02:13.859 --> 01:02:17.126
ways of contributing to the ecosystem. The most obvious one is writing code

01:02:17.626 --> 01:02:21.046
and releasing it and helping others use it. But also what I'm doing,

01:02:21.159 --> 01:02:24.514
scanning stuff and reporting vulnerabilities, is another way of contributing,

01:02:24.788 --> 01:02:28.137
you know? And then you have brilliant people who write blog posts about what they

01:02:28.153 --> 01:02:31.518
work on. I think that's also a great contribution to the ecosystem.

01:02:31.566 --> 01:02:35.366
So. You know, just because I'm doing this doesn't mean that this

01:02:35.866 --> 01:02:38.906
is the only way of contributing, like by far not. Of course.

01:02:40.172 --> 01:02:43.777
Of course. But it helps everyone. So we need

01:02:44.277 --> 01:02:46.917
to make sure that we let you know how thankful we are for it.

01:02:47.077 --> 01:02:50.345
So yeah, thank you. Just don't, don't be

01:02:50.845 --> 01:02:53.726
mad at me when I approach you about a vulnerability that, that helps me the

01:02:54.226 --> 01:02:58.068
most. Nightmare scenario, getting a cold outreach

01:02:58.180 --> 01:03:01.112
from Peter. Yeah, I know when people get Slack messages from me now,

01:03:01.304 --> 01:03:03.467
it just says, hi, like They're ready.

01:03:04.695 --> 01:03:06.425
Their heart rate goes up a little.

01:03:10.429 --> 01:03:13.968
Yeah. All right. Well, Peter, this has been a fun discussion,

01:03:14.385 --> 01:03:17.904
but unfortunately, I think you have things to do. I have

01:03:18.000 --> 01:03:20.641
things to do. It's been more of an interview than a discussion, but maybe next

01:03:21.141 --> 01:03:24.179
time we have something actual to discuss again. Fair enough.

01:03:24.309 --> 01:03:28.153
Yeah. Well, with that, thank you very much everyone for staying

01:03:28.348 --> 01:03:31.292
until the 1-hour mark. As always,

01:03:31.789 --> 01:03:34.888
thank you for listening. Subscribe if you haven't,

01:03:35.241 --> 01:03:38.901
and otherwise we will see you back in 2 weeks, which will

01:03:38.949 --> 01:03:42.578
be after Codebeam Europe, I believe.

01:03:43.701 --> 01:03:47.394
So we'll get a little bit of a conference report. You're going? I'm going.

01:03:47.442 --> 01:03:51.070
I'm speaking on the 22nd together with Jonathan about our work

01:03:51.134 --> 01:03:54.265
of vulnerability research, vulnerability work at EFF.

01:03:54.907 --> 01:03:58.545
So I'm there. If you're there too, You know, say hi to

01:03:59.045 --> 01:04:02.415
me. I'm approachable. I like talking to people. So just, you know,

01:04:02.690 --> 01:04:04.909
say hi. Don't be a stranger.

01:04:08.100 --> 01:04:11.831
And then see you in 2 weeks again. Thank you for tuning in. Bye-bye.