Essential Tools, Updates, and Strategies in Rails Eight with Greg Molnar - RUBY_671

In this episode of Top End Devs, we dive deep into the realm of security within the Rails ecosystem with our guest, Greg Molnar. Known for his expertise in this field, Greg joins our panelists Valentino Stoll and host Charles Max Wood to unravel the intricacies of security measures and updates in Rails 8 and 7.2. From exploring built-in features like rate limiting, authentication generators, and parameter filtering to discussing the importance of tools like dependabot and Brakeman, this episode offers a comprehensive look at how developers can maintain high-security standards in their Ruby on Rails applications. We also touch on practical strategies for handling authentication, authorization, and the evolving nature of security challenges developers face today. Whether you're a Rails veteran or new to web development, tune in to gain valuable insights into creating secure applications with ease.

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

Episode Transcript

Speaker 1 (00:04):
Hey everybody, Welcome back to another episode of the Ruby
Rogues podcast. This week, on our panel we have Valentino Stole.
They know. I'm Charles Maxwood from Top Endevs. We have
a special guest this week. It is Greg Monar. Greg,
we've had you on before. But how are things in
the middle of the Atlantic?

Speaker 2 (00:25):
Hi, guys. Yeah, all is good. Still, We're still alive
in the middle of the ocean.

Speaker 1 (00:33):
The island's still upright, so things are good.

Speaker 2 (00:36):
Yes, yes, shitty leather sometimes, but yeah. It's been that time.

Speaker 1 (00:41):
I heard a clip not that long ago. It's an
older clip, but it was a US congressman that he
was interviewing a general or an admiral or something, and
basically he was talking about Guam and he said, well,
are you worried that the island is going to capsize?
And the general with the straight face, right, because they

(01:04):
have to have some decorum in there and they don't
want to tick off the congressman. He looks at him
and he goes he goes, no, no, we don't anticipate
that didn't capsize.

Speaker 2 (01:17):
No, no, And the math it's supposed to be done
for a few years now and it's still there, right,
So I don't know what are these forecasts about.

Speaker 1 (01:24):
Yeah, all right, well we brought you on to talk
about security in Rails eight. I don't even know where
to start. Did a whole lot change or is it
mostly the same as seven point two?

Speaker 2 (01:40):
Well, yeah, there are a bunch of things which are
seven point two. But I think the imitation was triggered
by my talk at Rails fird Yes, which was tied
to the state of security in Rails eight. But some
of the things I mentioned were actually Rail seven point two.
But I think it was still worth mentioning those because
a lot of people don't even know about those new

(02:01):
features which were three years old back then, and Rail
say it wasn't even know it really is at the conference.
So it was a bit of a ah a pre
planned talk.

Speaker 1 (02:15):
So so yeah, so where do we start then?

Speaker 2 (02:19):
Well, I can just list out the things which I
was talking about. If you guys are that, you can
go through all of those and you can ask questions
and we can sound So one of the first things
I mentioned during the talk was every new rails app
this is a seven point two feature. Every newly generated
Rails application has a default depend about GitLab CI file,

(02:42):
which means if you are using not gitlabs for GitHub,
if you're using GitHub, then on your CI automatically runs
depend about, which is a dependent vulnerable dependency checks. So
if any of the gems you are using has a
vulnerability public, then you are getting alerted and then you
can just upgrade and save yourselves from any hustles and

(03:07):
so good.

Speaker 1 (03:08):
Yeah, I think yep, Well, I was just gonna say
some people. I think most people know what depend about
it is. But effectively you get poor requests if you
have vulnerable versions of your dependencies.

Speaker 2 (03:22):
Yeah, or even for outdated bones. That's why I don't
like dependabo. Actually I prefer bundle oud it, but it's
basically it's very similar thing. But bundleoud it only alerts
you about security issues, whereas depend about I think you
can configure it depends a but also alerts you're about
outdated ones. Where usually my way of when I work

(03:42):
on the rest, my way of handling upgrades is it's
like on a regular basis, like every three months. That
is like a spike update all the dependencies. But secretary
dependency is a different. Secrety issues are different. Obviously, you
want to upgrade them immediately. But the rest I don't
really care when a new GEM comes out. If it's
just a non security issue, I will update it when
I do my regular upgrade upgrades.

Speaker 1 (04:06):
Right, that makes sense. I do the same thing because
a lot of times you're you're upgrades. If it's a
major even sometimes a minor version, you know, it changes
the API. Right, It's not just oh, hey, you're going
to upgrade this and you're going to get security goodies
right now. You may have to pull a major minor
upgrade version because because there is a security issue and

(04:30):
they didn't fix it in the version you're using, in
which case, yeah, you have to go through the upgrade
rigmarole and update your code as well as the gem.
But yeah, I'm with you. I tend to tackle those
things when I feel the need, right. So sometimes legitimately
it's like, hey, there's a new feature in this that
I need yep, But if it's the older version, how

(04:54):
do I put this? I've been having conversations with people
about like AI in programming, and it's like, hey, look,
it makes you more effective in all of these different ways,
and a lot of people are asking, is that going
to replace programmers and I'm like, have you ever met
a have you ever worked on a project that ran
out of things for you to work on? And the
answer is you might have had a side project that
you decided was done right, And so with this, it's

(05:17):
the same thing. It's like, okay, until it's a real
high priority, there's just no reason to do it. And
so I'm with you on that.

Speaker 3 (05:25):
Yeah, Yeah, it's funny.

Speaker 4 (05:27):
I've been trying to push people to just like bundle
update patch on like every deploy because like the chances
of something going wrong in a patch release is like
so low that like you've gained so much more by
like all of those security enhancements and like fixes in
a patch little version that it's almost worth just like

(05:47):
doing it if the test pass right, Like, yeah.

Speaker 1 (05:50):
So what does bundle update patch do Because I've used
like the pessimized gem that locks in your version right
and let's you upgrade from there.

Speaker 4 (05:58):
Yeah, so bundle bundle update tool it has like a
way to give it different flags of like, so it's
a canonical version to all the Ruby gems typically are,
so as long as the gems in dependency's using our canonicals,
meaning there's like a patch level a minor and a
major version to it, then you could just say, okay,
give me only the latest you know, patch updates. And

(06:23):
like people I feel like as at least for like
everything that reels would touch, Like the gem maintainers of
those are very careful about what to release in a
patch version and not like cause any issues because like
they don't want to deal with all the issues that
come from that, right, Like I'm not being like, oh, hey,
like I have like this new like obscure thing, like
they would rather just like, okay, let's make it minimal

(06:44):
and then you know, in a minor major version, like
it's to be expected, right, We've outlined these things that's
gone through the process. But a patch version like it's like, hey,
we fix this thing as serious, Like you should really
integrate this.

Speaker 1 (06:58):
Right. So if I have in my gem file just
sidekick and I didn't specify a version and there's a
major version update, I can do bundle update with patch
flag and it'll just update it to the highest patch
version and it won't do a major update.

Speaker 3 (07:15):
It won't do it won't even do the minor right,
so it will keep it.

Speaker 4 (07:18):
If it's like three point two, it'll do that and
then just like pump it to the latest one, which,
to be.

