Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
On Tue, 2010-12-14 at 00:00 +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. 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? That would be still a change in the behavior that shouldn't in my opinon be committed to the stable branches, definitely not to the 1.0.0 branch. -- 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
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
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
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 #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'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. __ 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
Hi, Am 28.08.2010 00:19, schrieb Guenter via RT: 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)? 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
Hi, Am 28.08.2010 00:19, schrieb Guenter via RT: 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)? 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
Hi,
Am 20.08.2010 11:33, schrieb Guenter via RT:
while hacking on a script where I use the openssl commandline tool for
processing PEM certs I found that suprisingly the md5 fingerprint output
always goes to stdout instead of using the -out stream, f.e. when using:
openssl x509 -md5 -fingerprint -text -inform PEM -in tmpin.crt -out
tmpout.crt
the md5 fingerprint output goes to stdout while the whole rest of output
goes into tmpout.crt as expected ...
is this now intended behaviour, or just an oversight? If the latter I
would look into the sources for fixing it ...
tested versions:
OpenSSL 0.9.8o 01 Jun 2010
OpenSSL 1.0.0a 1 Jun 2010
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 ...
thanks, Gün.
--- x509.c.orig Fri Jun 26 13:34:21 2009
+++ x509.c Fri Aug 27 23:32:32 2010
@@ -898,11 +898,11 @@
BIO_printf(bio_err,out of memory\n);
goto end;
}
- BIO_printf(STDout,%s Fingerprint=,
+ BIO_printf(out,%s Fingerprint=,
OBJ_nid2sn(EVP_MD_type(digest)));
for (j=0; j(int)n; j++)
{
- BIO_printf(STDout,%02X%c,md[j],
+ BIO_printf(out,%02X%c,md[j],
(j+1 == (int)n)
?'\n':':');
}
--- x509.c.orig Tue Jan 12 19:27:09 2010
+++ x509.c Fri Aug 27 23:38:23 2010
@@ -932,11 +932,11 @@
BIO_printf(bio_err,out of memory\n);
goto end;
}
- BIO_printf(STDout,%s Fingerprint=,
+ BIO_printf(out,%s Fingerprint=,
OBJ_nid2sn(EVP_MD_type(fdig)));
for (j=0; j(int)n; j++)
{
- BIO_printf(STDout,%02X%c,md[j],
+ BIO_printf(out,%02X%c,md[j],
(j+1 == (int)n)
?'\n':':');
}
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
Hi,
Am 20.08.2010 11:33, schrieb Guenter via RT:
while hacking on a script where I use the openssl commandline tool for
processing PEM certs I found that suprisingly the md5 fingerprint output
always goes to stdout instead of using the -out stream, f.e. when using:
openssl x509 -md5 -fingerprint -text -inform PEM -in tmpin.crt -out
tmpout.crt
the md5 fingerprint output goes to stdout while the whole rest of output
goes into tmpout.crt as expected ...
is this now intended behaviour, or just an oversight? If the latter I
would look into the sources for fixing it ...
tested versions:
OpenSSL 0.9.8o 01 Jun 2010
OpenSSL 1.0.0a 1 Jun 2010
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 ...
thanks, Gün.
--- x509.c.orig Fri Jun 26 13:34:21 2009
+++ x509.c Fri Aug 27 23:32:32 2010
@@ -898,11 +898,11 @@
BIO_printf(bio_err,out of memory\n);
goto end;
}
- BIO_printf(STDout,%s Fingerprint=,
+ BIO_printf(out,%s Fingerprint=,
OBJ_nid2sn(EVP_MD_type(digest)));
for (j=0; j(int)n; j++)
{
- BIO_printf(STDout,%02X%c,md[j],
+ BIO_printf(out,%02X%c,md[j],
(j+1 == (int)n)
?'\n':':');
}
--- x509.c.orig Tue Jan 12 19:27:09 2010
+++ x509.c Fri Aug 27 23:38:23 2010
@@ -932,11 +932,11 @@
BIO_printf(bio_err,out of memory\n);
goto end;
}
- BIO_printf(STDout,%s Fingerprint=,
+ BIO_printf(out,%s Fingerprint=,
OBJ_nid2sn(EVP_MD_type(fdig)));
for (j=0; j(int)n; j++)
{
- BIO_printf(STDout,%02X%c,md[j],
+ BIO_printf(out,%02X%c,md[j],
(j+1 == (int)n)
?'\n':':');
}
[openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
Hi, while hacking on a script where I use the openssl commandline tool for processing PEM certs I found that suprisingly the md5 fingerprint output always goes to stdout instead of using the -out stream, f.e. when using: openssl x509 -md5 -fingerprint -text -inform PEM -in tmpin.crt -out tmpout.crt the md5 fingerprint output goes to stdout while the whole rest of output goes into tmpout.crt as expected ... is this now intended behaviour, or just an oversight? If the latter I would look into the sources for fixing it ... tested versions: OpenSSL 0.9.8o 01 Jun 2010 OpenSSL 1.0.0a 1 Jun 2010 regards, Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
