Re: LYNX-DEV 02-Nov-96 2-6updates.zip && lynx2-6ssleay.zip

[Foteos Macrides]

Tom Zerucha <address@hidden> wrote to the list:
>On Sat, 2 Nov 1996, Foteos Macrides wrote:
>
>>      I sent Hiram and Tom a v2.6 general update zip, and an SSLeay
>> zip with additional replacement or supplemental files.  The general
>> update zip has:
>> 
>
>This has created a split since the update represents several differences
>from what I have.  It seems to work though.
>
>Now I have a few problems.
>
>Should I continue to update the existing patch, or shift to the new one
>(and what should it be called? 2-6a?).
>
>Should I post the ssleay diff as a patch against the update?
>
>Should I just work on the pre-2.7?

        I don't know.  The lynx2-6mods.zip on our servers is just my
personal incorporation of what's available via posted patches, with
modifications of those as I personally deem appropriate, and stuff
I've personally added.  It's in the same category as anything else
anyone does and makes available, not in the same category as Hiram's
Composite, or Rob's LynxRP.  They'll have to advise you on that matter.

>In some test code, I have certificate handling working (but you would have
>to have SSLeay, probably 6.5 to get all the CAs, set up and configured
>properly).  After resolving some potential export problems with the test
>code I can integrate it with lynx, but which one?

        My Nov. 5 lynx2-6mods.zip has all of your available patches
incorporated.  I'll also email you a uuencoded zip of the SSL hooks
and Makefile (Unix) or .com files (VMS) I'm using as of Nov. 5.  Do
with them as you see fit.


Tom Zerucha <address@hidden> wrote to me instead of lynx-dev:
>
>I have not prepared a patch for distribution for the updates.  I have a
>few observations/suggestions/etc.
>
>My handling for HTFormat was different as of my latest patch.  I don't
>know where HTOutputBinary is used, but if it ever was used for an SSL
>connection it would need to be decoded as well. 

        We don't use HTOutputBinary(), so I didn't bother modifying it.


>In HTFormat.c, in my version, I removed the HTGetSSLCharacter, (and a
>unique HTNewsGetCharacter in HTNews.c) by using macros at the top. 
>
>In general, my patches moved the SSL/nonSSL decision to the top, so there
>would be a (NEWS_or) HTTP_NETREAD defined at the top, and the SSL patch
>would normally only have to affect that.  Your HTFormat and HTAAUtil
>follow the point by point (#ifdef USE_SSL / SSL_read / #else NETREAD). 
>
>One other thing I did was to make handle (I called it ssl_handle) public
>in HTTP.c, and extern elsewhere.  These can be defined in each, but then
>must be passed to where they are used.
>
>The general idea is when everything uses HTTP_NETREAD, I should be able to
>crate an HTSSL.h file so that I can just do
>#ifdef USE_SSL
>#include <HTSSL.h>
>#endif
>and very few other adjustments.
>
>In HTAAUtil, you have a namespace problem with a parameter, the line reads
>
>#if USE_SSL
>       handle = (SSL *) handle;
>#endif

        That's not a problem for our compilers, but I changed the static
handles in HTAAUtil.c and HTNews.c to Handle, and left the function
argument names handle.


>Also, Netscape has a "Security Proxy" for all SSL links that uses the
>CONNECT method.  Has this merely been separated into the snews and https
>proxy entries? 
>
>I also don't understand this section from HTNews.c:
>Is this for some kind of proxy or retry?
>
>@@ -1521,27 +1528,6 @@
>      *  Now, let's get a stream setup up from the NewsHost.
>      */
>     for (retries = 0; retries < 2; retries++) {
>-#ifdef USE_SSL
>-        if (handle && channel_s >= 0) {
>-           s = channel_s;
>-           channel_s = -1;
>-           HTInitInput(s);             /* set up buffering */
>-           if ((response(NULL) / 100) != 2) {
>-               char message[BIG];
>-               NEWS_NETCLOSE(s);
>-               s = -1;
>-               HTAlert("Can't read news info.");
>-               if (TRACE)
>-                   fprintf(stderr, "\nNews host %.20s responded:
>%.200s\n",
>-                                   NewsHost, response_text);
>-               FREE(NewsHost);
>-               FREE(NewsHREF);
>-               FREE(ListArg);
>-               return HT_NO_DATA;
>-           }
>-        }
>-#endif /* USE_SSL */
>-
>         if (s < 0) {
>            /* CONNECTING to news host */
>             char url[1024];

        In HTNews.c, we maintain the NNTP connection once one is made,
and only close it if a news, nntp or snews request is made with a
different host.  I declare Handle as static, and only free it on
close of connection, to create a new handle for the new server.  That's
fine as I posted before.  The CONNECT protocol is for an SSL capable
browser to use the SSL procedure through a proxy, with the proxy simply
passing everything back and forth, and not handling the SSL procedure
itself, that always goes though HTLoadHTTP(), to a special function
which creates the static Handle, and then invokes HTLoadNews().  Anything
which goes through HTLoadHTTP() must be re-entrant (see below), and my
mods of your mods restored that, as in my original hooks for the RSA and
the Netscape SSL libraries, as well as plugging some memory leaks.

        By using a module-wide global handle, you preclude the re-entrant
use of HTLoadHTTP() for both standard SSL handling and for CONNECT.  My
mods restore the passing of handles as function arguments, and thus the
ability to have several handles with multiple invokations of HTLoadHTTP(),
as well as a static one for the current NNTP connection.  The static
Handle in HTAAUtil.c is just equated to one created in HTLoadHTTP()
and passed as an argument, 'cuz that's OK for now, but eventually we
will need to keep it contained as an argument passed among the functions.

        In any case, I'm sending you the way I did it for your information
and consideration.  You need not do it that way, and I certainly appreciate
your comments on the way I'm doing it.  I wasn't anticipating that the four
C modules with SSL hooks would be changing very often, such that they
would need changes in conjunction with other mods.  I haven't actually
tried it, but the four modules I'll be sending you should work with
either the current Composite or with my current lynx2-6mods.zip replacement
files (i.e., as further replacements of those).

        I guess just do your thing there, and I, like others will keep
checking anything new you do.  And I'll keep you up to date on my version
of the hooks.

        If Hiram and Rob incorporate my incorporations of your SOCKs mods
and NSL_FORK mods, you're off the "hook" with those (i.e., they're common
"development" code) and you need only keep up the SSL hooks.  I can't
distribute my version of the hooks from here, just email them to
qualified recipients, and I don't want to start up a big email list
for them, rather than just sending them to you for your consideration
and feedback.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;