Speaker 3 (07:22):
Honest, doing that with Rails maybe a little trickier because.

Speaker 1 (07:26):
It does like, yeah, Rails is fine.

Speaker 4 (07:27):
You know, it has so many patches that get released,
so if you like fall behind, but like that's why
you're like, if you're deploying a lot anyway, right, Like
then like getting Rails to update itself incrementally as it
gets updated at a patch level is not going to
be so bad. And a lot of times, you know,
if you have a good test case, which you know,
let's hope everybody does, but like if you don't, like

(07:49):
obviously maybe you don't want to build this into your
deployee process. But like, if you have a good like
test infrastructure, like doing a patch update, like it's gonna
be almost nothing and you'll catch most of the issues
in any of the test files applications.

Speaker 2 (08:06):
What if they deplicate things in a I know it's
shit they shouldn't, but sometimes they do, and then your
logs are littered with all of the deplication warnings, right,
and then you're.

Speaker 4 (08:16):
Like, I mean, personally, I would rather have it be
secure than like, uh, you know, worry about all the
proposity of the outputs, right, Like I feel like, you know, yeah,
littered logs is not great to deal with, but like
it's honestly better than the alternative of having like a

(08:38):
security hole and then like getting like you know, page
your duty in the middle of the night, like, hey,
somebody took advantage of this. We need to like start
an incident response, right Like, yeah.

Speaker 2 (08:49):
But that's why you should use bundle audit or depend
on what we the security updates, because then even though
it's a patrities, you will notified that this is an
important paturities you need to do this upgrade.

Speaker 4 (09:02):
Yeah, So I'm curious what your thoughts are there, Like
is that the best like approach still today is like
using the audit feature, Like what is your workflow?

Speaker 3 (09:13):
Like, look like that's.

Speaker 2 (09:14):
What I use. It's running on CI and it's running
also in development in a git hook and then it's
just you not divide imitated also on cil of people.
What they forget is they sell it up to run
on the Magic Quest or Poor Requests, whichever geitos they use,
but they don't run it daily on the master or

(09:35):
main branch, which is if you don't deplay every day.
If you don't match requests every day, then you might
not be notified about an important secretaries. So it's a
good idea to actually the way I sell it up,
if I have the chance to set up anywhere, run
it twice a day on the master branch, and run
it on every poor quest MARGC quest M because then
you all anyways also like weekends, so if it's on

(09:58):
a weekend, really something on a Saturday, you don't getting
notified if you.

Speaker 1 (10:05):
Right, and it'll it'll fail the build if if it
doesn't pass the audit right.

Speaker 2 (10:12):
Yeah, and if it fails a musta but you are
don't expect the old day, we'll get an need imlification
or whatever you set up and then you know that,
oh I need to look into this because something is up.

Speaker 1 (10:24):
Makes sense.

Speaker 4 (10:26):
Yeah, I'm just waiting for the day to have like
you know, reels autopilot just automatic like if you have
like a bunch of hobby projects that you're just like, oh,
like I'm not going to spend any time on this
for six months, like just like automatically merge any updates
as it comes and like resolve itself, Like oh I
would love that and then just come back and then
you know, if when I'm ready to work on it again,
at least it's up to date and I can like

(10:47):
resolve any issues that there are. Right, But you know,
every single time I go back to a hobby project
and I'm like, shit, I can't spend any time on
this because I gotta spend the time update again, and
then I lose that.

Speaker 2 (10:58):
Like you know, uh, you should very depend I think
dependab What doesn't You can set it automatic? Yeah you can.
You can, yeah, yeah, for for a patch level, and
maybe you can do it for mine, and maybe you
can do it for every level. I don't know, but
you can do it for sure, and then yeah it
is everything. Things might break because you might not get

(11:21):
it with the test, but there is you never know.
I don't, right, I don't. Maybe it's just me that
this is why I also don't trust AI. It's I
just I trust humans more for some reason, there's some
human oversight. I trust that process like an order of
magnitude more than if it's just something wholly automated.

Speaker 1 (11:41):
Yeah. I think it's getting better, but I don't blame
you there.

Speaker 4 (11:45):
Yeah, yeah, I've been liking the review process so like automate,
but review, so like you know, well, all just like
set out a plan and then like the okay, I
executed all the plan and then notify you okay, review this.
I did the things right right, and then if you do,
like decide not to review it, like okay, Well that's
the same as like working with a coworker that did

(12:07):
the same thing right and you didn't review it and
they did it anyway right.

Speaker 2 (12:11):
Yeah, definitely, But also from a human I expect more
than from a So with AI, my issue is that
I write a piece of code, right, I asked him
can you refractor this to me? It speeds back a
bunch of changes which I need to review. And if
I ask a junior developer can you work on this feature?
They work, They submit to polly quest and if they

(12:34):
are uncertain about some things which they did, they will
highlight that here is my polly quest, but I'm not
really sure about this part. Can you review that more totally?
But yeah, doesn't do that. It's confidently saying this is
the solution, and they are like, okay, it's like fifty
lines of changes. Am I going to focus on each
fifty line?

Speaker 4 (12:54):
You bring up a great point maybe what we're missing
is a junior AI right, like that has it in
I am not confident, I don't know what I'm doing.
And then IT can, you know, be maybe a little
more cautious.

Speaker 3 (13:08):
I think you're onto something there or.

Speaker 2 (13:10):
Vey or vade what it gives it, because it can
be confident about some parts which are like basic or
or it knows it too well. But if you are
a little bit uncertain about something, highlight that, so I
carry you that more.

Speaker 1 (13:24):
Yeah. The issue that I run into though, is that
a lot of times what I get back from AI,
I'm not confident that A it would flag the right
things or B that a lot of times I get
code back that it's like it's like, yeah, like the
general structure as far as like I have to loop
over these things, or I have to make this kind
of a request or you know, call into this API

(13:47):
is generally correct, and then the rest of it it's
it's it may as well have written pseudo code, right,
And it's like it's like you guessed at the method
name instead of looking it up what a human would do,
they'd go look it up. How do I whatever? Anyway,
we're off on a tangent I want to get back
to security. So so the catabot is in there by default.

(14:14):
You can use bundle audit if you want instead and
put that into your CI.

Speaker 2 (14:19):
What else do we get on the change is really
similar is Brakeman. It's also got a default CI file.
So Breakman is a static code analyzer for security issues.
It basically highlights code spots where you might do something
which is insecure. I think that's also a great addition.
It gives you false positives, you can ignore those, but

(14:40):
it at least makes you aver of certain things. That
saves you from sidy mistakes. It's so easy to make
a silly mistake which you don't realize you use an
insect an API and insecure way because you just forget
about something, and it just saves you from those issues.
I think that's also a great change or great addition.

Speaker 1 (15:00):
The thing I like about Breakman is that, yeah, it
gives you false positives, but like all of the commonly
understood bad things you can do, or the the traps
that you more easily fall into, it's got all of
that in there. And so yeah, I might give you
a false positive and say this is insecure, and you
look at it and you go, no, I'm not doing
what you think I'm doing. But it catches the really

(15:22):
easy dumb stuff.

Speaker 2 (15:24):
Yeah, yeah, definitely. And the next one is which is
a new feature in this it's the rate limiting, the
built in rate limiting. Sure you guys heard about that one.

