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: <Pine.LNX.4.64.0706181447430.14890@asgard.lang.hm>
Date:	Mon, 18 Jun 2007 14:52:19 -0700 (PDT)
From:	david@...g.hm
To:	Alexandre Oliva <aoliva@...hat.com>
cc:	Anders Larsen <al@...rsen.net>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Hazelton <dhazelton@...er.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	debian developer <debiandev@...il.com>,
	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

On Mon, 18 Jun 2007, Alexandre Oliva wrote:

> On Jun 18, 2007, david@...g.hm wrote:
>
>> On Mon, 18 Jun 2007, Alexandre Oliva wrote:
>>> On Jun 18, 2007, david@...g.hm wrote:
>>>
>>>> they want to prevent anyone from modifying the credit card machine to
>>>> store copies of all the card info locally.
>>>
>>> I see.  Thanks for enlightening me.
>>>
>>>> you don't really answer this issue. since these boxes are required to
>>>> be sealed and physically anti-tamper, changing the ROM is not
>>>> acceptable.
>>>
>>> Given the ROM exception in GPLv3, I guess you could seal and
>>> anti-tamper it as much as you want, and leave the ROM at such a place
>>> in which it's easily replaceable but with signature checking and all
>>> such that the user doesn't install ROM that is not authorized by you.
>
>> 'sealed, but easy to replace ROM containing the programming' is a
>> contridiction.
>
>> if a local person can easily replace the programming it doesn't meet
>> the PCI requirements and therefor you just cannot use GPLv3 code for
>> this sort of application.
>
> How can someone easily replace the programming if there's signature
> checking and all?
>
> The sealing of the ROMmed software is accomplished by other means, but
> it's there.  I shall mention that I'm not endorsing or recommending
> this practice, it might very well be copyright infringement even under
> GPLv1 and v2.

Ok, next question, could you do the same thing if you used a CD instead of 
a ROM?

what makes a blob delivered via a network inherently different from the 
same blob delivered via a plugin ROM or CD?

David Lang
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