The Equitable Society presents this is your FBI. This is your FBI. An official broadcast from the files of the Federal Bureau of Investigation presented as a public service by the Equitable Life Assurance Society of the United States and the Equitable Society's representative in your community. Before opening tonight's file, this first broadcast of 1946, this first week in January, is a good time to look forward into the future and back at the past. We of the Equitable Life Assurance Society of the United States are happy to report that the end of World War II finds our society in a stronger position than ever before. Our membership, our assets, and the amount of life insurance owned by our members increased during the war years. So the Equitable Society has weathered this war as successfully as it did three previous wars and seven major depressions. We wish to report also that in the future, as in the past, the premium dollars of Equitable Society members will be invested in ways that benefit the entire country. And by serving its members, the Equitable Society will continue to serve America. Tonight's file, crime in the roaring 20. This week, as America begins the first year of another post-war era, he faces here at home just as she did some 25 years ago, those many grave problems which grow out of war. But of them all, none is a greater menace to the right of American citizens to life, liberty, and the pursuit of happiness. The net problem which is splashing more and more black ink across the front pages of our newspapers every day. Crime. Addressing the International Association of Chiefs of Police recently, Director J. Edgar Hoover of the Federal Bureau of Investigation, your FBI, uttered this warning. After every great war, there has been a recession of moral fortitude. This one will be no exception. I hope, as you do, that the racketeers, the overlords, the desperados, and the criminal scum who characterize the roaring 20s will not come back to the American scene. I fear, however, that this is wishful thinking. Once they get a start and find they can succeed, we shall face very serious trouble. It is the delinquent youngster of the war years who is now graduating into the ranks of seasoned criminals. They are now becoming the post-graduates of crime and are committing the more despicable offenses. It was the delinquent youngsters of 1917 and 1918 who graduated into the seasoned criminals of that post-war era. Who made the roaring 20s roar? Roar with the explosions of pistols, machine guns, and pineapple bombs. Will it happen here again? This is how it happened then. This is how one delinquent youngster of 1917 became a post-graduate of crime in the roaring 20s. In the cellar room of the Black Cat Club, the roadhouse just outside a large Midwestern city, the slot machines and dice games, as usual, were taking more than giving. While upstairs on the main floor, the young hip-flass set were drinking bootleg liquor in dim corners and dancing the black-bottom to a pastely-faced orchestra. Presently, young Red Martin and two companions sweep into the room and take over a boot in a corner. Hey, waiter. Yeah. Get these guys a set up and bring me a coke, will you? Okay. What's with the coke? Why don't you take a real drink, Red? None of that rotgut for me, pal. You can't make dough out of it and ulcers, too. And I'm gonna make dough out of it. Yeah? How do you mean? I'll tell you all about it in a minute. Hey. Look. Yeah? A couple of dames over there making a big play. Forget him. I'll show you something with real class. Where? That blonde. Huh? There she goes now. It's out the back. Hey. That's for me, fellas. Are you kidding, Red? You know who that is? That's Legs Miller's name. I know. Guy that runs this joint? Yeah.  Don't you know who Legs Miller really is? Yeah, I know. He does little food-legging. A little. He ain't in the pint and quart business. He runs his stuff by the truckload. Yeah? Sure. And he's the guy I'm here to do business with. Are you kidding, Red?  Your coke, Red. Okay. Say, uh... Tell Casey I want to see him. Sure. Now, before this Casey gets here, I want to tell you guys something. Okay. After now, we've just been playing a nickel in dime rackets. It's time we graduated. Oh. We'll hook up with a gang like Legs Miller's. Make some real, though. And if we're smart, we'll have our own business before you know it, okay? Well... Well, gee, Red, I... What's the matter, you yellow? No, no. Of course not. You want to see me, Red? Yeah. What about it? You know what about it, Casey? Yeah, but Legs ain't... Don't give me that. He's here. I saw his name go back a minute ago. Look, Red. The guy is busy. I want to see him now. Okay, kid. Come on. Stick right here, boys. I'll be back with a deal. Yeah, Casey? Hey, got a minute? What is it? I, uh... I got a guy here. What's the talk for you? Okay. Bring him in. You want me to leave? No. Stick around, honey. Quiet, Red. This here is Red Martin. Hiya. Hi, Legs. What do you want, kid? I want to talk business. I'm not a kid. He means now he's chiefin', honey. But where did he get those big shoulders? You like him, sweetheart? What do you mean by that crack, kid? Darling, he means do I like him, and I do. Look, Legs, do you want to talk business or don't you? Okay, Mr. Martin. What kind of business? Did Casey tell you anything about me? Yeah. What's on your mind? Well, I got a proposition for you. Yeah? You've been doing pretty good for yourself, but you could be doing a whole lot better. No, kid. Yeah. That's my deal. This'll really put you on top. I got some guys, you got some guys. I bring my guys in and join up with you and work on a commission. Before you know it, everybody in the whiskey business is working for us. That's your proposition? Yeah. How's it sound to you? Casey, bounce this bum. Wait a minute. I said bounce him. Keep away from me. I'll walk out of here under my own power. I want you to remember something, Legs. Next time you and me get together, it'll be you that gets to bounce. What?  Who are you? What happened, Red? Did you make a deal? No. But I made a promise. So let's get started on this. What are we going to do? First we're going to get lots of power on wheels somewhere. Come on. Crime, like history, repeats itself. This juvenile delinquent product of World War I has his counterpart today. Somewhere in the nation a youngster like Red Martin may be planning a similar career of ruthless violence. Let him listen, then. Listen and learn. The first report on Red Martin is received in the local office of the FBI. Special Agent Brown speaking. All right. What is it? Forest town across the state line last night. Yes? Three young fellas stuck up in all my cat-likes at hand. What are the details? The car. What do the thieves look like? Give me your light, will you, Casey? Better wait. We're going to stop for this railroad crossing, you know? Don't worry.  Looks clear to me. Give me that light before I give... Okay, put your hands up and get out of that... What is it? Hey, what's the idea?  They ain't fooling, Casey. We better haul out. Yeah.  Right. This is for not moving when I told you. Drive more to the ditch, Al, quick. Okay. You know what? Drive the truck. Joe, get at it. Sure. Casey, I guess we better rough you up a little, too, so everything will look on the up and up for you when your pal comes out of it. Okay.  Legs might start wondering. Just tip me off about it. Right. Hey, you know something? What? Knocking off this truck makes me and legs partners after all. It's the Cadillac we're looking for, all right? And I've got some fingerprints. They abandoned it right at the scene of the hijacking? Yes. The watchman at the crossing who saw it take place said one hijacker drove off with a truck. And while he was calling the police, the other two disappeared on the run down the tracks. What about the two men on the truck? He was sure one of them was slugged. But by the time he made the call and got over there, there wasn't a sign of anybody or anything but the Cadillac. Since the victims didn't bother to report to the police, that tells what was in the truck. Liquor. Exactly. But why did the hijackers leave the Cadillac there? They don't have to worry about a hot car anymore. They can buy their own now.  The start of a new gang, eh? Yes. So let's get busy and find out who they are and see how soon we can stop them. Hiya, Red. Oh. Hiya, Joe. I've been looking all over for you. What's the matter? Huh? Nothing. Nothing. I just thought we might get a couple of dames and go dancing. I'm a scratch. Why? I already got a date. Oh, yeah? Who? Legs Miller's dame. Huh? Yeah, I sent word to her. She should be here. Oh, you did, huh? What makes you think she'll come? She'll come. You know, eh, you mean plenty of trouble, Red? This kind of trouble I like. Yeah, but if legs find out... Wait a minute, wait a minute. Huh? She's coming in the door. Blow, will ya? Okay, but take it easy, will you, Red? Hello, shoulders. Hi, honey. Sit down. Thanks. You want a drink? No. Okay. How's his legs? He's all right. Did you, uh, tell him you were coming here? No, what do you think? Well, he's got an old sonora later. What do you mean? About us. You're wonderful. That's right. What about us? We're in business, baby. Just like that, huh? Look, I had this figured months ago. And when I got ready for you, that's when I sent you the word. Really? Yeah. You see, there was a lot of things I had to do along the way. Get cars, which I got. Get dough, which I got. And now you. Which you ain't got.  I'm your kind of guy. How do you figure that? You hear that music? Is that what the guy is playing? Yeah. That's my favorite song. That's why he's playing it. See the box there? Yes. It's loaded with them orchids. Your favorite flower. And I got an order in with the jeweler for a ruby ring. That's your favorite rock. How did you know all this? I done research on you, honey. Now you see what I mean? I'm your kind of guy. You're forgetting something, Red. What's that? Legs. What about them? He's gonna have something to say about this. I figured that too, honey. You know something? I'm gonna give him a chance to say it. Gonna pay a call on Mr. Legs Miller tomorrow night. I found the dealer finally, Jim. Good. He sold them two second-hand Cadillacs. Here are the descriptions. Registered in what name? Jack Smith, obviously an alias. What did Jack Smith look like? The one with the red hair according to the dealer. There's a report from Washington, though. Thank you, friend, Jim. Thanks. Did we get anything? On the redhead, yes. His name is George Redmartin. Served six months in a reformatory in 1917. Here's the full description and photo is on the way. Good. I think I'd better get over to police headquarters and see if they have anything on the private life and public habits of said George Redmartin. All right, you guys. Listen to me a minute, will you? Here's what I figure we do. Yeah. Hi, honey. Come on in. A convention? No, sweetheart. It's sort of like a reception committee. For who? Mr. Casey. Oh. The boys here got some kind of bad reports on it. Like what? He's been hanging around with that punk Redmartin, which just about accounts for a lot of that liquor we've been losing lately. Yeah? Hi, Alex. Come on in, Casey. Okay. What is this? A meeting or something? Yeah. A real important meeting. It's about you. What do you mean? Where have you been tonight? I was just down collecting a little dough I had righting in an egg. Why? Let's see the dough.  Now wait a minute, Alex. What's the matter with you? The horse's name was Redmartin, wasn't it? Redmartin? I don't know what you're talking about. Okay, boys. Pick him up. Take him out for a little ride. Now wait a minute, Alex. Give me a chance with you. Get him out of here quick. All right.  Cover him, boys. First, when he makes a move for his heater, gets a belly full of this. Hi, honey. Hello, Red. Legs. This is what I told you would happen, remember? Yeah. I want all you guys to listen to me. I'm in it. I'm taking over. And you don't want to play ball with me. Line up against the wall, and I'll check you off right now. Okay, then you're working for me. There you... You come just in time, Red. Jasey, get over there with legs. What? I said get over there. Oh, sure. But, uh, what's your idea? There ain't gonna be any double crosses in my outfit. Hmm? With double cross legs, you might double cross me. Now take it, both of you. Oh, all right. Wait a minute. From now on, as long as you play it straight, these big shoulders are yours. Now for a moment, let's talk about another kind of youngster. The kind of clean-cut American boy in a typical American home who was going to be one of America's worthwhile citizens. This week at the Equitable Society, one of the agents told me a story that gave me quite a kick. It seems that when he got home the other evening, his young son Jimmy, aged eight, was chewing candy. Well, like fathers everywhere, he said, don't eat that candy now, Jimmy. You'll spoil your dinner. Where'd you get the candy anyway? Red gave it to me, said Jimmy. His father's in the candy business, and he brings home samples. Say, Dad, why don't you ever bring home some life insurance sample? Well, Jimmy's dad tried to explain. Look, son, he said, life insurance isn't like candy. Candy is something you can see and feel and touch and taste right now. But life insurance, well, now let's suppose that Fred's dad should die. There wouldn't be any more candy unless Fred's dad had arranged for life insurance to keep Fred supplied with candy and food and clothes. Well, Jimmy thought a minute, he said, I get it, I get it. Life insurance is candy for when the samples run out. Candy for when the samples run out. That's something to think about. Life insurance is candy for future delivery, security for tomorrow. Well, thinking about that makes us of the Equitable Life Assurance Society of the United States feel pretty happy about the work we do. With the real satisfaction in being in a business like this, you see, we always know that what we're doing today will benefit boys like Jimmy and millions of other young Americans far, far into the future. Yes, this week and every week for more than 86 years, the Equitable Society has been building security for you, your home, and your country. We'll be back in a while on crime in the Roaring 20s. Red Martin and his companions, delinquent youngsters of 1917, had now graduated into major crime and together with thousands like themselves whose potential counterparts after this war were to be far greater in number, had added the explosions of their guns to the roar of the Roaring 20s. It is now some 30 or 40 minutes after Red Martin's blazing Tommy-gun put him on the little throne which had been occupied by the man called Legs Miller. The murdered man has been discovered. The police notified. They, the special agents of the FBI are now viewing the bodies. That's Legs, all right. The other one I've heard him call Casey. Who did it? Waiter, do you know? Let me answer that, officer. It was Red Martin, wasn't it, Witte? Well, I...  Is that right? I've seen Casey and Red Martin together. But why did Casey get it? I guess Martin doesn't want any double crosses on his staff. Find anything, officer? A couple of slugs on the floor that went clear through them. I'd like to have them for a lab check, if you don't mind. Yeah. Obviously, Martin doesn't intend to do business here. He'll probably set up a new headquarters. Waiter. Yes, sir? Did Legs Miller have a girlfriend? Yes, sir. Is this her picture on the desk here? Yes, sir. With all my love, honey. That's what she was called. We're taking this picture along, too, officer. All right, Miss Brown. I guess we can go now. And let's keep our fingers crossed. This picture could be the clue to the whereabouts of Red Martin. Assuming you mean that when Red Martin takes over, he takes everything over. Right. Red. Yeah? What time is it? A little after ten. Thanks. Are you tired? No, darling. Bored. What's the matter? Well, these past few days haven't been what you might call exciting. Now, look, honey, I told you... I know. We have to stay here until the heat's off. Couldn't you have picked someplace else for a hideout? Did it have to be two dingy rooms above a garage?  We already have been. Who is it? Come on in. Hello, Junior. You want to see me, Red? Yeah. Tell the boys that tomorrow we start expanding. We do? How? We're gonna start taking over Mr. Cicero's customers. That's a big order. I'm a big guy. Tomorrow the boys start calling on Cicero's customers to tell them from now on they're buying from us, okay? It'll be okay. Mr. Cicero decides to pay us a visit. That's what I want. It'll be a quick way to take over. We'll be here waiting for him. Pass the word on now. All right. See you later. After Mr. Cicero, will we hide out again? Come here, baby. Well? Look, just play along with us for a few more days, will you? Oh, I wish you didn't have those big shoulders. What luck, Bob. Enough, I think. What do you mean? I checked the photographer this morning who made this picture of Honey. Well, he said all he knew she was a nightclub singer. So I checked with the booking officers and I finally got this address. Whose? Her mother's, on the north side. I'm bound to see her mother once in a while. We'll keep her 24 hours surveillance on the house and wait for Honey to show up. Brown speaking. Yes? You follow yourself, Bob, and then come on in. Why? I want to pick up everybody at once. Yes, but how? You keep tabs on Honey and find Martin's hideout. I think I've got a way for seeing that everybody is at home when we go calling. Joe? Yeah? Stand over there by the window. Right. Now, find yourself by the door. Okay. And don't take any chances. Have your rods in that door once she opens. And, Honey? Yes, sir. For the tenth time, go on. Back home to your mother's. Nothing doing. I'm staying here. Look, baby, that was Cicero that called and said he was coming over. Not a magazine salesman, Cicero. I'm not afraid of Cicero. So I suppose you're like his shoulders, too. Darling. Okay, then get out a line of that door anyway. Hey, Red. Yeah? They're here. How many? Big gospel. Get set for anything. They'll be upstairs any minute. But they won't all come up here. Never mind what stays downstairs. Just take care of what comes in that door. That's all we have to... Hey, listen, Red. Only one guy coming up. Yeah. Must be Cicero himself. We'll try talking first, I guess. We'll let him have it when he comes in. I'll take care of him. Come in. That's not Cicero. Hey. Who are you, pal? I'm Special Agent Brown of the FBI. You better get out of here. There might be a lot of shooting in a minute. There'll be an awful lot of any of you starts at Martin. Those are FBI agents down there and they're ready to blast you to Kingdom Come. But Cicero... I'm afraid I am guilty of impersonating Cicero, Mr. Martin. What? I just wanted to show you how easily you boys can be taken over, that's all. Now drop your guns and file quietly downstairs. We'll go to headquarters and arrange futures for one and all. Young Red Martin's short and unprofitable career of crime ended with his death in the electric chair. The members of his mob were sentenced to long terms in prison. That was a page out of the roaring twenties, part of the criminal aftermath in America of World War I. Already the criminal aftermath of World War II is splashing black ink across the front pages of our newspapers. It happened before. It can happen here again. The FBI and your local law enforcement officers will fight it day and night. But it must be fought by all the people if it is to be licked. What are you doing about it? In your community. Before we tell you about next week's case from the files of the FBI, a word about a man worth knowing. To the FBI, America looks for national security. And to the Equitable Society, three and a quarter million Americans look for the financial security of life insurance. These three and a quarter million people are the sole owners of the Equitable Society. Because you see the moment they purchased life insurance through an Equitable Society agent, they became part owners of this great mutual organization. Yes, like your FBI, the Equitable Society representative in your community is constantly working for the security of you, your home, and your country. Next week we will bring you another colorful story from the files of the Federal Bureau of Investigation. The innocent killer. The incidents used in tonight's Equitable Society's broadcasts are taken from the files of the Federal Bureau of Investigation. The role of J. Edgar Hoover was impersonated. But all other names used are fictitious and any similarity thereof to the names of persons living or dead is accidental. Tonight the music was under the direction of Frederick Steiner, the author was Frank Ferries, and your narrator was Dean Carlton. This is your FBI is a Jerry Divine production. And now this is Carl Frank speaking for the Equitable Life Assurance Society of the United States and the Equitable Society's representative in your community and inviting you to tune in again next week at this same time for this is your FBI. This is ABC, the American Broadcasting Company.