Speaker 1 (15:37):
And I don't know how many times.

Speaker 3 (15:41):
But I don't know how many times I'm built rate limiting.

Speaker 1 (15:45):
I've got an app that I want to build to
replace a process we went through last year. It's part
of my political stuff, but letting people register for our
caucus night in Utah, we get we having like nine
hundred thousand party members that are eligible to attend our
caucus meetings, and we got ddasked last year by somebody

(16:08):
who doesn't like the party. And so I'm wondering if
something like this will help.

Speaker 2 (16:14):
It could help, but it might not have for a
DDA setech. I think it's a you would need something
like cloud fare, which.

Speaker 1 (16:21):
That's what That's what I'm seriously looking at.

Speaker 2 (16:23):
But yeah, so for what this one is good for.
The thing this one is good for eight limiting is
save you from creditial stuff in attacks. For instance, you
know when there is a league password database, and then
a malicious ouctors will try to use all of those
logging details on your side to see if the same
person has an account with the same credentials and then

(16:44):
they oh, I gotcha, and then they can take over
doct and do whatever malicius things. And in my talk
I highlighted a few examples from it's actually now the
three years ago from twenty to twenty three, it was
the year before, like twenty three, and Meter the DNA
they analyze this side, they had an issue with this. Also,

(17:06):
General Motors had a big issue. They had a bunch
of account taken over and like Credit partially credit card
details leaked, and Roku the streaming platform also had like
half a million of their users access details were leaked
because of our credentials stuff creditial stuff in attack. So
I think there's a very good addition trails to prevent

(17:28):
all of these issues. We already had wreck attack, which
is a jam. It's a very old jam, but a
lot of people don't know about that. And this is
why I really like these changes in rails because once
it's in rail score, a lot of people are becoming
aware of these issues, which they these too solve and
it might not be the best for that team or
that person, but at least now they are oh, I

(17:50):
need to think about credential stuffing, and then they find
out a solution which works for them.

Speaker 1 (17:56):
So is this in RAILS seven to or is this
in Rails eight.

Speaker 2 (18:00):
It's in Rael seven too. It got some improvements which
only landed in Rals eight. And it's really simple. You
add a single line to your controller and you just
set the You set that the two parameter, which is
how many requests you want to allow, and you set
the wedding, which is like the timeframe. Let's say you

(18:21):
want to allow ten requests within ten within three minutes
from the same user, and then that's it, and then
you have great limiting. You can also configure which actions
you want it to be called on. It's like a
before filter in the control aft. You can set if
you want to exclude any actions or if you want
to include only set in actions. You can also configure

(18:44):
a custom response because by default it raised a four
to nine header, and then you can change that and
just redirect to a page, display a message or whatever
you want to do. Also another important thing to mention initially,
but the first implementation used reddis but then it's been

(19:06):
rewritten and now this storage the back end is any
rare cash compatible storage can work, so you can use
the solid cash or whatever you want and you don't
need to you don't need to have reddie as a dependency.

Speaker 1 (19:25):
I love that move away from reddis.

Speaker 4 (19:28):
The storage patterns across the border just really great to
see it become more cohesive. I really like this byeline
to give it a product and say like, hey, you
know rate limited, biop or whatever you want to filter
scope to.

Speaker 2 (19:45):
Yeah, if you would want to have something like cloud flare,
you could achieve that using that parameter. So you would
set a cookie and then you would rately meet by
that cookie, and then you can handle more propell adidos
attack as well. Otherwise, if you do it by the
ip adidos is usually they use a whole range of ideas.
It's one client, so if you set a cookie on

(20:07):
that client, then you can identify the same client from
a different idea.

Speaker 1 (20:13):
Yeah, I'm liking where this is going for sure. I
think cloud flare is probably the best answer for what
I'm looking for, but I like this to manage your
credential stuffing and things like that.

Speaker 2 (20:27):
Yeah, my only problem with cloud Flare. I love them.
They're really cool. It's very cheap, but I think now
they are swallowing a big part of the Internet and
maybe one day they will say, Okay, now we are
greedy and now start an extortion amount on everybody. Let's
hope they never do this, but it happened before, and

(20:49):
they might say, yeah, now we want all the money
and now you rely on us. There is nowhere else
to go, or the small competitors are gone and I
need to pay us a lot. But let's hope they
are not going to do that.

Speaker 1 (21:04):
Yeah.

Speaker 2 (21:07):
Cool. And so the next thing I mentioned in the
talk was the new authentication generator in rails.

Speaker 1 (21:14):
Oh I love this.

Speaker 2 (21:16):
Yeah, well, we had another one before. It's called Authentication zero,
which is wasn't in reels. It was done by forget
the name of the guy. He's a Brasadian guy. I
probably can't even pronounce his name properly. Lazarro Nixon, I think,
or something like that, but I'm sure my pronunciation is
not correct, So sorry.

Speaker 1 (21:37):
For Yeah, it was an awesome project.

Speaker 2 (21:40):
Yes it's still it's still a great project and it
does more. But the building in Rails generator. But the
thing is, even though the generator was there, other people
don't know about it. Now that res has a built
in one, a lot of people are ever, oh, we
can have an authentication generator, and they might say the
build in Rails, but is not for me that they
find the other one or other alternatives. So this is

(22:03):
why I love getting these features into Rails. And the
building one in Rails doesn't have registration and what else.
It doesn't have a few features which you would expect
from an authentication flow because I think the reason for
that is the core team believes that they are custom

(22:24):
for applications usually like sign up. It might it's very
different for all of applications, so they expect you to
implement that on your own. But this authentication zero, for instance,
it generates all of those parts as well. If you
are into a fully flashed you just want your own code,
the code to sit in the repository, but you don't
want to write a line of code. I think that's

(22:46):
a better option. If you want to have something custom
and use just Rails generated stuff, then go with the
built in Rails one.

Speaker 1 (22:55):
Yeah, I'm working on a generator of my own that
will generate the views. I don't like the views that
I got when I ran the rails generator, But yeah,
I mean just it's it's basically I would like to
build the tool build things that run on top of
the built in rails generator because I think it does

(23:15):
a really good job.

Speaker 3 (23:17):
Yep, I'm curious here.

Speaker 4 (23:19):
I love your insight, Greg, I know it's it does
like passwords as like the default for the generation. Uh,
how do you feel about you know, passwords with users?
Like I know there's a lot of talk around this,
like do we go password lists pass keys for the
future for a bit, like you know, where where do

(23:41):
you see like the industry like coming together or is
it still kind of like a little bit uncertain.

Speaker 1 (23:48):
Or the oaths that's the other one. Somebody else is
managing your credentials and SAP or whatever it is. You
have a token from them and you authenticate them on
the token.

Speaker 2 (23:59):
Yeah. I on both of those cases, I think I
might not be the mainstream with my opinion. So for
pest keys, I love peskys. I use a ubiki for
two factor authentication. I think it's amazing for that because
for that you can have multiple options. For instance, I
have a Ubiki, but I have two laptops, so sometimes

