Coding Blocks - PagerDuty’s Security Training for Engineers! Part Deux

Episode Date: January 4, 2022

We continue our discussion of PagerDuty's Security Training presentation while Michael buys a vowel, Joe has some buffer, and Allen hits everything he doesn't aim for.

You're listening to Coding Blocks, episode 175. Subscribe to us on iTunes, Spotify, Stitcher, wherever you like to find your podcasts. I hope we're there. And yeah, leave us a review if you can. Yeah, there we go. And visit us at codingblocks.net where you can find our show notes, examples, discussions, and more, and send your feedback, questions, and rants to comments at codingblocks.net. And follow us on Twitter at Coding Blocks.

And if you've got a cool project or something, just hit us up, let us know, and we'll share it out and we want to see it. Also, website, codingblocks.net. And we've got social links at the top of the page. With that, I'm Joe Zak. I'm Michael Outlaw. And I'm Alan Underwood. This episode is sponsored by Datadog, the unified monitoring and analytics platform for end-to-end visibility into modern applications. And Linode, simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.

And Shortcut, formerly known as Clubhouse, you shouldn't have to project manage your project management. Hey, so today we are continuing on talking about security training for engineers using PagerDuty's slides that we found, and we've got linked in the show notes. But first, a little bit of news. We've got some reviews. Yeah, so from iTunes. Okay, so I'm going to... There's like a lot of vowels in this one. from iTunes. There's a lot of vowels in this one. Hardly any consonants. I'm going to try it and I'm sure I'm going to mess it up, but it's going to be something like

audio. It's pronounced O-D-O-D-O-D-O-D-O. Wait, really? Yeah. You've never heard that word before? I think you're messing with me. Yeah, I am. Can we get an R-S-T-L-N-E, please?

Yeah, this would not be like Will of Fortune. You would lose on Will of Fortune with that one. But if you bought a vowel vowel you'd do really good yeah that's true that's true uh almost got uh half of them in there hey uh also this is the last episode that's going to come out i think uh it's all right before the game which is coming up the january 21st 24th so make sure you sign up uh you can do team you can do solo just make game submit it it's gonna be fun you go in after just make a game, submit it, it's going to be fun. You go in after you submit a game, you go play other people's

games, you say, hey, this one's really quirky, or this one's really fun, or whatever. And then things get ranked, everyone plays your game, and it's awesome. So you should go sign up and make a game. There is one more episode before the Game Jam. Alright, cool, so you're going gonna hear that again whatever all right so apparently

alan hasn't been attending our branding classes when we've talked about game j-j-j-j-jamuary yeah i can't speak this morning i don't know what's up i think it's too early yeah it definitely is yeah all right so we're we're picking back up on this uh on this pager duty thing that we talked about and so the very next one that we're going to jump into here are is vulnerability number three and that's encryption and and i think i think all three of us sort of when we see this we're like oh man we don't want to say this any of this wrong right yeah it's so hard to get right and uh oasp has the more generic category of kind of cryptographic failures and uh just talk about oasp real quick um in case this is your first episode basically they're a

conglomeration a group of people that get together uh every couple years and decide on um looking at a bunch of stats and security vulnerabilities what are the worst problems facing our apps today because what they find over and over again is it's not Stuxnet it's not the really sophisticated you know advanced persistent threats that are really wreaking havoc across the world it

tends to be the same 10 problems over and over again and so they've got this one scripted graphic failures which could be anything from having the same key on the same, you know, accessible in the database or wherever the data is, or maybe it's, it's basically just doing it wrong using,

you know, coming up with your own custom wrote custom encryption or doing rotation or not salting your passwords, anything like that to get, get your encryption wrong. And so now we've got some more information coming up on how to do it right yep and it's probably worth saying what they define encryption as and it's encoding information in such a way that only authorized readers can access it so pretty simple yep and that's an informal definition so yeah it's so it's so hard not to

want to kind of caveat all over the place especially uh especially problematic because i like i'm not qualified but i did want to mention that there are mathematic uh definitions of cryptography and encryption and even those two terms like we kind of use them like as if they're synonymous but um they've got they've got pretty rigid definitions that were you know probably go back to like i don't know 400 bc or something so uh we're gonna do our best and just hope you stick with this is that bc as in before computer yep yeah so like you know 40 years ago, um, you know, you know, what's, what's probably a really good resource for anybody that hasn't heard us talk about it before is security. Now,

Steve Gibson goes over this stuff. It seems like all the time. Um, so if you want more listening material, you could go search his podcast security now as well, where he deep dive some of this stuff, um, frequently. So, you know, just, just a side note, we'll put a link to a show in, in the show notes as well. And then now we can get into the meat of what we're going to hit on sort of a surface level. Yeah. And I think, uh, there's one more caveat. I got to slip in here. We just, we told pain, which is just that, want to really hammer home that encryption is so, so tough to get right. And that, you know, it's kind of become a meme now at this point. You should never try to create your own encryption.

And it's kind of counterintuitive. Like, people always are, you know, I think there's like a natural inclination to kind of think that, like if i do something custom if i just do do this my way if i just divide by two if i just do this kind of thing that no one's ever heard of that's totally custom and totally unique uh the chances of someone figuring that out is going to be much smaller than if i'm using some common tools that they've seen before but uh there's all sorts of mathematical reasons why that's a no-no. We've seen time and time again that that strategy doesn't work and it gets broken constantly and you read about it all the it because it's kind of hard to really explain why like encryption and why mathematical cert mathematical security researchers always kind of assume the algorithm is known for cryptography and encryption but

it's really important that you're not messing up so just give it a google i always viewed it as if if you think that you're going to roll your own and that it'll, that it'll be secure. It's one of those problems where it's like, you don't see the forest for the trees type of thing. So you think that like you've created something super secure, but you know, somebody else who's looking at it with a fresh set of eyes,

looking at it, starting from a distance, they're like, Oh, wait a minute. I totally see the pattern. Right. Like if you just X or everything,

you, you know, up close, you're like, I got it. Nailed it. And then, you know, you look at it from a distance. You're like, oh, wait a minute. I totally see the pattern. Right. Like if you just XOR everything, you know, up close, you're like, I got it. Nailed it. And then, you know, you look at it from a distance. You're like, wait a minute. Yeah. Yeah. I mean, we can't stress that enough. Like the, the pager duty slides even have their recommended algorithms and stuff to use because computers get faster all the time. Right. And so the things that were good 10 years ago, aren't even good today. So, so pick the libraries that are recommended at this time, whenever you're listening to this, to, to go do your, your cryptography, your, your encryption or whatever it is, because it really don't do it yourself. Just don't. So I guess with that, let's get into the different types of encryption out there. There's not a ton. There's symmetric and asymmetric. And this basically refers to whether the keys for reading and writing the encryption are the same. So symmetric

encryption means that you're going to use the same key to encrypt that you're going to use to decrypt that information. Asymmetric is different. Asymmetric, you encrypt, and usually it's a public-private thing. With asymmetric encryption, you're going to encrypt it with a public key. And then when you get it, you're going to decrypt it with your private key. And the idea is anybody can encrypt using the public key. So if you want to send something secure to outlaw, right, he's got a public key that you can use to encrypt the data. And then when he gets it, he's the only person in the world that's supposed to have that private key to unlock it.

Right. And it's a big mathematical equation, right, is really what it boils down to. So there's some sort of formula that allows the one encryption key to work with the other one decrypting it. Yeah, and another one to mention is a block cipher, which is the word block there is the key because it lets you encrypt or decrypt whole chunks. So you can imagine like you encrypt the whole file at once. And basically, if any piece of that file is missing, like you only retrieve half the file or, you know, even a couple bits or bytes are off at the end, then you can't decrypt it because it requires the whole chunk. And we got things in a slightly different order. But just to kind of contrast it, we'll mention the next one is the stream cipher which is meant to be more on the fly so you can think about

something like hdps or anything you use like h you know streaming protocols where you can start reading before you have the entire message so you can start sending the data and start decrypting as soon as you receive that first byte we should ask really oh go ahead hey oh it's all good we should call out too though that like pager duty specifically separated public private key from uh asymmetric and yeah i wasn't really sure why because technically it is a form of asymmetric encryption is probably the most common form of asymmetric right so i i don't know either yeah it was kind of weird i thought it was weird that they put black cipher in front of it and so the arrangement is kind of weird too but yeah public private is kind of weird you know

what's funny about um the public private key is uh you can do a lot like so many encryption encryption schemes basically deal with like public private so like if i'm trying to write to outlaw well i've got uh his public key and i write to him and he can decrypt it now if he wants to communicate with me well now he's got my public key and i've got a private key that can decrypt it but um so the strategy overall is not that bad but the hard part is like how do we dynamically kind of send those keys and how do we rotate them like the devil's in the details there yeah yeah i don't we're not even going to talk about nonsense no no h max and yeah it's there's so much it's a lot it's such a topic yeah i mean it really is so like the thing is is that pager duty did a really good job of describing what you needed to know without getting too lost in the weeds of it.

Because it is an extremely complicated topic that you can very easily say one thing and like all of a sudden everything you said is wrong, you know. But they kind of they shoot straight down the middle of the road, basically. So these are like the most common con comps that you hit and they hear and like we mentioned earlier uh it's usually the easy kind of basic stuff that people get wrong over and over again so so the ones that we just talked about a second ago are usually what you would consider encryption at rest, right? So when you store a file on your hard drive, right? And then you encrypt it with either the symmetric or asymmetric or the block cipher or any of that kind of stuff. That's usually what you call encryption at rest

