Linux on DRM, for those who haven't read this.(OT)
Ok, there's no way to do this gracefully, so I won't even try. I'm going to just hunker down for some really impressive extended flaming, and my asbestos underwear is firmly in place, and extremely uncomfortable. I want to make it clear that DRM is perfectly ok with Linux! There, I've said it. I'm out of the closet. So bring it on... I've had some private discussions with various people about this already, and I do realize that a lot of people want to use the kernel in some way to just make DRM go away, at least as far as Linux is concerned. Either by some policy decision or by extending the GPL to just not allow it. In some ways the discussion was very similar to some of the software patent related GPL-NG discussions from a year or so ago: "we don't like it, and we should change the license to make it not work somehow". And like the software patent issue, I also don't necessarily like DRM myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse to play politics with Linux, and I think you can use Linux for whatever you want to - which very much includes things I don't necessarily personally approve of. The GPL requires you to give out sources to the kernel, but it doesn't limit what you can _do_ with the kernel. On the whole, this is just another example of why rms calls me "just an engineer" and thinks I have no ideals. [ Personally, I see it as a virtue - trying to make the world a slightly better place _without_ trying to impose your moral values on other people. You do whatever the h*ll rings your bell, I'm just an engineer who wants to make the best OS possible. ] In short, it's perfectly ok to sign a kernel image - I do it myself indirectly every day through the kernel.org, as kernel.org will sign the tar-balls I upload to make sure people can at least verify that they came that way. Doing the same thing on the binary is no different: signing a binary is a perfectly fine way to show the world that you're the one behind it, and that _you_ trust it. And since I can imaging signing binaries myself, I don't feel that I can disallow anybody else doing so. Another part of the DRM discussion is the fact that signing is only the first step: _acting_ on the fact whether a binary is signed or not (by refusing to load it, for example, or by refusing to give it a secret key) is required too. But since the signature is pointless unless you _use_ it for something, and since the decision how to use the signature is clearly outside of the scope of the kernel itself (and thus not a "derived work" or anything like that), I have to convince myself that not only is it clearly ok to act on the knowledge of whather the kernel is signed or not, it's also outside of the scope of what the GPL talks about, and thus irrelevant to the license. That's the short and sweet of it. I wanted to bring this out in the open, because I know there are people who think that signed binaries are an act of "subversion" (or "perversion") of the GPL, and I wanted to make sure that people don't live under mis-apprehension that it can't be done. I think there are many quite valid reasons to sign (and verify) your kernel images, and while some of the uses of signing are odious, I don't see any sane way to distinguish between "good" signers and "bad" signers. Comments? I'd love to get some real discussion about this, but in the end I'm personally convinced that we have to allow it. Btw, one thing that is clearly _not_ allowed by the GPL is hiding private keys in the binary. You can sign the binary that is a result of the build process, but you can _not_ make a binary that is aware of certain keys without making those keys public - because those keys will obviously have been part of the kernel build itself. So don't get these two things confused - one is an external key that is applied _to_ the kernel (ok, and outside the license), and the other one is embedding a key _into_ the kernel (still ok, but the GPL requires that such a key has to be made available as "source" to the kernel). Linus -- "DRM.. Digitally Retarded Media. That's exactly what it is - content that cannot reach its full potential because of artificial restraints." -Paul Rickard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, I'm confused... On Monday 28 April 2003 11:16 am, Fred A. Miller wrote:
Ok, there's no way to do this gracefully, so I won't even try. [...] [snipped potentially volatile discussion]
[signed (?)]
Linus
[and with .sig]
-- "DRM.. Digitally Retarded Media. That's exactly what it is - content that cannot reach its full potential because of artificial restraints." -Paul Rickard
I know Fred posts [usually] short one-paragraph "teasers" and a link to the original, so since this wasn't in that format, I first thought it was from Fred himself till I got to the line I presume was the "signature" -- and without an explicit last name, I'll have to ASSume this would be Mr. Torvalds. Further, the subject matter is in direct conflict with the ".sig" quote, so my brain went into a tight loop for a few seconds trying to resolve this. - -- Yet another Blog: http://osnut.homelinux.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: http://osnut.homelinux.net/TomEmerson.asc iD8DBQE+rYUEV/YHUqq2SwsRAv4qAJ0UWcZFmwrtng9RNMtJnub8WUghPACgvOY/ DqIwcK9xjWraCA/AAa5mT2M= =qTsD -----END PGP SIGNATURE-----
On Mon, 28 Apr 2003 14:16:55 -0400
"Fred A. Miller"
I want to make it clear that DRM is perfectly ok with Linux!
There, I've said it. I'm out of the closet. So bring it on...
Btw, one thing that is clearly _not_ allowed by the GPL is hiding private keys in the binary. You can sign the binary that is a result of the build process, but you can _not_ make a binary that is aware of certain keys without making those keys public - because those keys will obviously have been part of the kernel build itself.
So don't get these two things confused - one is an external key that is applied _to_ the kernel (ok, and outside the license), and the other one is embedding a key _into_ the kernel (still ok, but the GPL requires that such a key has to be made available as "source" to the kernel).
Linus
I don't know if this specifically applies..... a way to pgp sign elf files. http://www.jukie.net/~bart/elfpgp This is a way to actually put your gpg key right inside a binary, and a way to check it. It also kindof shows how trojans could be injected into binaries. There will be alot more development in this area, on both windows and linux. I think the problem comes when the government wants to mandate that all processors are built with circuits built in, that will check these keys. Even that is not so bad, having a real time gpg hardware; but it does get crummy looking when Microsoft wants to run it. It would be a pretty nice system, to have a processor which could load a "bank of keys", (like soundfonts get loaded). Then verify binaries when they are run. This would benefit everyone. I'll start worry when they mandate that you implant "pgp idenfication chips" under everyone's skin, and all monitors won't work unless the "keyserver in command central" says you're "OK". -- use Perl; #powerful programmable prestidigitation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 28 April 2003 17:44 pm, zentara wrote:
I think the problem comes when the government wants to mandate that all processors are built with circuits built in, that will check these keys. Even that is not so bad, having a real time gpg hardware; but it does get crummy looking when Microsoft wants to run it.
This mirrors my sentiments pretty closely. I have to wonder about why M$ thinks they have the right to be able to oversee/admin this sort of stuff, especially if it goes to the hardware side of things (i.e. on/in a chip and either via firmware, hardcodeed die work or both). Though not crazy about having the government run this stuff (initially this means U.S. government, 'till/if others follow). If given a choice between the feds or M$ I think the lesser of two evils is obvious. I am always leary about this stuff when one gets past the how to implement this stuff phase and moves on to the "who holds the keys to the kingdom" question. For me this is the real show stopper. How does on make sure that the right entity is adminimg this and in the right fashion? I understand why Linus has a rather detached attitude about this. If it doesn't go into the kernel/GPL, etc without being opened then the issue is less of a concern. But, I am greatly bothered by the push M$ is doing to both implement this and then try to get everyone on board with them as admin to manage this stuff. Funny thing is they have a big time guru that's work for them on a catalog/tracking program that boils down those all too familiar M$ things like my pictures, my documents, and yes his project, My Life (been a lot of fun on /.). Until I can be fairly assured that some responsible party (and M$ ain't it) will be overseeing and running this it gets a big NO vote from me. Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+rwzE7WVLiDrqeksRAirHAJ4+CXVxelrIaIwHJcVH0sdxyvrKUACbBUxQ 54xIv6+ywZbmR6b9Wy5WC6o= =f1H4 -----END PGP SIGNATURE-----
I'm sure that somewhere in the world, a team of "game crackers" are already working on getting around this one. Only hoping that what they create works in the linux world as well as 'other' os's. scsijon At 09:37 AM 4/30/03, Curtis Rey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 28 April 2003 17:44 pm, zentara wrote:
I think the problem comes when the government wants to mandate that all processors are built with circuits built in, that will check these keys. Even that is not so bad, having a real time gpg hardware; but it does get crummy looking when Microsoft wants to run it.
This mirrors my sentiments pretty closely. I have to wonder about why M$ thinks they have the right to be able to oversee/admin this sort of stuff, especially if it goes to the hardware side of things (i.e. on/in a chip and either via firmware, hardcodeed die work or both).
Though not crazy about having the government run this stuff (initially this means U.S. government, 'till/if others follow). If given a choice between the feds or M$ I think the lesser of two evils is obvious. I am always leary about this stuff when one gets past the how to implement this stuff phase and moves on to the "who holds the keys to the kingdom" question. For me this is the real show stopper. How does on make sure that the right entity is adminimg this and in the right fashion?
I understand why Linus has a rather detached attitude about this. If it doesn't go into the kernel/GPL, etc without being opened then the issue is less of a concern.
But, I am greatly bothered by the push M$ is doing to both implement this and then try to get everyone on board with them as admin to manage this stuff. Funny thing is they have a big time guru that's work for them on a catalog/tracking program that boils down those all too familiar M$ things like my pictures, my documents, and yes his project, My Life (been a lot of fun on /.).
Until I can be fairly assured that some responsible party (and M$ ain't it) will be overseeing and running this it gets a big NO vote from me.
Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+rwzE7WVLiDrqeksRAirHAJ4+CXVxelrIaIwHJcVH0sdxyvrKUACbBUxQ 54xIv6+ywZbmR6b9Wy5WC6o= =f1H4 -----END PGP SIGNATURE-----
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (5)
-
Curtis Rey -
Fred A. Miller -
scsijon -
Tom Emerson -
zentara