(24:19):
I don't have my Ubiki with me, and I have
two Ubi keys, but I keep on as a backup
at home, so I never really that's not in a laptop.
That's just if I if my brakes, I can use
that one. So I have multiple authentication two factor autification
set up at most services. I can use my phone
within the app on my phone, or I can use
the Uiki, which is much more convenient when I'm at home.

(24:40):
I just touch it and then it's done. But for
whole authentication, I think there are a bunch of things
which are not so easily resolved, like what are you
doing with the logging in on your iPhone and on
your Windows laptop with the same pestky because you contantly

(25:00):
transferred between divis. You can if you're on iOS and
Mac with everything, it's it's amazing, it's fine, it's convenient,
everything is in the whole ecosystem. But what if you
have an Entrade phone and the MacBook or it's not
so easy to transfer your credentials between different services. That's
my main problem with pastkis. It will be probably solved
eventually in the future, then I will be all for paskis.

(25:23):
But since then, I think it's not so easy to
handle all of those edge cases.

Speaker 1 (25:31):
Yeah. One thing that I'm wondering that along the lines
of what Valentino's asking though, is that it seems like
when folks credentials get compromised, it's it is the password, right,
It's hey, here's a username and a password that'll get
you into the website. So do you favor more passwordless options?
I mean, that's what the past key is. But you've

(25:53):
also got like magic links or you know, hey, here's
an email and we're going to send you one time
password or any of that. Like is that any more
secure or is that just an illusion?

Speaker 2 (26:04):
In my opinion, not at all, because if I get
access to your email account, I have the keys to
all of your accounts, right, But usually so it's not
that clear because also if all of the sites you
signed up for support a password is set by email,
then I can also take our right. So I think
the solution for all of this is multi factor authentication,

(26:27):
because even with pest keys, what if my laptop gets
stolen and store in the state when it's open, and
then they have access to all of my all I have, right,
Usually this is why it should be something you know
and something you have access to, because my one password
shuts it down after five minutes or whatever. If someone

(26:48):
gets access to my loptop, they can't get access to
my passwords. They can access to my ubiki because it's
plugged into the laptop, but they don't have the passwords.
So I still have two things which they can only
get one of them, save me the email. When someone's
exited the email, they can take over your raccon. But
this is the same if it's only pest words, So

(27:09):
just pestwords on their own. I don't think they are
good enough.

Speaker 1 (27:14):
So the other piece of this for me is how
do I put this. I'm super cheap, and so like
Riverside for example, right, I could set up an account
for every single one of the hosts to be able
to start the podcast, but realistically that's a lot more

(27:36):
expensive than setting up, you know, a couple of generic
host accounts. But then you know, how do you set
up third party authentication for shared accounts or two factor
authentication for shared accounts? That that's been the rub, right,
and so I tend to not turn it on and
then essentially just trust the people that I've shared the

(27:58):
password out to because I don't have a better way
to do it.

Speaker 2 (28:02):
You can do that. Actually, so I'm working on something
with a team where we have the same problem and
the wave has resolved it. You know, if you set
up two factor authentication with an authenticator app, it's just
you just need a seed and it generates it token
based on that seed. So we have that saved and
whenever you want to share that to favor with someone,

(28:23):
he gets the seed and he can have the same
setup on their phone. And then you have authenticate po
multiple devices for multiple people so they can still have
the second factor.

Speaker 1 (28:36):
That makes sense.

Speaker 3 (28:37):
That's really cool.

Speaker 1 (28:39):
That's that's been the piece that I've been missing is Yeah,
it's like, okay, how do I share the second factor
of two factor authentication?

Speaker 2 (28:46):
Or you can go down the other way, which I
don't recommend, but it's quite popular. You use something like
one password where you can share.

Speaker 1 (28:55):
That's essentially what I've been doing because I've been sharing
the password out of one password.

Speaker 2 (28:59):
Pro and with dead then it's not too factor because
you have the password and the second factor at the
same place. Anybody gets access to that one, they have
everything they need to look I like to separate these
the factors from each other.

Speaker 1 (29:14):
Well that's the whole idea. Yeah, and may have preempted
other questions from Valentino, so I'll let them keep.

Speaker 2 (29:23):
On the topic of outsourcing your authentication. I don't think
that's a good idea. Actually the Q and A somebody
asked me about this, and Octa is one of very
popular service for outsourcinger authentication.

Speaker 1 (29:36):
Octa and zero but at zeros owned by Octa these days.

Speaker 2 (29:39):
So yes, So they had breaches in the past, and
they just had a breach after my conference talk again,
not a bridge with a security incident, but they had
a proper breach a few months before the conference, And I.

Speaker 4 (29:53):
Think, yeah, i' kind of like the approach like single
sign on took in that. It's like, at least there's
a rollover approach, right, Like, Okay, if they if you've
been identified of a breach, like you can invalidate everything
that's in that, right, But.

Speaker 2 (30:16):
If you're a past word nagin and you have unique
pestwords everywhere, if you are in a bridge, it doesn't
really matter because they don't have the old.

Speaker 3 (30:22):
Password, right, That's true.

Speaker 2 (30:24):
And my problem with UKTA is their altitude. I think,
even though they are a security company, they are more
money and profit oriented than security oriented. That's what I
see from their behavior. They might not like that opinion,
but that's what I see, and I think they they
care more about sales than actually making a security and

(30:46):
you can see that from the secretitysies they had in
the past, because some of them is I don't want
to be rude, or just because everybody makes mistakes, but
some of it you wouldn't expect from a security company.

Speaker 1 (30:57):
Yeah, I will say so. When I started building top
end devs, I was using off zero and I had
two problems. Well I had more than two problems, but
a couple of the problems came into if they were down,
I was down. It was one right because nobody could
authenticate Y. The other issue that I ran into was

(31:18):
it was way more complicated than just allowing people to
have passwords in my own system using device or you know,
building my own these days, I just rolled my own.
I used the Rails generator and then I just put
what I want on top of it and so so
it was just overkill. And then the last issue was

(31:42):
I mean literally literally anytime I had any kind of
problem like it. Yeah, it wasn't just the complications, and
it wasn't just that I was down when they were down,
but but there were some other issues within just the
way that I had things set up, and it was
easy to fall into those problems and it affected everybody.

Speaker 2 (32:03):
So anyway, and sometimes if there's an issue, you can'try
solve it because it's out of your hands. It's the
way you implemented their integration.

Speaker 1 (32:13):
But they do a lot of things for you too,
so you know, they do some level of authorization. They'll
handle the third party like Google and Apple and Facebook,
you know, whatever whoever you want to let people log
in with gethub like, they do all of that, and
so you don't have to go and jump through the
hoops with an omnios right there. There are reasons why

(32:36):
people go for it. You know, they're probably a little
bit better at security than you are. But you know,
as you're pointing out, Greg, yeah, you may not know
the issues that they actually have because you're outsourcing it
and trusting them instead of being in your own system
where you can audit and verify it. So exactly, anyway,

(33:01):
I see people use it. They seem to like it,
but I think it's for those bigger apps where you're
really looking for that enterprise level set of features. For
the things that I was doing, it just didn't makes sense.

Speaker 2 (33:16):
Yeah. I also think it doesn't make sense for most organizations,
but probably it does for some. I don't know. But
even then I wouldn't go with doctor for shure. I
haven't heard of Old zero, which is probably a good thing.
Probably they didn't have any bread Cheese.

