0.9.6e boffed on Win32 ... but easily recoverable
Attached is a trivial patch to allow Win32 to build the OpenSSL dll's. If you want to post it up to contrib, that's fine. Even a non-patch user should be able to follow what to do. Will # The new OpenSSLDie() entry point was undefined in the 0.9.6e release # and win32 dll's will not build without it. Here's the fix; # --- ../orig/openssl-0.9.6e/util/libeay.num Fri Jan 04 07:02:40 2002 +++ util/libeay.num Wed Jul 31 12:53:53 2002 @@ -1934,3 +1934,4 @@ BN_pseudo_rand_range2523 EXIST::FUNCTION: X509_STORE_CTX_set_verify_cb2524 EXIST::FUNCTION: ERR_load_COMP_strings 2525 EXIST::FUNCTION: +OpenSSLDie 2526EXIST::FUNCTION: --- ../orig/openssl-0.9.6e/util/mkdef.plWed Dec 19 11:48:51 2001 +++ util/mkdef.pl Wed Jul 31 12:50:51 2002 @@ -202,6 +202,7 @@ $crypto.=" crypto/rand/rand.h"; $crypto.=" crypto/comp/comp.h"; $crypto.=" crypto/tmdiff.h"; +$crypto.=" crypto/cryptlib.h"; my $symhacks="crypto/symhacks.h";
[Fwd: OpenSSL Patents?]
This bounced first try, but I was not (yet) subscribed, so I'm resending. Appologies if this arrives twice. Original Message Subject: OpenSSL Patents? Date: Tue, 06 Dec 2005 16:26:15 -0600 From: William A. Rowe, Jr. <[EMAIL PROTECTED]> Reply-To: dev@httpd.apache.org To: dev@httpd.apache.org, openssl-dev@openssl.org Looking at 0.9.8(a) for the official httpd 2.2.0 binary distribution, this includes these (major) new features; Addition of BIGNUM functions for fields GF(2^m) and NIST curves, to support the Elliptic Crypto functions. Major work on Elliptic Crypto; ECDH and ECDSA added, including the use through EVP, X509 and ENGINE. The list of patented methods (therefore not built by the ASF for distribution) remains the same listing RC5, MDC2 and IDEA in the README. But I'm wondering if any of these new Crypto features are known to be protected by patent. Please clarify so I can update our building for win32 document and package the correct binaries for US+International distribution. Bill . __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: OpenSSL Patents?]
Nils Larsch wrote: afaik the included ec algorithms are not tainted by patents but as some countries have braindead patent laws you can never be sure ... Obviously neither the openssl nor apache httpd projects take responsibility for deep patent searches, and should we discover we have offended, we simply pull down the offending project/release until it's resolved. Whoever contributed those algorithms knows from their research if patent claims existed on the published background work they drew from, which is why I ask. I'm not asking for any accounting of submarine patents, just those known to the authors of that code :) Thanks Nils! Bill __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
HPUX PARISC 32 Fatal Makefile Flaw
Well here's a nice ten-liner that will undo the recent damage to HPUX
32 bit builds using HP's compilers/linkers;
+ cc -b -Wl,-B,symbolic,+vnocompatwarnings,-z,+h,libssl.sl.0.9.7 -o
libssl.sl.0.9.7 -Wl,-Fl,libssl.a -ldld
chmod: can't access libssl.sl.0.9.7
WTF is it about? Well, used to link using ld directly, now we are
passing through cc. But without splitting -Wl,-Fl from libssl.a with
a space, therefore without libssl.a as a link input, cc says "ha! nothing
to link" and -silently- goes away (leaving the user wondering, for hours,
what didn't just happen.) Yes, of course there is no libssl.sl.0.9.7.
Secondly, once we remove the space, we crash out with
/usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file
/opt/langtools/lib/crt0.o - shared library must be position
independent. Use +z or +Z to recompile.
http://mail.gnome.org/archives/gtk-list/1999-March/msg00704.html reports
similar issues, with no resolution on how-to-exclude crt0.o from the 'cc'
flavor, so the patch proposes to go back to using ld as worked in 0.9.7e
and other releases.
Finally -b +s disappeared between 0.9.7e and 0.9.7i, for what reason I do
not know, but it certainly is needed on 32 bit builds. Now if the flag
interferes with the 64 bit ld/link loader, then perhaps these can go into
their own set of 32-bit flavor flags? immediately prior to -Fl? Discussion
welcome, I'm happy to play with the 64 bit flavor in about 2-3 weeks when
I'm back from ApacheCon.
Bill
--- Makefile 21 Oct 2005 18:18:09 -
+++ Makefile 7 Dec 2005 00:35:44 -
@@ -516,11 +516,11 @@
shlib=lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR}; \
fi; \
[ -f $$shlib ] && rm -f $$shlib; \
- ALLSYMSFLAGS='-Wl,-Fl'; \
- expr $(PLATFORM) : 'hpux64' > /dev/null && ALLSYMSFLAGS='-Wl,+forceload'; \
- ( set -x; ${CC} ${SHARED_LDFLAGS} \
- -Wl,-B,symbolic,+vnocompatwarnings,-z,+h,$$shlib \
- -o $$shlib $$ALLSYMSFLAGS,lib$$i.a -ldld ) || exit 1; \
+ ALLSYMSFLAGS='-Fl'; \
+ expr $(PLATFORM) : 'hpux64' > /dev/null && ALLSYMSFLAGS='+forceload'; \
+ ( set -x; /usr/ccs/bin/ld ${SHARED_LDFLAGS} \
+ -B symbolic +vnocompatwarnings -b -z +s +h $$shlib \
+ -o $$shlib $$ALLSYMSFLAGS lib$$i.a -ldld -lc ) || exit 1; \
chmod a=rx $$shlib; \
done
--- Makefile.org 21 Oct 2005 18:18:09 -
+++ Makefile.org 7 Dec 2005 00:35:44 -
@@ -516,11 +516,11 @@
shlib=lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR}; \
fi; \
[ -f $$shlib ] && rm -f $$shlib; \
- ALLSYMSFLAGS='-Wl,-Fl'; \
- expr $(PLATFORM) : 'hpux64' > /dev/null && ALLSYMSFLAGS='-Wl,+forceload'; \
- ( set -x; ${CC} ${SHARED_LDFLAGS} \
- -Wl,-B,symbolic,+vnocompatwarnings,-z,+h,$$shlib \
- -o $$shlib $$ALLSYMSFLAGS,lib$$i.a -ldld ) || exit 1; \
+ ALLSYMSFLAGS='-Fl'; \
+ expr $(PLATFORM) : 'hpux64' > /dev/null && ALLSYMSFLAGS='+forceload'; \
+ ( set -x; /usr/ccs/bin/ld ${SHARED_LDFLAGS} \
+ -B symbolic +vnocompatwarnings -b -z +s +h $$shlib \
+ -o $$shlib $$ALLSYMSFLAGS lib$$i.a -ldld -lc ) || exit 1; \
chmod a=rx $$shlib; \
done
Re: HPUX PARISC 32 Fatal Makefile Flaw
Andy Polyakov wrote: But without splitting -Wl,-Fl from libssl.a with a space, ??? 'cc -b -Wl,-Fl,libssl.a ...' should be/is translated to 'ld -b -Fl libssl.a ...' by cc. Comma in cc -Wl stands for space in ld line. Yes, that is absolutely correct. However, you are telling cc to pass this through without thinking about it, correct? So cc doesn't know that, in fact, there is a source object (libssl.a) because it was burried in a -Wl. Therefore cc thinks there are no inputs, and does nothing. Change to a space and now ld gets to chew on it. Secondly, once we remove the space, You contradict yourself: first you say "space is required," and here you say "space has to be removed." Make up your mind:-) Yes, I mistyped. Once we have a space, and therefore, one input (a .a file) we crash out with /usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file /opt/langtools/lib/crt0.o - shared library must be position independent. Use +z or +Z to recompile. 'cc -b ...' should be/is translated to 'ld -b ...' *without* crt0.o. Add -v flag to the above command line and test with and without -b. cc in this case did add crt0.o . I will retest this theory with otherwise absolutely minimum changes, verify the results and report back what ld was given. http://mail.gnome.org/archives/gtk-list/1999-March/msg00704.html reports similar issues, with no resolution on how-to-exclude crt0.o from the 'cc' flavor, They were using -Wl,-b, while you're expected to pass -b directly to cc. Ack, I see that, but the two mean different things I expect. -b to hp ld means no built in link paths (same as +b disable to chatr). Finally -b +s disappeared between 0.9.7e and 0.9.7i, ??? You yourself have presented evidence that -b is there [command line above]. That's HPUX -b which means something quite different than cc thinks. Again, I'll retest and report back. As for +s, it's used to link executables [where it's actually effective], but not to lib*.sl [where it does nothing anyway]. Verify the application link command line for presence of +s. chatr tells me it's staticbound, and I desired to follow SHLIB_PATH. But this is fair disagreement on the point. I can override with my own LDFLAGS choice, but it's a -change- from 0.9.6/.7 prior versions, therefore likely to bite someone. +s determines that SHLIB_PATH is used to follow -this- binaries (executable or shared lib) dependent libs are found. I concur, it might not be necessary, so I'll drop the question for the moment. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: servername extension and apache 2.2.0
If you want to submit and have considered by the httpd project, perhaps you ment to submit it there? Nice work b.t.w. Bill Peter Sylvester wrote: Hello, I just have put together the small patch for apache 2.2.0 which allows to use the sernername extension logic in the development snapshot in order to select a different ssl context, and also to renegotiate if the vhost indicated by Host: has a different SSL_ctx (e.g. certificate). The patch also includes a little "const" fix due the SSL_method change. See http://www.edelweb.fr/EdelKey/files/apache-2.2.0+0.9.9+servername.patch and http://www.edelweb.fr/EdelKey/ for the background story Have fun Peter __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ts/*.c files
Gisle Vanem wrote: "Mike Frysinger" <[EMAIL PROTECTED]> wrote: On Tuesday 14 February 2006 11:26, Gisle Vanem wrote: Some of the new ts/ files are too long for a 8+3 filesystem. a ton of files are too long for 8+3 filesystem in the openssl tarball None of the *.[ch] files. They are all 8+3 unique AFAICS (and that's pretty unusual these days). But I need 6.3 for my PDP box!!! Seriously, I first read the request, and from win32's perspective... ts_rsp_print.c > ts_rsp~1.c ts_rsp_sign.c> ts_rsp~2.c ts_rsp_utils.c > ts_rsp~3.c ts_rsp_verify.c > ts_rsp~4.c but then I recalled Netware and some others which do truncation by default and decoration only on a 2nd (and later) name clash, so your request doesn't seem too unorthodox or troublesome. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test
Glad this licked it [yes I was that guest, forgot to sign my note, sorry.] One thing about -xdepend is that Solaris cc 5.x is unrolling one of our loops incorrectly. If someone wants to simplify, try reducing the complex for (;;) and while () loops to avoid (;;x++, y++) or (;x[c++] +=x;) sorts of grammers which have apparently confounded the optimizer. Bill [EMAIL PROTECTED] via RT wrote: via RT schrieb: The fix is trivial; in the solaris-x86-cc line of Configure, you must replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by the -fast argument.) The implicit -xdepend=yes implied by -fast was causing this failure. There may be further code fixes in the evp code to ensure that data dependencies in the loops can be unrolled and optimized. excellent! now it works fine thanks a lot ! best regards, Steffen -- Steffen Unger <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test
Kyle Hamilton wrote: Have you filed a bug with Sun about this issue? No, because the specific loop that failed hasn't been identified, so it's difficult to give them a precise reproduction case. Moreso, we need to patch this given the large number of Solaris cc compilers deployed. Loop-data optimizations are a historical sore point with solaris compilers, appearing to have many artificats from overly agressive optimization. Research "-xdepend" bugs in the solaris CC release notes, any flavor from the SunStudio 8 through 11. Bill On 2/27/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Glad this licked it [yes I was that guest, forgot to sign my note, sorry.] One thing about -xdepend is that Solaris cc 5.x is unrolling one of our loops incorrectly. If someone wants to simplify, try reducing the complex for (;;) and while () loops to avoid (;;x++, y++) or (;x[c++] +=x;) sorts of grammers which have apparently confounded the optimizer. Bill [EMAIL PROTECTED] via RT wrote: via RT schrieb: The fix is trivial; in the solaris-x86-cc line of Configure, you must replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by the -fast argument.) The implicit -xdepend=yes implied by -fast was causing this failure. There may be further code fixes in the evp code to ensure that data dependencies in the loops can be unrolled and optimized. excellent! now it works fine thanks a lot ! best regards, Steffen -- Steffen Unger <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Alternative Interface that doesn't use Sockets?
Apache 2.x mod_ssl (http://httpd.apache.org/) in fact does not use sockets,
but creates a brigade of buffers to pass up and down the chain. You may want
to compare your implementation ideas to that implementation.
Bill
Michael B Allen wrote:
Hi,
I have an idea for a new interface. At least from looking at the SSL man
pages it looks like everything depends heavily on reading and writing
directly to/from sockets. If the herein suggested interface already
exists then I'd really like to know more about it.
Anyway, I don't have access to sockets. All socket I/O is handled in
another process. I only have access to shared memory buffers.
This is what I was thinking about:
typedef struct {
unsigned char *buf;
size_t bn;
...
} buf_t;
struct ssl {
buf_t *intok;
buf_t *outtok;
...
};
int
ssl_write_encode(struct ssl *ssl, buf_t *output)
{
if (buf_length(ssl->intok))
do_read_handshake_stuff(ssl, ssl->intok);
if (buf_length(ssl->outtok))
do_write_handshake_stuff(ssl, ssl->outtok);
try_write_encode_payload(output);
}
The 'buf_t' type just makes thing a little easier on the eyes. The 'struct
ssl' type is of course the context that holds all handshake state. The
'ssl_write_encode' function would be used to "write" data. So far, nothing
new - here's the different part. Ssl_write_encode just takes data from
'output' and copies it to 'ssl->outtok' but only after being called a
few times to let "tokens" go back and fourth. The idea is conceptually
just like GSSAPI.
To further illustrate how this might be used, consider the following
example [1]:
int
test_ssl_write(struct ssl *ssl, int sock, buf_t output)
{
FD_SET(sock, &rset_master);
FD_CLR(sock, &wset_master);
for ( ;; ) {
rset = rset_master;
wset = wset_master;
select(&rset, &wset);
/* If there's something to read, then read
*/
if (FD_ISSET(sock, &rset)) {
buf_read(sock, ssl->intok);
}
ssl_write_encode(ssl, output);
/* If ready to write we must want to write so write it.
*/
if (FD_ISSET(sock, &wset)) {
buf_write(sock, ssl->outtok);
FD_CLR(sock, &wset_master);
}
/* If there's something to write, indicate so
*/
if (buf_length(ssl->outtok)) {
FD_SET(sock, &wset_master);
}
}
}
This is a standard select loop. Basically 'ssl_write_encode' is called
which initially will very likely not even touch 'output'. Instead it
probably will produce data in 'ssl->outtok' which will cause FD_SET to
indicate writing is desired. On the next pass 'ssl_write_encode' will be
called again and presumably do absolutely nothing since it's internal
state is waiting for an input token which it has not received. But
the data in outtok will be written, we wait on select, read data into
'ssl->intok' and keep going around until the handshake is complete and
'output' is actually copied into 'outtok' and transmitted to the remote
peer.
What do you think? How hard would it be to implement this interface? Any
ideas?
Thanks,
Mike
[1] This example defeats the purpose of the interface since it operates on
sockets but it's the expected test for my new ssl_write_encode function.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1281] Solaris9: 'make test' failure in evp_test
Ping? Any action before the next 0.9.7/0.9.8 releases? As I've mentioned, there is a long and sordid history of bugs/assumptions in Solaris -xdepend optimization, so the trivial solution is to simply apply the fix and be done with it for Solaris cc. Getting a 'fix' from Sun, or finding the lines offensive to the optimizer, seems like an exercise in futility... >>>>> The fix is trivial; in the solaris-x86-cc line of Configure, you must >>>>> replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by >>>>> the -fast argument.) The implicit -xdepend=yes implied by -fast was >>>>> causing this failure. We now have confirmation that this fixes problems seen in solaris 9 and 10, multiple cc versions, both x86 and sparc hardware. Please apply :) Bill William A. Rowe, Jr. wrote: Kyle Hamilton wrote: Have you filed a bug with Sun about this issue? No, because the specific loop that failed hasn't been identified, so it's difficult to give them a precise reproduction case. Moreso, we need to patch this given the large number of Solaris cc compilers deployed. Loop-data optimizations are a historical sore point with solaris compilers, appearing to have many artificats from overly agressive optimization. Research "-xdepend" bugs in the solaris CC release notes, any flavor from the SunStudio 8 through 11. Bill On 2/27/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Glad this licked it [yes I was that guest, forgot to sign my note, sorry.] One thing about -xdepend is that Solaris cc 5.x is unrolling one of our loops incorrectly. If someone wants to simplify, try reducing the complex for (;;) and while () loops to avoid (;;x++, y++) or (;x[c++] +=x;) sorts of grammers which have apparently confounded the optimizer. Bill [EMAIL PROTECTED] via RT wrote: via RT schrieb: The fix is trivial; in the solaris-x86-cc line of Configure, you must replace -fast -xO5 with -fast -xdepend=no (note: -xO5 was implied by the -fast argument.) The implicit -xdepend=yes implied by -fast was causing this failure. There may be further code fixes in the evp code to ensure that data dependencies in the loops can be unrolled and optimized. excellent! now it works fine thanks a lot ! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1322] Patch to openssl-0.9.8a tree to compile on Win32 with "Visual C++ 2005 Express"
FWIW, I've posted our short-term fix to openssl-0.9.7i and 0.9.8a at http://www.apache.org/dist/httpd/binaries/win32/patches_applied/ Almost every patch I've seen is painfully twisted, these are the least complex I could come up with that seemed rational. Note; they add the .pdb output I've been insisting makes the build actually usable (anyone who rolls a binary without should be shot) and the /Oy- which slows things down, a bit, but makes it possible to unroll the stack without a .pdb handy. They emit warnings (harmless - not caught by -WX) that -wd4996 isn't known to Visual Studio 5 and 6, while the -G5 is no longer recognized by Studio 2005. Neither flag is one you would want to part with. Only -D_USE_32BIT_TIME_T is something of a hack, good in that it gets us to the year 2038, bad in that it's probably worth working around, because this may not be the last time we see time_t become disjoint from int. It also rolls in the manifests into their respective binaries. My gut reaction said this would overwrite the existing resources, but in fact they merge quite cleanly. The tweaks to ms/do_masm.bat could probably be applied to the other ms/do_* scripts, they simply ensure that if you ms/do_masm no-this no-that no-theother, everything falls together. Oh, just my 2c, the choices of VC-WIN64I/VC-WIN64A are absolutely horrid. What I wouldn't give for sane VC-WINX64 and VC-WINIA64 target names :) Bill Stephen Henson via RT wrote: [steve - Wed Apr 26 14:13:22 2006]: There is still an error about undefined externals which I'm looking into now. That turned out to be down to a bad installation of VC 2005 Express on my laptop. A reinstall fixed it and the latest snapshot now compiles without any problems. Please check this out as OpenSSL 0.9.8b will be released in the next week or so. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] . __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Any possibility of GPL-based license in the future?
Is it perhaps time for the project maintainers to author the definative "Why OpenSSL is not GPL Licensed, and why it will not be" (not argumentative diatriabe, just simply stating the facts)? Post this on openssl.org and offer inquiring minds a pointer? This is getting silly when 30 days can't pass without folks using OpenSSL's dev list to wax Ptoemaic about the virtues of BSD and GPL schemes. Better to let the license warriors find other homes for this neverending debate? Howard Chu wrote: I think Winsock is an obvious counter-example - it is clearly BSD-derived, and they have no problems modifying it and staying far away from the original source tree. As a consumer of the Winsock 2.2 MS-enhanced API in the APR compatibility library and Apache httpd, I assure you we thank goodness for that :-) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Compiler otimization error on Solaris AMD64
Well documented; see bug rt 1281, just tweak -xdepend - because this was already a problem for both sparc and x86, the fact that it's present in 64 bit compilations is no surprise. David Shambroom wrote: > The file openssl_0.9.8b/crypto/aes/aes_core.c is based on > rijndael-alg-fst.c by Rijnmen, Bosselaers, and Barreto. I discovered in > the context of another project that when this file is compiled on > Solaris AMD64: > > $ uname -a > SunOS opterondev 5.10 Generic i86pc i386 i86pc > > using Sun's compiler with the -fast option, the generated code produces > incorrect output. The Configure target solaris64-x86_64-cc includes > this option. Testing with: > > ./Configure solaris64-x86_64-cc > make > make test > > confirms that OpenSSL has inherited the problem: > > Testing cipher AES-128-ECB(encrypt) > Key > 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f > Plaintext > 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff > Ciphertext > 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a > Ciphertext mismatch > Got > c7 a8 a6 29 7a 35 71 44 21 e3 7a f9 e8 b5 bd af > Expected > 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a > > I will be opening a support case with Sun. > > --David __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Issues with arch:opt:opt:opt pattern replacement
Rather than perpetually patch Configure, I'm trying to determine if there is a way to substitute just one of the options. E.g., the patterns for linux are fine, but in order to avoid confusing the environment, I'd like to override cc with gcc -m32 or gcc33 and otherwise accept openssl's other opt patterns verbatim. In other cases, I tweak the HP/UX flags to handle shared libs the way I prefer; here again it would be better to just tweak two patterns rather than passing a monstrous platform:vals pattern. Some of the existing flags include some very quirky macro substitutions which I have alot of issues passing from the ./Configure line. If this is not supported in any manner whatsoever, would a patch be entertained to accomplish this opt-by-opt? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Issues with arch:opt:opt:opt pattern replacement
Richard Salz wrote:
>> E.g., the patterns for linux are fine, but in order to avoid confusing
>> the environment, I'd like to override cc with gcc -m32 or gcc33 and
>> otherwise accept openssl's other opt patterns verbatim.
>
> something like this, around line 943:
> my $cc = $ENV{'CC'} || $fields[$idx_cc];
> So you can do
> CC=gcc33 ./Configure
> or ( setenv CC gcc33 ; ./Configure )
Wouldn't care to have that much code times 20+ options that are plugged
in from the pattern string, and if you are overriding, you probably do
not want to pick up the CC envvar, because the rest of the flags are
very closely tied to the compiler type. Not a real solution, and back
to patching openssl, which I'd like to quit.
This is the syntax I'm thinking of...
./Configure platform:cc:cflags:unistd:thread_cflag:sys_id:lflags
today sets the remaining 17 flags to defaults - not to {platform}'s original
defaults, but far less useful defaults. For an illustration, compare
configuring with your {platform}:gcc to simply {platform}.
I'm not suggesting we break this syntax; we really shouldn't.
So the alternate syntax I'm thinking of is...
platform:=gcc:+{more_cflags}={lflags_override}
which would preserve all but the three fields assigned by default
to the given platform.
The rule is that the first option, the cc choice, must have a leading
= or + to trigger the behavior. A field of :=value: would replace the
existing table field, a field of :=: would unset the table field, and
a other :value: entries would append to the existing table field (space
separated).
In the first field :+-m32: would append -m32 and trigger this behavior,
:=gcc33: would set gcc32 and trigger the behavior, while :+: alone is
a shorthand to simply trigger the new behavior but leave the existing
cc value alone. The :+ meaning applies only to the first field.
I specifically choose not to give :+xxx: a different meaning in the
remaining fields because + is very often a legitimate leading character,
while there's not a single example where = is a legitimate leading character.
I considered a corresponding remove partial syntax but that seems just a
bit to aggravating, and can usually be accomplished by simply overriding
the default with :=value: syntax.
Feedback on this proposal?
Bill
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[Patch]: Issues with arch:opt:opt:opt pattern replacement
Patch attached against 0.9.7, out of cycles to try applying this to HEAD at
this exact moment. The patch does one other small conservation, when it
splits options it leaves one lingering ::: value beyond the last used
element rather than several dozen unused array values.
Again, comments and feedback welcome.
Bill
William A. Rowe, Jr. wrote:
>
> ./Configure platform:cc:cflags:unistd:thread_cflag:sys_id:lflags
>
> today sets the remaining 17 flags to defaults - not to {platform}'s original
> defaults, but far less useful defaults. For an illustration, compare
> configuring with your {platform}:gcc to simply {platform}.
>
> I'm not suggesting we break this syntax; we really shouldn't.
>
> So the alternate syntax I'm thinking of is...
>
> platform:=gcc:+{more_cflags}={lflags_override}
>
> which would preserve all but the three fields assigned by default
> to the given platform.
>
> The rule is that the first option, the cc choice, must have a leading
> = or + to trigger the behavior. A field of :=value: would replace the
> existing table field, a field of :=: would unset the table field, and
> a other :value: entries would append to the existing table field (space
> separated).
>
> In the first field :+-m32: would append -m32 and trigger this behavior,
> :=gcc33: would set gcc32 and trigger the behavior, while :+: alone is
> a shorthand to simply trigger the new behavior but leave the existing
> cc value alone. The :+ meaning applies ONLY to the first field.
>
> I specifically choose not to give :+xxx: a different meaning in the
> remaining fields because + is very often a legitimate leading character,
> while there's not a single example where = is a legitimate leading character.
Note if I had, the format platform:+-m32:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+
required was damned ugly :)
> I considered a corresponding remove partial syntax but that seems just a
> bit to aggravating, and can usually be accomplished by simply overriding
> the default with :=value: syntax.
>
> Feedback on this proposal?
--- Configure 6 Sep 2006 03:01:18 - 1.3
+++ Configure 18 Jan 2007 20:54:48 -
@@ -616,6 +616,7 @@
my $idx_shared_extension = $idx++;
my $idx_ranlib = $idx++;
my $idx_arflags = $idx++;
+my $idx_count = $idx;
my $prefix="";
my $openssldir="";
@@ -891,8 +892,14 @@
}
elsif ($_ =~ /^([^:]+):(.+)$/)
{
- eval "\$table{\$1} = \"$2\""; # allow $xxx constructs in the string
- $target=$1;
+ my $scheme;
+ $target = $1;
+ eval "\$scheme = \"$2\""; # allow $xxx constructs in the string
+ if (defined $table{$target})
+{
+$scheme = merge_build_cmds($scheme, $table{$target});
+}
+ $table{$target} = $scheme;
}
else
{
@@ -1000,7 +1007,7 @@
print "IsWindows=$IsWindows\n";
-my @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
+my @fields = split(/\s*:\s*/,$table{$target} . ":" x $idx_count, $idx_count + 1);
for (@fields) { s/%([\dA-Fa-f]{2})/chr(hex($1))/eg; }
my $cc = $fields[$idx_cc];
my $cflags = $fields[$idx_cflags];
@@ -1699,7 +1706,7 @@
{
my $target = shift;
- my @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
+ my @fields = split(/\s*:\s*/,$table{$target} . ":" x $idx_count, $idx_count + 1);
for (@fields) { s/%([\dA-Fa-f]{2})/chr(hex($1))/eg; }
(my $cc,my $cflags,my $unistd,my $thread_cflag,my $sys_id,my $lflags,
my $bn_ops,my $bn_obj,my $des_obj,my $bf_obj,
@@ -1747,7 +1754,7 @@
foreach $target (sort keys %table)
{
- @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
+ @fields = split(/\s*:\s*/,$table{$target} . ":" x $idx_count, $idx_count + 1);
for (@fields) { s/%([\dA-Fa-f]{2})/chr(hex($1))/eg; }
if ($fields[$idx_dso_scheme-1] =~ /^(dl|dlfcn|win32|vms)$/)
@@ -1772,3 +1779,39 @@
print STDERR "No sanity errors detected!\n" if $errorcnt == 0;
return $errorcnt;
}
+
+sub merge_build_cmds
+ {
+ my $new; my $orig;
+ ($new, $orig)[EMAIL PROTECTED];
+ print 'Base: ' . $orig . "\n";
+ print 'Add: ' . $new . "\n";
+ if ( ! (( $new =~ m/^=/ ) || ( $new =~ s/^\+// )) )
+ {
+ return $new;
+ }
+
+ my @newfields = split(/\s*:\s*/,$new . ':' x $idx_count, $idx_count + 1);
+ my @origfields = split(/\s*:\s*/,$orig . ':' x $idx_count, $idx_count + 1);
+ my $idx = 0;
+ while ($idx < $idx_count)
+ {
+ if ( ! ( $newfields[$idx] =~ s/^=// ) )
+ {
+ if ( ! length($newfields[$idx]) )
+{
+$newfields[$idx] = $origfields[$idx];
+}
+ elsif ( length($origfields[$idx]) )
+{
+$newfields[$idx] = $origfields[$idx] . ' '
+ . $newfields[$idx];
+}
+ }
+ $idx++;
+ }
+ $new = join(':',@newfields);
+ print 'Fin: ' . $new . "\n";
+ return $new;
+ }
+
Re: [Patch]: Issues with arch:opt:opt:opt pattern replacement
Gentle ping...
is there any desire to implement this sort of a solution? Any feedback on the
suggested syntax? I'm happy to forward port this now to trunk for folks to
begin experimenting with it, if there is interest.
William A. Rowe, Jr. wrote:
> Patch attached against 0.9.7, out of cycles to try applying this to HEAD at
> this exact moment. The patch does one other small conservation, when it
> splits options it leaves one lingering ::: value beyond the last used
> element rather than several dozen unused array values.
>
> Again, comments and feedback welcome.
>
> Bill
>
>
> William A. Rowe, Jr. wrote:
>> ./Configure platform:cc:cflags:unistd:thread_cflag:sys_id:lflags
>>
>> today sets the remaining 17 flags to defaults - not to {platform}'s original
>> defaults, but far less useful defaults. For an illustration, compare
>> configuring with your {platform}:gcc to simply {platform}.
>>
>> I'm not suggesting we break this syntax; we really shouldn't.
>>
>> So the alternate syntax I'm thinking of is...
>>
>> platform:=gcc:+{more_cflags}={lflags_override}
>>
>> which would preserve all but the three fields assigned by default
>> to the given platform.
>>
>> The rule is that the first option, the cc choice, must have a leading
>> = or + to trigger the behavior. A field of :=value: would replace the
>> existing table field, a field of :=: would unset the table field, and
>> a other :value: entries would append to the existing table field (space
>> separated).
>>
>> In the first field :+-m32: would append -m32 and trigger this behavior,
>> :=gcc33: would set gcc32 and trigger the behavior, while :+: alone is
>> a shorthand to simply trigger the new behavior but leave the existing
>> cc value alone. The :+ meaning applies ONLY to the first field.
>>
>> I specifically choose not to give :+xxx: a different meaning in the
>> remaining fields because + is very often a legitimate leading character,
>> while there's not a single example where = is a legitimate leading character.
>
> Note if I had, the format platform:+-m32:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+
> required was damned ugly :)
>
>> I considered a corresponding remove partial syntax but that seems just a
>> bit to aggravating, and can usually be accomplished by simply overriding
>> the default with :=value: syntax.
>>
>> Feedback on this proposal?
>>
>>
>>
>> --- Configure6 Sep 2006 03:01:18 - 1.3
>> +++ Configure18 Jan 2007 20:54:48 -
>> @@ -616,6 +616,7 @@
>> my $idx_shared_extension = $idx++;
>> my $idx_ranlib = $idx++;
>> my $idx_arflags = $idx++;
>> +my $idx_count = $idx;
>>
>> my $prefix="";
>> my $openssldir="";
>> @@ -891,8 +892,14 @@
>> }
>> elsif ($_ =~ /^([^:]+):(.+)$/)
>> {
>> -eval "\$table{\$1} = \"$2\""; # allow $xxx constructs
>> in the string
>> -$target=$1;
>> +my $scheme;
>> +$target = $1;
>> +eval "\$scheme = \"$2\""; # allow $xxx constructs in
>> the string
>> +if (defined $table{$target})
>> +{
>> +$scheme = merge_build_cmds($scheme,
>> $table{$target});
>> +}
>> +$table{$target} = $scheme;
>> }
>> else
>> {
>> @@ -1000,7 +1007,7 @@
>>
>> print "IsWindows=$IsWindows\n";
>>
>> -my @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
>> +my @fields = split(/\s*:\s*/,$table{$target} . ":" x $idx_count, $idx_count
>> + 1);
>> for (@fields) { s/%([\dA-Fa-f]{2})/chr(hex($1))/eg; }
>> my $cc = $fields[$idx_cc];
>> my $cflags = $fields[$idx_cflags];
>> @@ -1699,7 +1706,7 @@
>> {
>> my $target = shift;
>>
>> -my @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
>> +my @fields = split(/\s*:\s*/,$table{$target} . ":" x $idx_count,
>> $idx_count + 1);
>> for (@fields) { s/%([\dA-Fa-f]{2})/chr(hex($1))/eg; }
>> (my $cc,my $cflags,my $unistd,my $thread_cflag,my $sys_id,my $lflags,
>> my $bn_ops,my $bn_obj,my $des_ob
Re: OpenSSL FIPS 140-2 validation
Steve Marquess wrote: > > The "OpenSSL FIPS Object Module", a software component compatible with > the OpenSSL API, has been FIPS 140-2 validated (see certificate #733 and > Security Policy document at > http://csrc.nist.gov/cryptval/140-1/1401val2007.htm). The source > distribution that generates this validated module is at > http://www.openssl.org/source/openssl-fips-1.1.1.tar.gz. >From what I've learned of the FIPS validation process, just want to pause and congratulate (again) all of the openssl developers who had a hand in fitting this round peg in a square hole. Bravo! Bill __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fw: How is OpenSSL affected by changes to Daylight Saving Time (DST) in 2007?
durgaprasad jammula wrote: > > I have a question. How is OpenSSL affected by changes to Daylight Saving Time > (DST) in 2007? And how long ago did you stop beating your wife? (A question with an inherent assumption that it's affected in the first place.) OpenSSL code falls back on the c library (ultimately the kernel on many platforms) so you'll have to consult your C library/OS vendor for more info and updates. Offhand, the impact could be a one-hour error in the creation or expiration dates of certificate data, or the failure of the cache to cross over time zones at the right moment. Since OpenSSL attempts to resolve to GMT there would be a potential one-hour discrepancy between the new changeover and the historical/anticipated change of date, with possibly no impact to the resulting gmt conversion whatsoever depending on the c library implementation, AFAIK. Of course other things on an unpatched system are likely to fall over first. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Clean up no-mdc2 default no-patent cruft?
This patent expired 2 years ago, it seems 1.0.0 is a good time to get this fixed... at least if it remains default-disabled, then the justification should be noted (no longer "patented" but perhaps some "deprecated" commentary?) I think the changes are limited to the lines below... README -- The MDC2 algorithm is patented by IBM. FAQ --- You can configure OpenSSL so as not to use IDEA, MDC2 and RC5 by using ./config no-idea no-mdc2 no-rc5 [...] FYI: Patent numbers and expiry dates of US patents: MDC-2: 4,908,861 13/03/2007 util/cygwin.sh -- CONFIG_OPTIONS="--prefix=/usr shared no-idea no-rc5 no-mdc2" Configure - my %disabled = ( # "what" => "comment" [or special keyword "experimental"] [...] "mdc2" => "default", [...] # This is what $depflags will look like with the above defaults # (we need this to see if we should advise the user to run "make depend"): my $default_depflags = " -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_STORE"; Miscellany -- from util/mk1mf.pl "no-patents" => [\$no_rc2, \$no_rc4, \$no_rc5, \$no_idea, \$no_rsa], Why RSA (expired in 2000)? How are RC2, RC4 in this list. Not patents. Trademarks? Also it seems odd this is recognized by mk1mf.pl - wrong place. Should be set up in Configure. No? Somewhere, perhaps add; MDC2 was covered by a US patent issued to IBM which expired in March 2007. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Geode on-chip AES 128-bit crypto accelerations but OpenSSL doesn't use it
Kyle Hamilton wrote: > > In addition, Intel has been playing nice and getting its code in the > openssl distribution, as a set of patches that were integrated not too > long ago. Nobody has submitted such a patch for the Geode to my > knowledge (I'm not god of the request tracker, but most mails sent to > r...@openssl.org are forwarded to the -dev list; I've not seen any patches > come in). (i.e.: Intel is doing strategic positioning that AMD is not.) So what is the word on the OpenSSL patches to extend driver support for the T2000/T1000 class CPU's, since Intel's patches are being rapidly committed? What is the position on Sun's patches? Is this for code style? Lack of review? Lack of time to commit? I'd like to see the already-written Sparc patched incorporated already, maintaining two forks is a pain. If I can be of help, I would. Bill __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 0.9.8l released
Dr. Stephen Henson wrote: > On Sat, Nov 07, 2009, Guenter wrote: > >> Hi Steve, >> Dr. Stephen Henson schrieb: >>> Oops, I forgot 0.9.8l is just 0.9.8k + the reneg patch and not 0.9.8-stable. >> hmmm, that is really not what many would expect now; f.e. all folks who >> reported bugs agaist 0.9.8k will now wonder why a version which is >> released 8 months later does *not* contain the fixes although the RTs >> where closed which normally indicate that the fix will show up with next >> release. >> > > It was decided that the volume of changes in 0.9.8-stable meant that a > 0.9.8k+reneg patch was the best option to get a fix out quickly with least > chance of any other issues. And AIUI if the new draft RFC seems sensible, .8m follows quickly. Which suggests that trusting 0_9_8 branch would be sensible, so that the whole project feels comfortable shipping such bug fixes plus the full monty solution. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
