[openssl.org #2394] Check-in 20157 breaks FreeBSD build
On Check-in 20157, it adds #include . http://cvs.openssl.org/chngview?cn=20157 But on FreeBSD /usr/include/malloc.h is following: % cat /usr/include/malloc.h /* $FreeBSD: src/include/malloc.h,v 1.5.36.1.4.1 2010/06/14 02:09:06 kensmith Exp $ */ #if __STDC__ #error " has been replaced by " #else #include #endif So the check-in breaks it. Also note that Mac OS X doesn't have malloc.h, but have malloc/malloc.h. -- NARUSE, Yui nar...@airemix.jp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build
Hello I'm sending again to RT - otherwise it might be forgotten. I would appreciate any comment. Thank you. Regards, Z -Original Message- From: Arpadffy Zoltan [mailto:zoltan.arpad...@scientificgames.se] Sent: den 7 december 2010 12:54 To: Richard Levitte; openssl-dev@openssl.org Subject: RE: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3 Hello Richard, I am sorry for delay, but I am quite busy nowadays. Zoltan.Arpadffy> Zoltan.Arpadffy> ...I am dreaming of the possibility to choose between the 64 and the 32 bit version build and reuse this "not-used option" in MAKEVMS.COM Zoltan.Arpadffy> Zoltan.Arpadffy> During the summer I have submitted a patch for this "feature"... wonder is there any chance for this code to be merged in? Zoltan.Arpadffy> Zoltan.Arpadffy> Richard Levitte> I recall discussing it, because it seemed to be a no-op... but I can't recall getting to an answer (and I'll admit not being a good Zoltan.Arpadffy> participant in that discussion). Zoltan.Arpadffy> Zoltan.Arpadffy> This would be very useful as there are still users that link against 32 bit libraries for some reasons. Zoltan.Arpadffy> From other side the current 64 bits build stays as a default and you would not see any difference if the 32 bit parameter is not explicitly used. Zoltan.Arpadffy> Zoltan.Arpadffy> I'll prepare a patch against STABLE-SNAP-20101124 and when I'm ready I'll submit it again. Richard Levitte> I'll have a look at it when I get it :-) Please, review the attached patch (against STABLE-SNAP-20101124). Changes is short: USAGE: @MAKEVMS.COM [Target] Like @MAKEVMS.COM ALL Defaults: Pointer size = 64 (VAX 32) Debug option= NODEBUG Libraries with pointer_size=32 has a 32 sufix in the name (LIBCRYPTO32, LIBSSL32) pointer_size=64 is the default (except on VAX) and produces standard libraries (LIBCRYPTO, LIBSSL) It works well on my system. ALL TESTS SUCCESSFUL. OpenSSL 1.0.1-dev xx XXX built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /pointer_size=32 OPENSSLDIR: N/A Thank you. Regards, Z pointer_size.patch Description: Binary data
[openssl.org #2392] Haiku patch for openssl-1.0.0c
I first sent in this patch to allow openssl to build on Haiku back in March 2010. This latest patch has only changed the line numbers, everytihng else seems to be the same. Original ticket number was openssl.org #2184 I am leaving a HaikuPorts ticket open until we hear back that this patch has been upstreamed. http://ports.haiku-files.org/ticket/298 -scottmc Scott McCreary HaikuPorts openssl-1.0.0c.patch Description: Binary data
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
Andy,
Am 14.12.2010 00:00, schrieb Andy Polyakov via RT:
My initial reason for the RT was exactly for catching the
output with a script; sure its possible to catch it with IO redirection
too, but in my case I run a VBScript on Windows which is not able to do
IO redirection without launching cmd.exe 1st;
set ex=shell.Exec("...")
while not ex.StdOut.AtEndOfStream
... ex.StdOut.ReadLine ...
wend
hmm, when I was on it I got IO redirection only working when launched
with cscript - not wscript; do you know if the above works with wscript too?
Günter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
>>> I'd argue that it's intentional. The original purpose for -out option
>>> appears to be to emit *certificate* itself, not information about it.
>>> Yes, this kind of means that I reckon that -text option should result in
>>> output to STDout, not to one appointed by -out. There also is
>>> inconsistent usage of STDout when treating -days parameter: error
>>> message should be printed on stderr, not STDout. If nobody screams for
>>> a week, http://cvs.openssl.org/chngview?cn=20156 will go down to
>>> 1.0.x.
>>
>> I'm afraid that the change of the target of the -text option output will
>> break expectations of some scripts people in the wild use. Although it
>> is slightly more logical with the change than before I'd prefer keeping
>> it as is at least for 1.0.x. Of course the -days error output change is
>> fine.
> I second this.
How about -text -noout -out foo.txt writing info to foo.txt, and -text
-out foo.txt to stdout?
> My initial reason for the RT was exactly for catching the
> output with a script; sure its possible to catch it with IO redirection
> too, but in my case I run a VBScript on Windows which is not able to do
> IO redirection without launching cmd.exe 1st;
set ex=shell.Exec("...")
while not ex.StdOut.AtEndOfStream
... ex.StdOut.ReadLine ...
wend
???
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2361] win32: non-blocking BIO_do_connect() returns wrong value
Below remark do *not* mean that issue is dismissed, only that using
Sleep(1) probably is not really good programming practice. The
"work-around" mentioned closer to the end of originating report should
not be considered as "work-around", but as *proper solution*.
> Problem: While using non-blocking I/O, a *second* call to
> BIO_do_connect() always returns non-zero even if the underlying
> connection has not yet been established. A subsequent SSL_connect()
> fails with SSL_ERROR_SYSCALL. (A subsequent WSAGetLastError() returns
> 10057 == WSAENOTCONN == Socket is not connected.) Using
> BIO_should_retry() does not circumvent the problem; it is equally
> misleading as BIO_do_connect().
>
> Here's a rough outline of code to trigger the bug.
>
> BIO *_bio = BIO_new(BIO_s_connect());
> BIO_set_nbio(_bio, 1);
> BIO_set_conn_hostname(_bio, "foo.bar.baz:123"); // some hostname:port
>
> while(1) {
> int r = BIO_do_connect(_bio);
>
> ...
>
> Sleep(1); // ie, sleep for one *millisecond*
> }
What do we know about Sleep? MSDN says that "If dwMilliseconds is less
than the resolution of the system clock, the thread may sleep for less
than the specified length of time. If dwMilliseconds is greater than one
tick but less than two, the wait can be anywhere between one and two
ticks, and so on." Question what does it mean in case when
dwMilliseconds is *much* less than clock resolution? Does it mean that
it may sleep for approximately clock tick? Or does it mean that it will
use instrumented loop? What is clock resolution? To the last question,
it's variable and it's up to 15ms. Does it mean that Sleep(1) may take
up 15 ms or that it consumes 100% CPU in instrumented loop? Neither
sounds expected... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
Am 13.12.2010 08:44, schrieb Tomas Mraz: On Sun, 2010-12-12 at 11:54 +0100, Andy Polyakov via RT wrote: I'd argue that it's intentional. The original purpose for -out option appears to be to emit *certificate* itself, not information about it. Yes, this kind of means that I reckon that -text option should result in output to STDout, not to one appointed by -out. There also is inconsistent usage of STDout when treating -days parameter: error message should be printed on stderr, not STDout. If nobody screams for a week, http://cvs.openssl.org/chngview?cn=20156 will go down to 1.0.x. A. I'm afraid that the change of the target of the -text option output will break expectations of some scripts people in the wild use. Although it is slightly more logical with the change than before I'd prefer keeping it as is at least for 1.0.x. Of course the -days error output change is fine. I second this. My initial reason for the RT was exactly for catching the output with a script; sure its possible to catch it with IO redirection too, but in my case I run a VBScript on Windows which is not able to do IO redirection without launching cmd.exe 1st; doing so makes the script 10+ times slower for 140 certs due to the launch of the shell for 140 times; maybe on Linux this is not that dramatical, but forking a new shell is there time-intensive too. Perhaps a 2nd file output option for catching informational output would be more nice ... Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
On Sun, 2010-12-12 at 11:54 +0100, Andy Polyakov via RT wrote: > >> I've meanwhile checked apps/x509.c, and patching it to send output to > >> file is trivial (attached); but looking at the other output options > >> around these lines makes me a bit unsure if these options are intended > >> to go to STDOUT rather than to honor a file option? However if the later > >> then I'm asking me why? Almost all options print their output to STDOUT > >> and ignore a file option - except for the text option ... > > no comments on this? > > Is this behaviour now intended? Then lets close the RT with a comment > > stating this; > > or just an oversight, and can we then fix this (see my patches)? > > I'd argue that it's intentional. The original purpose for -out option > appears to be to emit *certificate* itself, not information about it. > Yes, this kind of means that I reckon that -text option should result in > output to STDout, not to one appointed by -out. There also is > inconsistent usage of STDout when treating -days parameter: error > message should be printed on stderr, not STDout. If nobody screams for > a week, http://cvs.openssl.org/chngview?cn=20156 will go down to 1.0.x. A. I'm afraid that the change of the target of the -text option output will break expectations of some scripts people in the wild use. Although it is slightly more logical with the change than before I'd prefer keeping it as is at least for 1.0.x. Of course the -days error output change is fine. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
