Date: Fri, 04 Aug 1995 06:26:00 -0700 From: Paul Traina <pst@shockwave.com> To: paul@freebsd.org Cc: ache@freefall.cdrom.com (Andrey A. Chernov), CVS-commiters@freefall.cdrom.com, cvs-user@freefall.cdrom.com Subject: Re: cvs commit: src/secure/libexec/telnetd ext.h Message-ID: <199508041326.GAA02096@precipice.shockwave.com> In-Reply-To: Your message of "Fri, 04 Aug 1995 13:25:44 BST." <199508041225.NAA15143@server.netcraft.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Paul Richards <paul@netcraft.co.uk> Subject: Re: cvs commit: src/secure/libexec/telnetd ext.h In reply to Andrey A. Chernov who said > > ache 95/08/03 17:12:09 > > Modified: secure/libexec/telnetd ext.h > Log: > Change default banner to FreeBSD, properly ifdefed by __FreeBSD__ > Hmm, I obviously haven't been paying enough attention but can someone explain to me why we have two telnetd's in the tree? A conservative interpretation of US crypto export laws would lead one to believe that not only can you not export the actual crypto code, you cannot export code that has CALLS to the crypto code. <flame> We all know this is fundamentally bullshit, since the actual descriptions are intended to cover hardware (moving parts) devices, however the bastards who are screwing us in the first place have no motivation to indemnify anyone who tries to export code without a license, and no one has had the wherewithal to take this particular matter to court. </flame> The basic idea here is to foil people from doing plug-in encryption devices where "all but the crypto" is there and supported. The only difference between secure/*/*telnet* and */*telnet* is that the non-secure one has had all of the calls to anything that might remotely be considered encryption physically removed. <flame> This is an ultimate pain in the ass, since we need to maintain the farce of shipping an "un-tainted" version of source code for export, when we have a non-US repository that basicly mirrors the US secure repository. </flame> If we were to be less conservative in our interpretation of the law, we could ship all of secure/* in the normal source tree, and the only difference would be that secure/lib/libdes would remain in secure. In the exportable version, this would simply contain stubs, and we'd link against the stubs... then all you need to do is replace libdes.so.* with a real one and the system would do the right thing. <flame> I just find the whole thing hypocritical, since IMO, the entire point of the exercise is not to control the export of strong crypto, but rather to make it so bloody expensive for companies to incorporate strong general purpose cryptography in their products. </flame>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508041326.GAA02096>