Thanks for the reminder.  I'm using this as a todo list right now, and
am dedicating some time for this this weekend.

Cheers,
Richard

In message <[email protected]> on Tue, 30 Mar 2010 22:45:36 
-0500 (CDT), "Steven M. Schweda" <[email protected]> said:

sms> From: "Dr. Stephen Henson" <[email protected]>
sms> 
sms> > Have any of these patches been sent to the request tracker?
sms> 
sms>    A similar question was raised back around 12-NOV-2009:
sms> 
sms> > Can you (and others in this thread) please submit bug fix patches to the
sms> > request tracker ([email protected]) so they don't get overlooked??
sms> 
sms> which got this still-applicable (whining) response:
sms> 
sms> >    From my point of view, "overlooked" is less of a problem than
sms> > "rejected".  And some of the stuff which gets added appears to have been
sms> > tested by no one.
sms> > 
sms> >    For example, I offered revised VMS builders which (among other
sms> > things):
sms> > 
sms> >       Obviated the annoying copying of C source files into the "test"
sms> > directory (symlinks being unsupported on many VMS systems and/or file
sms> > systems).
sms> > 
sms> >       Added an "SSL_" prefix to the object library names so that a
sms> > victim might have some chance of identifying the things amid the clutter
sms> > in SYS$SHARE:
sms> > 
sms> >       A bunch of other stuff which I've forgotten.
sms> > 
sms> >    I also tried building the stuff before I submitted my suggestions.
sms> > 
sms> >    Some of these proposed changes involve functional changes which would
sms> > affect the victims (object library and shared image file name changes,
sms> > for example), so deserve some discussion.  I see very little such
sms> > discussion here.  Suggestions get submitted.  Some get adopted.  Some
sms> > get rejected.  I find out what happened when I see the next "betaN" kit.
sms> > It's not very satisfying, and I've largely stopped caring.  (This may or
sms> > may not be seen as much of a loss.)
sms> 
sms>    Since then, I've tried to engage in some discussion of some changes
sms> I'd like to see, but only Arpadffy Zoltan and I seem to be interested,
sms> and, even when we agree, we have no control over what gets done when. 
sms> It seems pointeless to invest much time submitting extensive patches of
sms> which only small parts are accepted.  I'd prefer to have the argument
sms> first, but that seems almost never to happen.
sms> 
sms>    For example, at least six months ago, I suggested a change to the
sms> names of the shareable images on VMS to correspond more closely with the
sms> naming scheme HP uses in its OpenSSL kit.  Mr. Zoltan also reminded us
sms> that HP ships 32-bit and 64-bit binaries, and suggested making their
sms> generation easier.  The 1.0.0 release seemed to me to be an ideal time
sms> to make those changes.  Repeated attempts to discuss these changes
sms> failed to elicit a response.
sms> 
sms>    Apparently, no one tests any release, beta or final, on VMS until
sms> it's too late.
sms> 
sms>    I'm still testing, but I may have VMS builders working for 1.0.0
sms> which minimize pointless file copying and source tree mutilation.  I
sms> believe that they will even work on newer VMS systems (V8.3) where
sms> symlinks are supported (on ODS5 file systems), and the source kit is
sms> unwrapped so that the symlinks are extracted as symlinks.  There are, of
sms> course, some remaining mysteries:
sms> 
sms>    1.  What's the purpose of this in "apps"?:
sms> 
sms>       md4.c -> ../crypto/md4/md4.c
sms> 
sms> It's the only symlink in there, and it's not obvious to me why.
sms> 
sms>    2.  There are no symlinks in "include/openssl" in the source kit for
sms> these header files:
sms> 
sms>       jpake.h
sms>       md2.h
sms>       rc5.h
sms>       store.h
sms> 
sms> Conscious decision or oversight?
sms> 
sms>    3.  In the new "crypto/whrlpool" code, "wp_block.c" causes problems
sms> on the VAX, where there is no 64-bit integer type to use for "u64". 
sms> There seems to be code in there which pretends that the size of u64 is
sms> open to discussion ("sizeof(u64)"), but it seems (to me) to be pretty
sms> clear that other things will break if it's not 64 bits.
sms> 
sms>    I assume that this stuff can be disabled on the VAX, but I haven't
sms> yet looked for a standard method for doing that.  (Assuming that no one
sms> has any nice 32-bit code to insert to obviate that.)
sms> 
sms>    I'll publish what I have after I get through a VAX build.  Perhaps
sms> Wednesday, but no bets.

-- 
Richard Levitte                         [email protected]
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to