Speaker 1 (33:31):
Acquired zero like three or four years ago.

Speaker 2 (33:34):
So oh so it's basically the same company.

Speaker 1 (33:36):
Now it's more or less the same company. But for
me and I think this is what you're saying too,
is do your due diligence if you're going to pick one,
and make sure that you know why you're going that
way as opposed to building yourself.

Speaker 2 (33:54):
Yeah, definitely. And one more thing I wanted to mention
about the Rails Authentication Generator is the reason I really
like this one because res has a bunch of helpers
which people don't know about, like has secured password. All
of these new secure token generation methods and validation.

Speaker 1 (34:14):
Methods are so nice. Use them for here. So I'm
going to back up for a second, because I love these,
so I use them for all kinds of things. Right,
People people think, oh, I have a secure token generator.
That's you know, so I'm gonna put it in my cookie.
Is some kind of authentication key or you know, I'm
going to use it for this other ath and that
other ath. But you can generate keys for anything, and

(34:37):
so I've been using it. I'm trying to get to
the point where I'm running my own premium podcast feeds,
and it's like, hey, look, if you donate to the show,
you'll get you know, ad free stuff, right, and so
you can generate tokens for that. You can generate anyway.
I don't mean to derail, but this is a really
really handy feature. And if you if you need something

(34:59):
that not guessable, then this makes it really easy to
do it.

Speaker 2 (35:05):
Yep, and verified. It's just built in. It's just super
easy everything. Yeah. Yeah, And I think that's why it's good,
because you generate your authentication system and then you read
through the code and you learn from it. You just say, oh, yeah,
what is this helper? Never heard of this? I think
this is also why it's good to have this. It's

(35:25):
just traises, awareness of seftain Rails helpers and features which
people wouldn't know about otherwise probably yep. And then the
next thing I mentioned the talk is it's not really
a technical change, but it's an important change. It's Raels
has a new maintenance policy, which is I need to

(35:48):
read this because I can't say that tell it from
the top of my head. So every minor releases we
receive security fixes for two years after the first ree
is in its series, which means practically, if one point
one point zero is really is January first in twenty
twenty three, if we receive secretary fixes until January first,

(36:08):
twenty twenty five, after that it will reach its end
of life. So it's I think the maintenance period became shorter,
which means that you should everybody should take upgrades seriously
and don't stay on all versions of Rails because it's
just it's not going to get secretary updates. They make
exceptions sometimes, but you shouldn't rely on that. In my opinion,

(36:32):
you should make sure your apps are up to date.

Speaker 1 (36:36):
Yeah, I think a lot of things have changed on
that front. Two though, because I've worked on a handful
of apps for clients where I had to upgrade from
saying rails four or Rails five, right, and those upgrades
were often rather painful for one. And the other thing

(36:57):
is is that, yeah, it's just you know, it was
kind of a giant thing and you had to take
it on and you know, the maintenance cycle on things. Anyway, lately,
with everything pasted about Rails six Rail seven, for sure,
like the upgrades have not been nearly as bad. And

(37:21):
so I, you know, you're mentioning the maintenance cycle, and hey,
this encourages people to upgrade, and you know, maybe you
have a different window to get security patches and stuff
like that. But the other side of it is is that,
like I have a whole bunch of Rail seven two
apps that I need to get around to upgrading to

(37:41):
Rails eight, and I've kind of been waiting for like
a couple of patch versions to come out, right, so
that whatever issues everybody else is finding, good on you folks,
and I really appreciate the work you're doing and you know,
and then I can go pick them up. But yeah,
I from what I've seen like seven to seven to
one to seven, two to eight, they really haven't been

(38:04):
that bad. And so you know it's okay. I'll spend
a few days on this or a week on this.
If it's a really big app maybe it takes longer.

Speaker 2 (38:12):
But yeah, yeah, it's much better. I did Trails two
to three upgrades as well, two point three to three.
That was a big thing about it. A little bit easier,
four to five, a little bit easier from five on.
I think, yeah, it's much easier. It's except when you
go rails eight, you need to ask yourself the question

(38:34):
what am I gonna do with the front end stuff?
Are you gonna keep that pocket or are you killing it?
Because then it might be a bigger change.

Speaker 1 (38:42):
Yeah. The prop shaft, yeah, prop shaft, prop shaft, and uh,
you know all the stuff that's there. The way that
Rails eight and Rail seven two, frankly, in a lot
of ways handles the front end stuff. It is. It
is so nice, you know, I don't I don't miss

(39:04):
what it'sprockets don't miss Webpacker. When I moved off of Webpacker,
I wanted to throw a party because it was so
much easier. I mean, the issue with Webpacker a lot
of people had was just setting it up and knowing
how to do it, but I found myself having to
tinker with it a lot, and so prop Shaft I've

(39:26):
just kind of said it and forget it. It's been
really cool and the.

Speaker 2 (39:29):
Build step is always like, yes, something faz At the
built step, it's like I need to deal with this. Yeah,
it was just slowing things down. I also didn't like.

Speaker 1 (39:37):
The important maps. I love them.

Speaker 4 (39:40):
It's funny you don't you don't realize how stable like
Rails and Ruby ecosystem has become because I mean going back,
like you know, upgrades, Like you know, I was thinking
of my first Raels upgrade. I did like a Rails
one app that was on Ruby one eighty seven, which
was like the nightmare Ruby upgrade because there were just

(40:01):
so many drastic changes, right, and so like I don't
think people realize like what the early stages of a
framework or a language are, right like, because like the
stability that we get now likes just a mind boggling
right like you know, yes, there'll be some depreciation warnings
and things like that, or like you know, the big
changes like are really not that big in like the

(40:23):
grand scheme of things, right, Like if you look at
like some of the other libraries out there, you're like,
you know, the whole like back end could get swapped
out and you'll be like, well, what do I do
with all this stuff I built? Like yeah, you know,
it's like incredibly stable now, so it's it's just wild.

Speaker 1 (40:41):
Yeah. Yeah. And for the record, when Greg was talking
about upgrading from Rails two to three to Rails three,
that was when they merged another framework called merbr into Rails,
and so there were just major major changes. I mean
a lot of stuff got a lot better, but the
upgrade was painful.

Speaker 2 (41:03):
Oct record was pretty much completely changed. It was a
lot of Yeah.

Speaker 4 (41:08):
That's a shout out to, uh to Machondra who like
maintains the Rails are lts.

Speaker 3 (41:15):
Oh stuff.

Speaker 4 (41:16):
Uh, if you're like honestly, if you're out there stuck
on a Rails upgrade and it's just like not worth
it to your business, like just pay the service. Rails
LTS long term support and it's just like they make
sure that like yeah, they give you the security patches
and uh yeah, we use that for a couple of
clients a long time ago, and it just like it

(41:37):
works incredible out of the box, like turn key.

Speaker 1 (41:41):
Yeah, we have to get them on and ask them
how that all goes.

Speaker 3 (41:47):
So long?

Speaker 2 (41:48):
Now, sometimes I'm sure it's very tricky to sow these shoes.
Sometimes for them, I wouldn't want to be in their shoes.