because the data is encrypted and just sits there. There's also encryption in transit, which depending on whether you're in the security world or not, you might hear it as data in motion or other names, right? But that means that you're encrypting the stuff while it's going, which is what, you know, we probably all know as our HTTPS in our browsers, or if you heard of TLS or what used to be SSL, right? Like that was the purpose of those things. Well, you can make the analogy that if you have an encrypted hard drive, that would be at rest.

And then anytime you go to a website that's HTTPS, that's in transit. Yep. And for people who don't really know what the HTTPS and the TLS stuff is, it's funny. I was at a conference a couple of years ago for the whole COVID stuff hit. And it was funny. Troy Hunt, who is really big on security stuff, right? Like I think he has the I have been pwned or whatever that website is. Have I been owned?

Have I been pwned? He was talking and he said, you know, a lot of people, and it's actually marketing, it's marketing's fault that people think this. They'll see a lock up in their browser and they think that that means that their information is secure. And that's different, right? That lock in your browser says that when you're talking to the website, all the data going back and forth between the website is secure. That doesn't mean that they're storing anything secure. It doesn't mean that they have good encryption protocols. It doesn't mean any of that. It just means that the chances of somebody doing a man in the middle attack or hijacking that traffic when you put in your username and password is very low, right?

In terms of the likeliness, it does not mean anything about how they're handling your data once they have it. So just be aware of that, right? Like they are two totally different things, moving data and storing data. Yeah, there was actually, uh, cause remember when Google was making a big to do about the type of certificate. So if you had an extended validation certificate, they would actually show the name of the company, but then they stopped doing that because it was putting like the wrong, it's basically what you're describing. It's like the wrong and fastest on the wrong syllable. Right, right. It's making you think that it's something more than it is. And so they

stopped doing that now and they, now it's just back to the normal padlock. Yep. I did learn something in this pager duty thing. Um, I had never heard of this perfect Ford secrecy. Um, had you guys come across this before? Yes. You want to describe it there outlaw? Uh,

I don't know if I'll do it or a really good job, but Steve Gibson definitely has done it. This is the idea here is that, um, let's say, okay. So as Alan said earlier, computers always get faster. And, uh, you know, so what, what's good encryption today isn't necessarily good encryption tomorrow. Right. Well, the idea is that like, what if you have like a large, uh, you know, nation state actor that could just vacuum up all the traffic and hold onto it for a

while. And eventually they know that they'll be able to decrypt it. Right. And then maybe they can't today, but eventually they will be. So the idea of perfect forward secrecy is it's trying to solve that type of problem so that not only is it, you know,

you can't break the encryption today, but you also won't be able to break it tomorrow. Yeah. And the way that they do that, and this is what was interesting. This is why they say, don't try and roll your own is because you probably wouldn't even thought about this case, right? Like what I lost said is you hold on to this data for a long time. What they do essentially is, is create like a session type thing. So, so that your encrypted data, while it may be using the same encryption keys and stuff, it almost has like its own salt essentially as a session so that while they might be able to decrypt this one set of data that came across, they wouldn have its own unique piece of data there that's

going to keep them from being able to decrypt every single thing that ever came across on that particular certificate or whatever. So it's, again, it's just not something you'd probably think about if you were trying to roll your own. So again, you really, really want to stick with the tools available out there. Yeah. And it's just a matter of how much work you have to do. So if you imagine if um you know you did the work once you figure out the key and now you can see all traffic going to or from microsoft.com that's the difference between that and having to do the work for each session session so you have to keep figuring it out again so it's just a technique for kind of

generating those keys like you said for for the session which is really nice. So encryption arrest, we talked about over the wire, data in motion, and now we're basically talking about storing the data where, or encrypting the data where it's stored. So like full-disk encryption is an example. Sometimes on cloud platforms, S3 or whatever, you can check a little box and have those items encrypted where they're actually stored it means if somebody like steals the hard drive they still have some work to do

with uh in order to access your data yep so that's also really important to know if you're somebody that does have one of these laptops that has full disk encryption on like i mean i know for the dells for a long time when you go to turn on the laptop, it'd ask you for a password, right. To, to be able to log into it. And that's what essentially decrypts the data on the disc. Don't ever share that password. Right. Um, there, there are companies would use the same password for all the laptops. So you probably shouldn't do that either. So if you know that there's, if that's being practiced, then that means any attacker, if they got ahold of a bunch of hard drives somewhere, they could go get all the information off of it, right? So you definitely want to be careful about that stuff.

Yeah, like even on the Macs nowadays, they will prompt you first for your password during the boot sequence just so that it can decrypt the drive so that it can continue the boot process. Yep. And it's really, especially for businesses, it's important, but probably even on your own personal computer, right? Like if you're using something that allows for disk encryption, computers have gotten so fast nowadays. Back in the day, they didn't want to do it because it took a performance hit, right? Nowadays, if you can, I'd say do it, right?

I mean, if you've got personal tax information or whatever's on your laptop you don't really want that being grabbed by by an attacker out there i mean like take ios devices for example i mean it's by default they're they're encrypted by default you don't even get asked anymore like it used to be a thing like you know back in the first couple versions where you could like you know select to turn that feature on. But now it's just, it's done. And when you go to a quote, erase your iPhone to reset it, it's just throwing away the key. Oh, that's awesome. I didn't even know that. So it's not even,

it's not even formatting the thing just makes it all gibberish. Well, yeah. I mean, cause like why bother, right? It's technically that's a a bad operation to do on any kind of ssd anyways to like you know to write to it unnecessarily would be bad and you know if you throw away the key then that's that's it that's all that's necessary anyways that's pretty cool didn't know it it is weird though because there's like some uh solutions out there for encryption because like you, you know, like we mentioned, FileVault that's built into the Mac operating system

does a really good job of it. But then for the Windows platform, there is BitLocker, but there's also like third-party solutions out there too. And it's curious to me like how some of them work because some of them, you know, you can have your password to decrypt it, but an admin can have a separate password and somehow it works. And then I'm like,

wait a minute, that's like mind boggling because isn't that the, like, shouldn't that not work? Like how, how do you, how are you both able to, you know,

decrypt it with different keys? Uh, I gotta imagine that like the software itself must be storing a key somewhere and you know, you're, you're authenticating to that and getting the real key with one of two IDs. But you'd hope so. Even then that seems kind of like,

you know, like in the, yeah. Cause it seems very much like you're rolling your own in that kind of scenario. Cause then it's like, well, wait a minute.

Can I just crack that little, that little database? So I know there's some pretty funky algorithms out there. I don't know what they're doing there. But I've heard tales of encryption schemes where you can have two different keys and each one can work. I've also heard of a really weird case where there are encryption schemes where you can have multiple keys, say seven keys, and any three of the keys can decrypt. So that would be an example. You imagine like a military purpose or something like seven generals have keys,

and as long as any three of them agree, they can encrypt the data, but no one key alone can do it. Well, that's different, though. That's like, God, I can't even think of it. It's a consensus, right? It's like what you said, right? One person can't think of it. It's a consensus, right? It's like what you said, right? Like one person can't push the red button and start a war,

right? Like there's gotta be multiple people that do it. As a matter of fact, HashiCorp vault also has a similar type thing to where you can require that there'd be a certain number of people do something because they don't want people to be able to unseal the vault and get to all this stuff. So, yeah.

Um, but that doesn't seem as, as quite the sameseal the vault and get to all this stuff. So, yeah. Um, but that doesn't seem as, as quite the same as having two passwords to get to the same key. That's just multiple passwords to unlock something. So I don't know. It does seem weird. Um, but at any rate, one of the things that, excuse me, pager duty does say in here and I completely agree with this is the most important data to them is the

customer data, right? And they do go into the multiple types of classification of data that they have, and they only have three, I think. Yeah. So the first one is general data, anything available to the public. They don't care about that data whatsoever. It could get leaked, doesn't matter, not going to hurt anybody or anything. Then they have their business data. This is, this is their data for operating the business. And they called this like payroll information or employee information or whatever. Um, this, they encrypt in transit and at rest, which is really good. You want that? And then customer data. This is data that was provided to the company by the customer. And this is also encrypted in transit and at rest. So they

take all of those seriously. Now they did have some, some controls that they put over the data that was interesting. And honestly, I wonder how you guys feel about this. Like when they said that they treat their customer data more important than their employee data, that kind of bothered me a little bit because if you're in their payroll system, that means that, that means that you've actually got your social security number in their systems, right? And that kind of stuff. Now, granted, they said they encrypt in transit and at rest but you're almost a customer of them right so it kind of bothered me that they said that this was not as important as customer data i don't know yeah i remember amazon had a distinction between customer data employee data too and the customer

was like red red it was like the most critical and employee was less um but yeah it seems like if you can get into the employee stuff it'd be easier getting the customer stuff so i don't really i never understood the distinction either yeah so here's what here's the controls that they wrapped around it and this is also where it's sort of gray to me in terms of why they made this decision. So the customer data, they control the Titus and that means they, they take care of authentication, access control, storage, auditing, encryption, and destruction. So that's all the types of things that they wrap around it. The only difference between that and their business data was they did all of it

except for auditing. And that just doesn't make sense to me. To not audit that business controls. Yeah. Yeah. Like I'm with you on that. Like that was like the only distinction. And like, why would you not want to audit who has, who's accessing the payroll information or anything like health care related. Yeah. Yeah. I mean, I understand their point, though. Yeah, totally. And I'm not trying to rip PagerDuty apart, like super appreciate the fact that they put this out there for other people to learn from. But I mean, auditing seems like it should be a core feature of anything that has sensitive data. You need to know who logged into a system, when they logged in, from what computer, all that kind of stuff, right?

