5 ms·
> Sounds like kernel mode DRM or some similarly unwanted bullshit. Look, I hate systemd just as much as the next guy - but how are you getting "DRM" out of thi
by youarentrightjr 9mo ago
> Sounds like kernel mode DRM or some similarly unwanted bullshit.
Look, I hate systemd just as much as the next guy - but how are you getting "DRM" out of this?
- omnicognate 9mo agoAs the immediate responder to this comment, I claim to be the next guy. I love systemd.
- PunchyHamster 9mo agoI don't like few pieces and Mr. Lennarts attitude to some bugs/obvious flaws, but by far much better than old sysv or really any alternative we have. Doing complex flows like "run app to load keys from remote server to unlock encrypted partition" is far easier under systemd and it have dependency system robust enough to trigger that mount automatically if app needing it starts
- mikkupikku 9mo agoI don't mind SystemD.
- josephcsible 9mo ago"cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html
- bri3d 9mo agoHacker News has recently been dominated by conspiracy theorists who believe that all applications of cryptography are evil attempts by shadowy corporate overlords to dominate their use of computing.
- josephcsible 9mo agoNo, it's not "all applications of cryptography". It's only remote attestation.
- mikkupikku 9mo agoBuddy, if I want encryption of my own I've got secure boot, LUKS, GPG, etc. With all of those, why would I need or even want remote attestation? The purpose of that is to assure corporations that their code is running on my computer without me being able to modify it. It's for DRM.
- bri3d 9mo agoI am fairly confident that this company is going to assure corporations that their own code is running on their own computers (ie - to secure datacenter workloads), to allow _you_ (or auditors) to assure that only _your_ asserted code is also running on their rented computers (to secure cloud workloads), or to assure that the code running on _their_ computers is what they say it is, which is actually pretty cool since it lets you use Somebody Else's Computer with some assurance that they aren't spying on you (see: Apple Private Cloud Compute). Maybe they will also try to use this to assert "deep" embedded devices which already lock the user out, although even this seems less likely given that these devices frequently already have such systems in place. IMO it's pretty clear that this is a server play because the only place where Linux has enough of a foothold to make client / end-user attestation financially interesting is Android, where it already exists. And to me the server play actually gives me more capabilities than I had: it lets me run my code on cloud provided machines and/or use cloud services with some level of assurance that the provider hasn't backdoored me and my systems haven't been compromised.
- mikkupikku 9mo agoHow can you be "pretty sure" they're going to develop precisely the technology needed to implement DRM but also will never use or allow it to be used by anybody but the lawful owners of the hardware? You can't. It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
- 9mo ago
- direwolf20 9mo agoRemote attestation is literally a form of DRM
- microtonal 9mo agoThere are genuine positive applications for remote attestation. E.g., if you maintain a set of servers, you can verify that it runs the software it should be running (the software is not compromised). Or if you are running something similar to Apple's Private Compute Cloud to run models, users can verify that it is running the privacy-preserving image that it is claiming to be running. There are also bad forms of remote attestation (like Google's variant that helps them let banks block you if you are running an alt-os). Those suck and should be rejected. Edit: bri3d described what I mean better here: https://news.ycombinator.com/item?id=46785123 https://news.ycombinator.com/item?id=46785123
- direwolf20 9mo agoI agree that DRM feels good when you're the one controlling it.
- egorfine 9mo ago> There are genuine positive applications for remote attestation No doubt. Fully agree with you on that. However Intel ME will make sure no system is truly secure and server vendors do add their mandatory own backdoors on top of that (iLO for HP, etc). Having said that, we must face the reality: this is not being built for you to secure your servers.
- youarentrightjr 9mo ago> Remote attestation is literally a form of DRM Let's say I accept this statement. What makes you think trusted boot == remote attestation?
- direwolf20 9mo agoTrusted boot is literally a form of DRM. A different one than remote attestation.
- elcritch 9mo agoSecure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control.
- youarentrightjr 9mo ago> Secure boot and attestation both generally require a form of DRM. They literally don't. For a decade, I worked on secure boot & attestation for a device that was both: - firmware updatable - had zero concept or hardware that connected it to anything that could remotely be called a network
- warkdarrior 9mo agoInteresting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?
- youarentrightjr 9mo ago> Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source? The update is predicated on a valid signature.
- direwolf20 9mo agoSo your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
- youarentrightjr 9mo ago> So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money. Would love to hear more of your thoughts on how the users of the device I worked on had their freedom restricted! I guess my company, the user of the device that I worked on, was being harmed by my company, the creator of the device that I worked on. It's too bad that my company chose to restrict the user's freedom in this way. Who cares if the application of the device was an industrial control scenario where errors are practically guaranteed to result in the loss of human life, and as a result are incredibly high value targets ala Stuxnet. No, the users rights to run any code trumps everything! Commercial device or not, ever sold outside of the company or not, terrorist firmware update or not - this right shall not be infringed. I now recognize I have committed a great sin, and hope you will forgive me.