Speaker 1 (41:59):
Yeah, But the same time, I mean it's got to
be really because I just went to their page and
they have LTS versions for RAILS too crazy, and so
I'm going, boy, what what are you having to fix?

Speaker 2 (42:15):
You know?

Speaker 1 (42:16):
And how deep into the weeds do you have to get?

Speaker 2 (42:19):
Yeah, but from a security perspective, I think it's still
risky to be on the tour to measure because nobody
really tests. That's true thions. So there are no security
patches or security issues made public. There might be some
non public ones which people might abuse, you just don't

(42:41):
know about them. So I think it's because, like the
latest version of RAILS, a lot of companies are using
to get patrition tests, and sometimes issues are upstreamed from
the resort to a patration test. They find an issue,
it turns out, oh, it's actually an issue inside of RAILS,
so we upstream the patch and fix it for everybody.

Speaker 1 (42:59):
Yeah, that's true, But.

Speaker 2 (43:01):
Those old versions I think are not a good idea
to use. Even though you get some support.

Speaker 1 (43:08):
Yeah.

Speaker 2 (43:10):
Yeah. And then the next thing I mentioned the talk
is is a bit of a pretty small change, is
that CBV and CBC was added to the parameter filter defaults.
But the reason I wanted to mention that in the
talk is because a lot of people don't know about
the real parameter filtering, which is a very handy tool

(43:32):
to filter out anything sensitive from your logs. Like you know,
when a request comes in with a password in it,
you don't want that to show up in your logs,
or if you store social secretary numbers, you don't want
them to show up in your logs before you encry them.
And this feature is just amazing. For anything sensitive which
you don't want to be in the logs, you can

(43:53):
just study to your initializer and then it gets excluded.
These are the things which I also think rares excess
because a bunch of other frameworks don't really haven't an
easy solution for this problem. But Rasia is just out
of the books and for years it's it's amazing.

Speaker 1 (44:11):
Yeah. I did have this bite me in the rear
end once, but yeah, I agree. The way it bit
me in the rear end was I had a stripe
web hook key that for some reason wasn't being set
and it still showed it as filtered, and so I

(44:31):
didn't know it was empty until I actually like forced
it to log it out.

Speaker 2 (44:37):
Ah, I see.

Speaker 1 (44:38):
But yeah, this is definitely a best practice. And if
you get into like hipA or what's the financial one,
PCI or any of these, they they they will crucify
you on this stuff if you're not doing it. And
and the logs are usually an area of vulnerability that's.

Speaker 2 (45:01):
Overlooked, yep.

Speaker 1 (45:03):
And Rails does it by default for all the common
sense stuff yep.

Speaker 2 (45:11):
Yeah. And then the second half of my talk was
these are the new features, which wasn't that many, to
be honest, but still there are spilled small progresses and
that's all we need, I think. And the second half
I wanted to highlight to people why I think somebody
should choose Rails if they want a if they need

(45:32):
an application with high security standards. And my main reason
for that is there is a tool for everything you
would need in the Rails and Ruby ecosystem, like parameter
filtering which we just mentioned built into the framework, great
limiting now built into the framework authentication. You have device
and a bunch of other things, multifactor authentication, a bunch

(45:55):
of gems you can choose from. It's super easy to
implement all of these features or I have a list here.

Speaker 3 (46:02):
Or the other thing, which is scripting stuff.

Speaker 2 (46:05):
Oh yeah, yeah, you don't even need to think about it. Actually,
cross side scripting you need, but cross sideicquest forgery for instance,
it's just BILS the framework for I don't even know
which version, like LS it's forever. Yeah, it's so we
have a lot of things which you just get read
it for free and granted it's amazing, and other things

(46:29):
which are not built into the framework. Like if you're
talking about compliance, one of the the requirements to be
soked to or ISZO compliant, is that your developers shouldn't
access anything in production without you knowing about it. So
if you have a rogue employee, it's not like they
can just steal whatever they want. They still usually they can,

(46:52):
but at least you have an auditlog so you can
pinpoint who was the the malicious actor and there are
there is a gem from thirty seven Signals called Audit
nineteen eighty four and Console nineteen eighty four, which is
if you install that. Anybody who goes to the RES console,

(47:12):
they need to authenticate themselves, so they need to say
who they are and why are they accessing the data,
and then you have an audit trail. So whenever somebody
accesses production data, you have an audit trail. One important
thing to know about this, though, is it's advised to
store these data in a read only database. Sorry, I'll

(47:36):
write only database, so they can't. Nobody can update the data.
They can it only rights, but you can't update otherwise.
If somebody wants to be really tricky, they can just
Ruby is very dynamics. They can find a way. I
found a bunch of ways. But now it's much more
secure than the initial really was. You can find a
bunch of ways to treat the system and overrite existing

(47:58):
log entries. But if you store it in a database
which is only you you block update commands on the
database connection, then it's pretty secure and safe.

Speaker 3 (48:11):
When did they change that to ride only? That's really awesome.

Speaker 2 (48:15):
They didn't change it. You need to change that on
change yourself. Yeah, you can't. You can't build it into
the GEM because you do it on the database level.
If you build it into the GEM, then you can.
You might still find a way to override it. In Ruby,
because it's a super dynamic language, you can do things
that you shouldn't even think about. That's how I found
a bunch of things to over to bypass it. Ah.

(48:40):
But yeah, that's a really good tool for compliance reasons.
Also startic CAD analysis. That is breakmen. There are other
tools dependent vulnerable dependencies. We just mentioned bundle aud it
depend a boat and probably there are others as well.
CSP content security policies build into else opery directs OPERI

(49:02):
direct protection is deffault built into THEIRS nowadays. So you
have you have for every security requirement or need encryption
active record encryption. It's really easy to do now. You
don't even need to think about anything cryptography. It's just
you set your keys and you are good to go,
and everything is in gypted in the database.

Speaker 3 (49:25):
The only thing that's missing is secret scanning.

Speaker 2 (49:28):
Secret scanning you mean the repository.

Speaker 3 (49:34):
Like something like trouple hog. That's the best example.

Speaker 2 (49:39):
Uh yeah, Well, but you should do that on the repository,
and there are services or there are tools for that
for should even in Ruby. I don't know any from
the top of my head, but I'm pretty sure that
there are some.

Speaker 4 (49:57):
How do you feel about like storing encrypted real secrets
in a repol?

Speaker 2 (50:03):
As long as your master key stores safely, it's a
very hard to break encryption. It's quantum computing. We might
get into trouble in a few years, but until then
we are fine and safe. And then you figure out
how to have to save that. I'm sure not us,
but someone who's good with cryptography. Then you figure out
the way. But I think that's perfectly fine. You just

(50:26):
need to make sure your master key is safe and secure, right,
and then it also it simplifies the whole process. You
can use environment bariables, but then how do you handle
that during the deployment flow? How are you going to
pull those from secret storage? It all adds complications and complexity,

(50:48):
a lot of that.

Speaker 1 (50:48):
I've just been doing what Kamal does, so it just
sticks it on the container when it runs YEP and.

Speaker 2 (50:56):
Comera as good integration with one past word and others. Actually,
secret storage is like a bit bucket.

Speaker 1 (51:04):
I haven't used any of that because I'm the only
one that deploys.