So it just seems like that should be wrapped around all of it. So again, not trying to throw stones at them, but if you're doing it, just do it for all of it. Like auditing makes sense. So what if by business they mean more like, you know, chat messages and emails and not like sensitive employee uh, employee data. Cause then it's not so bad. Right. Then you're like, okay, I get it.

Yeah. Maybe except for they're the ones that said that their business operation stuff was payroll and employee info. So yeah, I don't know. Um, may, maybe they have it around things like payroll, which would be good. We don't know. We're not part of the business. But, yeah, I do think that you should audit it. Yeah, you're right. They did list out specifically the list of employees and payroll information. Yeah, so whatever.

But at the end of the day, like if somebody found out how much you made, that's not, like not devastating to you. Right. It's just if your social security number's in there or something like that. Yeah, that's devastating. Right. And that's what I'm saying. Who knows what's in their payroll systems?

Again, we don't work there. We don't see that stuff. But it was an interesting distinction. Who rolls their own payroll anymore? Like ADP, done. Right? That's what you should do. Yeah, companies don Who rolls their own payroll anymore? Like ADP, done. That's what you should do. Companies don't use their own software. For real.

Do you think there's any company that uses 100% their own stack? What about the couch, not couch base, the people who write Ruby and Rails? No, they don't do it? No. The people who wrote Ruby and Rails. It seems like that's, no, they don't do it either. Yeah, I don't know, man.

I would think nowadays you wouldn't. It's just too expensive to even try and create that kind of stuff that's not core to your business. Well, because the thing is, is that like you take a look at like a big company like an Amazon or a Microsoft. You know, they absolutely have the ability to, but when you get to a certain point, it's like, do you even want the liability of it? Right.

So, so it might be, you know, more advantageous from a liability perspective to let somebody else handle it. That way, you know, you can wash your hands of it. Even if you do have the ability to deal with it.

And that service might end up using your systems to run it. Like in the case of AWS, you hire an ADP and they're running on top of AWS, for example. I don't know if they are, but you could picture a situation like that where everything's running on top of AWS. This is total tangent. Tangent alert. Tangent alert. Uh,

but speaking of AWS, I read, I read something recently where, um, they were talking about how dependent is an older article, but it was talking about how dependent Apple is on Amazon. Care to take a gander at how much the, the Apple bill for AWS was per month.

2 million. What'd per month? Two million. What'd you say? Two million. Two million. The M? I'm going to say one billion. One billion. Wow.

You guys are like drastically different. It was 30 million a month. Wow. Yeah. And this was an old article too. This was like a couple years old too. So who knows? Could be more, could be less. Wow. Yeah. And this was an old article too. This was, this was like a couple of years old too. So who knows? It could be more, it could be less interesting. And that with all the topical information, you know, now you're up to date with, you know, old, uh, Apple news up to the minute,

a few years late for good. Yeah. I like that up to a minute, a few years late. Yeah. Trademark that phrase. So here's another thing that PagerDuty said when they were talking about like using cloud systems. And this is really important for anybody that's using AWS, Azure, Google cloud, whatever, right? Is they said, you have to make sure you're enabling encryption on all the various services. If you're using storage like S3 or GCS or blob storage in Azure, you want to make sure you're enabling encryption on all the various services. If you're using storage like S3 or GCS or blob storage in Azure, you want to make sure they do it. Now, one thing that they said that as a developer, you know is not the reality is they're like,

hey, anytime that you provision something, make sure you click that box, that checkbox, right? Which means that they're doing it via UI. So in the real world, as a developer, you're automating a lot of that setup, right? Like if you, if you're provisioning buckets or whatever to store your data, it's not a checkbox. There's a configuration somewhere that you've got to set. Well, you iterate to that though, right? You do iterate to that. Yes. But on top of that, there's also additional things that come with it, right? Like whether or not you're using cloud managed keys or customer managed keys and all that kind of stuff.

So the only real call out that I wanted to make here is be aware for most cloud services that you use that there is the ability to encrypt data either at rest or in transit. Be aware that those exist. Go find them before you implement anything and turn that stuff on. I kind of viewed it as like a sign of how mature are you at using that particular service? Because in the beginning, it's always like, oh, what is it? How does this thing work? Let me point and click around and like, okay, I kind of got an idea of it. And, you know, I want this feature on, I want that feature on, Hey, can I script it? What's the API? And then you, then you eventually, you know, you start out with like a simple shell script and then you might, you know, put a UI on top of that, you know, or, or make it to where it's automated in some kind of fashion. But,

you know, these things start small. And so, you know, in the beginning, you might have to manually click that button. But then over time, you know, you have some kind of script that's just always setting the encryption. But I also viewed this whole section, too, as like an example of the old phrase of you're only as strong as your weakest link. So if you're, you know, if all your data in transit is encrypted, okay, fine. I'll just wait for you to write it to disk because if you're not encrypting it there, then that's good enough for me. Right. And you know another thing that we might have even had tips on this in the past. Like what Outlaw was saying is typically you'll iterate towards the scripted solution or the automated solution.

A lot of the UIs, I know Google does it, Azure does it. I would be completely shocked. I know Amazon does it as well, is if you click your way to creating something like a bucket per se, a lot of times right at the end of it, you can say, hey, show me the configuration output, give me the JSON for what I just did. Or YAML. Say what? Or YAML. Or YAML. Yeah. Give me the JSON or the YAML or, or sometimes I know GCP even has the cloud shell scripts, right? So, um, so do that just so you're aware. Now there are people out there using things like Terraform and I would hope that Terraform is pretty complete in this regard, but I would say you also want to check if you're provisioning a service through Terraform to create something, make sure that

the underlying service does provide encryption and make sure that that's exposed also through your Terraform scripts, right? Like if you're using some sort of, you know, cloud agnostic way of doing things, make sure that it supports this ability to keep your data secure. It doesn't even have to be like any of these big cloud providers that we're talking about. Like the, really the one that came to mind as I was going through this section was, do you remember Citus?

Oh, I do. Citus data. So for those not that haven't experienced Citus, Citus is a cloud service for Postgres where, um, I'm not sure, like at least their big claim to fame in my mind, uh, in, in, they probably have a lot of other features. So I'm probably like, you know, uh, undermining what they, what they do. But one of the big things that they are, that they have as a capability that they add on to Postgres is a

sharding by, uh, like a customer. So you could have one database, one multi-tenant database, and it'll shard that by each individual customer for you and deal with all the underlying details therein. But they can do that at a cloud level. So originally, you could use it for, uh, on AWS or on top of Azure or whatnot. Uh, they eventually got bought by Microsoft.

And last I saw, uh, they, their offerings for non Azure platforms were, were, um, somewhat dwindling at the time only because their focus was on Azure. But,

um, I mean, that they were an example of like, you know, it's not, it's not a big cloud provider thing, but yet they were totally scriptable. You could,

you know, they totally had an API that you could figure out, you know, how to, how to create your, uh, you know, a site is data database.

Um, you know, and that's a great call. I would in an automated fashion. Yeah. You're talking about like software as a service type things, right? Like, yeah. What, whatever you're using out there, see if, yeah, if it, if it matters, if it's data that matters, see that you can do encryption in transit and at rest.

Because databases specifically are like one of those areas of like, when you want to talk about encryption at rest, where it can be, you know, a trade-off conversation, right? Like, ah, do I want to? Cause man, like that, that encryption is definitely going to hurt. It's definitely going to hinder my ability to read fast. And so like, there's might be a side of you that's like, Hey, let's go for performance and, you know, not care about the encryption, uh, at rest part. But you know, then you get, then you get hit with some, uh, you know, nasty, um, uh, data leakage because you didn't encrypt it.

So, yeah. So, so there's another tangent for you. Does it even matter anymore? What's that? The leakages, like how many notifications do you get that your data has been leaked now? I think, I think in 2020, I might've gotten four from, from healthcare providers to banks to whatever. And it's like, I remember you guys remember back when Target had its first data breach and it was a massive deal. Their stock took a hit. Everything was like, oh my God, the sky is falling. I was thinking of Sony as the first.

Remember Sony? Because they got hit multiple times. And it was like, oh, you still haven't learned your lesson. Okay, well, here's another one. We've been in your network for five years now. Yeah. But nowadays, yeah. Home Depot. That's right. But, but nowadays it honestly feels like I get these notifications. I get, I get mail, right? Like snail mail is like, Hey, I'm sorry. Um, we let your data get out.

Here's a year of free monitoring, right? Like I've probably got 10 of those offers in the mail. And it's like, does it matter? So where I think it matters is that we talked about this a little bit on the past episode as it related to like rainbow tables and whatnot. So you should definitely be aware that every time there's a data leakage like that, um, you know, the bad guys, they're collecting those, those databases and, and they're, they're going through and like, okay, I already know this password or, uh, here's, you know, the same email address from, you know, I found the same email address in the target breach that I found in the home Depot breach. And, you know, now I can compile a list of like their secret questions, right? Because over here, he, you know, he or

she said what high school they graduated from. And over in this other breach, they said what city they were born in. And so now I'm starting to compile enough information. Oh, I got this other breach that now gives me their social security. So now I know their social security, where they were born. Pretty soon I'm going to get to birth date and now I can start combining all this data to create, here's a list of identities that I could sell out on the quote dark web, so that type of thing is definitely happening. You know, I mean, like we, we worked at, uh, you know, a place where every time there was a, uh, outage, we were getting a copy of that, uh, that data leakage to see like, Hey, are

