[openssl-dev] [openssl.org #3638] [PATCH] Fix build with -DOPENSSL_NO_SRTP
Hey guys, 1.0.2-stable and master are currently broken when building with -DOPENSSL_NO_SRTP. Attached patches fix that. Best regards, Piotr Sikora OpenSSL_1_0_2__Fix-build-with-DOPENSSL_NO_SRTP.patch Description: Binary data OpenSSL_master__Fix-build-with-DOPENSSL_NO_SRTP.patch Description: Binary data ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl.org #3597] [PATCH] Advance to the next state variant when reusing messages.
Advance to the next state variant when reusing messages. Previously, state variant was not advanced, which resulted in state being stuck in the st1 variant (usually "_A"). This broke certificate callback retry logic when accepting connections that were using SSLv2 ClientHello (hence reusing the message), because their state never advanced to SSL3_ST_SR_CLNT_HELLO_C variant required for the retry code path. Reported by Yichun Zhang (agentzh). Signed-off-by: Piotr Sikora --- ssl/s3_both.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ssl/s3_both.c b/ssl/s3_both.c index beef06f..10921a2 100644 --- a/ssl/s3_both.c +++ b/ssl/s3_both.c @@ -358,6 +358,7 @@ long ssl3_get_message(SSL *s, int st1, int stn, int mt, goto f_err; } *ok=1; + s->state=stn; s->init_msg = s->init_buf->data + 4; s->init_num = (int)s->s3->tmp.message_size; return s->init_num; -- 2.1.2 OpenSSL__Advance-to-the-next-state-variant-when-reusing-messa.patch Description: Binary data
[PATCH] Advance to the next state variant when reusing messages
(for some reason it was never received by rt@, so resending here) Advance to the next state variant when reusing messages. Previously, state variant was not advanced, which resulted in state being stuck in the st1 variant (usually "_A"). This broke certificate callback retry logic when accepting connections that were using SSLv2 ClientHello (hence reusing the message), because their state never advanced to SSL3_ST_SR_CLNT_HELLO_C variant required for the retry code path. Reported by Yichun Zhang (agentzh). Signed-off-by: Piotr Sikora --- ssl/s3_both.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ssl/s3_both.c b/ssl/s3_both.c index beef06f..10921a2 100644 --- a/ssl/s3_both.c +++ b/ssl/s3_both.c @@ -358,6 +358,7 @@ long ssl3_get_message(SSL *s, int st1, int stn, int mt, long max, int *ok) goto f_err; } *ok=1; + s->state=stn; s->init_msg = s->init_buf->data + 4; s->init_num = (int)s->s3->tmp.message_size; return s->init_num; -- 2.1.2 OpenSSL__Advance-to-the-next-state-variant-when-reusing-messa.patch Description: Binary data
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Hey, >> How many of those sites are served by CDN's, for example? > > I don't know, if you have a semi-robust way to detect that I'm willing to > implement it. > > Though, the scan was more of a ballpark estimate than a truly representative > result. Whois the IP? That should work for majority of the CDN. For Amazon, you can distinguish S3 from CloudFront by looking for at the HTTP headers: - X-Amz-Cf-Id, - Via: ... .cloudfront.net (CloudFront), - X-Cache: ... from cloudfront. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3191] [BUG] OpenSSL-1.0.2 segfaulting on sha1_block_data_order asm
Hey Andy, > Some kind of deja vu here. I remember I was looking at this and drew > some conclusion... I think it was addressed and commit > b77b58a398c8b9b4113f3fb6b48e162a3b8d4527 actually mentions this ticket. > Can you confirm? Yes, it's been fixed by this commit. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL has exploit mitigation countermeasures to make sure its exploitable
Hey,
> His patch was not against -current.
>
> http://elandsys.com/~logan/openssl_fix.diff
>
> Please find it here:
>
> diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
> index b9e45c7..61b017f 100644
> --- a/ssl/s3_pkt.c
> +++ b/ssl/s3_pkt.c
> @@ -1334,8 +1334,6 @@ start:
> {
> s->rstate=SSL_ST_READ_HEADER;
> rr->off=0;
> - if (s->mode & SSL_MODE_RELEASE_BUFFERS)
> - ssl3_release_read_buffer(s);
> }
> }
> return(n);
>
>
> I tested by building OpenSSL from github.
>
> I would be interested in improving the diff further, so feedback welcomed :-)
A better version of this patch was submitted a while ago:
https://rt.openssl.org/Ticket/Display.html?id=3265 (guest:guest)
Best regards,
Piotr Sikora
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] Disable RC4 for TLS v1.1+ (server-side).
Hello Patrick,
> While no longer using RC4 might be a good idea, I'm not certain that OpenSSL
> should /force/ it as long as the cipher is still a valid choice.
Agreed, that's why I wrote it should be an SSL{,_CTX}_set_options()
option, but there are no unused values to do that.
> This seems like a job for SSL_CTX_set_cipher_list
> (http://www.openssl.org/docs/ssl/SSL_CTX_set_cipher_list.html). A good server
> would be calling this anyway since (at least according to the docs at
> http://www.openssl.org/docs/apps/ciphers.html) the default cipher list is
> ALL:!aNULL:!eNULL. I could even conceive of turning of RC4 by default, but
> you should probably let people turn it back on if they have it in their
> cipher list.
The main point of this patch is to disable RC4 only for connections
using TLS v1.1+ and keep it around for connections using TLS v1.0 to
protect against the BEAST attack. Currently, there is no way to
specify different cipher suites for different protocols, so yo cannot
achieve that with SSL{,_CTX}_set_cipher_list.
Best regards,
Piotr Sikora
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[PATCH] Disable RC4 for TLS v1.1+ (server-side).
(this was originally sent to rt@, but it never made it through)
Hello,
considering that RC4 is pretty much broken by now, I don't think there
is a good reason for using it in TLS v1.1+.
Attached patch stops servers from negotiating RC4-based cipher suites
on connections using TLS v1.1+. This is mostly RFC and not something
ready to be committed, because users should (or maybe not?) be able to
tweak this via SSL{,_CTX}_set_options(). However, it seems that all
the option values are already taken and I'm not in the position to
decide if this is more important than any of the existing options.
Best regards,
Piotr Sikora
openssl_1_0_1__disable_rc4.patch
Description: Binary data
openssl_1_0_2__disable_rc4.patch
Description: Binary data
[openssl.org #3191] [BUG] OpenSSL-1.0.2 segfaulting on sha1_block_data_order asm
Hello, after moving from OpenSSL-1.0.1e to OpenSSL-1.0.2-5ff68e8 our nginx instances started crashing (very rarely, but still...) with backtraces pointing to either "sha1_block_data_order_avx" or "sha1_block_data_order_ssse3", depending on machine. This is happening when nginx is acting as a client, as well when it's acting as a server. The OS is Linux 3.9.x and we are using relatively recent OpenSSL-1.0.2 checkout (commit: 5ff68e8f6dac3b0d8997b8bc379f9111c2bab74f). Let me know if you need any more details. Best regards, Piotr Sikora --- sha1_block_data_order_avx --- (gdb) bt #0 sha1_block_data_order_avx () at sha1-x86_64.s:3338 #1 0xca62c1d6ca62c1d6 in ?? () #2 0xca62c1d6ca62c1d6 in ?? () #3 0xca62c1d6ca62c1d6 in ?? () #4 0xca62c1d6ca62c1d6 in ?? () #5 0xca62c1d6ca62c1d6 in ?? () #6 0xca62c1d6ca62c1d6 in ?? () #7 0xca62c1d6ca62c1d6 in ?? () #8 0xca62c1d6ca62c1d6 in ?? () #9 0x04533188 in ?? () #10 0x0020 in ?? () #11 0x0eabc170 in ?? () #12 0x0059903b in sha1_update (ctx=Unhandled dwarf expression opcode 0xf3) at e_aes_cbc_hmac_sha1.c:162 #13 aesni_cbc_hmac_sha1_cipher (ctx=Unhandled dwarf expression opcode 0xf3) at e_aes_cbc_hmac_sha1.c:223 #14 0x005010a9 in tls1_enc (s=0x10338110, send=1) at t1_enc.c:855 #15 0x0052ab87 in do_ssl3_write (s=0x10338110, type=21, buf=0xd1c9e88 "\002F", len=2, create_empty_fragment=0) at s3_pkt.c:826 #16 0x0052c540 in ssl3_dispatch_alert (s=0x10338110) at s3_pkt.c:1500 #17 0x0052b54c in ssl3_send_alert (s=0x10338110, type=22, buf=0x549af40 "\024", len=4, peek=0) at s3_pkt.c:1488 #18 ssl3_get_record (s=0x10338110, type=22, buf=0x549af40 "\024", len=4, peek=0) at s3_pkt.c:536 #19 ssl3_read_bytes (s=0x10338110, type=22, buf=0x549af40 "\024", len=4, peek=0) at s3_pkt.c:1010 #20 0x0052cea0 in ssl3_get_message (s=0x10338110, st1=Unhandled dwarf expression opcode 0xf3) at s3_both.c:370 #21 0x0052c8bb in ssl3_get_finished (s=0x10338110, a=Unhandled dwarf expression opcode 0xf3) at s3_both.c:233 #22 0x0051f27a in ssl3_accept (s=0x10338110) at s3_srvr.c:725 #23 0x00468a5b in ngx_ssl_handshake (c=0x7f457adca6d0) at src/event/ngx_event_openssl.c:1114 (gdb) info reg rax0x753851ae 1966625198 rbx0x21be16be 566105790 rcx0x1bc8df34 466149172 rdx0x6f8554d1 1871008977 rsi0xfe447b08 4265900808 rdi0xec908aab 3968895659 rbp0xee05b36e 0xee05b36e rsp0x763dd800 0x763dd800 r8 0xeabc324246137636 r9 0x15364fcb 355880907 r100x453314b72560971 r110x543300 5518080 r120x453318872561032 r130x0 0 r140x453318872561032 r150x45331cb72561099 rip0x5416c0 0x5416c0 eflags 0x202[ IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 fctrl 0x37f895 fstat 0x0 0 ftag 0x 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop0x0 0 mxcsr 0x1f80 [ IM DM ZM OM UM PM ] --- sha1_block_data_order_ssse3 --- (gdb) bt #0 sha1_block_data_order_ssse3 () at sha1-x86_64.s:2226 #1 0xca62c1d6ca62c1d6 in ?? () #2 0xca62c1d6ca62c1d6 in ?? () #3 0xca62c1d6ca62c1d6 in ?? () #4 0xca62c1d6ca62c1d6 in ?? () #5 0xca62c1d6ca62c1d6 in ?? () #6 0xca62c1d6ca62c1d6 in ?? () #7 0xca62c1d6ca62c1d6 in ?? () #8 0xca62c1d6ca62c1d6 in ?? () #9 0x01d17528 in ?? () #10 0x0020 in ?? () #11 0x01eb35c0 in ?? () #12 0x005c627b in sha1_update (ctx=Unhandled dwarf expression opcode 0xf3) at e_aes_cbc_hmac_sha1.c:162 #13 aesni_cbc_hmac_sha1_cipher (ctx=Unhandled dwarf expression opcode 0xf3) at e_aes_cbc_hmac_sha1.c:223 #14 0x0052e2e9 in tls1_enc (s=0x1f01200, send=1) at t1_enc.c:855 #15 0x00557dc7 in do_ssl3_write (s=0x1f01200, type=21, buf=0x1e55208 "\002F", len=2, create_empty_fragment=0) at s3_pkt.c:826 #16 0x00559780 in ssl3_dispatch_alert (s=0x1f01200) at s3_pkt.c:1500 #17 0x0055878c in ssl3_send_alert (s=0x1f01200, type=23, buf=0x2204b50 "...", len=8192, peek=0) at s3_pkt.c:1488 #18 ssl3_get_record (s=0x1f01200, type=23, buf=0x2204b50 "...", len=8192, peek=0) at s3_pkt.c:536 #19 ssl3_read_bytes (s=0x1f01200, type=23, buf=0x2204b50 "...", len=8192, peek=0) at s3_pkt.c:1010 #20 0x005550dc in ssl3_read_internal (s=0x1f01200, buf=0x2204b50, len=8192) at s3_lib.c:4426 #21 ssl3_read (s=0x1f01200, buf=0x2204b50, len=8192) at s3_lib.c:4446 #22 0x0046d204
Re: [openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hey guys, could you please look into it? Right now, this is show-stopper for adding ALPN support for nginx. Attached patches against current master and OpenSSL_1_0_2-stable branch. Best regards, Piotr Sikora Fix-compilation-with-no-nextprotoneg-master.patch Description: Binary data Fix-compilation-with-no-nextprotoneg-OpenSSL_1_0_2-stable.patch Description: Binary data
Re: ECDHE problem with 1.0.2-dev
Hey Steve, > It picks the highest preference curve supported by both sides, which is > usually the strongest curve but it doesn't have to be. Oh, cool! Thanks for clarifying that, I somehow missed the new functions to set the curves list before. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE problem with 1.0.2-dev
Hey, > I think it's a bug in OpenSSL 1.0.2. It shouldn't break anything that works in > previous versions, at least not without a very good reason. > > I'll look into it. I already reported / patched this a while ago (with no response): https://rt.openssl.org/Ticket/Display.html?id=3103 > It's the preferred way as it just does the right thing. It always choses the strongest curve supported by both sides, which isn't always preferred (IMHO). Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hey Steve, >> While it cannot be enabled via ./config options, > > Why not? The standard way to include such options is via config or Configure > and some platforms (e.g. Windows) require this. Actually, it turns out that I was wrong, so please ignore that part. For the reference: What I meant is that currently (i.e. git master, nothing to do with the patch) OPENSSL_NO_NEXTPROTONEG cannot be enabled via ./config options and I had to pass it via CFLAGS, but that turned out to be just a user error... I didn't know that "no-XXX" is automatically translated to OPENSSL_NO_XXX and I was trying to disable NPN with "no-npn" (as described in CHANGES), which obviously didn't do much good... "no-nextprotoneg" works fine, though :) Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hey Steve, >> While it cannot be enabled via ./config options, > > Why not? The standard way to include such options is via config or Configure > and some platforms (e.g. Windows) require this. Actually, it turns out that I was wrong, so please ignore that part. For the reference: What I meant is that currently (i.e. git master, nothing to do with the patch) OPENSSL_NO_NEXTPROTONEG cannot be enabled via ./config options and I had to pass it via CFLAGS, but that turned out to be just a user error... I didn't know that "no-XXX" is automatically translated to OPENSSL_NO_XXX and I was trying to disable NPN with "no-npn" (as described in CHANGES), which obviously didn't do much good... "no-nextprotoneg" works fine, though :) Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and the APLN Patch
Hey Mark, ALPN support is already in the mainline: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f017a8f9db3a79f3a3406cf8d493ccd346db691 Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.
Hello, attached patch fixes build with OPENSSL_NO_NEXTPROTONEG. While it cannot be enabled via ./config options, compiling OpenSSL with this define turned out to be extremely useful while adding ALPN support to 3rd-party software (i.e. to make sure that nothing in the added ALPN support relies on NPN code). Also, I wanted to make sure that SSL_select_next_proto() is not part of NPN and that it will be available going forward. Best regards, Piotr Sikora Fix-build-with-OPENSSL_NO_NEXTPROTONEG.patch Description: Binary data
[openssl.org #3104] [BUG] Build broken on OSX (RSAZ assembly)
Hello, it looks that the RSAZ assembly broke build on OSX. clang: /opt/local/bin/perl5 asm/rsaz-x86_64.pl macosx > rsaz-x86_64.s clang -c -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DDSO_DLFCN -DHAVE_DLFCN_H -g -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPEN SSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o rsaz-x86_64.o rsaz-x86_64. s rsaz-x86_64.s:934:1: error: invalid symbol redefinition _rsaz_512_mul: ^ make[4]: *** [rsaz-x86_64.o] Error 1 gcc: /opt/local/bin/perl5 asm/rsaz-x86_64.pl macosx > rsaz-x86_64.s gcc -c -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DDSO_DLFCN -DHAVE_DLFCN_H -g -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o rsaz-x86_64.o rsaz-x86_64.s rsaz-x86_64.s:394:Unknown pseudo-op: .global rsaz-x86_64.s:394:Rest of line ignored. 1st junk character valued 95 (_). rsaz-x86_64.s:451:Unknown pseudo-op: .global rsaz-x86_64.s:451:Rest of line ignored. 1st junk character valued 95 (_). rsaz-x86_64.s:654:Unknown pseudo-op: .global rsaz-x86_64.s:654:Rest of line ignored. 1st junk character valued 95 (_). rsaz-x86_64.s:934:FATAL:Symbol _rsaz_512_mul already defined. make[4]: *** [rsaz-x86_64.o] Error 1 $ git show | head -1 commit 006784378db1a8957fcf587ee1deaa5cf2ae76c7 $ clang -v clang version 3.3 (tags/RELEASE_33/final) $ gcc -v gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) $ uname -mrs Darwin 12.4.0 x86_64 $ sw_vers ProductName:Mac OS X ProductVersion: 10.8.4 BuildVersion: 12E55 Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3103] [PATCH] Set TLS EC curve_id from EC group alone.
Hello,
attached patch fixes the issue with dropped support for EC cipher
suites in software that uses SSL_OP_SINGLE_ECDH_USE after upgrading to
OpenSSL-1.0.2+.
As far as I can tell, the public key isn't necessary to set TLS EC
curve_id and removing this requirement is safe.
Best regards,
Piotr Sikora
Set TLS EC curve_id from EC group alone.
Strict EC parameter checking code runs before ephemeral EC key
is generated and existing code didn't account for that.
This resulted in dropped support for EC cipher suites in software
that uses SSL_OP_SINGLE_ECDH_USE, i.e.:
SSL_CTX_set_options(ctx, SSL_OP_SINGLE_ECDH_USE);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
The solution is to use only EC group and don't require EC key
to be already generated.
Signed-off-by: Piotr Sikora
---
ssl/t1_lib.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index ee376de..e24627f 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -578,14 +578,12 @@ static int tls1_set_ec_id(unsigned char
*curve_id, unsigned char *comp_id,
{
int is_prime, id;
const EC_GROUP *grp;
- const EC_POINT *pt;
const EC_METHOD *meth;
if (!ec)
return 0;
/* Determine if it is a prime field */
grp = EC_KEY_get0_group(ec);
-pt = EC_KEY_get0_public_key(ec);
- if (!grp || !pt)
+ if (!grp)
return 0;
meth = EC_GROUP_method_of(grp);
if (!meth)
Set-TLS-EC-curve_id-from-EC-group-alone.patch
Description: Binary data
Re: [Patch] ALPN Implementation for OpenSSL
Hey, > Yes, supporting both at runtime would be best. But having a compile-time > option now, and defaulting to NPN should keep this from being a blocking > issue with the patch, correct? It would also make it kind of useless, at least from my non-authoritative point of view. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
Hey Jeff, > The idea is to have the choice as a ./config option. The default will stay as > NPN, as to not disrupt anyone. I don't have this in the patch yet. Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
Hi, > We really want to work with you to get this patch into OpenSSL to help > developers of HTTP/2.0 draft implementations. We welcome your assistance to > review this patch. What really makes this patch unusable (at least for us) is this snippet: +#if !defined(OPENSSL_NO_NEXTPROTONEG) && !defined(OPENSSL_NO_ALPN) +#error "Cannot define both NPN and ALPN" +#endif We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN. IMHO, the correct solution would be to always prefer and offer ALPN, unless client announced only NPN support in Client Hello. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3046] bug report, openssl 1.0.1e sha1 hash generation
Hey, > When executed in a user account, or on one of the SHA1 generating web > pages on the net, it returns: > > 8cb2237d0679ca88db6464eac60da96345513964 > > When executed from the root account it returns: > > 10298ad22a68325ec5b2a69f209cac87135a5884 root shell's built-in echo doesn't support "-n" parameter: $ echo -n "12345" | openssl dgst -sha1 -hex (stdin)= 8cb2237d0679ca88db6464eac60da96345513964 $ echo "-n 12345" | openssl dgst -sha1 -hex (stdin)= 10298ad22a68325ec5b2a69f209cac87135a5884 Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