Speaker 2 (51:08):
Yeah, then it's yeah, it's it's super easy. If it's
only you. If it's a team, it gets a bit
more complicated, but still it's it's not hard.

Speaker 4 (51:14):
So do you have like a a security checklist that
you run through for REILS apps, they make sure, oh
make sure all these things are.

Speaker 2 (51:25):
You know, not really to be honest, when I do
a penetration test, I have a checklist which I go through,
but it doesn't really depend on a rail step. I
have some rare specific things which I know I would
a real set then I need to check this and that,
But a lot of it is only in my head, to.

Speaker 4 (51:44):
Be honest, I mean to that point, like you know,
real is pretty secure out of the box, right, Like
it's not exactly difficult to you know, break that, but
like it's not easy either, right.

Speaker 2 (52:01):
Yeah.

Speaker 3 (52:01):
I feel like with the REILS new like it's going to.

Speaker 4 (52:04):
Be pretty hard to like do something insecure until you
start actually like you know, adding new things.

Speaker 2 (52:12):
Yeah, most of the vulnerabilities I see now it's it's
used to be excesses and it's still I would say
that's kind of the second, but the top one nowadays
is authorization. So because it's super easy to make a
mistake to forget to authorize some endpoints and then it
can be accessed by someone who shouldn't have access.

Speaker 1 (52:32):
Right.

Speaker 2 (52:33):
So, but I think if you are talking with a
basic level of security, make sure your authentication is secure,
make sure your authorization is secure, and then make sure
that there are no excessises. And that's pretty much the
rest like secret injections, really hard to have a secret
injection issue in reals now because eighty percent of the
APIs in reels in the octave record are safe and secure.

(52:57):
And for authorization, what I always command is use a
wideist approach rather than a blacklist a blacklist because it's
always better to have someone complain about not having access
to something they should have access to. They're realizing, oh shit,
somebody has access to something they shouldn't, right, because then

(53:18):
it's and you need to report it then to your customers.
That said that, if you have a it's basically a
data bridge. If somebody can access things they shouldn't.

Speaker 3 (53:27):
Well, one thing, I'm curious.

Speaker 4 (53:28):
I know we're short on time, but I'm curious to
get your thoughts on Like one common pattern that reels
doesn embrace this is this like RESTful resources like targeted
by IDs and like part of The problem with that
is just like guessable because they're like equally ordered ideas
like do you do you feel like reels is like

(53:50):
overdue for like a new pattern there, or like is
it not worth the effort.

Speaker 2 (53:55):
To like, it doesn't matter even if it's guessing or
not guessing. I found authorization issues with the u I
ds because they are not secure. They can be guessed,
they can be brute forced, and they can be leaked.
That's the that's the most common thing that you have
u I ds and you think, oh, it's safe, we
don't need authorization, but somebody in your API you leak

(54:18):
the u I d s and then people can just
find them.

Speaker 1 (54:21):
And security through obscurity.

Speaker 2 (54:24):
Huh, exactly. You should. You should have autodation. That's why
actually I think pnumeric ideas are better because then it
forces you to think about authorization. If you're like, oh,
it's hard to guess, we don't need authorization, Yeah, down
the line, you see for sure you have issues.

Speaker 1 (54:42):
Well, the other thing is is that typically you're going
to see your authorization at the controller level, and so
if you've got good tests around either end to end
or controller tests, you should be able to pick up.
You know, a person has what whatever it is that
credentials them, right, whether it's a membership or a role

(55:03):
or something. Right, you should be able to test that
and say, Okay, I with reasonable confidence running my tests
every day or you know whatever twice a day or yeah,
or every time I check in. Right, I can say
with reasonable confidence people don't have access to stuff they

(55:24):
shouldn't have access to.

Speaker 2 (55:25):
Yeah, but you can still make mistakes, and you can
use a feature and then you forgot forget to an
authorization to that. And like I found an issue recently
during a parent test where they were doing autolitions. The
same endpoint could fetch one record or a list of records,
so they were expecting either an ID or an array

(55:47):
of IDs, and they did the authorization on the on
the first item. So what you could do You could
set the ID to something which the user is authorized
to have access to, and then you get set the
ideas in the same request to something they don't have
access to. And then because it thought, oh, it's only

(56:07):
requesting one item, but actually it returned all of the
items because the second parameter, the autoidation check was successful.
But you could still get access to things which you shouldn't.
It's easy to make mistake, to be.

Speaker 1 (56:20):
Honest, Yeah, I guess, I guess what I'm saying is
for kind of your baseline stuff if you're testing it,
you know, But yeah, you're right if your strategy isn't
well thought out and your test only tests that your
strategy works, yep.

Speaker 2 (56:41):
Yeah, this is why I think gems like bundit is
really useful. Because it bunded, you can turn on a
feature which we eraise an exception if you don't call
the authories. I think it's called authorized the method in
a countra action, So it forces you to have out
ridition in every end point and if you don't, then

(57:04):
you might make a mistake and then it will warn you.
And also it really like you can do a widely
stopproach easily with that one. So nothing can be accessed
by anybody, and you explicitly grant access to certain records
right for certain conditions.

Speaker 1 (57:24):
Yeah, all right, cool, Well, is there anything else you
want to make sure that people know before we do
our picks?

Speaker 2 (57:34):
I think that's it. Basically is still a great choice
for security in my opinion. But still you need to
be aware all the time and be on the lookout
because it's easy to make a mistake. Nobody to blame
for that. We all make mistakes and we should learn
from them and get better.

Speaker 1 (57:54):
Yeh, all right, well let's go ahead and do some picks. Valentino,
you got some picks for us?

Speaker 3 (58:01):
Oh yeah.

Speaker 4 (58:03):
So I was at the last New York City Ruby
AI meet up in a happy hour and demo night,
which has now been consolidated into a nice Artificial Ruby event.
So I gave a talk on a project I'm working
on called ruby Tuner to try and fine tune an
ll M specifically for Ruby code generation.

Speaker 1 (58:25):
And I.

Speaker 4 (58:28):
Have this whole framework built that wraps Python basically to
start with the idea of over time moving it away
from Python as the new Ruby features start to become available.
And so I showed showcase kind of like the whole
process and to end of fine tuning a very specific
contrived example of turning a u r L into markdown

(58:51):
and then getting.

Speaker 3 (58:52):
A response out of it. So it's a lot of fun.
There's a new event in March.

Speaker 4 (58:59):
I recommend signing up for at Artificial Movie dot AI
and check out Ruby sooner and then just like something
really fun and because I always share something very specifically ai.

Speaker 1 (59:12):
Uh.

Speaker 4 (59:13):
Peter Cooper has been like diving deep uh and he
runs the Ruby Weekly.

Speaker 1 (59:18):
Uh.

Speaker 3 (59:18):
He shared this really.

Speaker 4 (59:19):
Fun and kind of hilarious prompting strategy for basically creating
a group of specific authors of software. So he has
like Paul Graham and Linus Torvald and David Hannamer Hansen
and like kind of made personas for each of these
characters and then got them into a prompt to like

(59:43):
argue over very specific implementation strategy at a very detailed level.

Speaker 2 (59:48):
And then.