All right, hi everyone. Thank you for being patient. Appreciate everyone being here today. It looked like a great turnout. I did not get to come last year because my sister decided to have a university graduation at the same time, so I hope my team did a great job representing VMware last year. But my name is Marilyn Basanta. I'm a Senior Director of Product Management for VMware's Edge Compute Products. So today, I realized after we submitted the keynote talking, as you guys heard, we both had two people who decided that Sharpen Your Edge was the right title to go with, so I think we all used the same chat, GPT prompt. And so I'd like to talk to you about these three different themes that we see come up with our Edge at Enterprise Deployments, especially over the last year, as things for us have accelerated and we've made a lot of great progress at VMware with our Edge portfolio and our products, especially our Kubernetes offering. I would say that's where we've made the most leaps and bounds in how we're gonna support apps at the Edge over the last year. We had the most recent Kubernetes release that we just had end of January, we had a lot of great things that I can cover that'll help accelerate deployments and applications at the Edge. So I'll cover these three themes. First is around scaling, large scaling and efficiently. And this is definitely a very difficult problem that I don't think any of us have yet solved. We can solve different aspects of it, but it's really how we're gonna bring all of it together and scaling your edges out. So the first thing I see come up is how are you gonna manage this? Everyone wants a cloud-like management experience for their Edge. At least that's what I'm hearing from our customers. How do we make this easy and holistically give you that one view where you have all your edges, you have your policies, you have your security, you have your applications? So how do you make this super easy to manage holistically? So this is something we've been working on with our own Kubernetes management console, but then how do I up level that even further, not just for Kubernetes, but for everything else adjacent to the Edge, or all the different other applications and the tooling that you need? Another thing that is very important for us to be able to scale efficiently is working on how do we make it easy for it to be scripted? So this, we're working on more of a get-ops approach for this, and we have some interesting projects that were announced last fall that are now kind of converging together to give people a different, some people will want an easy UI, other people will wanna take control with scripting, and how do we take that approach to not just the Kubernetes offering, but everything else and how you define your Edge sites. Another piece is how you design your Edges. And so what we've seen at VMware, people wanna deploy Kubernetes in lots of different ways. We just recently introduced some single node clusters, but we've got a reference architecture, different designs of how some people will need to scale their Kubernetes offering differently. And then separately, in which of course is very important is how do you handle these costs? So a lot of things from a business value perspective of our customers who've been successful is how do we make this easy to manage and so that way they can contain the cost. So everything's around having a killer use case or having that application that then kind of leads you into having the different applications at the Edge. Okay, so now that we've covered that's how important it is to scale your Edge, is how do we then make this quick to deploy? Cause that's the other thing that we see where there are enterprise customers who have customers coming in who know they wanna roll out a new computer vision application at the Edge and do inferencing and have real-time decision-making, but they're telling us, hey, this is gonna take years for us to roll out to all these different stores or into these manufacturing plants. So how do we get our customers taking advantage of the latest and greatest technologies that we all have in the open source community or in our here in our enterprise offerings to take advantage of the new things at the Edge? And so we're working a lot in orchestration. It goes back to what I was talking about, this GitOps approach. We're trying to make it super simple to get the infrastructure up and running and in a variety of ways cause not everyone will want it from the cloud. Some people wanna send it to their system integrators and have things staged. Other people have limited bandwidth. So it's a variety of permutations of how do we accelerate these deployments and make it easy. The second part is what I've talked about and I'll talk a little bit more about the new apps. I believe that's kind of the pitch I gave before. I love talking about the new reasons and the new apps, why apps are being deployed at the Edge, excuse me, but it's very important that we take into account the tooling, like I said, and making these applications easy to use. Things like enabling real-time functionality in the operating system to taking advantage of messaging and streaming queues to help build your applications to do closed loop automation to speak to each other. But another thing that's important that I've seen come up recently that I think is nice to point out is security. It's definitely had a bigger emphasis on security as we help our customers accelerate Edge sites. So things like Coverna, sorry, I'm gonna butcher the company name, I'm sorry, different open-source tooling and things like that that we have to kind of feed into the architecture to make sure that security is taken into account. And I'm not just talking about application security. I'm also talking physical security at the Edge locations. How do we help enable the hardware that if someone's gonna walk away from it in a grocery store or at a coffee shop that you have the hardware secure? And of course, most importantly to accelerate deployments is life cycle management. So a lot of work has also gone into how we're thinking of the life cycle management experience for Kubernetes. Okay, and then now that you've scaled your platform, we figured out reasons, important things for scaling your platform. How do you accelerate the deployment? And then so what's really driving the acceleration of the deployment? So to me, this is the most fun part to talk about. So what we're really doing, and the reason why workloads are going back to the Edge and why Kubernetes is so important to the Edge is because of the new workloads that are coming up at the Edge. And so what we're seeing this is of course in retail, manufacturing, oil and gas, power utility, the fact that everyone's on a modernization journey and their applications. And so how do we enable these new applications? In many cases I already touched upon this a little bit is their real-time applications. So if you're a power substation, how do we work with the ecosystem ISV partners to enable their application to be containerized and handle the critical optimization of power utility? In the cases of manufacturing, we're working a lot in manufacturing. In fact, this week, half of my team is here and half of my team is actually at the Hannover Messe conference, which is one of the biggest manufacturing shows. We're showing real-time Kubernetes applications there. And retail, retail is all about the immersive in-store consumer experience. Everyone's wants their experience now. So how do we help enable these new Edge workloads? So this is all about Edge native applications, which I know the CNCF have released a draft on that kind of cover the criteria of how we see Edge native applications and what makes them different. Everything I kind of talked about is very use case-based, very line of business-driven. So these are the real reasons on why we're trying to meet that use case. We're trying to say that this one use case kind of pays for the platform and then you're enabled to do lots of other things on the platform. And so to run critical application we normally see is one, we start off, a customer might start off with one use case. I would say this is a retail store with video surveillance. So if you're taking that surveillance, you have to store it for 30 days, you have to store it somewhere, you have to secure the platform, and then that video feed could be inference to serve different applications. You can send it to another device, you can send it, you can inference it there or you can need to store and forward what you need. So that's now one use case has multiple difference, serving points, storing points and capturing the video. So then as you multiply different devices in different use cases in a retail store, you then have more data sources and how do you help these applications actually communicate with each other? Then that leads to what I think is the real value of the edge, the fact that you can take all of the data sources at the edge, bring them together on a common platform that we have with our Kubernetes offering, but more importantly, how do you help these applications communicate with each other? And that could be with something like RabbitMQ because you need to capture for multiple sources, we're going to store, process, bandwidth reduce, transform and then forward. We need to process and serve it across the different edge sites for different applications and then it has to be secure. So the fact that we can help bring together a complete platform from automating, scaling and then helping build these applications and have a common communication method to make it easy to create these applications, I think are the three tools that you can use to help enable your edge and help your customers. So thank you.


