linux-kernel - Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46797C52.4020907@iders.ca>
Date:	Wed, 20 Jun 2007 14:13:22 -0500
From:	Andrew McKay <amckay@...rs.ca>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Alexandre Oliva <aoliva@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@....linux.org.uk>,
	Bernd Schmidt <bernds_cb1@...nline.de>,
	Ingo Molnar <mingo@...e.hu>,
	Daniel Hazelton <dhazelton@...er.net>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>, david@...g.hm,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

Alan Cox wrote:
>> Secondly GPLv3 will cause companies like TIVO, router companies, security 
>> companies to not adopt Linux as an operating system, because they can't secure 
>> their system.  Placing code in a ROM so they can't upgrade their own systems is 
> 
> You've made an important mistake. You said "their system". Now its "our
> code" and "whoever bought the units' hardware" so it isn't their anything.

Yes, the hardware belongs to the user, and the software belongs to the Linux 
community.   However I think I wasn't 100% clear, I also mean keeping companies 
networks and content secured.  Credit card companies insuring the software 
hasn't been modified to skim cards (not that it's the only way to skim a card), 
  or Tivo making sure that their content providers are protected.  Lets look at 
the credit card example.  Sure the user could modify the system and boot their 
own kernel, but it doesn't have to play nice with Mastercard's network anymore. 
  Or better yet, would actually report that a certain business's card reader had 
been tampered with.

> 
> You've made a second mistake I think by assuming that vendor held keys
> "improve" security and must be vendor held and secret for it to work. In
> fact vendor owned key systems that cannot be changed usually reduce
> security.
> 
> There are very very good reasons for having vendor owned secret keys.
> There are also very very good reasons for being able to rekey or disable
> the key on your box.
> 
> Ask people whose product vendor went bankrupt. With the ability to
> override/replace the keys they could have maintained their system
> securely instead they could make no updates and the boxes were left
> insecure.

I do see what you're saying here, and I can see how this is a problem.  However 
what is the solution?  Sure having the system open for users to replace software 
and tinker is great.  It's how I got into engineering.  I can also appreciate 
the ability for the end user to fix and continue to use a system long after a 
vendor goes out of business.  However, I don't see how this would ever require a 
company like Tivo or Mastercard to have their networks play nice with a unit 
that has been modified by the end user, potentially opening up some serious 
security holes.  From what I understand this would still violate GPLv3 because 
the system could no longer preform the task it was designed to do with modified 
code, but maybe I have misunderstood.

Andrew McKay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/