any of our users part of this? And if they are, we want to let them know, Hey, you need to change your password because you used the same password with us that you used on this other place. Right. Right. So, I mean, people are doing some good things with it now. You know, does it mean, you know, is it is it all doom and gloom that maybe we once thought it was? You know, I don't know. I think that I think the evolution of the hacks has like, it used to be, you know, the evolution of hacking was like, oh, let's just, you know, tear up your computer, right? Tear up your own personal computer. But I don't benefit from it in any way. And then over time, it evolved into like, oh,

hey, I'm going to go out and I'm going to steal 60 million people's credit cards. And now I can either sell those or I can run up charges on it and I can get stuff and now I can benefit from it. But you know, it's like, I'm going to do like, you know, a thousand micro transactions in order to get something big. Or now it's like evolved into, Hey, let me just get into your network and encrypt a bunch of your stuff. And now I'll ransom you. And so you, the individual person whose data might be impacted, eh, I don't care about you. But the overall company, I do care about, right? Because I want to go after the deeper wallet.

So I went and looked at Have I Been Pwned? It's a website we've talked about many times. So it's basically kind of almost made a business or a website out of looking up passwords or email accounts to see if it's been compromised. And they have a list of the most recently added breaches. And they also have a list of the largest breaches. So, the largest collections of passwords. Recently added breaches.

Go through the top five here and tell me if you've heard of any of them. Ducks Unlimited. Yeah, 1 billion. IDC Games. No. Yeah, 4 billion uh gravatar yeah yeah okay so i did hear about that breach that was 114 billion accounts or sorry million million accounts and the last one was pro temps so that was the five most recently so like you know we were only even we're aware even though each like those were millions we're talking millions and we haven't even heard of most of them uh largest breaches so these are kind of silly to talk about but i just wanted to mention it because it was interesting

uh the collections here are um they're not necessarily from individual uh breaches so they're like um for example like the number one 772 million accounts is called collection number one it's because it's uh somebody had amassed the collection from all these other things. They aggregate it and that this thing is being passed around as a big group. Number two, verifications.io. Never heard about it. Online spammer, spam bot accounts. Data enrichment exposure from PDL.

And then finally, exploit.in. The next one on the list, I said it was only going to be five, but the next one was Facebook, which is interesting. data enrichment exposure from PDL and then finally exploit dot in, uh, the next one on the list, uh, I said it was only going to be five, but the next one was Facebook, which is interesting. So that one was 500 million.

I don't know that I'd ever heard of the Facebook one. It was years ago. Um, if it's the one I'm thinking of, because there was an exploit where, uh, it was the way they were dealing with impersonation. If I recall. so i think that's

the different thing uh this one is you can click on it and see this came from april 2021 where a large data set of over 500 million was made freely available for download uh encompassing about 20 of facebook subscribers wow and is was allegedly obtained from explaining a vulnerability on Facebook from 2019. So maybe that's the tie-in. So the thing is, I was being a little bit facetious, right? With the, does it even matter? Yeah, of course it does. But I think it's just as important on you as an individual to make sure that you're using different passwords. If you can use different usernames on sites, right? I mean, some sites require that you use your email and you're kind

of locked into a few of those that you have. Um, if we actually had a conversation at work about this the other day, emails are so irritating because you might say that, Hey, well, I'll just use that plus in my Gmail, right? And, and put things in there. But so many companies don't do pass or email validation properly. So it'll break in any number of various spots, right? So I just stopped using the plus when I would use my email as a username, because I found out that half the time it would work and half the time it wouldn't. So, you know, just do your due diligence and make sure you're not ever using the same password, Have it randomly generated. If you can, swap out your usernames, that kind of stuff.

And that'll help if there's one leak on one side over here and it shouldn't affect you on these other ones. I mean, we're getting there with the ability to swap out your usernames rather easily there, right? Because there was that new ability that Apple added to iOS. I think it was this year where, what did they call it? Where the email hiding, where they'll generate, it's basically like a proxy email address that they'll create, like a bogus iCloud.com email address. And then anything that goes to that, they'll know to forward to you. Yeah, I actually like that. You know, I always hated the, uh, anytime that you go to sign into a new account, it'd

be like, Hey, do you want to use Google? Or do you want to use Twitter? You want to use whatever. And the problem I always had with those is if you said yes to use your Google account, it would request access to your entire profile. Right. And it was like, I don't really want you to have access to my entire profile because I want to download a white paper on something, you know? Um, but the Apple thing that the outlaws talking about was actually pretty amazing because you could actually say,

yeah, don't share any of my information. Just give the email that you're going to generate, not even my real one. And then you could authenticate with apple and in in my opinion that was like the best of all these oauth type providers out there like it was they did a really good job of keeping your information private but yeah i never used that uh that feature with the oauth to like log in with your twitter or Gmail or whatever other account, you know, I mean, the reason to me, it seemed like the only benefit, the only person who really benefits from it, well, they try to make it like convenient for you. And that's how they sell it to you is, you know, it's a convenience measure and security, uh, security I've always viewed as

like, it's not supposed to be convenient. If it, if it's convenient, it, then you're doing something wrong. Um, but the only entity who really benefits from you using that feature is the company. So like, um, if you use your Google account to access into some other service, then it's Google that's benefiting because now that's like one more signal that they can use to track like, oh, yeah, you also shop here or, you know, visit that or, you know, have this interest in this. And, you know, I'm just like, why bother? Yeah, that's true. All right. So so we we veered a little bit off the tracks here.

A little bit. The last, the last thing that we were talking about was the, the fact that they wanted you to check a box to encrypt things, right? NS3 or whatever. So one interesting thing that they did say about it is if you create a resource in the cloud that wasn't encrypted, they get an alert. And so the admins at pager duty will actually go delete the resource, right? They'll, they may contact you and be like, Hey, why'd you do this? But they will actually remove it. Um, and so that's pretty good. And then the next thing that they

said is, well, what if you're using some other third party? And Outlaw mentioned Citus, right? Should they encrypt if you care about the data? Absolutely. Like, yes. As a matter of fact, Joe, here I go again. Jay-Z mentioned that, you know, at Amazon, there were certain practices they did, and they were super serious about security, which was always something that I know I loved about them, and I think all of us did. And they were super serious about security, which was always something that I know I loved about them. And I think all of us did. But they had auditing protocols in place for third parties. If you're going to use a third party vendor, they had security audits that said,

hey, do they do this, this, this, and this? And if they didn't, you couldn't use them. So either they had to get their ducks in a line or, or in a row or, or you had to find another vendor like that. That's all it was. You didn't even have any other options. So, um, absolutely. They should encrypt.

And this also, they said that you should perform a vendor assessment, which, you know, like I just said, Amazon does. Today's episode of coding blocks is sponsored by data dog, the monitoring and security and analytics platform for developers, IT operation teams, security engineers, and business users in the cloud age.

Their SaaS platform integrates and automates infrastructure monitoring, application performance monitoring, and log management to provide unified real-time observability of customers' entire technology stack. Datadog is used by organizations of all sizes and across a wide range of industries to enable digital transformation and cloud migration, drive collaboration among development, operations, security, and business teams, accelerate time to market for applications, reduce time to problem resolutions, secure applications and infrastructure, understand user behavior, and track key business metrics. So it's that time of year where I start looking at New Year's resolutions and just looking at kind of planning my career and the things that I spend time with.

And Datadog keeps coming up because the things that I'm interested in for managing my own career, cloud, site reliability engineering, big data, streaming, application performance and security. These are all things that Datadog does in spades. And they have tools and dashboards and visualizations for really taking everything that I want to do and getting it to a professional level. So it's awesome to see what they do. It's inspirational. But it's also really important for actually using this stuff kind of in the real world and kind of taking your operations to the next level. So you've got to go to the website and check out. Yep.

So you can start your free Datadog trial today so you can monitor and collaborate in real time. Listeners of this podcast will receive a free t-shirt once you install the agent and create your first dashboard. Visit datadoghq.com slash coding blocks. Again, that's datadoghq.com slash coding blocks to get started today. Okay, well, it's that time. So buckle up because here we go. Dear listener, if you would be so kind as to leave us a review, we would greatly appreciate it. You can find some helpful links at www.codingbox.net slash review. And oh, by the way, you can leave us a review on Spotify now. Did you guys know that?

I'm kind of breaking character here. No, I didn't know that. Yeah. Spotify added a new feature to where you can uh uh within the app it seems like it's only within the app though like i didn't see how you could do it from the website um well that's fine i'd say just about everybody has it installed now yeah i even installed the windows version like the app oh that's very cool i'll have to update the uh the review page to have a link to this as well yep yep yeah so cool stuff there all right um so with that we

head into my favorite portion of the show survey says all right uh so a couple of episodes back, we asked, how likely are you to give a presentation? And your choices were extremely likely to attend one. Oh, you mean speak at one? Oh, no, definitely not. Extremely likely to think about giving a presentation, maybe a little daydream about how awesome I'd be at it. Or extremely likely to say that I will give a presentation, but go through with it. Ain't nobody got time for that. Or extremely likely to actually give a presentation. I love the opportunity to learn something and share it with others.

All right. This is what episode? 175. So Alan, according to Tatako's trademarked rules of engagement, you are first. Yeah, I don't honestly have a good idea on this one. I'm going to say to think about giving a presentation, maybe a little daydream. We'll go with a very low 30%.

Okay. Okay. Okay, I'm going to say I'd extremely like to think about it with 20, 20, 24%. So you're both picking the same one to think about

giving a presentation. I would have gone $1 if I had been Joe, but that's fine. Alan's going with 30% and Joe is going with 24%. Yeah. He's trying to hit that target. Well, I mean, hey, I got to tell you, if it works for you, then go with it. It didn't work for you this time.