Good morning folks. Good afternoon. Good evening. And the HackMD link is in their chat. Folks want to scribble your name. And Nios, you have the floor today. So I'll probably just give a couple of minutes for folks to join. Sounds good. Folks want to just take a look at the hack, the PR that Nios has got up. I think that's a preparatory reading for the call. Marina, do you know if Tisha is joining today? I think he had a conflicting meeting today. Yeah, and I didn't get the link up to the videos, but I saw somebody else posted them. So who was that so I can thank them specifically. I'm going to go ahead and get started now. Okay. So we're continuing looking at the requirements from last meeting. We were in, we were close to kind of signing off on this. So we're going to go ahead and get started. So we're going to go ahead and get started. Okay. So we're continuing looking at the requirements from last meeting. We were in, we were close to kind of signing off on this fourth requirement, which was a rotation of the root key should not require the use of the existing root key. I don't think we, I didn't see the notes from last meeting. And so was there any other concerns, Marina, that we needed to address? I thought we'd kind of closed on this one. I think that there's still the concern about how to actually communicate that the new root key in a secure manner. But I think that using that an out of band process should be all right for this. Okay. What I'm going to add is a section to this doc that calls out certain assumptions that we're making in terms of what is happening out of band. So for example, the sharing of the root key. This is something that we assume here there is a secure mechanism that happens out of band to make that work for the initial root, root sharing. So I'll add in a section for assumptions that we're making or happening outside of the scope of this document. Yeah, I think that's a good idea because it's important people understand what happens out of band because I think sometimes not explicit enough. Yeah, I'll add in a section for assumptions and also guidance. There's certain things that we've called out as best practices for setting up like roots and signing keys. I think we can start kind of tracking those. So we have a list of practices as well available once we're done with the implementation. Okay. Moving on to the next requirement. Publishers should be able to sign with keys stored in their local machines, including your tokens, HSMs or cloud based key management services. I think this one coming out of Nordery v1 we realize that we would need to support developers having keys in a variety of different places. Is there any objection to this requirement? Okay. Next one. It does have some implications about the kinds of keys we support just because of so because those mechanisms don't always often have restricted sets of kinds of keys they support. It does. I mean, it does in terms of best practice or usage, it means we have to be fairly lenient in the types of keys we allow. Are you basically saying that a registry would require a specific type of keys so doing offline? Well, I mean, we can't just say you have to use like ED 25519 keys because to be honest, no cloud provider has a service that can sign with ED 25519 keys. And so we just, it means we, in general, most clients are going to have to be able to understand them for as you have key types, which is fine, I think, generally, but it's just, it's kind of, it's kind of frustrating how unstandardized and different the cloud provider APIs, for example, happen to be for signing. The focus of this meeting that we should come up with a standard. Well, it's not, it's just like you should come up with, you should, you should use more of the date. Now, I think that's part of one of the things that we want to hash out as we get into implementation, right? Like what is the crypto API standards that we want to support? And that should come out and have requirements then for each one of the cloud providers to have an interface that works with the V2 client. And so the interface, I think we need a little bit more research to do, but once we agree on here's the approach, I think we have a common set of approaches we can look at and have a more detailed sort of discussion around key types and API support as we get into more of the detail. The next one that we had, go ahead. No, I think it should be fine, but one point that was one cloud provider who didn't support asymmetric encryption in there, but I think that may have been fixed. The next requirement we had was publishers should be able to generate multiple signatures for a single artifact. This one has come up several times where we need prior signatures to be preserved when an artifact is being re-signed. So I think this brings up a requirement for having multiple signatures, the ability to sign off on a single signature or essentially append a signature with their own. And I think just mostly technicality. I think that pairs with clients being able to kind of specify who should be signing different artifacts. Right. This does introduce a trade-off in that signature size can essentially be unbounded or could have multiple, but with multiple signatures, the signature size is growing. Are there any concerns around that? So the way it's worded, I would do it a little differently because it sounds like a publisher can provide multiple keys, which they could, but it almost makes it too narrow. What we're really trying to do is an artifact can have multiple signatures. So the publisher might provide one or more. I'm not sure why they would provide more than one for as a publisher. But the idea is that a publisher can provide one docker hub as, you know, a curator can add one to it without changing anything. And then in our example, Acme Rockets can add one for their private environment so that only things signed by that, their key can be deployed. So I would tweak the wording a little differently. So the end result is broader. That just makes it a little narrower. And the, the second point is the size of the keys. It's an interesting one because what we're really, it's not that the key itself gets bigger because there's multiple signatures. What we're saying is you have multiple signatures that can be assigned, but each one is independent. So it means you can get multiples. There's nothing that says I couldn't get a hundred signatures for a particular artifact, but it's not one document. So that kind of raises the question. Well, great.  So one of the things we're saying is we'd like to have a filter mechanism to give me back the keys that I care about. It wasn't signed by Docker. I don't care if it was signed by Wabbit networks, but wasn't signed by Docker and wasn't signed by Acme Rockets. So I don't, it's my point is key size doesn't, signature size doesn't matter because it's a collection. And tweak the publisher. I mean, generally, I'm not bothered about signature size because it's very small compared to the object. So however, Justin, it's hard to hear you. Sorry. Signature size is very small compared to anything else in a registry. Yeah. The manifest is bigger than the signature size. I think. Yeah. So I'm really not, I'm not worried about that. But I think the as is making a point with, if you support multiples, it could get bigger depending on the implementation, but because I mean, even if signature is unique. Yeah, but that's still not ready that big.  That's fair. It just, we're paying the, but you have to go get them. Size isn't the issue here. Yeah. I agree on, I agree on the wording change. The size one is just something. Yeah. I agree. I agree on that. And just to call out to make sure that we don't have any bounds on it. And so if it's a collection, I think that's easily avoidable. Okay. And I'll reword it. Collections will have paging APIs too. So I, I don't know if we want to put an arbitrary limit on the collection as long as we provide. Filtering. And like from a spec perspective, which is what you're kind of driving down on. I don't know if we need to clarify it anymore. Okay. The next requirement was there should be a mechanism to evoke signatures to indicate they're no longer trusted. This is one we've heard from a lot of different customers about. And I think it's, it's almost essential for a signing feature. 100% agree. Is your screen frozen? I don't know how you would know that the top of your screens is not required. Do that we are. Oh, sorry. I can highlight it. Um, got you. I mean, what, what, I mean, this could be implemented in. Different ways, but I mean. So, um, you want to read revoke signatures separately from the keys that sign them to you? Is that the implication of this? I think the implication here, the implementation could be that you're revoking keys to say that here's a set of signatures that I no longer trust. Being able to revoke individual signatures does get pretty challenging unless you have a pretty robust key management in place. So, uh, it's more around the ability to revoke a set of signatures. I think is what we're trying to get at here. I think you doubled back. It's revoke keys, which implication revoke signatures. Right. Okay. And I also worded as not publisher, basically anybody that any key that was used to sign can be revoked. So that's the publisher. Yeah. Yeah. Yeah. So I think the key owner essentially should have a mechanism to revoke their keys. Um, and so I can, I can change the wording on this to kind of clarify that a little bit. Well, we, we want all keys to be rotatable. Was to write this rotatable and revocable. Or is the industry just assumed that when a key is rotated, the old ones revoked. Is that how it works? Yeah. But I mean the, the user should be able to rotate their key, the user of the key. If, if I think my key has been compromised, I want to rotate it. Uh, if we have a key hierarchy, the person who own, who is above me in the hierarchy should be able to remove my key. Like if I'm no longer an employee. And therefore. So I think there's a difference between key rotation and revocation, right? Like key rotation is something we expect to happen from a best practice to make sure that you have limited blast radius of things you're signing with your key. Uh, revocation is something that's saying that I no longer trust this key. So from our perspective, just because the key has been rotated, doesn't necessarily make the old key untrusted. Um, you wouldn't start on trusting the old key unless there's a very specific compromise that you're calling out. Or key, for example, has. Can we just make this a bit more, maybe break this down a bit more? Because it's just. Ian had a note because his mic isn't working. So voices, comments, um, something about. Yeah, I don't think. Can we, I think we're missing a bunch of. Requirements here. Cause we haven't got requirements about rotation as well. I was trying to say. I think that's a good call out. I can add in a mechanism for rotating keys. I think that's a requirement that should come in as well. And also I would say that it's probably the keys that are not the signatures. That's what I was saying originally. Yeah. So I think it's just a bit unclear. I think that's fair. So I'm going to change this wording to go revoke keys and then add in another requirement for rotating keys. Uh, the next requirement that we had was, uh, I would say that the trust store should be configurable by the deployer. This is essentially calling out that you can go configure the routes you want to trust in your deployment environment. I would say it's a, um, it's definitely true that you want it to be configurable by the um, Deployer, but I would say that the trust stories. I feel like it's a bit of an implementation. Details in the requirements. Um, Exactly how. That works. If that makes sense. Um, I don't know what you mean. I don't know what you mean. The registry, the client. Oh, that section right there. You just scroll past. Okay. Yeah. So a trust or essentially recalling out as a relationship between. Uh, the signing keys and the validation being done. Um, so the trust is essentially going to relate. A source, whether it's a specific registry or positive tree or specific target or any source. Uh, with a, uh, certificate that has like a root key, uh, either intermediate or signing key. Um, and so that's really the relationship we're establishing there. And so, um, what we're calling out here is that there should be some control for, uh, Uh, developers to essentially go in and say, here are the roots that I want to trust. Uh, and that's a control that should be exposed. Okay. I think I understand now. So I'm a little confused as whether this is in the registry on the client or both still, like, um, Maybe an example call out. They should be in the client. I can add some more context and narrow this requirement down. So essentially what I think we're, uh, what this requirement is, uh, can be rewarded as like developers should have the ability to configure roots that they trust in their deployment environments. That makes it super clear. Um, I, I, I mean, that's enough. That's why I'm asking others. I'm wondering if the definition needs to be tweaked a little bit because maybe the, what you're teasing out as an interesting one is certainly on a client. I want to make a determination that regardless of what keys may or may not be on an artifact, it must have this one, two or three. And if it doesn't have one, two, or, or end all three, I think we're going to be able to, you know, have this one, two or three. And if it doesn't have one, two, or or end all three, I won't deploy it. There's another one maybe I'm asking is in a registry, should there be some enforcement of what keys and roots are allowed to be pushed to a registry? Do I get to push the bad guy key to a registry of, I know if the registry knows there's the bad guy key that it doesn't want to accept. Is that a real scenario? I think that should be an optional requirement because I want to leave that choice up to the registry operator to say here's how we're going to curate signatures and here's what validation presentation we're going to do. But there's nothing that prevents them from using whatever we're using in the deployment environments to do a similar validation themselves. The next one that I had was deployers must be able to configure trusted entities for individual repositories and target. I think this one gets rewarded to say for individual registries repositories and targets just to make sure we cover all three granularities. But this is essentially saying that rather than saying here's the key that I trust for everything, we're allowing the capability of saying which specific registry repository or target do I trust this key for? What's the use case for configuration per target? That seems really weird thing to do. I think it kind of boils down to how do artifacts get managed? Do we always expect like a uniform management where let's say large enterprises are going to have let's say individual repositories per different applications that they publish or do they end up the same targets in the same in a single repository? And then you're saying I trust this key for this team versus this entire organization. Normally the permission boundary and the registry is the repository. So normally the same people have right to access for everything in the repository. And we don't have separate permissions per target. So it does. I mean effectively if you have set it for one target then it's simply one item and he must well just use the hash of it and not check the signatures. It just seems very strange to me. The hash would essentially tell you that the whatever you're getting from the registry is has not been tampered with but doesn't necessarily tell you whether coming from the publisher has been tampered with or not, right? And I think this kind of went more into like do we expect a scenario where multiple teams would end up with different targets in the same repository and would you want to scope that trust down to like a single team or single sort of like group within an organization, right? And so this one I think you know if we don't have a use case for that it's pretty simple to kind of say registries or repositories but it I don't think you chain, go ahead. Whether, but you wouldn't, if a target would be one you'd have to know which items were going to be pushed up front to know which team they belong to which would be, it's just I can't see any circumstances in which that would really work. And you'd have to have a list of items and I know in advance what all the items were going to be. I think you're touching a little bit on the permission boundaries and stuff. Whereas, you know, individual registries, you know, Coke and Pepsi in the same cloud are going to have different registries or different storage buckets whatever we want to call them. So they have complete autonomy amongst themselves. In a single registry as a number of us support multiple teams in the same registry with some permission boundaries. Team A should not have any access to Team B's content even in the same registry. And the same repository like in the same namespace. In the same namespace. I don't think many of us are doing unique permission. That's why there's that that's that's why the target thing doesn't make sense to me. Yeah, and that's why I think I'm curious if we're just getting tied up into some of the the update framework. Terminology of targets. When that case, what do you mean by targets? Yeah, that's what I'm asking. I kind of went down to sort of like what is the most granular level that you can specify trust for us. And that would be down at the individual artifact level. Like from a signature validation perspective, it doesn't really matter much because you're essentially just looking at different chunks of like, you know, where this artifact came from, right? So we can like this. I don't think this changes the trust or except that if you have people kind of like, you know, scoping down individual targets, that's a lot of like work they're putting in and the trust or can essentially just grow in size. But it doesn't, I think, break down the implementation that we would have in how do we go validate these signatures. So if this is a control that we feel like is going too far, I think that's fairly easy to kind of just say we're going to allow you to scope it down to repositories, but yeah. You put mast and I mean, I don't think I'm, I wouldn't implement it. So I would not be in spec. I guess that's what I'm saying. It seems, I think taking out the mast for targets would be fine. So when you're saying targets, Justin, just so I understand the term, target is the specific artifact in the same repo. So artifact and artifact two are separate targets. So it's a permit to 16.10.1 and you have a special rule for a bunch of 16.10.1 that is different from your rule for a bunch of 16.10.2. Okay. So the way we think different tags in the same repo should not, we don't believe today. And I think this is, so maybe it's at repository instead of targets. And this might be just terminology around registries compared to other package managers. As of today, I don't know of any registry that does unique permissions within a repository. So to Justin's point, whether it be a version tag of the same Ubuntu image or even an architecture tag in the same, basically, because the tag is just a string. There should be no, we're not saying we want to support permissions at that granular level because none of, I don't know any of us that are doing it. I don't know any of us that would want to take on that extra burden. But at a repo makes total sense. So I, and this would give me some amount of that rollback protection, I assume, because the 16.04 versus the 16.01. Having some kind of rollback protection around that makes, makes sense in the permission boundaries that we support today. Coke and Pepsi can't play in the same repo. And neither can team A and team B. So I think part of this is also kind of making sure that you have roll forward protections, right? So let's say you have Ubuntu 16.1 and 16.2 comes out. Your administrator may not want you to go to 16.2 until they have been able to validate it, right? And they may still want you to kind of verify with the original Ubuntu signature. So in that scenario, there may be a case where they actually want to go in and update the target to say, okay, now we trust 16.2 with this signature and have that level of control. So you're not able to necessarily pull in any version of Ubuntu that you want. So I think there's different mechanisms to do that. The reason I have it here right now is that whether you're validating a registry repository or target in, in, in, in terms of the implementation, it doesn't really change much because you're really looking at what is the artifact I'm getting and what is the, what is, what's specified in my trust store for this artifact itself and you're matching to see which part of the registry repository or the target you're, you're matching from the entire string, right? So to me the, this putting in this functionality doesn't really change the implementation. But I think it is a good call out to say that the most of it should be registry repository because we don't have a strong case for target, but we can get the target out of like the same implementation. So targets is optional, but you'll get it as a result of the implementation.  I have to think about it more, but the conceptually it makes perfect sense that the beauty is because we allow signatures to move within a registry across repos and across registries, then there's a promotion process that can be done out of band. So I would have my staging registry or even my staging repo that could have multiples, but my prod or whatever I consider the critical work or that I don't want to do this roll forward thing until I'm comfortable is a way that I would probably suggest people doing it because now I don't have to worry about permission boundaries or even the configuration boundaries inside of a repo. So I think that threads the needle of what Justin and I are kind of covering on the boundaries of what we want to do in a repo versus a registry. So I think, and again, I think this requirement gets good. I think this requirement gets rewarded to say for individual registries and repositories because that's where the need is. If we get targets out of that same requirement, then that's a bonus. I think that's optional, right? I don't think we should. I agree with that there's probably not a strong requirement to kind of say, Hey, if we don't, if we can't support target, this is a no-go, but if we get it, then that's great to have. I would, unless somebody else says differently, I'm looking who else is here to represent the registry. I wouldn't actually not even include targets in that and just say registries and repos. Justin, what do you think? If we omit it from the mast, then that's what I'm happy with that. Because if someone makes an implementation that supports it, I guess I don't care. I'm not going to make one. Just because it's not in the spec doesn't mean somebody couldn't do something. I think CodeFresh does something at tag level, but I wouldn't want to put it in the spec of even a should or could or would. There's nothing stops people from going further, but I really want to be careful about trying to put any suggestion that you can do permissions or anything unique inside of a repo. I could have Ubuntu one was signed with one key and Ubuntu two signed with a different key because it's a really critical difference. Then I could have a configuration that says I don't trust key one. I only trust the one that goes to key two. That's one way if you really, really needed to do something in a repo, you could. I think we've beaten this one to death. I think the point is we're trying to suggest any permissions inside of a repo. Yeah, I think let's let's move on. I think I'm okay switching the language there and calling that out. The next one was developers must be able to validate signatures on any version of an artifact, including whether they've been revoked by the publisher. This one, I think just kind of going into like being able to validate older targets and make sure whether they've been revoked or not. What is. I'm confused on a little bit on the signatures or any version. The revocation is at the key level. What is the version aspect that can be. Basically, you have to be able to go back in time and see would you have validated this last Thursday or something for audit purposes or. Or I just want to, I want to my my machine. You know, that kind of that kind of question that you have to be able to answer. I think it's my understanding currently. Yeah, and then part of it also is that like, you know, when we go back to that earlier example of the boom to 10.1.2 versus 10.1.3, even when 10.1.3 is the latest, if my security team hasn't validated that I should still be able to use 10.1.2 or even 10.1.1 if two versions behind. And I should be able to validate whether those signatures have been revoked or not independent of the fact that 10.1.3 is the latest version that's out there. But you're using that term signature got revoked as opposed to the key got revoked. So I don't know how you revoke a signature. Yeah. I think I need to reword this to clarify whether the keys that have been used for that have been revoked or not. And then this goes back into the best practice where we would say that for each new major version, you're rotating your keys before you sign it. So you have a smaller blast radius in the in the scenario of a key compromise. Is that a best practice? Sorry. Major version. Are you rotating or rotating and revoking? You are just rotating. You're not rotating and revoking. Yeah. In that case, the wording is very confusing. I thought you actually want to test things that had been revoked. So that was why I came up with the example of testing what you would have seen last Thursday, which is a different use case. So I'll clarify this one to say that you should be able to validate signatures on any version, including whether the keys have been revoked by the publisher. Okay, let's take another iteration on that one. Okay. And then the last clarity when you when you give another scrum. Sure. And the last one I had was signature validation must be enforceable in an air kept environment with minimal updates. This goes into making sure that we don't need air kept operators to do constant changes in their environment. They're able to either pull in things like CRLs or update their trust doors and be able to manage them within an environment. We can come back and address what the minimal means in the more detailed implementation. I think a lot of it really depends on how quickly we expect trust configurations to change, which we want to minimize to the security events, essentially, like whenever something bad happens is when you'd want to go in and update that trust door. I think this is one we're going to have to elaborate a bit more because just to repeat the same thing that air gap is not nuclear submarines and oil platforms. Just or it is not just those it is in clouds. Customers want all public access disabled. So it's literally a private network, which there's millions of them inside each cloud. So if there's millions of them, we can't have millions of additional things, complex configurations set up. It should be super simple to set this up, I think is your main point here. In those cases, you would presumably say that they're not totally offline. They're not in a submarine. So they can actually update when keys, when new key configuration, when there's new keys and things like that. Well, the biggest secret is air gaps aren't completely offline. There's just a gap between it, whether it be a diode or others, there's always some way to get content in. It's just extremely controlled. I think it's what this is trying to call out is that if you have a controlled update where, let's say, I know that there has been like a route revocation, or I know that one of the keys has been revoked. That's only really when I need to go in and take an action, besides that I'm not necessarily having to go in and touch my trust doors, right? And so that's really what it boils down to is that, yes, there will be some work for air gap environments to update their configurations, but the work there should be minimized to when they need to. And I think this is where minimal is kind of like a goal here, rather than it is a requirement. Once we get into the implementation itself, I think if we have trade-offs where we need to discuss, like what would this mean for an air gap environment, I think this would help kind of clarify some of the decision-making there. I think maybe if it's not quite 100% clear, maybe not making a requirement, but some kind of like suggestion or something, just to make sure that's clear, that'd be helpful. Yes, the requirements, everything else is really good for requirements. This one's a little nebulous on the how, so it's almost like there's a goal, because what I, one implementation, or one more specific thing could be is, I don't have to go back to the root authority for the key to know it was revoked. There's a delegation model that says, in my air gap environment, this URL is a proxy for everything else. And I trust that proxy, so that's okay. So it's, I get what you're trying to say, like air gap is a requirement, that is a requirement for our success. This is the one that has a little more nebulous to it, that I don't know if we can get more clear. And again, I turned to the key experts on what is the standard practice for how to put that in a requirement? I can change this to an optional one just to kind of make sure that we track it as a goal. I don't want to lose sight of this one as we kind of go through some of the more implementation designs, right? I think minimizing the work for air gap environments is something that you should strive to do. So I can change this to make this a little bit more of an optional goal, but. It's an optional goal. I think it is a must goal. The problem is, is that the must minimal updates, I don't, I think people are struggling on the word minimal updates as opposed to we must support air gap environments. And maybe you can just say we must support air gap environments and don't, and just drop off the minimal updates part and then we get more clear later on. I think the minimal updates is the kick me. I'll look into this one a little bit more and see if there's a clear language. I think there is a different requirement though that we want to talk about. I just saw Trishong's note come in, which was the fourth requirement, which is rotation of the root key should not require the use of the existing root key. Yeah, hi. So as we discussed last week, yeah, my objection here is that it, well, maybe it's meant to be optional, but it seems to strongly discourage users who want to do this anyway from being able to support this use case. That's my concern. So I think the reason we take a strong stance on that is that from the perspective of the deployer, there's no way to know whether this rotation is a transparent rotation or it is a malicious rotation, right? And this is where we think going back to how you're out of band mechanism that you have to establish the root is where we want to push people towards. And those roots should be long lived, should be used infrequently and we should really push more towards like being using intermediates that you're rotating this that I think gives us the best security posture. But if you're able to rotate your roots transparently, it means a malicious attacker could also potentially rotate your roots transparently. I think this is where the difference between rotation and revocation comes in. Because I think that if you're revoking the root, I think you definitely need to do that, not using the existing key that is compromised or at least have a mechanism to overwrite an attacker rotated key. But in the usual case, when there's not an attack, I think this is actually more secure because it uses something that's already trusted instead of an out of band mechanism, which could also be compromised, kind of adding to the attack surface. But the deployer doesn't can't differentiate between the two is what I'm getting at, right? Like as a deployer, I don't know if you have updated your root because it was a normal operation or you've updated it. A malicious attacker has updated it, right? Like I can't distinguish that. Yeah, you also can distinguish if an attacker is just uploading metadata. Yeah, I mean, if a malicious attacker owns the root key, you can't trust anything at that point. So I need doing an out of band, right? Replacement is the only thing you can do at that point. Well, not for uncompromised users, right? So I think it's a double H. I think I understand where Nias is coming from here, and I think it's a valid concern. I think you end up with two, it's damned if you do, damned if you don't. And here's what I mean, because let's say the root key is compromised and just is absolutely right here. You could do a lot more damage than just updating it to malicious root keys you control next, right? You could do a lot of damage. You could install malware and use as machines. So being able to prevent them and then say, hey, look, you're not going to be able to use the old root keys to make it sign for new ones. Great. Now here's the problem. What about, let's say that scenario happens and then now you have all these other users who have not fallen for this attack. Now how do they update? So the root keys are broken until everyone updates, which is also potentially destructive. Does that make sense? I'm not quite sure I followed in the sense that if the root is compromised, you essentially need to configure a new root, right? And that's a painful process. I totally agree with that. But how you know which one is the new root to trust, right? You would need some kind of a mechanism to say here's what we do trust, right? And I think this boils down to when we think about configuring trust, I'm not necessarily saying I trust this key because I got it from a hub. I'm saying I trust this key because I can verify the publisher and I know that this is the key that they're providing because of X, Y and Z reason, right? Either that's because for large enterprises, you may be able to go to their website and say this is like Microsoft.com or Amazon.com or Docker.io. I know that this website is validated so I trust the keys that are hosted here. It could also be something along the lines of I trust CAs because they're publishing audit reports and through their audits I know these are the roots that I can trust. But you have some mechanism that's not necessarily automated that tells you that this is the source of this key and this is why I trust it, right? And chaining up to sort of like a root, I think kind of like, yes, it does allow you to expedite kind of getting a key in place. But you're only just really trusting the previous key to say that and that key cannot necessarily always be trusted to the same degree that you would trust an out of band mechanism is what I'm getting at. Well, I mean, I think that you're putting a lot of faith in this out of band mechanism in this case. Because there's nothing to be said to say that the out of band mechanism can't also have, you know, cannot be compromised. I think that's part of the challenge here is how much you rely on the third party not really specified mechanism and how much to try and rely on the internal mechanisms which we know how much or how little we can trust. Well, this is kind of, I think, pushing towards a factor authentication, right? In that sense that if a root were compromised, you're expecting that their communication method hasn't been compromised. And if their communication method has been compromised, if their root isn't compromised, like you're not, it's not really, there's really not an issue there. You need both to be compromised. Sorry, but if you've managed to compromise the out of band mechanism and you replace the existing root key claiming that it's been compromised, you now have control of the registry. You don't because it's not an automated mechanism is what I was getting at, right? Like if I see that someone has rotated the key, I still have a mechanism of validating that it's not an automated process that's necessarily pushing in a new key into my deployment environment. Like there is still a manual action that I need to take. And when I see that key changing, like I have an opportunity to go ask, hey, why was this key changed, right? Yeah, I think that's what you're saying. That's a valid concern. So I think rather than trying to prevent this outright, what I would rather see, because I still think there's a valid use case where you do want to use the previous root key to transparently, in case things haven't gone wrong, for example, like Marina pointed out, there's no reason why you shouldn't be able to do this. So I think what might be a better solution is if we say something like by default, you tower shall not trust the previous root key to hand over the, hand you over a new root key. I think there's a good safe default. That's fine. You should be able to overwrite this default if you wanted to. Sorry, go ahead. There's also, it's actually confusing about what the wording is trying to rule out. So, yes, are you trying to say it should be possible for there to be a rotation without the use of the existing root key or are you trying to say you must not trust a rotation that does use the existing root key because those are kind of different things. I think it's the first where the rotation should not require the current root key. Okay, so you're not ruling out in-band key rotation. I actually think I should. That's not clear from, yeah. Say I want to rotate my key from 2448 bits to RSA 4,096 bits because it's more secure now. You know, kind of thing or something like that. Or some other, you know, I want to rotate from one cypher to another because it's got better support in my HSM or something like that. Why should I not be able to do that in-band? That seems a perfectly reasonable thing to want to do. The in-band part comes in because you can't differentiate whether the in-band is trusted or not. We have to think from the deployment and the signers being sort of like different entities. If you don't have communication or something else that says that, hey, go trust this, then you don't really know that that's what I'm getting at. Any mechanism where you have in-band rotation is vulnerable to an attacker compromising and then rotating the key for you. Sure, it can have other impacts, but the in-band rotation kind of, I think, adds to the pain of being able to kind of get back to where you need to be because now you have to go back and manually redo your cluster anyway. So I'm not sure what the in-band rotation offers. I think the two things that I would kind of throw out there is that we also want the root keys not to be rotated because there is like security requirements or something else that comes up, which there are, but you're not having to do this on a yearly basis. Yeah, that's fine. But you shouldn't prevent people who want to do this. So that's why I recommend you can turn this off by default. You can say, you know, we strongly recommend you don't do this. You don't trust in-band root rotations. It is turned off by default. You can just flip this Boolean, for example. I think that's much more reasonable. But what about the security scenario there, right? I think that is introducing a security flaw in our mind. Like it doesn't protect you from an attacker rotating your key. But this is true for, I mean, presumably you would need a way to rotate other keys, not just root key. That's where you're in the same flaw. Well, so you have your chain of trust coming in, right? Like if an intermediate is compromised, you know, or if, like, a signing key is compromised because, like, let's say a developer had access to it. You, because you have your root protected and your intermediate protected, you can actually go out and say, I'm going to revoke this key and I'm going to rotate an issue, a new signing key and sign with those, right? So from the perspective of, like, you know, the keys should have different exposure. The keys that have the most exposure have rotation built in. It's really just the root that we're saying should not have auto rotation built in. Everything else, go ahead. But if you're, if the attacker has compromised the root key, they can rotate all the other intermediaries to their keys, which has basically the same effect as rotating the root. That's true. Yeah. Ken, what do you key management experts parse what the end is suggesting also here or adding? I think that that's a really good idea because it does mitigate the impact of any of these compromises we discuss if you have two different roots. Then as long as they're stored in very, very different locations and different methods or whatever, so that they're not both compromised at the same time. I think that's part of the idea of having multiple signatures on root, in fact, is that you can have different keys stored in different ways that theoretically couldn't be compromised at the same time. I think in practice, we're going to see very different things. That's what concerns me there. Yes, we can expect people that have, or developers that have a lot of resources to potentially go set something up, but are we really going to see multiple roots across multiple regions or distinct HSMs for individual developers? I think that's where my concern is. The way I look at it, let's say, for example, if Docker had a root, right, and if you have intermediates going out to different developers that are using it, then potentially those intermediates can be rotated, but really Docker saying that, hey, I need to rotate my root is a very different distinction than a publisher having to rotate their root. It really boils down to how much trust we're placing in this root, and that's where I think I'm very uncomfortable saying that an automated mechanism to rotate it would be something that we'd be okay with. I think this goes back to how much is covered by the root, because if every developer has their own root, then yes, I agree that maybe it would be hard to store, but if the root is higher up in the chain in the registry level, I think we would have a higher or expect a little bit better key management from that group. And I think that's kind of what we were going towards, right, like for individual developers, we don't necessarily expect them to set up the PKI as much as they need a mechanism for key distribution, which I think could have like a curated root, right, where you're signing up for some sort of an identity, you're getting an intermediate, but the root is not something that you would be touching or have exposure to. Yeah, exactly. I think we all have the same ideas in mind. I'm just concerned about ruling out use cases like Justin mentioned, for example, you want to update from smaller size keys to bigger size keys, because suddenly the security requirements have changed. And I'm not sure that's a great idea. I think I'm kind of also looking at how TLS certs have also been managed. And I think, you know, like I said, like a root update is a painful process regardless of how you do it. And we've seen that work. Like that model is something that we know, like, you know, root rotations will take years to plan for. And you need to make sure that the update gets out. It's not a streamlined process where you can just go flip a switch and like the root gets updated. I totally agree with that. But I think the trade-off there from what we've seen it has worked, right? And this automated root rotation is something that we have gotten a strong pushback from in terms of like it goes counter to the security models that we have in place today. Well, in practice, Karan, if you look at TLS, the way root it's done through your operating system or sometimes the application itself. So there is work done somewhere and you don't get it for free yet to update the application or your operating system. I think this is a larger issue that I'm afraid we're running out of time and I don't keep... Yeah. But we should discuss this offline. So I'm not sure that we should make this a requirement. What are people wanting to? Shall we revisit this? Shall we do people want to spend more time thinking about it and come back with some further discussion or what or what do we want to do here? I mean, we did want to get something committed. So maybe Niaz, if you want to tweak the ones where I think it's just a tweak if we agree in concept and propose that and then do a separate issue or separate PR on this one to iterate. Does that sound like a way to divide and conquer on this one? Yeah. I can mark this one with an asterisk and say like, you know, we were still working on this one and have the rest kind of revised. I think that works. I'll set some time up with you to kind of like chat more in depth and see if we can find the middle ground here. Sounds good. Thanks. Anyone else interested, please join us too. I'm just a point of order for scheduling. So we have next week and then the following week is the Thanksgiving week and a lot of people just turn in the turkeys so that week will be kind of shot. So my proposal, we won't have any week, any meeting the week of the 23rd. So anything we want to cover next week and then we'll resume back on the 30th. So just a point there. So what date, when's KubeCon? Is that next week? I don't know. Let me do the recording. So I don't know. Yeah, I think it is. So it's the whole week. Okay. So you want to, you're saying basically let's take a quick look and then we'll just I think, um, yeah. I made security days on Monday. I think. November 17th to 20th. So technically, oh, because you're saying it's the clouds, the pre-con is the 16th. Yeah. Yeah. Okay. So you're proposing cancel next week as well. Yeah. But if we can try and follow up on Slack. It's a bit of a gap. Yeah. Obviously everybody keep up on Slack conversations. So, um, I've got a couple of things that I've been, uh, focusing on, um, this week and planning. So, uh, I probably won't have many updates from the distribution side and the notary client. And the next two weeks, but, um, any company, why don't we just do that? Let's, let's put a focus on. The coup con for next week. Unless somebody has something specific to talk about, we could talk about in Slack. So let's cancel next Monday's. And the 23rd. And we'll resume on the 30th. So with that, we'll let people get on with their day or evening. Thanks, folks. And I'll get, uh, the hack of D doc updated with the, uh, the recordings. See you later. Thanks.


