Mailing List Archive

some cpan issues
First, I keep wondering wehther we really ought to include db-1.85
standard with perl. How to download and set it up is not obvious, and it's
a significant gain over NDBM. At the very least, it should be included in
CPAN,a nd so far it isn't.

Next, I notice a DES module that is present in CPAN even in North American. While
I dispise our current national policy, I don't want to go to jail. it
eerytime so I and the rest of us don't get dragged off to jail for being
illegal munitions dealers?

Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
"I find this a nice feature but it is not according to the
documentation. Or is it a BUG?" "Let's call it an accidental feature.
:-)" Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Re: some cpan issues [ In reply to ]
The older des.pl in scripts/admin is now gone. Left a note
in index.html. I'm not sure whether that one really fit
into the definition, but perl-hackers have had enough trouble
lately.

Thanks for keepin' us sober, Tom.

Sorry to all the non-US sites, I guess it's gonna take
a regexp to mirror.defaults for y'all.

Bill
some cpan issues [ In reply to ]
Tom Christiansen writes:
> First, I keep wondering wehther we really ought to include db-1.85
> standard with perl. How to download and set it up is not obvious, and it's
> a significant gain over NDBM. At the very least, it should be included in
> CPAN,a nd so far it isn't.

I have no idea which CPAN you are talking about.

nic:~ ; ls -l CPAN/src/misc/db*
-rw-r--r-- 1 jhi ftp 258569 Jun 20 1994 CPAN/src/misc/db.1.79.tar.gz
-rw-r--r-- 1 jhi ftp 270953 Sep 1 1994 CPAN/src/misc/db.1.85.tar.gz
lrwxrwxr-x 1 jhi ftp 14 Jun 17 14:30 CPAN/src/misc/db.tar.gz -> db.1.85.tar.gz
nic:~ ;

> Next, I notice a DES module that is present in CPAN even in North American. While
> I dispise our current national policy, I don't want to go to jail. it
> eerytime so I and the rest of us don't get dragged off to jail for being
> illegal munitions dealers?

Sigh. Why don't you just do something like [spook spook spook spook]
to your rotten [spook] and idiotic [spook spook]?

ITAR cares about USAns trading "arms" to foreigners. You USA sites
better also stop distributing modules/by-module/Des/ if you are going
to behave as your national security people want.

Rather than deleting the naughty bits I would rather see all the CPAN
USA sites carrying a separate document (README.something) that would
explicitly prohibit any non-USAn to pick anything encryption stuff
from this site. I can put a note about such a file to the top level
README -- but some of you USAns will have to write such a file
first. This is the policy for example Digital uses in gatekeeper *) --
there are naughty files in there but DEC forswears any responsibility
because it has told about there possibly being such naughty files.

The French are by law not allowed even to _use_ _any_ encryption (sole
privilege of the army and the like) but I have still to see them stop
distributing it.

++jhi;

P.S. ftp://ftp.gatekeeper.dec.com/US-Legal-Regs-ITAR-NOTICE:
***** WARNING *****

This notice references certain program source code which may be subject to
United States Federal Law and regulations concerning distribution outside
of the United States or transfer to a "non US entity". Digital employees
should consult with a representative of the Digital US Export Compliance
office prior to accessing this software. Other users of this archive are
advised to seek legal advice. Programs containing implementation of data
encryption and other algorithms are subject to US Federal ITAR regulation.
An export license from the US State Department may be required. Legal
advice is advised.
some cpan issues [ In reply to ]
I of course understand you deleting the des.pl, it has very clearly
come from Australia to Bill at Metronet, very-much-USA, and from there
it has sailed away and duplicated all over the world. I have seen
people explain that ITAR's groping hands apply even to the Eric
Young's (the guy in Australia who has written a well-known DES
implementation and _also_ the guy, erm, mate?, behind the des.pl)
encryption software _because_ the network connection of Australia _comes_
through_ the US. *) Because the DES code has touched the American soil
it has become a munition.

++jhi;

*) Not unlike someone saying that 'because the pop concert came through
the radio _I_ own I also can deny playing the songs to foreigners.'
Re: some cpan issues [ In reply to ]
> Next, I notice a DES module that is present in CPAN even in North America.
> While
> I dispise our current national policy, I don't want to go to jail. it
> eerytime so I and the rest of us don't get dragged off to jail for being
> illegal munitions dealers?

Ah! No wonder you wrote "MUNITIONS" in four-inch high letters on
the review copy of my book!

DES is kosher. It's pretty much only RSA that poses problems, because
it's a) patented, and b) really *is* hard to break.

DES is non-proprietary (even though IBM did the initial development)
and exportable. It's even the "ANSI Standard for Data Encryption"
as per X3.92-1981. The ISO even said, "yeah, let's make this a worldwide
standard" before they decided to avoid cryptography altogether.

FIPS (Federal Information Processing Standard) 46-1 states that
federal employees should *not* use DES to protect classified
information. So the ITAR boys can't really say that it's in "the
interests of national security" to keep it bottled up.

Jon
Re: some cpan issues [ In reply to ]
>>>>> "tom" == Tom Christiansen <tchrist@mox.perl.com> writes:

tom> Next, I notice a DES module that is present in CPAN even in North American. While
tom> I dispise our current national policy, I don't want to go to jail. it
tom> eerytime so I and the rest of us don't get dragged off to jail for being
tom> illegal munitions dealers?

Malcolm Beattie's DES module does not contain DES code. It's a module
based on the des library by Eric Young which is not contained in the
package. Sure you still might run a risk of breaking USA law -- I
don't know. Could anybody check that out, before all the USA sites
delete the module?

