RE: [RFC PATCH] s_client/s_server: support unix domain sockets

Looks neat. I'd rather have ipv6 first, but +1 for this -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project

RE: reworking docs: mdoc or pod format?

Please, not mdoc. It doesn't offer any particular feature it's just different. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: open ssl rsa key generation improvement idea

I've converted all the divisibility rules for all the primes less than 25 into binary. All the sums can be calculated at once. Nice work! /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: Which platforms will be supported in the future on which platforms will be removed?

The core team should come up with a list and announce the decision. SOON. Be firm. Say something like in xxx months, support for these platforms will be dropped and we will start to remove that code. Encourage folks interested in supporting those platforms to maintain a fork. I don't care

RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension.

RE: AW: Which platforms will be supported in the future on which platforms will be removed?

especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. With no disrespect intended to either man, I have to say that this is an analogy that never would have occurred to me in a million years. /r$ -- Principal Security Engineer

RE: patch for make depend, chacha

Is there somebody working on it to get Chacha/Poly cipher suites production ready? It's expected that the way the ciphers are used will change as it goes through the IETF TLS group. Therefore, Google has not been encouraging folks to pick up and use these patches other than an on your own

RE: [openssl.org #3331] [PATCH] respect LDFLAGS during build

Perhaps Configure should have a -f nnn flag, that lets folks add their own local table without having to patch the script -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz -Original Message- From: owner-openssl-...@openssl.org

RE: [openssl.org #3331] [PATCH] respect LDFLAGS during build

I think this misses the point, one can already just pass a table entry on the command-line as a colon-separated target name. Yes, you're right, I was mis-using the thread. But putting a config spec on the command line is, shall we say, awkward. And adding the flag would help with code

RE: Two phases compilation

Is it possible to adapt the Configure tool in order to - first execute the preprocessing stage (macro expand and source code generation) like gcc -E - execute some custom source code manipulation (free/malloc enhance, array bound checks, etc) of my own One way to do this would be to use

Locking inefficiency

A colleague here noticed that the pthreads-based locking loses the distinction between read and write locks. We've collected mutex contention data, and found that the CRYPTO_ERR lock, used while getting error info, is one of the biggest offenders. It turns out that pthreads_locking_callback

RE: [openssl.org #3378] heartbeat_test: Using internal APIs

And I want to reduce the number of exposed APIs. Except that as we (hopefully) move to making struct's opaque, then we'll need add lots of accessors. I assume you know that, but just want to make sure folks realize it. In the medium term, I'd like to see things like this BN foo; break at

RE: Another security bug, this time in MAC verification...

http://opensslrampage.org/post/88383880093 The rampager is wrong; see Adam Langley's comments on twitter; https://twitter.com/agl__/status/476420434095648768 /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: Locking inefficiency

What kinds of operations are protected by read locks? Looking at almost any of the global data structures, such as error tables, OID tables, and so on. Often, RW locks aren't a win because maintaining just the read locks (without any writers) introduces contention at the hardware level, and

RE: Locking inefficiency

Ø Preload them all at startup with a global lock held, delete them at shutdown with a global lock held. If all the other access is 'read' the structures don't need a lock between times. Ø Might be something to consider putting on the to do list. I can understand things being done like that

RE: [openssl.org #3403] Null dereference and memory leak reports for openssl-1.0.1h from Facebook's Infer static analyzer

Hey, that's very neat. The REPORT part looks automated; are the REMARKS your commentary or does the tool do that too? /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: [openssl.org #3373] [BUG] [WIN] DLL copyright message not synchronize for quite a while

For what it's worth, the policy at IBM (where I used to work, and where they know quite a few things about software intellectual property), is that you only update the copyright on an individual file *when you modify it.* /r$ -- Principal Security Engineer Akamai Technologies,

splitting clientHello into fragments?

Does openssl handle a clientHello (or any handshake message) that splits across records? I can't quite tell ... :) -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz

RE: splitting clientHello into fragments?

Ø Mostly yes (I know because I made the changes to allow this a long time ago). That’s what it seemed to me (because read_message will fill a buffer as needed), but the intern here was pretty sure of himself. Now, maybe not so sure ☺ -- Principal Security Engineer Akamai Technologies,

RE: [openssl.org #1531] typo: 'rouines' should read 'routines' in all Copyright sections

It is perhaps appropriate that my comment had a typo. We can't change it. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: [openssl.org #44] OpenSSL_add_all_algorithms problems in Win32

From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Erik Forsberg What would be the best equivalent yo pthread_once on Windows ? I was once looking for one, and back then, years ago, I didnt like the choices. Perhaps

RE: SSLv2 SSLv3

We need to support embedded clients that only speak SSL2 :( -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project

RE: SSLv2 SSLv3

I have no problem disabling it by default and think that should have been done awhile ago, actually. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz

RE: Website Contribution

The website is written using a tool called wml. It would be great if someone wanted to make it more modern and properly use things like CSS. Then it might make sense to put it into a github repository. Want to volunteer? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:

RE: Website Contribution

(Sorry if this is a duplicate message.) Right now the website is written in WML (http://thewml.org) so it's not clear how useful it would be to put the pages up on github. I think it would be great if they were converted to HTML+CSS. Then it would make more sense. /r$ -- Principal

RE: [openssl.org #3107] Resolved: Bug Report with Patch 1.0.1c/e (Typo in apps/ocsp.c line 1412)

I fixed that one on master :) commit 327f3c040ed7451e6f7fb461e13044884607273c Author: Rich Salz rs...@akamai.com Date: Sun Jun 29 11:40:05 2014 -0400 Fix typo in message (RT 3107) -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

RE: [openssl.org #1979] Add uClibc support

Platform in the h/w and s/w sense, not just hardware. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Philip A.

RE: [openssl.org #1979] Add uClibc support

Feel free to re-open :) -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Kurt Roeckx via RT Sent: Monday, June 30,

Do *you* know about Mingw and/or DJGPP?

There are several tickets about mingw and djgpp builds breaking, or building software that crashes, and so on. If you can help me understand the current state of things with those toolchains, please drop me a line. Thanks. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:

RE: Very old release, unsupported platform

I thought until now, that as long there are developers who are willing to develop for a certain platform and there is some community interest in using that - the platform will be supported as odd might it be in the Windows and Linux dominated World. With the releases now in github, one

RE: Very old release, unsupported platform

Hope you are right...but not sure.. Neither are we. That is why the current roadmap says that we're working on it. It's important to realize that supporting a platform incurs a cost, and we need to have some way of making the appropriate trade-offs. Clearly, we don't want to end up where

RE: Makedepend bug?

So now gcc/clang is required to build OpenSSL? No, nobody's said that. The phrase was perhaps And if openssl ships with a default set of dependencies, which it does, there's no issue about which compiler you use at all. Once we fix the make depend requirement. -- Principal Security

RE: Makedepend bug?

I was wondering why 'make depend' output was saved in the Makefiles. Because way back when (think like early X and xmkmf) that's the way things were done. So I guess adding the .d files to the repository and using include statements in the Makefiles is a reasonable possibility? (That's the

RE: Makedepend bug?

Really? Its much more efficient to update the .d files when you compile the (changed) source - which more-or-less implies one per source file. Not necessarily. One process scanning all the sources, and one file open/parse in make is often more efficient. I read this on the internet

RE: OpenSSL roadmap

However, I feel that the developer group is a bit closed to outsiders. More communication and transparency is coming, as we have a bigger and more invigorated developer team. It will take time. But not everything will always be discussed in public mailing lists right away, parciularly

RE: OpenSSL roadmap

-openssl- d...@openssl.org] On Behalf Of Loganaden Velvindron Sent: Wednesday, July 02, 2014 2:24 PM To: openssl-dev@openssl.org Subject: Re: OpenSSL roadmap On Wed, Jul 2, 2014 at 9:48 PM, Salz, Rich rs...@akamai.com wrote: However, I feel that the developer group is a bit closed to outsiders

RE: [openssl.org #3277] OpenSSL s_client doc missing option

Looks to me like you've only fixed this (and many others) in master - surely should also go to 1.0.2 at least (and probably older branches, too)? Okay, tell me which branches. Also, we generally rebase rather than merge... I don't know the difference. But okay, if that's the practice, I'll

RE: OpenSSL roadmap

No, I don't mean to imply that you are one of the bad guys. It's just that we have only one real way of knowing who the good guys are, and that is being part of the development team. Yes, that can be very inconvenient. Trust me, I know, it took more than 10 years for the team to open up and

RE: [openssl.org #3277] OpenSSL s_client doc missing option

Of Ben Laurie Sent: Thursday, July 03, 2014 7:15 AM To: OpenSSL development Cc: Jeffrey Walton Subject: Re: [openssl.org #3277] OpenSSL s_client doc missing option On 3 July 2014 12:04, Salz, Rich rs...@akamai.com wrote: Looks to me like you've only fixed this (and many others) in master

RE: [openssl.org #2563] Please close this bug; changes have been applied.

Closed, thanks. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz

RE: OpenSSL roadmap

release processes at various distributions. (Given that Microsoft has weekly patch Tuesdays, if even slow moving *Microsoft* can turn around a security update in a week, what's your excuse? :-) They have a regular release train, but it doesn't mean that everything gets fixed in one week.

RE: [openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures

Why not just have bn_expand_internal call memset? ; git diff bn_lib.c diff --git a/crypto/bn/bn_lib.c b/crypto/bn/bn_lib.c index b1e224b..86d1d37 100644 --- a/crypto/bn/bn_lib.c +++ b/crypto/bn/bn_lib.c @@ -324,6 +324,9 @@ static BN_ULONG *bn_expand_internal(const BIGNUM *b, int words)

argv/Argv hacks in openssl.c

There's a bunch of hacks in apps/openssl.c to work around some old VMS releases; the coment is dated 2011-03-22. I am going to delete it. Speak up now if you can justify keeping it. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me;

RE: BIO_get_accept_socket weirdness

Those who forget history are doomed to re-implement it, wrongly. SO_REUSEADDR was implemented in 4.2BSD so that a server could restart without waiting for the various FIN_WAIT timeouts to happen. :) /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:

RE: [openssl.org #3436] Platform strategy

...but can not let the less popular platforms decline, therefore I decided to set up Jenkins builds on polarhome.com's 30+ rare operating systems and Wow, that is really great. Thank you! As Ben said, we haven't decided on *anything* yet. /r$ -- Principal Security Engineer Akamai

RE: argv/Argv hacks in openssl.c

Steve, Thanks for the explanation. I'll refactor it a bit, and keep it. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project

RE: [openssl.org #3451] patch for x509.c

The Globus syntax is strange. :) We should support the ISO date/time standard, and use that throughout and not invent yet another syntax, or yet another flag. It's fairly simple to parse, and handles timezones, relative times, date/time mixing, and so on. The XML XSD spec, for example, has a

RE: [openssl.org #3451] patch for x509.c

But then it has to be supported for, like ever. :) If the right thing to do is the ISO format, and I strongly believe it is, then we should just work toward that and not add variants to solve a short-term need that will require long-term care and confusion. /r$ -- Principal

RE: argv/Argv hacks in openssl.c

Would it work to *always* copy argv on VMS? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org

RE: argv/Argv hacks in openssl.c

The amount of time it took me to read the comment and figure out what is going on, and your time to write email explaining it, and Ted's time to chime in about the necessity of doing all this far outweighs the new code which is #ifdef VMS'd Because now main() looks really simple and

RE: [openssl.org #3451] patch for x509.c

do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. No, we'll never drop support for -days. But whether the code is atoi() or atof() is a big difference and might cause important silent failures for new scripts

RE: [openssl.org #3451] patch for x509.c

date '+%Y%m%d%H%M%SZ' -d '1 month 12 hours' Wow. Old code never dies; that's my get_date code from August 1990 :) /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz

openssl apps; flags, parsing dates, etc.

I agree with that as well. I did not look at the actual code in openssl so I did not know that the fractional argument with the current version does not error out. I have a branch that adds pretty comprehensive option-checking to all the openssl commands: ; ./openssl x509 --CA

RE: openssl apps; flags, parsing dates, etc.

You've declared -days to take only positive numbers, it should allow negative numbers. Pushed, thanks. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL

RE: openssl apps; flags, parsing dates, etc.

keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE) while the valid choices seem to be PEM or DER, not PEM or ENGINE: No, it depends on the command. Some, for example, expect keys to be stored in the ENGINE (presumably an HSM). The docs are often outdated. But pem/der is

RE: openssl apps; flags, parsing dates, etc.

The right thing to do is change opt_format to be generic, and specify exactly which types of formats are supported. Done and pushed. Some of the bit-settings are probably more loose than I'd like, but it works. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

Yes, you’re totally right about the root cause being poor abstractions. We will probably remove all mention of MSDOS, which should be another way to fix the problem, right? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter:

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

You are preaching to the choir. Look at the rsalz-monolith branch in akamai/openssl on github. If you have a patch to go into that, I'll take it right away.

RE: [openssl.org #3464] openssl s_client waiting for input on Windows

We’re going to address the larger issues, in time. For now: does removing MSDOS fix the problem? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz

RE: [openssl.org #3467] FW: Critical vulnerabilities found (#8083-432678597-2590)

Where did you get your SSL package? Did it come with the OS? If so, then ask them for an update. If not, then where did you get it? Contact them. If you built it internally, you'll have to learn or buy expertise. -- Principal Security Engineer, Akamai Technologies, Cambridge, MA IM:

GCC performance hack

If you're doing multi-threaded builds with GCC, the following performance hack can help a great deal. #ifdef _GNU_SOURCE int gnu_builtin_sync(int *pointer, int amount, int type, const char *file, int line) { int ret; if (amount 0) ret = __sync_add_and_fetch(pointer, amount); else

If you use kerberos/ssl

Can you take a look at http://rt.openssl.org/Ticket/Display.html?id=549 And let us know what you think? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz

RE: Question in regards to early warning about new openssl versions

Thanks for your kind words. We do post a notice that we're putting out a security update. Not sure how you missed it... -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

session cache and multiple threads

What's the programming model for using session cache with a multi-threaded server? When a client connections, a refcount on the object is incremented. But then fields can be changed (such as ecpointformat). Does it make more sense for session to deep-copy the session from the cache? --

RE: session cache and multiple threads

We're using the standard internal session (maintained per SSL_CTX object); not tickets. We're seeing that the sessions are shared, a refcount is maintained, but that SSL does modified fields within a session while it's being used. Most notably an address sanitizer build found the EC point

RE: Netware support?

please dont do that! I maintained it in the past (and try to do in future as my time permits), and currently it still builds (except for asm support were ich Okay. Thanks for your efforts. The NETWARE port is really messy, with about 130 #ifdef flags in 70 files. It would be great if we

RE: Netware support?

Thanks for the info! -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List

RE: Single-Makefile Build Experiment report

Just a comment. the OpenSSL build already depends on Perl and Perl already has a Make of it's own . Ooh, that could be interesting. What's the perl make thing called? A web search for perl make was too voluminous... /r$ -- Principal Security Engineer Akamai Technologies,

RE: [openssl.org #2483] X509 conversions

Problem solved by me three years ago. Still using old platform. Works fine. Glad it works! Anything worth sharing or was it very specific? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #832] ocsp and dsa key+socket option SO_REUSEADDR for responder

Ugh, you're right. Re-opening this. BIO sockets are a tangle that will take some time to figure out. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

Platform query

Does anyone want to speak up for the requirement that we continue to support BEOS (apparently B/1 and R5?), OS/2, or pre-Windows MSDOS? Unless there is strong interest and commitment, we will drop these after 1.0.2 /r$ -- Principal Security Engineer Akamai Technologies,

RE: Platform query

Minor clarification is appropriate. MSDOS is supported in single stance, namely DJGPP, which is 32-bit environment. Good point. So the idea is that MSDOS gets turned into DJGPP. BEOS and OS/2 are removed in HEAD (i.e., after 1.0.2), and Microsoft means WINDOWS of various flavors. If this is

RE: Platform query

I'm not sure what WINDOWS means. And I'm not sure MSFT knows either :) Less flippantly, the goal is that OPENSSL_SYS_WINDOWS means any Windows platform, and then there are subtypes within that. We'll figure it out as we go along. It's gonna take a while to clean up the #ifdef world without

RE: Platform query

Thanks for the feedback! There are 70 files that have OS2 in them, for a total of 130 instances. That's rather a lot for a platform that hasn't had an update in five years. This is my personal opinion, as a team member. We will release 1.0.2 this year. At that time we will announce end of

RE: AW: Platform query

So I would not understand that we go in a hurry to remove WCE compatibility I do not think we are in a hurry to do that. Your patch looks nice. I am CC'ing rt, so that this thread becomes an issue and we'll see the link to your mail. -- Principal Security Engineer Akamai Technologies,

RE: Platform query

Did I miss something, or did you happen to count the includes of e_os2.h which is not OS/2 specific at all? Or both? No, I made the stupid mistake. The current version of eComStation, 2.1, was released only a year after version 2.0, in May 2011. We were not aware of eComStation. Thanks.

RE: [openssl.org #3497] Move dclean actions to clean

Just generated a pull request for this; let me know if it's what you actually had in mind: https://github.com/openssl/openssl/pull/161 I already had the fix in-hand :) See attached. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

RE: nameConstraints bypass bug

It'd be good to fix this. Opening an RT (email to r...@openssl.org) is the simplest way. Thanks! -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #3505] rewrite c_rehash in C

Find a C version (which I have written) of the utility at: http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c That's pretty cool. We'd need to modify it to not use the XXXat functions or fnmatch, but definitely something we should consider for a future release. --

RE: [openssl.org #3503] BUG: make dclean deletes the test/ directory, which results in duplicate symbols on subsequent make's

I changed the bug title, since the test directory isn't ever removed. But yes, something strange is going on. :��IϮ��r�m (Z+�7�zZ)���1���x��hW^��^��%����jם.+-1�ځ��j:+v���h�

RE: [openssl.org #3505] rewrite c_rehash in C

Don't rush. It'll be a while until (or if) we switch over. Neat job tho. Perhaps it should be merged into the openssl command? (see https://github.com/akamai/openssl/tree/rsalz-monolith) -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #3505] rewrite c_rehash in C

BTW, as you work on this, also take a look at RT items 2272 and 2973 :) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated

RE: official repository vs forks, and fixes

Think of this as pre-release software. The changes are too large to disrupt the 1.0.2 release, which is already in beta. We haven’t yet figured out how to make early-access to branches available, so for now I just did it via Akamai. At some point, I’d expect that branch to “move” over to

RE: official repository vs forks, and fixes

FWIW, most of us picking up 1.0.2 will be in it for the long haul, I wouldn't expect many to shift from 1.0.2 again to 1.0.3 over the course of a year or several.  It might be worth rethinking the 1.0.2 release plan to pick I understand the concern. But we have already declared that 1.0.2

RE: official repository vs forks, and fixes

Would it be an idea to create branches in the official repo for (certain classes of) bugfixes, which can be merged onto the respective branches at set times ? For instance one for documentation fixes ? You could Yes. But we (the dev team) haven't figured out all of the details of our

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

i don't think that's really true. else, why is autoconf friends relying on a shell and not perl ? those see way more distribution than openssl. Last I looked, autoconf doesn't use anything that really wasn't in Version 7 Bourne shell. In my comment, I deliberately used the term posix

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

These all first appeared in ksh: functions, local, return, $((math)) But to my mind, the question is moot, since post-1.0.2 we'll almost definitely have c_rehash builtin to the openssl command. that would also work :) It will also be much much much faster, since it doesn't have to call

RE: [openssl.org #2990] Bug Report:openssl timezone issue

Not according to the PKIX RFC 5280 CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity

RE: [openssl.org #2665] s_client support for starttls ldap

What about usoing stunnel?

RE: [openssl.org #3512] SSL_MODE_ENABLE_PARTIAL_WRITE does not work in DTLS

You can't use partial writes. The size of your UDP packet depends on the MTU supported by everyone along the path. (BTW, that's what heartbeat was created.) I suggest you get your program working properly for your definition of what properly means, without DTLS. Then add DTLS. And have you

RE: [openssl.org #2665] s_client support for starttls ldap

My point is that since stunnel has a different goal of wrapping almost any protocol, that might be a better place for it, rather than going down the slippery slope of putting a binary hack into s_client which wouldn't let you actually USE the protocol.

RE: openssl 1.0.1i ignores ciphers in cipherlist

If Frank doesn't want SSLv2 then he needs to disable it in the SSL_CTX first, no? The mechanism to say what ciphers you want is orthogonal to the mechanism to say what protcols you want. That's unfortunate and a source of confusion, but is unlikely to change any time soon. -- Principal

RE: apps/ts.c patch - engine support

Of no less importance is to emphasise that it adds additional keyform parameter to functions defined in ts.c and utilized by -reply function, that will *break* compatibility with any previously existing code. How does it break? We don't care about source-level compatibility within the apps

RE: [openssl.org #3494] Possible sign bit bug in openssl 1.0.1i handling of 128-bit serial numbers

RFC 5280 requires that serial numbers MUST be positive, negative serial numbers do not conform with RFC (see 4.1.2.2). Yes, thanks for the clarification. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz

RE: [openssl.org #3470] [BUG] DTLS abort

Partial writes do not work over UDP; by design. As to whether or not you can use a packet as big as 16K, in depends on the path MTU -- what's the maximum transmission size between you and the destination, along the communication path. You'll have to make your packets smaller then that. This

RE: apps/ts.c patch - engine support

You are right - it should not break anything as the patch only affects the ts app. I put this on my dev branch for post-1.0.2 release: https://github.com/akamai/openssl/tree/rsalz-monolith -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter:

RE: [openssl.org #3203] Normalize PFS key exchange labels

I think there's interest for 1.0.1 and beyond. But I thought we already had a similar alias mechanism?

The no-stdio and NO_FP_API options

These configuration options do not build. I started to try and fix them, but after fixing the first few problems, things got really sticky. We hear that OpenSSL on embedded devices is important. Is anyone using this, willing to share their fixes, and help maintain it? If not, it will be

RE: [openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

Anyone? This mail was sent one minute after your previous mail. A little patience perhaps? :) :��IϮ��r�m (Z+�7�zZ)���1���x��hW^��^��%����jם.+-1�ځ��j:+v���h�

RE: [openssl.org #2560] missing NULL pointer check in ocsp_req_find_signer

It is from real world application. In some case the X509_find_by_subject (called from ocsp_req_find_signer) returned NULL, and the whole application halted. Ah, I misunderstood the ticket. Add if (!signer) return 0; after the call to X509_find_by_subject. I'll submit that shortly. Thanks!

<    1   2   3   4   5   6   7   8   9   10   >