Oh, oh. Busted. with it it didn't work for you this time oh but no busted no uh extremely likely to attend is the number one answer all right yeah at what percent 48 48 all right yeah oh so there's people at least so at least half of the people are at least considering the other three options, which is impressive. I like that. That is the trademark Alan Underwood optimism right there. In action, yes. Now, thinking about giving was the second answer, but Alan, you overshot it. But Jay-Z didn't. It was 29.

29? Wow. That's pretty good wow that's pretty good that's pretty good yeah i was impressed with how close how close you got it though but yeah um but you know we're not playing horseshoes so no it doesn't matter i lost does anybody really play horseshoes seems like nobody would but i love horseshoes it was the last time you played. It's like, it's like the original version of cornhole. Like it's amazing. Okay. I mean, this is total tangent.

Like I said that jokingly only because like one of my neighbors has a ridiculous professional kind of set up for it with like a stadium seating and they have scoreboards and like they make a big to-do of it and it's super annoying because uh you know their parties for horseshoe last like you know and it's an all-day affair but what yeah right exactly that's my thought because like otherwise i'm like wait a minute no horseshoes is something you do on like a 4th of July barbecue or, you know, cookout because like you're not the one cooking and you're bored and there's

literally nothing to do except throw this piece of metal at another piece of metal and see who gets closest. I love horseshoes, man. I would totally, I need to make friends with your neighbor I think is what it is really what it boils down to. Yeah. I can, I can toss the horseshoe that sounds like fun yeah man okay i think you're only doing it though so that like i get annoyed by the you know clink yeah the all day long horseshoe events i mean they have like brackets and everything like it's serious man they they take it serious

i i'm super excited about that to be honest with you i i seriously mean i need to come meet that neighbor that's that's awesome you if you saw this setup and how ridiculous it is i'm not kidding when i say there's like you know bleachers to for stadium seating on it like it is it is super ridiculous like i didn't realize anybody could love playing horseshoes that much until I saw that setup. And I was like, Oh, okay.

Um, all right. So, you know, we just had new years. So, uh, you know,

it's a common thing, at least here in the U S I don't know if it, if it, uh, how popular this tradition is outside of the U S, but you know, here in the U S for new years, you set a resolution.

And it's a thing of like, it's kind of a joke. It's like, how long do you keep the resolution, right? So for this episode survey, we ask, do you stick with your New Year's resolutions? And your choices are, for the first couple weeks, or I'm pretty good until spring-ish, or I'm like a machine. Resolutions are rules that are not meant to be broken. Or, wait, those things are to be taken seriously?

They're broken by noon on New Year's Day. I think I actually know both of yours. Oh? Yeah, I'm pretty sure I know both of yours. Okay. I'm listening. yeah you are absolutely these are the rules that are not meant to be broken i've never met anybody that has such a binary switch for on and off for things as you like people probably don't even know this about you you decided you were going to stop drinking sodas one year and the switch went off like you just

stopped drinking them you i don't need it anymore and then jay-z maybe i'm wrong but i'm thinking you're the springish guy is that about which one was spring looking pretty yeah so i definitely hang on to them but i also uh i change i cannot keep a resolution through a whole year. I redo my resolutions every June at a minimum. Even by then, it's already drifted to the point. By March, the things I'm doing and planning on are totally different from

what I planned on. Yeah. I've also rewritten my resolutions five times already for this year. I'm trying to make acrostic where the first letters I've also rewritten my resolutions like five times already for this year. I'm trying to make what they call acrostic where the first letters spell something. Ah, okay.

So, yeah, for my tech ones. I'm trying to really pare down the list. So, we should do an episode about this. Hey, we should also have another option in here, Outlaw. What are resolutions? Yeah, good point. Okay, I'll add that right now. Yeah, I always view it though, like in all honesty

as like because they are such a joke like if you set a resolution, you just know you're going to break it. Because everybody does. Yeah. But if you aim for nothing, you hit it. Yeah, I'm really good at that. All right.

I'm like, I'm like a hundred percent. Yeah. A hundred percent. Yeah. So, uh, so I, uh, snuck something in here real quick. So, uh, you know, every year for the game jam, we do like a round of of theme voting and the idea is that a theme gives you uh kind of some inspiration you know it's hard to start with a blank page and so the theme is kind of fun and plus it's fun to have a bunch of games that are kind of have something in common and so what we do uh last year we're doing again this

year is we um put out feelers we ask for submissions on the mailing list um forums twitter stuff like that and we gather up lists of suggestions of themes, and then we do rounds of voting. And we just completed our first round of voting. I'm going to go through today and turn the ones out. And I thought it'd be fun to talk about the list here. And actually, I don't know if this is the full list. I don't know how many we're going to keep, but I just kind of went and grabbed like the top, what looked like roughly the top half of themes

so that'd be fun to kind of talk about what those are and these are not in any particular order except the last two which i just thought would be fun to say so uh it looks like all these are going to go on to the next round of voting and remember that game james coming up january 22nd 24th sign up so i'm going to blast through these just really quickly to give you kind of a sense of, you know, what the games are going to be about or what the games might be about. We got no time to lose. Can't stop. All your base are belong to us. There's a ticket for that.

Trust nothing. Failure is the option. A link to somewhere. The rising tide. It's alive. Work-life balance. Spaced out. It's following me.

And the last two, I just wanted to say, these are probably my two favorites. We got snake, Snake, Snake! And Game Jam 2 Electric Boogaloo. So thank you. That was from Prodigal Sons Games and Micro G. So I've actually tracked where every suggestion came from. So thank you to everyone who submitted one. But yeah, those two are leading for me. So now I assume that you two have also voted.

I have not. I need to. What? Alan? My life has been complete disarray for the past month. So yeah, I will get on there and do it here. I'm not going to accept that excuse because it doesn't take that much effort to click the button to vote.

It does. I can't find anything to click on. So no, it's a very good UI. Don't take that away from Jay-Z. Yeah, so I was actually kind of happy because a couple of mine seem to be pretty popular so far. Yours is a ticket for that, isn't it? It's definitely one of them. There were a couple that I thought, oh, that would be kind of funny because I could continue on with the game that I did from last year. Although I don't plan to because I'm like, oh, that would be too derivative and boring, right?

Because mine last year was a game about a ticketing system for developers, right? And so there was one that was – there's a ticket for that that is doing pretty well. And I was like, oh, that's kind of funny. It would dovetail nicely into it. And then there was one that was, there's a ticket for that that is doing pretty well. And I was like, Oh, that's kind of funny. It would, it would, uh, you know, dovetail nicely into it.

And then there was another one last year's theme was everything is broken. So there was another one this year that was, everything is fixed. Yeah. Yep. I was like, Oh yeah, those,

those would go like pretty, uh, dovetail quite nicely from one to the other. I like it. This episode is sponsored by Linode. Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines. Develop, deploy, and scale your modern applications faster and easier. Whether you're developing a personal project or managing larger workloads,

you deserve simple, affordable, and accessible cloud computing solutions. You can get started on Linode today with $100 in free credit for listeners of Coding Blocks. You can find all the details at linode.com slash coding blocks. Linode has data centers around the world with simple and consistent pricing regardless of the location. A hundred bucks can get you a lot of Linux in the cloud. If you're doing any sort of web application, you just want to experiment.

If you want to run Kubernetes, you need some object persistence, you can use that credit for all of that. It's great for running your personal projects and kind of bootstrapping. And it's also just fun to have a computer up in the cloud that you can do stuff with. And so definitely recommend checking out Linode.

We use it for all sorts of stuff and definitely racked up quite a few side projects and just kind of experiments now that I've checked into GitHub here that are all based in Linode. Yep. So choose the data center nearest you. You also receive 24 by 7 by 365 human support with no tiers or handoffs regardless of your plan size. You can choose shared and dedicated compute instances, or you can use that $100 credit on S3-compatible object storage, managed Kubernetes, and more. Hey, if it runs on Linux, it runs on Linode. Visit linode.com slash codingblocks. Again, that's l-i-n-o-d-e dot com slash codingblocks. And click on the Create Free Account button to get started today.

All right. So let's talk about secret management. And, you know, I got to be annoying and talk about OWASP here. But this one is really, it's kind of bundled with the last topic that we mentioned, which was about vulnerability, you know, encryption. And so this kind of gets lumped in with cryptographic failures. So this is a very specific kind of portion of that. But

it's also maybe the hardest thing in security. I don't know. It's really hard. I don't know. I'm pretty good at managing secrets. You tell me a secret and I will hold it so i don't think it's pretty easy it's gonna be a good secret though i don't want no trash secrets uh yeah so and the reason is like once you start talking about uh encryption and security uh

if the question immediately becomes where do we put the key? And so secret management deals with that question, like protecting and auditing access to secrets. And when we say auditing, we mean seeing when someone has used that secret and knowing whether or not they should have been able to and, and making sure that those patterns make sense. And that's actually the right person. Yeah. And I put a link in here,

not because I'm trying to sell HashiCorp Vault to anybody, but there is a video about their product that describes why their product even was created. And it talks about the different challenges with dealing with secrets. And so I think it's about a 15 minute video. If you put it on 1.5 speed, then you can cut back on that a bit, but just to get familiar with the landscape of what secret management is, or it, and actually I said that wrong. It's not secret management. It's secret storage, right? Um, that kind of stuff, because there's actually a thing for managing keys and stuff that is a separate type deal. So, so I would highly recommend watching this video. We'll have it in the show notes, maybe

in the resources. But it's a good primer just to understand what you're dealing with. It's also important to note too, HashiCorp Vault isn't the only capability. I remember before Vault was the big to do, we use one called secret server. Remember that? And basically the idea was that like that one thing knew all the passwords and