Household cleaning products can be hazardous, landing hundreds of thousands of children in U.S. emergency rooms, and the product most commonly associated with injury was bleach, which can be toxic even if used as directed. We've known that those with asthma who work with cleaning products day in and day out can suffer adverse respiratory effects, over worsening of symptoms, declining lung function, inflamed airways, but even cleaning workers without asthma can be affected. Even below so-called acceptable exposure levels, cleaners with or without reactive airways can suffer a substantial decrease in lung function. Okay, but that's people who claim for a living. Although we've known that occupational use of bleach may have adverse respiratory health effects, but it was unknown whether just common domestic use of bleach in the household may put lungs at risk until now. Bleach use was significantly associated with nearly five times the odds of non-allergic adult onset asthma, as well as ongoing lower respiratory symptoms, such as chronic cough. The way bleach works is as such a strong pro-oxidant that the thought is that it can lead to like leaky lungs and allow allergens to penetrate. This phenomenon of cleaning product-induced asthma has been known for decades. More than three-quarters of the dozens of population studies looking into it have found increased risk of asthma or nasal inflammation. Ideally, safer cleaning products should be available. Unfortunately, this body of evidence has been largely ignored by the manufacturers and commercial cleaning companies, and most of workers put at risk are women. In fact, that may help explain some of the gender differences in asthma. The relatively high frequency of bleach use for home cleaning by women around the world, together with a strong association between bleach use and non-allergic asthma, emphasizes the need for reconsidering the use of bleach for cleaning. There are natural, environmentally friendly cleaning products that may offer a safer alternative, safer perhaps, but are they as effective? We didn't know until now. The effectiveness of three home products in cleaning and disinfection of staphylococcus aureus, the bacteria that causes staph infections, and E. coli on home environmental surfaces. The first report ever of the performance of purportedly safer alternatives. In the home setting, some individuals will select conventional products such as bleach due to familiarity. It's a smell some associate with cleanliness. Others are seeking less hazardous and environmentally preferable green, organic or natural disinfectants, which you can buy or make yourself. So-called DIY do-it-yourself recipes that typically involve ingredients like vinegar, club soda, and plant essential oil, such as tea tree oil, prized for its antimicrobial qualities. So, researchers pitted head-to-head Clorox bleach versus a natural disinfectant based on thymol, which is from thyme essential oil, versus a DIY recipe, half club soda, half white vinegar with a few drops of tea tree oil. You could probably buy the bleach for around three bucks, the natural stuff from like $7, but the DIY mix for less than a dollar. Yeah, but does it work? On the bottle, it says bleach can kill 99.9% of germs, which is the EPA standard for the disinfection of surfaces that don't come into contact with food, like the bathroom sink or something. They claim 99% of germs, but when put to the test, the bleach actually killed 99.999% of germs, completely wiping out the E. coli and staff germs, which even exceeds the EPA standard for food, contact surfaces like the kitchen counter. And so did the expensive natural stuff, worked just as well as the bleach, but the club soda vinegar tea tree oil concoction flopped, allowing as many as a few percent of the staff bugs to thrive. Now maybe they didn't use enough of the tea tree oil, only adding about a drop per cup, but from a performance perspective, the environmentally preferable product is an effective alternative to conventional bleach, and I would say even better, since bleach is well known as a respiratory irritant, and it's corrosive, too, and may end up damaging surfaces. What I would find interesting is to test how effective a cheap DIY time oil solution would be.


