Geoff:
I do not speak for the OpenSSL core team (especially because I am not
a member of it) but I believe that the opinion voiced below does not
reflect the opinion of all Core Team members. At least not from the
conversations that I remember from the openssl-dev list that took
place last Feb. Since the export rules state that I can post source
code to the web as long as I send the web address to bxa, I can most
certainly export a patch (at least by posting it to a web site.)
There were letters of opinion from BXA staff to indicate that open
source projects could not be "contaminated" by exported source code.
- Jeff
> Hi there,
>
> Unfortunately the laws governing exports of software from the US are still
> not yet cut-and-dried. If you are sending patches from the US, there's
> unfortunately a very real risk of "contamination" of the code base if we
> incorporate them. We have been obtaining legal opinion on this issue and
> will continue to keep an eye on how things are changing.
>
> Bug reports from the US that lead to fixes are almost certainly no
> problem, but specific code submissions probably need to be avoided for
> now. I'm sure the others from the development team will pitch in if I've
> misrepresented the situation in any way, and as always;
>
> * I'm not a lawyer.
> * These are only my opinions.
> * They aren't really even *my* opinions but were forced upon me by
> roaming aliens.
>
> Cheers,
> Geoff
>
> On Fri, 4 Aug 2000, Bill Rebey wrote:
>
> > I'm trying to get Windows builds working "better" (a relative term, of
> > course <g>)
> >
> > I would like to see the following changes if I can get them:
> >
> > For Borland C++ Builds:
> >
> > 1) There is a function called ERR_load_CRYPTO_strings in the generated
> > file "cpt_err.c", and another function called ERR_load_crypto _strings in
> > "err_all.c". The names differ only in case, and they end up clashing in the
> > library at TLIB time for libeay32.lib. I don't know what the intention here
> > is, but the collision in the library can't be correct/intended, can it?
> > This may be present in all builds - I don't know - but it is brought to
> > one's attention during Borland builds and should be corrected.
> >
> > 2) I had to make some changes to the makefile 'bcb.mak' to get things
> > to build. I have included a 'diff' to illustrate the suggested changes.
> > All of these changes we necessary to get OpenSSL to build with Borland's
> > "make v5.2", and "bcc 5.4" (the tools that ship with BC Builder 4.0). Could
> > you make the bcb.mak makefile generator generate the makefile with these
> > changes in it?
> >
> > 3) One of the changes in the makefile is to turn off some warnings so
> > that build is at least a little cleaner. I'm a kind of a fanatic about
> > clean, warningless builds and leaving all warnings turned ON if possible so
> > that legitimate mistakes can be caught by a compiler rather than a debugger
> > or a QA lab. If I took the time to prototype all the "missing prototype"
> > functions, parenthesize all the "possibly incorrect assignment" statements,
> > and clean up whatever other warnings I can that BC is spotting for us, would
> > you put the changes in for me or would it be waste of my time?
> >
> > For all Windows Builds:
> >
> > I would like to be able to omit the RAND_SCREEN code from builds. I
> > have diffs of app_rand.c, rand_win.c, and rand.h that can (if NO_RAND_SCREEN
> > is defined) switch off the RAND_screen stuff and instead supply a method of
> > seeding the PRNG that is extremely similar to the UNIX version of RAND_poll
> > in rand_win.c. Are these valid changes? The reason that I'm asking for them
> > is because I don't ever want to use that RAND_screen seeding method, and if
> > I leave that code in there, I get about 10 "_imp_Xxxx undefined" functions
> > when I link with static OpenSSL libraries. Rather than fix the link trouble,
> > I would prefer to just opt out of using this code altogether.
> >
> > These changes are against the 20000731 Snapshot.
> >
> > <<app_rand.c_diff>> <<rand_win.c_diff>> <<rand.h_diff>> <<bcb.mak_diff>>
> >
> > Thanks for considering these changes for me.
> >
> > Bill Rebey
> >
> >
> >
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