you could like, you know, kind of check them out or, or you like temporarily use it. But now there's like capabilities like this. I was about to say last pass for enterprise, for example, kind of fits into that same kind of category where you can like let somebody use the quote secret and the

advantage of like a last pass, for example, you don't even have to know what it is you're using. Like you might not even be able to read the password, but yet you could use it in a, in a form like last pass will fill it in for you. Yep. And, and honestly, I think the only reason why HashiCorp Vault is one of the ones that, that I've probably been more drawn to of late is because they have options for like Kubernetes and, and other situations. And so it's something you can deploy with your, you know, your infrastructure. And so that's why I bring this one out. But yeah but yeah, totally there, there are several solutions out there and probably a lot of them are very good, right? Like I would

have a lot of faith in the last pass one only because Steve Gibson did a write-up on the personal last pass one at one point. And it was amazing. Like the, the level of detail he went into it. So, so yeah, definitely not the only one out there, but like I said, this video is a really good primer and just understanding some of the things out there. And, and so one of the things that they bring up in pager duty is, okay, so we're talking about secrets. Well, what are secrets, right? They can be a token. They can be a key. They can be a password. They can be a username. They can be anything that is sort of sensitive that you want to keep protected, right? That's really what it boils down to.

It doesn't have to just be a password. And this next one is amazing because we've talked about it several times and we've all done it. I mean, just about anybody who's ever written any code has probably done this. You should not put secrets in your store, in your source control, right? You need to do your level best to make sure they can't accidentally be added to source control.

So if you are using secrets on your local system, they need to be outside the folder where you have your get repo or whatever source control you're using, right? Like they should not accidentally even be able to be added to source control. This is where it gets complicated though. Cause like,

um, Jay Z mentioned this in the last episode. And in fact, you had a term for it that I don't remember what it was called, uh, where, where you do security development first as part of it, but move left,

start left. Yeah. Start left. There you go. Like it can sometimes just be frustrating because sometimes you just want to get started, right? And solving security isn't the thing that you're trying to solve, but yet you get lost in the details of, okay, wait a minute, how do I just move this out?

And sometimes it's just... You're tempted to code that in, but, um, you know, even, even the user ID itself can be a hint as to, uh, what the credential is that you don't really want somebody to know. Yeah. It's exhausting. Uh uh working on security is not fun but there's a real talk jay-z uh not fun to work on if you're good at it people don't like you it's very unfortunate oh that's actually true people anytime somebody throws up the security flag everybody's like man i gotta get stuff done you know leave me alone but it's unfortunate that's why you just start left start there get really good at it and just yeah keep it rolling yeah and and

this whole thing that you shouldn't put secrets in source control it happens all the time um you got to do your best to try and make sure it doesn't. But the problem is anyone with access to that code now has access to the secrets. And we've heard on GitHub and GitLabs and probably Bitbucket and every other one have had data breaches to where people were able to log in and download source code. So if you have your passwords up there, then people have access to your production systems,

potentially, right, with all your good stuff in there there so here's where you can get super tricky is that like if you accidentally store it in there then you're like oh well let me just overwrite the file well technically it's still in the history still there yeah so you didn't really get rid of it unless you like go through an operation like a destructive operation to to amend the history in your repo, which can get hairy. But that's why there's like services out there like secure code warrior, right? Where you can try to like ingrain these good start left practices into your,

your processes to where, you know, you don't even think about it. Like you're just automatically like, Oh, I know I got to use this other't even think about it. You're just automatically like, oh, I know I've got to use this other thing for my password management and don't add it into my code

manually. It's so easy just to copy and paste that password in there when you're just working on things, just to get it working. You're trying to rule something out. So, PagerDuty mentions they use vault i mean vault is if you do anything in kubernetes like they're just crushing it um securely stores secrets and this provides that audit uh history that we mentioned and rotating uh if and when it's necessary rotating can be really hard and that's why you know when stuff does get checked in to Git, depending on

how things are set up, that can be a really hard lift. If you've got a production password in there, that might mean taking production down so you can swap that secret out if you're not set up for it. And you should be set up for it, but that's one of those things that's hard to bolt in afterwards, which is why

we say start with security. Because if you try to go in after the fact and sink of sink that stuff in it ends up being bolted in and it ends up really hampering your ability to adapt to things like that whereas if that's part of your kind of um baked in from day one then that's going to be something that you're used to dealing with and do you ever notice how like everything in computer science is like this though it's like if you uh like think about the way you write your code for example if you uh don't write your code with unit tests in mind first then you like bake independencies and then it's like you know near impossible to like get rid of some of those dependencies and to like mock things out so that you can write unit tests for it right

and here's the other, another example where it's like, well, if you didn't code for security upfront or keep, you know, have security in mind when you wrote it upfront, then you could end up baking in dependencies and, and things that you didn't intend to.

And now it's near impossible when it comes time to like, Hey, I need to change your password. And it's like, Oh, it becomes a big to do. Yeah. Well,

I mean, so I think I talked about this on maybe a previous episode too. I can't remember now, but this whole notion of rotating secrets or rotating passwords or keys or whatever it is like in the past, I guess in my mind, I always thought, well, if you're rotating keys, that means you have to go back through decrypt everything that was there and then re-encrypt it with a new key. And this is where, again, trying not to roll your own thing really matters because what you'll find out is like Vault and I'm sure a lot of the other password management systems out there, they actually build in versioning with it. So if you have a key that you're using to encrypt data, when you encrypt that data, it'll store the version of that key with the data. And so when you go back to decrypt it, it'll say, Hey, go give me version three of this key to decrypt this data. What happens is if you need to roll your keys, typically what you're doing is you're rolling your keys for any

new data that comes through, right? So, so you're not, let's say that you have a billion items that have been encrypted with keys in the past. You don't want to have to go pull those billion items back out of storage, decrypt them, re-encrypt them and store them again. That's a lot of operations. But what happens is systems like vault will actually, you can tell it that, hey, this key version 3 is no longer usable for encrypting, right? And so Vault will know or these other password systems will know, hey, if I need to encrypt something, it's got to use version 4 of the key now, right? But the next time that you go to pull some older information that was encrypted at the time with version three, that old key is still there in the password management system. So you can decrypt it. But what happens is when it decrypts it, it will automatically re-encrypt it with a new key to roll that key at the time that it's accessed, right? So this is where just

knowing that you're using tools that are built for these things, handle all those things for you, right? You're not having to build your versioning system. You're not having to build in the thing that says, no, you can no longer encrypt with this key. That's all handled for you. It's all audited. It's all provisioned. All you have to do is know how to use the system, right? And so it forces you into good practices. And that's why like at the top of the show, when we were talking about using encryption algorithms and all that, don't roll your own.

It's not easy, right? Like, even what we're just talking about right here, just encrypting and decrypting something using a system has a ton of other features built in that you might not have even been aware to think about, right, if you were going to roll your own. You didn't realize you needed. Right, or didn't need.

And rolling keys has always been something that's really important. If one of your keys is compromised, you don't want to use that anymore to encrypt anything. And if a system has it built in where you can say, hey, just roll this key, you're done. Assuming that you're accessing the thing the proper way and using it, all you have to say is roll this key and you're completely over now. Now you might need to, depending on how bad that breach is, and you might say, hey, well, we have a lot of customer information that needs to be in there. So you might yourself say, okay, go download all this stuff and have it re-encrypted just to be safe.

But at least the tools are there to help you with that. So, well, it reminds me too, of some of the conversations that we've had from the designing data intensive applications book, where there were some operations that it was easier to do on a read, you know, on an as needed read basis than it was it was to try to, for example, rekey your entire index, right? It might be easier to just leave the current index in place as you need to move things along and move it. But I don't remember the specific example that was like that

from the Designing Data Intensive Applications book, but I swear there was one like that where it was doing something on the read. Do you guys remember what I'm talking about? I vaguely remember that too, but I couldn't tell that where it was doing something on the read um do you guys remember what i'm talking about too i i vaguely remember that too but i couldn't tell you what it was i mean i said the indexing but i feel like that was wrong but was it the ss tables or something i can't remember there was something where it indexed as it went and it wouldn't redo the files i know that um for instance um how we dealt with them in the past, not org files. What are the other files? Parquet files,

right? That's a similar type thing. A hoodie. We talked about hoodie at one point. Hoodie does something similar as it will build transactions on top of it. And then at some point, come back and redo it, right? So that it's more efficient and all that. But at any rate, I digress. I mean, the point is, is that like, if you think about like a super large system, like, um, you know, like your, your Google's, um, Microsoft, Apple, Facebook, Amazon's of the world, right. If, if they had to, uh, re-encrypt like that, you know, Google's key gets out and they need to re-encrypt all the email that's stored on disk, right? You know, that would be a huge operation if it had to be done, you know, all in one shot, right? Versus, hey, like as that one gets,

needs to be read, we'll re-encrypt that with a new key as we go. So it's just, it's just an ability to like scale out your operation to like, you know, doing it on an as needed basis. This episode is sponsored by shortcut. Have you ever been really happy with your project management tool? Most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant

prodding. Shortcut is different though, because it's worse. No, no, no, no. We mean it's better. Shortcut is a project management built specifically for software teams and they're fast, intuitive, flexible, powerful, and they have many other nice positive adjectives to go about them. So let's take a look at some of their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they want. Org-wide goals and roadmaps. The work in these workflows is automatically tied