andreas
Re: some cpan issues [ In reply to ]
>
>
> > Next, I notice a DES module that is present in CPAN even in North America.
> > While
> > I dispise our current national policy, I don't want to go to jail. it
> > eerytime so I and the rest of us don't get dragged off to jail for being
> > illegal munitions dealers?
>
> Ah! No wonder you wrote "MUNITIONS" in four-inch high letters on
> the review copy of my book!
>
> DES is kosher. It's pretty much only RSA that poses problems, because
> it's a) patented, and b) really *is* hard to break.
>
> DES is non-proprietary (even though IBM did the initial development)
> and exportable. It's even the "ANSI Standard for Data Encryption"
> as per X3.92-1981. The ISO even said, "yeah, let's make this a worldwide
> standard" before they decided to avoid cryptography altogether.

Could I get some confirmation on this? Tom? I was feeling
pretty wimpy after last night's removal, but I'm not willing
to put the metronet folks, or anyone here, at risk.


>
> FIPS (Federal Information Processing Standard) 46-1 states that
> federal employees should *not* use DES to protect classified
> information. So the ITAR boys can't really say that it's in "the
> interests of national security" to keep it bottled up.
>
> Jon
>

Thanks,

Bill
Re: some cpan issues [ In reply to ]
>>
>>
>> > Next, I notice a DES module that is present in CPAN even in North America.
>> > While
>> > I dispise our current national policy, I don't want to go to jail. it
>> > eerytime so I and the rest of us don't get dragged off to jail for being
>> > illegal munitions dealers?
>>
>> Ah! No wonder you wrote "MUNITIONS" in four-inch high letters on
>> the review copy of my book!
>>
>> DES is kosher. It's pretty much only RSA that poses problems, because
>> it's a) patented, and b) really *is* hard to break.
>>
>> DES is non-proprietary (even though IBM did the initial development)
>> and exportable. It's even the "ANSI Standard for Data Encryption"
>> as per X3.92-1981. The ISO even said, "yeah, let's make this a worldwide
>> standard" before they decided to avoid cryptography altogether.

>Could I get some confirmation on this? Tom? I was feeling
>pretty wimpy after last night's removal, but I'm not willing
>to put the metronet folks, or anyone here, at risk.

I have long labored under the idea that you can't ship DES stuff without
special dispensation. That's why there exist international versus
northamerican distributions of a lot of software. I guess I could ask
Phil when I get back to frigid 15 below 0 F Boulder tonight from sunny
pleasant Tucson. :-)

--tom
Re: some cpan issues [ In reply to ]
On Fri, 8 Dec 1995, Andreas Koenig wrote:

> Malcolm Beattie's DES module does not contain DES code. It's a module
> based on the des library by Eric Young which is not contained in the
> package. Sure you still might run a risk of breaking USA law -- I
> don't know. Could anybody check that out, before all the USA sites
> delete the module?

I think some of the export restrictions can even extend to code that
contains "hooks" for encryptation to be added later, so it probably isn't
absolutely safe. I am not a cryptology expert, so don't listen to me,
though.

> andreas

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: some cpan issues [ In reply to ]
> DES is kosher. It's pretty much only RSA that poses problems, because

Sorry, Jon, that's completely wrong. You can NOT export DES in source
or binary form with out a license, and you can't get the license for
source (you can for binary in authentication-only products, like
OpenVision's kerberos V product, but for source products, you can't
get export permission. My life would be a *lot* easier if I could
export des or kerberos source; you'd even find *my* implementation of
des (and kerberos!) in perl in CPAN, but instead I've never published
it...)
_Mark_ <eichin@cygnus.com>
Cygnus Support
Cygnus Network Security <network-security@cygnus.com>
http://www.cygnus.com/data/cns/
ps. For more details on the ITAR, check the ftp.cygnus.com ftp server
(there may be pointers on the web too) for John Gilmore's archive of
public actions related to the ITAR. However, don't take action based
on my advace, or probably even your own interpretation, without
competent legal counsel -- ITAR involves jail terms, and there have
been ITAR-related convictions.)
Re: some cpan issues [ In reply to ]
As for db-1.85 -- although it has some obvious superiorities over dbm,
we had some trouble with it at MIT with large [100K entries]
databases, so it might be worth finding a newer release (the author
may have fixed the bug, but not as of the 1.85 release, as far as I
know...) I don't actually know if there's a newer release, but it
might be worth investigating.
Re: some cpan issues [ In reply to ]
The State Department has, in particular instances, allowed DES export.
But---whoops---they don't do so by default, so they certainly wouldn't
approve of its appearance in CPAN, even though des.pl is freely available
(from U.S. sites, even).

I sincerely apologize for any felony convictions I might have caused.

But, still, I wonder: why the restrictions on an algorithm that was never
intended to be used with classified information?
Re: some cpan issues [ In reply to ]
> But, still, I wonder: why the restrictions on an algorithm that was never
> intended to be used with classified information?

You're forgetting that this is a _legal_ issue. You seem to keep
expecting this to somehow all make sense! :-)
Re: some cpan issues [ In reply to ]
On Sat, 9 Dec 1995, Jon Orwant wrote:

> The State Department has, in particular instances, allowed DES export.
> But---whoops---they don't do so by default, so they certainly wouldn't
> approve of its appearance in CPAN, even though des.pl is freely available
> (from U.S. sites, even).
>
> I sincerely apologize for any felony convictions I might have caused.
>
> But, still, I wonder: why the restrictions on an algorithm that was never
> intended to be used with classified information?

I think because the algorithm is appliable with different key sizes. (Or
something like that.) Implementations locked to lesser then 48-bit keys
are exportable. (Or something like that.)

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)