You carry them talking. Hello everybody, an improtu podcast, a surprise one for Paul. But we're testing out some new kits. You didn't realize we were going to be doing this, but we are and we're not in a pub. And there's a reason for that. I have a surprise for Mr Goddard. End you guys, hold the line. I'm nervous now. Oh dear. The agile pale ale and the pubcast pale ale. So you made this at home. You made this at home, did you? I did. This is the results of my home brew experiment. I'm a little bit nervous because obviously I've had to put them in packages. And so they were in a barrel and they had they were a little bit carbonated. You've even done the labels. Oh yeah, I've made the labels. I've even got the back. It says a pubcast pale ale. One of the outcomes of an agile experiment, an agile coach of pubcast landboard, that's main. Tested one batch of beer with different hops. This is a dark malt base with Syrian Golding hops, which give it a slightly sweet, sharp and citrusy aroma. Very good. So we're going to, we're going to try, I shouldn't have done that really. I shouldn't have done it. Let me try. Let me try. So now when you ask me what that tastes, I'm just going to read out that label. Yeah, so I'm hoping for a little bit of a pop, but I'm not sure it will. You've even designed, Jeff, you've got fire extinguisher time in your hands. It looks like whiskey. That's because it's a whiskey glass. So there was more of a head on that one. I pulled it this morning. Have you tried this yet though? You have tried this. I have tried it at various stages. Okay. So this is the, this is the base one. This was the normal one. Right. Following the recipe. Okay. This is what I'm calling the agile pale ale. So this has got a couple of different hops in it, but they're basically safe, safe hops. Easy to drink. There's unsafe hops. Well there's riskier hops. Right. So I've, I've, that's part of why the experiment was in place because I didn't know which hops I like. Okay. So rather than just follow the rest of small batch, I took the same batch of beer, split it into two, put different hops and different barrels. Okay. So that I could maximize my learning. Okay. So you got a bit, gave it a little bit of a benefit of the doubt because it would normally have a head on it, but I had to transport it to London. Smell. Smells nice. It smells like squash. It tastes like beer. It tastes like beer. Yeah. Yeah. Anything else other than that? Just beer. It's a pretty safe. Pretty normal. It's a 4.9% on your label. Is that official? No. You got to get it. But it's close. Okay. So I, I could work it out. Right. But I couldn't be bothered. Okay. So I know it's about that. Brood in England by Jeff Watts. So is this your retirement plan, is it Jeff? Well, we'll see. I'm at malt base. Kent got into fuggal. Fuggal hops. Is that right? Fuggal? Fuggal. Yeah. So now you can try the other one. Let's see which you like the better. So this is the experiment. Very good. Here's, here's a tasting glass number two. I'm pleasantly surprised by how it's worked out to be honest. Okay. Yeah. Is it better when it comes straight out of the barrel, but hey. So this one's called podcast. Podcast. PPA. Right. PPA. Smell. Smell different. Yeah. So it's the different hops. It's more floral, right? I don't know. I don't know. I've got no palette at all for beer. It does taste quite, yeah, floral. Yeah. Floral. That's the one. Tiny. Yeah. It's more sharper than that one. Yeah. Yeah. It's more like, I don't know which I prefer. I think I prefer the first one. I think I do. I think most people probably would if they're not beer drinkers. Yeah. I would say because that's a, there's nothing really, it's just plain. Yeah. It isn't. It's just plain. This one's a bit, a bit, a bit more challenging. It's a bit about it. Yeah. That was the idea anyway. So. Yeah. Very good. The idea of. But it looks, I mean, it looks drinkable and there's no, it's not cloudy. It's not, it doesn't look. So the technical term there is it's dropped clear. Is that right? Is that good? Yeah. So all the sediment is in the bottom of the bottle. So how much of it are you made? I think in total, about 40 pints. Of both? No, no, no. So there was 40 pints of sort of the base. Okay. And then I dry hopped them in two different batches. And there is a YouTube video online, isn't there? Well, I'm going to do a compilation because there were little videos along the way that our patrons could see. Okay. So I might make a little compilation. A montage. Yeah. Because there's various steps in the process. And so you, you can test it. So basically, because it's a live beer, as it, the longer it stays in the barrel, the more the taste changes. Okay. So it's sort of sharper and a bit more lively. Can you stop it? Can you then decide? Okay. You drink it. You can't preserve it at such a state. Yeah, I think you could if you put it into a bottle, maybe. I don't know. I like the labeling as well. You've taken a lot of time over that. Well, you know, I have a little bit of a gap. It's good. I enjoyed it. I enjoyed the process. I enjoyed the results. That's nice. So you kept some at home. This is my favourite. Is it? Which one? The second one. Is it? Yeah. I was speaking to the guy in the shop and I said, I don't know anything about the hops, but I know I do like a bit of a tangy, citrusy, bitter taste. So we'll try this one to start with. So the idea is, I've got two that I can compare them against. So I prefer this one. So then I'll run a couple of experiments and compare this one to another one or two similar ones and then I can sort of just keep experimenting. That's a unilever experiment. Just keep variations on the theme that you like. Yeah. That's a cold case to leave behind that. Yeah. Agile. That's kind of what we're going with it. Very good. So maybe we'll have a batch and you can buy some for Christmas. Well, there you go. There's an opportunity. I don't think it's very cost effective. Is it not? Well, so these bottles were like four quid. Well, they are litre bottles, two pints in there, but still. And I've got a bottle capping machine there so I can match this properly. And if I was going to keep them in a bottle for longer, I could put a little bit of sugar in them and that would keep the carbonation. But I knew I wasn't even going to open it today, so I thought I wouldn't pop it. It would just make it taste sweet. Very good. Well, there you go. Short little video for you there. We'll be back with a proper pubcast later. But for now. Cheers. Cheers.