into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and vice versa. They have tight VCS integrations. Whether you use GitHub, GitLab, Bitbucket, Shortcut ties directly to them so you can update progress from the command line. Keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly with their power bar, allowing you to do virtually anything without touching the mouse. Throw that thing in the trash. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burned down charts and other reporting. Give it a try at shortcut.com slash coding blocks.

Again, that's shortcut.com slash coding blocks. Shortcut, because you shouldn't have to project manage your project management. So what else do we have here? Like don't hard code or come up with crazy ways to get secrets in your applications. I feel like we already beat that one. Um, secrets should never be shared, but then like,

is it really a secret? If only you know it, right? Yeah. How many times you've been somewhere where everybody knows a password for one system. And then if something changes in there, somebody deletes something,

you never know who did it. And so, uh, that's a bit of a problem or worse. How many times have you ever been in a work environment where like somebody's like hey i don't know the password and they're like you know many people chime in they're like well it's probably this try this right yep oh go ahead oh uh it was gonna say another uh technique here is uh having a jump server

and uh bastion is the the name i'm familiar with which basically limits access to uh those boxes so basically you have to jump into that box and from there you get into the production system so that's not gonna help you with saving the secrets but it's a way of uh changing how you can even access those secrets which is nice i mentioned go ahead i always just kind of viewed that as like a, a gatekeeper between you and like a production system, not necessarily anything to do with secrets though. Yeah.

Yeah. It's yeah. That's what I was kind of thinking. It's you know, what is that particular about? Like it gives us like one box that can really lock down and kind of make sure as in a, you know,

is in good shape and is monitored and everything. It doesn't have crap installed on it. You don't have to worry about adware installed or key loggers or anything installed on there because you've got that kind of setup. And you can really limit what people can do on that box, which is nice. And also, it gives you one spot to turn off. So, if you want to turn off broad access, like boom, just turn that box off or take it off the network or whatever but you know the secret the secret management aspect of it i don't really get other than that's a good way to kind of make sure you only access it from that one spot yeah i think what they were trying to get out there is if you can't create more like

there's some systems where you can't have a bunch of passwords, right? Or a bunch of, of logins to that system. So they were saying in the situation, let's say that you have a database that you don't even have control over who knows. Um, but there's only, there's only one set of login credentials to that database system because you can't get to that thing directly. You could create a bastion server. People's logins to that bastion server would have access to that database, but your authentication credentials would work for that bastion server. And so your access would then be audited, right? Because you'd log into the bastion server and then you could access that database system that only had one username and

password, right? That's probably not a great example, but that was how they were saying you could manage a situation where you cannot create multiple logins with fine-grained control in an area. The next thing that they say, and I am huge about this, and God, I'll have to give an example here in a minute, but it drives me absolutely insane. Never share your passwords over insecure channels. Never. If you're using Slack, that is not secure. That is a public service, right? I think email is awful. Most people don't even know how email works, but if you send an email, it could bounce through a hundred different relay servers on the internet before it gets to where it's actually going, depending on the domains that, that own the emails and all that kind of stuff. SMS is not secure. I can't tell you guys how many times when I was looking to buy a new house

that I had people in the mortgage and the real estate industry asked me to send them sensitive information through email. And I'm like, no, I'm not doing it. You guys not have a secure file upload system that I can use. Like if you can't give that to me, then I'm going to have to figure out something like I'll put it up on box for the next 30 minutes and you can download it or something. Right. Like email is the worst. And they're like, well, our email secure. And I'm like, yeah, right. If I'm sending it from some domain that you don't control, email is not secure. Like, you don't know how many hops it's taking before it gets to your network. And that means that my information is sitting on some server out there that you have no idea about. for people who aren't in, um, technology, they,

this is the thing where like, I was thinking about this the other day, like where we use words and, you know, to try to relate things, but then people that might not be in the same know as you, they hear that word and then they'll, um, uh, you know, use others around it. So like I, what brought it up to mind the other day as I was watching, as I was watching an old TV show and they were talking about a virus, you know, computer virus and, uh, the, um, in the show, they were referring to the cure for the computer virus in like medical kind of terms. Right. And it was just because like, you know, this common word of virus was being used to describe

this thing. Right. And in the case of email, right, like it has this, you know, the root of the word mail in there. And so people assume like, oh, well, it works like how my mailbox does. Like I put a to Alan Underwood on the envelope and it's from Joe Zack. And you can't read the contents of what's in that envelope. And you just see the metadata of who it's to and from. And that's not true. In the case of email, as it's going around across the internet, it's more like a postcard. Everybody can read that postcard if they wanted to take the time to read it. But, you know, trying to explain that to like, you know,

your parents, for example, who, who, you know, are very comfortable with how mail works and maybe not so much into the, into computers, you know, it's, it's different story, right? Yeah. And, and what most people don't realize too, is not only is it readable by those, you don't know the path it's taking, right? So in your, in your real world mail example, you know, somebody from the post office is picking it up and then delivering it to another spot. So it's a trusted service, right? We'll call it in, in the email world. I can set up a mail relay server myself in almost no time. And that means that I can now be one of these routable places on the web that is a hot point for mail to make it to

somewhere else, right? So I potentially have copies of a lot of people's emails on my own server. And it drives me absolutely insane when companies, industries that deal with sensitive data don't know what they're telling people to do. I actually had a bank person one time tell me I forgot to I lost my password for logging into a bank account. Right. And she's like, well, you're you're you're secret in here, like your mother's last name or your mother's maiden name or something, it looks like gibberish. I would just put the same answer for all these three security questions. And I was like, I know you're not telling me that. Please tell me as a professional in the baking industry, you're not telling me to use the same simple answer for all these three security questions so that anybody could get into my account. Like that doesn't make sense.

I hate the idea that these security questions have become like so commonplace, you know, in the last couple of decades, like it is a thing. I don't put real information in there. I don't either. In my password manager, I'll like keep track of like what the question was and what the answer was that I used. And they'll always be bogus stuff. Can you read it? Yeah. Two factor authentication or something like that. But at any rate, yeah, man, just be aware of if you're using some sort of service like Slack or email or SMS or whatever, do not, if somebody is like, Hey, what's the password to the database you can't get in?

Don't put it on Slack. Don't. I don't, I almost put in here, but this might be wrong. Something like Microsoft Teams, I'm not sure. Is that a hosted service from Microsoft? And is it encrypted end to end? I don't know. Yeah, I'm not sure is that a hosted service from microsoft and is it encrypted end to end i don't know yeah i'm not sure i think you can have hosted solutions too so you could run your own i know they used to i yeah i remember back in the day when when companies would buy exchange server

and an office or whatever they you could have the messaging that was actually hosted internal to the company um but that also brings up another point. Don't, don't just assume that whatever your communications on any of these platforms are, are private, right? Like if, if you're working for a company, um, just assume they can read everything you're saying, right? Even if it was, uh, encrypted or whatever, like I still, like you still wouldn't want to, um, you know that to share the password because like let's pick on Slack for a moment. Like let's pretend that Slack was encrypted into end communication and it was encrypted at rest. with Slack to go and like download the, you know, the entire, you know, conversation history or go through past conversations. Like it, it's not, it's not difficult. And like Slack has a really

good API that you can go through with. So like, you know, those past conversations, even though they might've like aged out of view to where you can't see them, they're still there. Right. Right. They even, if you're on a plan that says, Hey, you know, pay X number a month for, you know, to unlock more messages. As soon as you do that, then all your old history shows back up, right? Like they're not deleting that stuff. So very important, but here's the interesting thing about what they said is, Hey, look, it's not the end of the world. If you if you're listening to this right now and you realize, oh, man, I just put in the past 10 production passwords to all the systems. Right. It's not the end of the world. It happens. But what they do is they let their security team immediately know that there was a problem.

Right. And we assume that you have a security team because you're big enough and they got the budget for it. Um, and then you find out how you need to rotate the keys and the passwords or whatever it is that you shared. And then you have to do that. Like it's, it's a big deal.

Like they basically make it out. Like if you accidentally do share it, there are steps that you need to take to mitigate that at that point. Yeah. The point was, is that like, you're not going to be judged. You're not going to be like, you know, people aren't going to get mad at you. It happens. And, you know, we have procedures and facilities in place to allow the ease of rolling the passwords. And so it's better that you speak up as soon as you know that this is an issue so that we can go ahead and get that process started and, you know,

and then you'll learn from it. Yep. You know, like there's always the joke about like, uh, sorry, I didn't mean to cut you off, but like every time there's like an AWS outage or something like that.

And, you know, you find out that it's a configuration bug that like brought down all of AWS or something like that. And you know, a lot of people would joke like, well, I guess somebody got fired today.

But I always think that like, no, that person is now an employee for life because they learned a very valuable lesson that they won't make again. And you know, management probably recognizes that like, huh? You know?

So I mean like, was it costly? Yeah, sure. But you benefit from it. You do. And on top of that, typically companies like Amazon or whoever, they learn that, oh, well, we need to probably have another check in place to make sure that this can't happen. It strengthens the system overall over time. Yeah, totally.

Now, I'm being totally optimistic. They probably totally were fired. But I want to believe in the world, though. I want to believe in it. It's going to happen again. I want to be curious about the rates. I don't know if security organizations, if you're working on a security team in a big organization, if like keep track of stuff like that like how often things get logged or how often they have incidents i do think that they do be cool to see uh see that over time because you know it's going to

happen again so yeah i agree like firing the person who did it is a terrible idea because it's one of those things that like happens pretty often right Right. Well, speaking of logging, and this is by no way a stab at the log4j bug, but they say to never allow your secrets to be logged. So when you are logging things from your application, you don't want to log like, oh, hey, and here's the credentials that I used. Because again, even the user ID itself could be a leakage of information, right? Like, if it was always the same user that was being used for everything, then somebody who was trying to break into the system would know like, oh, okay, there's only this one user. And if I find that one password, then I'm, then I'm good versus, uh, you know, if you had like different users for different activities or whatnot. So, um, you always want to like make it difficult, you know, not give away any information for somebody who might be trying to break into the