Speaker 4 (59:49):
And he shared the prompt that he used for it,
and like it's it's kind of fun to uh, to
play with this, and it like brings in kind of
like the a combination of mixture of agent or a
mixture of experts as well as like planning execute, like
combination of those two. It's just like really fun to
see that kind of stuff of all. And like see

(01:00:11):
a panel of judges, judge thinks in a simulated way.

Speaker 3 (01:00:16):
I recommend checking that out.

Speaker 1 (01:00:17):
It's just fun. That sounds that sounds so funny. I'm
gonna go ahead and throw in some picks. So first
of all, I do a board game pick or a
card game pick this week. I'm gonna be picking a
card game. It's called The Gang. It is essentially it's

(01:00:42):
Texas Holding Poker. Cooperative Texas Holding Poker. So what you're
trying to do is you are trying to sorry, I'm
trying to copy and paste the link and while I talk,
you're so you're all playing Texas hold them. So you
have two cards, you flip over the all that stuff
right that you're normally do, right, So, and then what

(01:01:11):
you do is, once you have your cards, you can
there are tokens out. There's one for each player, right,
so if you have five players, there's a five star
token of four star, three star, two star, one star.
And so what you're trying to do is there's no
bluffing in this game, because what you're trying to do
is you're trying to get the tokens to the right people.
So the five star token is with the person that wins,

(01:01:34):
and the four star token is with the person that
would come in second, right, third, fourth, fifth. We played
it with three players, so we you know, it was
just you know, three tokens. So anyway, so you grab
the token that you think you deserve and then somebody
may say no, I think I think I have that, right,
And so usually it's the top one that gets passed

(01:01:57):
around them a lot in the bottom one that gets
passed around a lot. Right. So it's like, you know,
I look at my cards. I can't remember the pocket cards.
I think is the term? Right, I have a two
and a three. I know that I'm you know, I'm
probably not going to win, right, But as you flip
over the river, maybe you flip over a two and
a three, right, So now I have two pair. Now

(01:02:17):
I have a good hand, and so you know, then
I may be more aggressively grabbing the top or next
to the top, you know, and so and you can't
talk about what you have, but you know, so somebody has,
you know, three of a kinding kings, right, they may
more aggressively take that five star token back when I
grab it, and but I can take it back from them,
and then they can take it back from me, and

(01:02:39):
so then I may be looking at it and going, well,
I have two pair, but they're kind of crappy pairs,
so maybe they do have something better. And then as
you flip over cards, you every time you flip over cards,
you put more tokens out, and so you can see
where people are changing what they want to do. And
so a lot of times, right you'll flip over a
ten and some who was kind of not sure where

(01:03:02):
they were all of a sudden is really aggressively saying
I should get the top one. And it means that,
you know, my hand went from having nothing to having
a pair or something like that, and so you're kind
of trying to read the table and figure out what
it is. And the way you win is you get
three in a row or not three in a row,
but you get three correct before you get three incorrect,

(01:03:25):
and that's pretty much it. And then there's a deck
of cards, and we only played with a handful of these,
but there's a bunch of cards that put restrictions on
what you can do right, and so maybe it takes
away a round of tokens where you know you would
get more information or things like that. So anyway, it
was a lot of fun. The gang board game Geek
has it as a weight of one point sixty four,

(01:03:48):
so it's pretty approachable for you know, most gamers. I
think my kids, you know, I don't know if i'd
play it with my kids. Because I'd have to explain
poker to them, and mostly it's that I would have to, like,
you have to explain the statistics and why this hand

(01:04:11):
beats that hand and how to figure out right. So anyway,
that's where it gets complicated, is just knowing which hand
beach which hand and then recognizing I have a straight
or I have a flush or I have you know, whatever.
So anyway, fun fun, fun fun stuff. We played it
after it was readily apparent that the Eagles were going
to win the Super Bowl, so we played it for

(01:04:32):
like an hour. By the way, go birds anyway, So
that's my pick there, and then the other pick I
have is I'm pretty aggressively pulling together Ruby geniuses. I
have meetups planned starting on the twenty fifth of February.
We're going to be getting into all kinds of stuff.

(01:04:55):
There's going to be a book club at the end
of March, and we're reading the O'Reilly book on prompt
engineering for AI, you know, so just diving into a
whole bunch of stuff. Basically, it's meetups. I'm gonna set
up a discord channel for each of them, right so
we can collaborate with that. You get discounts on summits

(01:05:18):
that I'm putting together. Right, They're not doing Ruby comp
this year, so I plan to put on a summit
about when they would do that, and I have people
show up and speak at that, you know, So just
just stuff like that. I'm trying to think because ultimately,
I guess the other thing is is if you sign
up by the end of the week, which means that

(01:05:40):
I guess people we didn't go live. So anyway, I
was also offering if you had questions, you could text
or send me a voice message and I would get
back to you and you would get that for six months.
But anyway, so yeah, so it's it's the book club,
it's the meetups, it's the the collaboration with other people.

(01:06:02):
Just the ability to kind of get feedback on what
you're doing or get help when you need it. These
are the things that really came through for me when
I was newer programmer. And what I found is that
even as a senior developer, I'm craving that kind of
interaction anyway, and so you know, getting a bunch of
people in and Okay, what's new, what's going on, things

(01:06:24):
like that, and then finally I'm also lining up. Some
of the meetups are going to be with people that
are on the show, right, so you know, I've asked
some of our past guests to do them, and we're
going to start doing some of those in March or April.
So the first handful, I just wanted stuff on the
calendar that people were asking me for that I could teach,

(01:06:45):
and that way I didn't have to worry about whether
or not I could fill those meetups with other presenters.
But yeah, we're going to have a lot more of
that because there are a lot of people who know
a lot more about stuff than I do. So anyway,
you can go get at rubygeniuses dot com and yeah, Greg,
what are your picks?

Speaker 2 (01:07:04):
I have two picks. One is a gem got Pundit,
which we just mentioned because I think it's really good
for outright to handle authorization rails app. It's a good
help and it helps you to solve a bunch of
issues easily or a bunch of problems. So that's one
of the picks. And the other pick is a bit

(01:07:24):
of a self plug, which is I'm working on a
course for almost a year about security for rals developers,
and now I'm close to get it ready and publish it.
And it's already in on free sale, and once I
record the video videos fit it's basically the written version
is pretty much done. I just need to record the

(01:07:45):
videos and then I will publish it. And I hope
it's going to be useful for people to learn more
about the caveats of security things in rails.

Speaker 1 (01:07:58):
Cool. Where do people find it?

Speaker 2 (01:08:00):
Uh? Just go on my website. There is a link
somewhere on it. Probably I should I should put the
bonner on it, but you can find it on my website.
There is a link I think at the top somewhere
some great.

Speaker 1 (01:08:14):
All right, cool, we'll put a link in the show
notes too, and that way people can go and keep
an eye out for it.

Speaker 2 (01:08:20):
Great.

Speaker 1 (01:08:20):
Thank you, Yeah, thanks for coming.

Speaker 2 (01:08:24):
Thanks for having me. It was fun again.

Speaker 1 (01:08:28):
Yeah all right, Well we'll go ahead and stop here,
wrap it up until next time, folks, Max out