▲ 290 ▼ Steam Client Is Now Faster Than Epic’s New Vibe Coded Launcher (archive.li) submitted 3 weeks ago by sirboozebum@lemmy.world to c/technology@lemmy.world 50 comments fedilink hide all child comments lol
[–] corsicanguppy@lemmy.ca -1 points 3 weeks ago (5 children) But it's a fucking container. So - speaking as a former security guy - no. permalink fedilink source hideshow 5 child comments replies: [–] Quazatron@lemmy.world 18 points 3 weeks ago (3 children) Could you please elaborate? How does containerizing harm security? permalink fedilink source parent hideshow 3 child comments replies: [–] platypode@sh.itjust.works 27 points 3 weeks ago (1 child) Because it lets you run code, which can harm your computer. For full compliance, throw your electronics into the nearest volcano. permalink fedilink source parent hideshow 1 child comment replies: [–] kmartburrito@lemmy.world 6 points 3 weeks ago This is the way permalink fedilink source parent [–] Carl@anarchist.nexus 8 points 3 weeks ago* (last edited 3 weeks ago) It doesn’t, as long as those images are good about keeping their dependencies up to date. Because containers are entirely self-sufficient and come packaged with all of their necessary dependencies, there is a potential security concern with images keeping dependencies pinned to old, insecure versions. And catching that can be tricky sometimes, especially when you’re running larger stacks with lots of containers. But I’d argue that is actually the image being insecure, not containerization itself. It would be no different from a program being considered insecure. We would handle an insecure image the same way we would handle an insecure program: push the maintainer to update their shit to a secure version, or fork it (if it’s OSS) to update the dependencies directly. Plus, containerization is much more straightforward compared to the olden days of directly managing dependencies. For larger setups, that was basically a full time job by itself. Especially when you have multiple different programs all trying to call different versions of the same dependency. permalink fedilink source parent load more comments (1 reply)
[–] Quazatron@lemmy.world 18 points 3 weeks ago (3 children) Could you please elaborate? How does containerizing harm security? permalink fedilink source parent hideshow 3 child comments replies: [–] platypode@sh.itjust.works 27 points 3 weeks ago (1 child) Because it lets you run code, which can harm your computer. For full compliance, throw your electronics into the nearest volcano. permalink fedilink source parent hideshow 1 child comment replies: [–] kmartburrito@lemmy.world 6 points 3 weeks ago This is the way permalink fedilink source parent [–] Carl@anarchist.nexus 8 points 3 weeks ago* (last edited 3 weeks ago) It doesn’t, as long as those images are good about keeping their dependencies up to date. Because containers are entirely self-sufficient and come packaged with all of their necessary dependencies, there is a potential security concern with images keeping dependencies pinned to old, insecure versions. And catching that can be tricky sometimes, especially when you’re running larger stacks with lots of containers. But I’d argue that is actually the image being insecure, not containerization itself. It would be no different from a program being considered insecure. We would handle an insecure image the same way we would handle an insecure program: push the maintainer to update their shit to a secure version, or fork it (if it’s OSS) to update the dependencies directly. Plus, containerization is much more straightforward compared to the olden days of directly managing dependencies. For larger setups, that was basically a full time job by itself. Especially when you have multiple different programs all trying to call different versions of the same dependency. permalink fedilink source parent
[–] platypode@sh.itjust.works 27 points 3 weeks ago (1 child) Because it lets you run code, which can harm your computer. For full compliance, throw your electronics into the nearest volcano. permalink fedilink source parent hideshow 1 child comment replies: [–] kmartburrito@lemmy.world 6 points 3 weeks ago This is the way permalink fedilink source parent
[–] Carl@anarchist.nexus 8 points 3 weeks ago* (last edited 3 weeks ago) It doesn’t, as long as those images are good about keeping their dependencies up to date. Because containers are entirely self-sufficient and come packaged with all of their necessary dependencies, there is a potential security concern with images keeping dependencies pinned to old, insecure versions. And catching that can be tricky sometimes, especially when you’re running larger stacks with lots of containers. But I’d argue that is actually the image being insecure, not containerization itself. It would be no different from a program being considered insecure. We would handle an insecure image the same way we would handle an insecure program: push the maintainer to update their shit to a secure version, or fork it (if it’s OSS) to update the dependencies directly. Plus, containerization is much more straightforward compared to the olden days of directly managing dependencies. For larger setups, that was basically a full time job by itself. Especially when you have multiple different programs all trying to call different versions of the same dependency. permalink fedilink source parent