system. So don't, don't log anything related to secrets. Yeah, and they did point out that this could actually be really bad if, let's say, that your service that you provide is some sort of transitional behind-the-scenes thing that allows customers to log into something else. One that comes to mind is I remember years ago when I was running a bunch of different WordPress sites, like to upgrade and manage plugins and WordPress can be an absolute pain in the butt. If you've got a bunch of different sites, right? You have to log into each one individually. Well, there were some services out there that would allow you to put in your credentials and it would automatically go and log into those systems for you, right? Well, if they were logging and they were accidentally logging out your credentials to those sites, that's really bad, right? So you want to be super careful about what you're logging because it might not even be your sensitive information. It could be your customer

sensitive information. And it includes the email addresses, phone numbers, names. Yep. And they say, be sure you're sanitizing your log data right so um if you know there are certain fields in in your data sets that put that have sensitive information just make sure those don't go in or um what's it called when you when you mark them through uh redact redact mask do something like that right so that so that it just doesn't show up in the logs. Yeah. I'm always surprised that like, um, I know I've picked on Jenkins a lot in, in recent episodes, but, uh, I'm always surprised with Jenkins with how well it does at masking things. Like if it'll recognize like, Oh, I think this is a user credential. So I'm going to go ahead and mask it in the, in the log.

Yeah, that's nice. Hey. And so I had one last link I threw in here and I think this came from pager duty. It was, and this was an overview of different secret management tools. And what I like about this is if you guys ever gone searching for, you know, I don't know, software or something, and you'll get people that just put bullet points next to things like this one has this and this one doesn't have this. And it's like, well, that doesn't tell me anything. This is actually a really nice write up that somebody from PagerDuty did that sort of talks about the things that these tools were useful for and why you might choose one over the other. So this was a really good brief write-up of a

bunch of different tools that were just excellent to be able to browse quickly. So I highly recommend checking that out. If you don't have any secret management tools or anything, this would be a good place to start looking at them. Yeah. And with that, we wrap it up so we'll have a bunch of links uh to the resources we like for this episode and with that we head into alan's favorite portion of the show it's the tip of the week all right so sticking with the theme of this particular show and being that i mentioned vault several times hashy court vault several times in the episode, I thought I would give the tip of the week of one of the reasons why you might want to consider vault. And it's their plug in architecture. So behind the scenes, vault mostly stores secrets and versions and all that kind of stuff.

Right. It also does so much more. an encryption in transit like access or API so that you can encrypt stuff using the services, all kinds of things. But what's really cool about it is they really try and set it up to where you're not storing or dealing with the secrets directly at all. So for instance, they have plugins for authentication and what it is is sort of a pass-through to different things. So you can authenticate with Kubernetes, Okta, Radius, TLS certificates, usernames, passwords, GitHub, cloud, all kinds of things, right? They have plugins that will pass through and use the systems behind the scenes that need to do that authorization. Another thing that I thought was really great, and we've dealt with this stuff in the past too, is you don't necessarily want

your applications logging directly into a database. This thing can provide that pass-through authentication for you. So as long as your system or your service is authenticated to Vault, then Vault can actually provide the login mechanism to Postgres, Elasticsearch, Couchbase, Cassandra, MySQL, MariaDB, all kinds of things, right? So they have plugins for all kinds of things. And another one that's a big one that I mentioned earlier in the show is secrets management is different than key management. So if you're creating keys like asymmetric or symmetric keys for encrypting data, a lot of times that is not in your secret stuff. That's what you a key to do encryption. And behind the scenes, it will use the key management services in the cloud so that you

don't have to code your application to use one specific implementation. It'll use Vault's abstraction. So tons of plugins for this thing that make it extremely useful especially if you're working in a cloud world or some sort of cloud agnostic world that you want to deal with very cool jay-z all right yeah so uh i'm still super hyped about the game to jam and so i've been doing a lot of kind of prepping and even streaming of the game dev stuff so i wanted to share a couple things i thought were really like uh just really useful i've kind of discovered recently and uh it just kind of goes along with what i said before which is uh you know unity and i'm sure unreal and

godot have the same kind of things um where where it's basically common game functionality is built in to the tools. And so the two I wanted to mention now are animation clips and nav meshes. And so animation clips are a way to create animations, which I kind of originally associated with being like advanced character animations, like a character picks something up or shoots a gun or something or jumps but you can actually create animation clips for all sorts of tweens which is basically moving between two numbers so if like if you want to rotate an object then you can do it with animation clip if you want to change the color over time or something you can do that here and basically what you do is you start, you define keyframes and say, second zero, this needs to be this value.

And the second five, it needs to be, you know, these values. And it can go just get crazier from there. But that's much easier than kind of creating the kind of classes that you see a lot of times in like Unity tutorials, which do like one thing, like changing a value or rotating an object or applying a force or something to it. And so it's something I've come to more recently, but it just makes it much more powerful, but don't worry. There's still plenty of code to write because you know,

it's a, it just, you're working at a higher level at that point. So it's nice. Originally I was doing a lot of like C sharp stuff just to like turn things on an on axis or pivot things and it's just you just don't need to do that and the second one i want one missions uh wanted to mention is uh nav meshes which are really efficient way to create kind of navigable zones so you can do basically a star kind of pathfinding type things where you can kind of tag these objects as being a navigation static.

So saying they're not going to move. And what unity is going to do is it's going to go and it's going to bake a navigation polygon that can figure out what objects can do to kind of walk around your scene. And from there you can give those objects, they call them nav, nav call them nav mesh security agents. You can tell these agents, hey, go to this spot. And they'll figure out based on that mesh that was created, the fastest way to get there,

most efficient way to get there. And so what it gives you is really quickly and really easily a way to have things moving around your map and walking around obstacles. And it gets more advanced and so you can have them doing jumps and um avoiding objects dynamically and stuff but it's just uh it really gets you a long way through a lot of the way through a lot of different kinds of games like tower defense i remember our last game jam we saw a lot of tower defense games and i was really surprised by that and we kind of talked about it and some of the feedback we got was people said that tower defense games are one of the easier

types of games to create i thought that seemed totally ludicrous at the time and now i get it in like 10 minutes i can set up a nav mesh with some obstacles and have things avoiding it and other things shooting at it's crazy and so i recommend just for anything and you'd be giving a google first because uh although it can be frustrating, sometimes it kind of feels like you're dealing with almost like third parties, you know, where you're constantly having to learn new system after new system. You can really get a lot done. And a lot of times these systems interact with each other. And so it's it's worth taking the time to learn those things rather than recreating your own. And like I said, don't worry, there's still plenty of C sharp to write.

So, yeah. So I guess your code that you're writing then is more about the, the actual business logic of the game, as opposed to just trying to twirl something on the screen. Right. Like, so I would say integration, it's just kind of like web development or anything else. Now after, you know, maybe back in the nineties,

you were writing a lot of P tags and divs, and you were writing a lot of select name from tableware clauses type stuff. But in the year 2020, you're doing a lot more integration with different tools and ORMs and APIs and things like that. And so the code that you write nowadays

in web development is much different than the code that you write nowadays and like web development is much different than the code that you wrote 20 years ago. And that can be frustrating sometimes. You've seen my code? Maybe not. Yeah. You're still writing p-tags and link tags. Marquee tag. That's right.

Cool. I have a feeling though that like when the game where it comes around like, you know, Joe has been constantly two or three times a day live streaming his Unity efforts here on Twitch for the past couple weeks. So by the time

the game jam comes along, he's going to destroy us. He'll have some super well-polished game. I might as well just spend the game jam playing Overwatch and Joe will have recreated Overwatch.

I promise you that will not be the case. Okay. For my tip of the week, I don't know that I'd ever mentioned this one before, but I thought that I would because it's a pretty useful plugin for Chrome called Go Full Page. And despite its name, what it does is it takes a screenshot of your page and it can be super handy. So like, you know, especially for work dev kind of purposes, you know, maybe you have a page that scrolls the entire screen and you want a screenshot of the whole thing

to like write up a ticket or whatever. Um, this plugin can, uh, scroll the screen to get the entire screenshot for you. Um, so pretty nice little thing. I'll, I'll have a link to that in the, uh, uh, show notes for the tip of the week and yeah, go full page.com is the, uh, the website for it. But you know, obviously the Chrome store link is a lot of gibberish. So I'll include that version of it as well. And with that, yeah, hope you've enjoyed this summary of PagerDuty's amazing security training that they've

provided out. I don't think we technically finished it, though. We probably got through, like, number three of their bullet points. We got through four. Okay. Four. And, yeah. So, subscribe to us on itunes spotify stitcher hey by the way like i said if you haven't already left us a review and even if you have left us a review if you're a spotify user uh we would greatly appreciate some uh reviews there just uh

click that star button and uh you know that five five star, obviously, let's be clear. And yeah, we would greatly appreciate it. Alan's going to update the site where you can find some helpful links at www.codingblocks.net slash review. Hey, and while you're up there, make sure you check out our copious show notes, examples, discussions, and more, and send your feedback questions and rants to our Slack channel, which if you're not a member of, you should go check it out at codingblocks.net slash slack. And you can use some tweets. We got some

tweets over on Twitter at CodingBlocks. And you can also go to the website, codingblocks.net, and find links up there to all of our other socials and, you know, get you some tweets.