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