|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Lentsov 2:4615/71.10 28 Mar 2002 17:36:00
To : All
Subject : URL: http://www.lwn.net/2002/0328/
--------------------------------------------------------------------------------
[1][LWN Logo] [2][oasisi.php?s=2&w=468&h=60]
[LWN.net]
Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all
interests
Sections:
Main page
[3]Security
[4]Kernel
[5]Distributions
[6]Development
[7]Commerce
[8]Linux in the news
[9]Announcements
[10]Letters
[11]All in one big page
Other LWN stuff:
[12]Daily Updates
[13]Calendar
[14]Linux Stocks Page
[15]Book reviews
[16]Penguin Gallery
[17]Advertise here
[18]Archives/search
[19]Use LWN headlines
[20]LWN Supporters
[21]Contact us
Recent features:
- [22]2001 Timeline
- [23]O'Reilly Open Source Conference
- [24]OLS 2001
- [25]Gael Duval
- [26]Kernel Summit
- [27]Singapore Linux Conference
- [28]djbdns
Here is the [29]permanent site for this page.
See also: [30]last week's LWN.
Leading items and editorials
The SSSCA under any other name smells just as foul. U.S. Senator
Ernest Hollings ("the Senator from Disney") has submitted his latest
payback to the entertainment industry as the "Consumer Broadband and
Digital Television Promotion Act," which goes under the awkward
acronym of CBDTPA. This proposed law would have far-reaching effects
for the free software community, and is thus worth a close look. For
those wanting more information, a look at [31]the full text of the
bill is worthwhile. We'll go over the relevant portions here.
The bill begins with a set of 23 "findings," intended to justify the
new law. They talk about the plight of the poor content providers, who
just can't bring themselves to make their wares available on the net
(or via digital television) without guaranteed protection. Current
protection schemes are inadequate because:
...those agreements do not prevent the continued use and
manufacture of digital media devices that fail to incorporate such
security measures.
In other words, we're being told that the government must step in and
make content controls mandatory for all "digital media devices." And
what benefit do they "find" we will get from this?
The secure protection of digital content is a necessary
precondition to the dissemination, and on-line availability, of
high quality digital content, which will benefit consumers and lead
to the rapid growth of broadband networks.
Many of our readers may have been unaware of the fact that any
problems with the growth rate of broadband networks are due to the
lack of mandatory copy protection schemes. Or that there is no high
quality digital content on the net. All we have to do is to turn the
net into another form of television, and these problems will go away.
Of course, the DMCA, too, was brought in with promises that it would
enable a flood of wonderful digital products for us to buy...
The core of the CBDTPA is new restrictions on what a "digital media
device" can do. According to the bill, a "digial media device" is
(emphasis added):
The term "digital media device" means any hardware or software
that: (A) reproduces copyrighted works in digital form;
(B) converts copyrighted works in digital form into a form whereby
the images and sounds are visible or audible; or (C) retrieves or
accesses copyrighted works in digital form and transfers or makes
available for transfer such works to hardware or software described
in subparagraph (B).
This is, of course, a very broad definition. Any computer, which has
no trouble "reproducing copyrighted works in digital form," certainly
qualifies. Importantly, a "device" can be software. A Linux
distribution falls under this definition, and would be bound by the
requirements of this law.
The operative part of the CBDTPA falls into two phases: (1) the
establishment of "security system standards," and (2) the requirement
that all "digital media devices" follow those standards.
The establishment of the standards is supposed to be done in the
private sector, which will be given a year to accomplish the task.
Should the private sector fail to get its act together, the government
(in the form of the Federal Communications Commission) will jump in
and set the standards instead. Either way, there's a set of criteria
to be met, defined in these vague terms:
* reliable
* renewable
* resistant to attack
* readily implemented
* modular
* applicable in multiple technology platforms
* extensible
* upgradable
* not cost prohibitive
These terms are not further defined in the proposed law. There is one
other, interesting requirement: "any software portion of such
standards is based on open source code." Of course, "open source" is
not defined for the purposes of this law either; still, in theory, it
means that we should at least be able to see the code for the
"security systems" that are being forced onto our computers.
There is a token nod toward fair use, saying that security systems
must not interfere with fair use rights. The penalties for
noncompliance with this section, though, are very small - far smaller
than those for selling a noncompliant device or stripping protective
codes. It does not look like it is meant to be taken seriously.
Once the standards are set, industry has one more year to implement
them, then the enforcement stage begins. There is a section requiring
ISPs to pass through protected content intact, but the core of the law
is Section 5:
A manufacturer, importer, or seller of digital media devices may
not: (1) sell, or offer for sale, in interstate commerce, or
(2) cause to be transported in, or in a manner affecting,
interstate commerce, a digital media device unless the device
includes and utilizes standard security technologies that adhere to
the security system standards adopted under Section 3.
In other words, unless your Linux distribution (which is a "digital
media device," remember?) implements the security standards, it is now
illegal - at least, if you want to sell it or transport it over state
lines. (The emphasis on "interstate commerce" is the hook that gives
the federal government the authority to regulate the movements of
"digital media devices").
So how can free software function in this legal environment? Given
that the code implementing the security standards is supposed to be
open source, it could conceivably be incorporated into a Linux
distribution. (Note, however, that nothing in the proposed law
requires a patent-free or royalty-free standard). Such work would have
to be done by a distributor; it's hard to imagine the kernel
maintainers willingly incorporating this stuff into the mainline code.
Then Linux users could simply remove that code. Then again, maybe not;
Section 6 says:
No person may knowingly remove or alter any security technology in
a digital media device lawfully transported in interstate
commerce...
So one of the fundamental freedoms of free software would be stripped
away: you would not legally be able to modify your system to fit your
needs.
But then, can a system based on free software ever meet the standards
being set by this law? A source-available system, where users can
remove the corporate big brother code at will, can never be "reliable"
or "resistant to attack" in the eyes of CBDTPA supporters. If that
interpretation holds, Linux systems become illegal whether or not they
include the security code.
What about downloading a Linux distribution from a non-US server? The
legality of such an act will depend on a court's interpretation: is a
user, by virtue of having performed a download, an "importer"? If so,
downloading Linux from outside the U.S. is not allowed; otherwise it
is legal. Either way, people would be at risk of prosecution until the
precedents had been set.
The absurdity of this legislation stretches belief. It's not clear
what chances it has to become law; the Senate seems well beholden to
the entertainment industry, but the House seems to be less
enthusiastic. We should not count on the House to put this one out of
its misery, though; those of us who are in the U.S. need to let our
Senators know what we think of this thing. See [32]this EFF advisory
for more information on how to do that.
iSCSI and patented technology. The [33]IETF IP Storage working group
is charged with the task of defining standards for accessing storage
devices (i.e. disks) directly over an IP network. This is an
increasingly interesting area: as computing systems become more
distributed over ever-faster networks, why not avoid expensive
"storage area network" interconnects and use the existing, cheap
technology? It may well be that, not too long from now, disk drives
(and arrays) will just plug into your household gigabit Ethernet next
to the printer. It will be desirable, of course, for Linux systems to
be able to make use of these drives.
Perhaps the most prominent standard coming out of the IPS working
group is [34]iSCSI, the encapsulation of SCSI commands within the TCP
protocol. The draft iSCSI standard is nearing completion; it will go
to the internet standards "last call" stage shortly. So, one would
hope, there would not be any major outstanding issues with the
standard at this point. Unfortunately, that is not quite true - there
is a patent issue with iSCSI that has the potential to make free
software implementations difficult or impossible.
An important part of the iSCSI standard is authentication. Just
because you have placed a disk drive on the network does not, after
all, mean that you want to let anybody have access to it. Network
drives need a strong and secure authentication protocol, and the
working group has tried to provide one.
The choice for authentication is the "Secure Remote Password" (SRP)
protocol, which is described in [35]RFC 2945. It looks like a
reasonable protocol, providing both authentication and secure key
exchange. There is only one problem: SRP appears to be covered by
three separate patents, with three holders.
* Stanford has an SRP patent. Stanford has offered [36]a
royalty-free license (PDF format) that would appear to offer no
obstacles to a free software implementation.
* Phoenix claims that its "SPEKE" patent may apply to SRP. The
company [37]will make a license available on RAND ("reasonable and
non-discriminatory") terms - not royalty-free.
* Lucent also has two patents which may be applicable to SRP. This
company has made vague promises to make the patents available "in
accordance with normal Lucent licensing practices," which are not
RAND, much less royalty free. Lucent is not currently committing
itself to a position on whether it believes a license is necessary
to use SRP.
The uncertainty behind Lucent's position, in particular, has given the
iSCSI working group cause to worry about the use of SRP. At a working
group meeting last week, the decision was made to demote SRP from an
implemention requirement to an option. Instead, another protocol
(perhaps CHAP augmented by a key exchange protocol) will be made
mandatory.
That could all change, though, and not for the better. According to
[38]the SRP summary from the working group meeting:
Lucent continues to be approached with requests to be more
cooperative. Lucent's actions (or lack thereof) are the primary
cause of this delay to iSCSI.
In other words, the working group is not bothered by the Phoenix
patent, which would require the purchase of a license under RAND
terms. If Lucent becomes "more cooperative," we could find ourselves
faced with an iSCSI standard which is encumbered by patents. That
would not be a good thing for the free software community.
For more information, see [39]the IPS working group's web page, which
has pointers to the relevant draft standards and a mailing list for
discussions.
Inside this LWN.net weekly edition:
* [40]Security: Format string exploits in libsafe; Apache security
and bug fix release
* [41]Kernel: Can close() fail?; cleaning up include files.
* [42]Distributions: Sorcerer, Sorcery, and Lunar-Penguin.
* [43]Development: Parrot 0.0.4, HPIJS 1.0.4, Apache 1.3.24, Analog
5.22 security fix, mpg321 0.2.10, Net Hack 3.4.0, FLTK 1.1.0b12,
Evolution 1.0.3, Advance 0.7.2, Gtk2Hs, mod_lisp 2.2, CPANPLUS
0.01, Python .2.1c2.
* [44]Commerce: The HRP-2P Linux-powered humanoid robot; Linux
software store for Zaurus Handheld; IBM and SuSE to offer
'enterprise ready' Linux services.
* [45]Letters: Hurd, GPL, devexit_p.
...plus the usual array of reports, updates, and announcements.
This Week's LWN was brought to you by:
* [46]Jonathan Corbet, Executive Editor
March 28, 2002
Sponsored Link
[47]Your Text Ad Here
Purchase your own text ad with our self-serve advertising system.
[48]Next: Security
[49]Eklektix, Inc. Linux powered! Copyright Л 2002 [50]Eklektix, Inc.,
all rights reserved
Linux (R) is a registered trademark of Linus Torvalds
References
1. http://lwn.net/
2. http://oasis.lwn.net/oasisc.php?s=2&w=468&h=60
3. http://lwn.net/2002/0328/security.php3
4. http://lwn.net/2002/0328/kernel.php3
5. http://lwn.net/2002/0328/dists.php3
6. http://lwn.net/2002/0328/devel.php3
7. http://lwn.net/2002/0328/commerce.php3
8. http://lwn.net/2002/0328/press.php3
9. http://lwn.net/2002/0328/announce.php3
10. http://lwn.net/2002/0328/letters.php3
11. http://lwn.net//2002/0328/bigpage.php3
12. http://lwn.net/daily/
13. http://linuxcalendar.com/
14. http://lwn.net/stocks/
15. http://lwn.net/Reviews/
16. http://lwn.net/Gallery/
17. http://lwn.net/mediakit/
18. http://lwn.net/archives/
19. http://lwn.net/op/headlines.phtml
20. http://lwn.net/corp/supporters.php3
21. http://lwn.net/op/Contact.html
22. http://lwn.net/2001/features/Timeline/
23. http://lwn.net/2001/features/oreilly2001/
24. http://lwn.net/2001/features/OLS/
25. http://lwn.net/2001/features/MandrakeSoft.php3
26. http://lwn.net/2001/features/KernelSummit/
27. http://lwn.net/2001/features/Singapore
28. http://lwn.net/2001/features/djbdns.php3
29. http://lwn.net/2002/0328/
30. http://lwn.net/2002/0321/
31. http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html
32. http://lwn.net/2002/0328/a/eff-cbdtpa.php3
33. http://www.ietf.org/html.charters/ips-charter.html
34. http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-11.txt
35. http://www.ietf.org/rfc/rfc2945.txt
36. http://otl.stanford.edu/pdf/97006.pdf
37. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09294.html
38. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html
39. http://www.ietf.org/html.charters/ips-charter.html
40. http://lwn.net/2002/0328/security.php3
41. http://lwn.net/2002/0328/kernel.php3
42. http://lwn.net/2002/0328/dists.php3
43. http://lwn.net/2002/0328/devel.php3
44. http://lwn.net/2002/0328/commerce.php3
45. http://lwn.net/2002/0328/letters.php3
46. mailto:lwn@lwn.net
47.
http://oasis.lwn.net/oasisc.php?s=2&c=5&cb=221235253&url=http%3A%2F%2Flwn.net%2F
corp%2Fadvertise%2Ftext%2F
48. http://lwn.net/2002/0328/security.php3
49. http://www.eklektix.com/
50. http://www.eklektix.com/
--- ifmail v.2.14.os7-aks1
* Origin: Unknown (2:4615/71.10@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
URL: http://www.lwn.net/2002/0328/ |
Sergey Lentsov |
28 Mar 2002 17:36:00 |
|
|
