The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(Fwd) Re: crypto export question

--- Forwarded mail from "Ira V. Heffan" <heffan@stanford.edu>

Date: Sat, 25 Jan 1997 03:00:46 -0800 (PST)
From: "Ira V. Heffan" <heffan@stanford.edu>
To: Bruce Perens <bruce@pixar.com>
Subject: Re: crypto export question



On Wed, 22 Jan 1997, Bruce Perens wrote:
> The domain of software designed to protect against malicious computer
> damage is very broad. It includes the login program, the protected-mode
> architecture of the kernel, the code that writes zeroes over memory
> pages before you get them so that you don't see someone else's data,
> internet firewalls, etc.  Other parts of the referenced act
> specifically exclude access control equipment and digital signature
> technology. Please comment on whether the intent or implementation of
> this law would block exports of programs such as /bin/login and network
> firewalls, or if it is specific to cryptography (which we already
> handle by originating and distributing it from a non-U.S. site).
>

Bruce,
Well, I'm waiting for some friends to arrive from the East Coast (who
got snowed in in Chicago), so I decided to wade through those export
regs again.

My conclusion is that I don't think the new rules change things much
for Debian.

The way I read it, the rules are focusing on software that
encrypts and decrypts. So if /bin/login doesn't do encryption, its not the
target of these regulations. The software that it calls to do the
encryption/decryption would be the target--just like before.

To the extent that firewalls use encryption to verify anything, or
especially include software that encrypts or decrypts (like if it
were to encrypt messages going outside a firewall headed for
a "friendly" subnet elsewhere), that would be an export issue.

In context, the virus software seems focused on virus software that uses
encryption to verify the integrity of the files.
It doesn't say that in that sentence, but that's what the rest of the
text indicates to me.  And if the encryption is not available to
the user, and doesn't allow the user to encrypt/decrypt info
directly, then there are exceptions and expedited procedures for it.

I still think its a horrid export policy. For example, I don't know
why we'd allow a book of code, but not the actual software.
My conclusion is that it doesn't seem to me to be an increased problem
for  Debian--but you would know more than I how much of the software
relies on encryption, or whether it would be more secure if encryption
were incorporated into other parts of the system (like the kernel?),
or into the general build instead of doing it as an option, etc.
I still think there's a lot to whine about--you tell me where it
fits into your priorities.

-Ira


---End of forwarded mail from "Ira V. Heffan" <heffan@stanford.edu>


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com