Thanks again. I had returned to the conf_def.c file and saw the logic that essentially summarizes your detailed sequence.
The workaround you suggested of specifying OPENSSL_CONF is a variation of what I had given our QA team (the original reporter of the issue on AIX), and this indeed circumvented the issue. Thanks to all for all the interest in and traffic on this question. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, Enterprise Storage Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -----Original Message----- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, January 22, 2015 5:34 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Salz, Rich > Sent: Thursday, January 22, 2015 16:37 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] missing default > /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all > others > > > I can't. The behavior of fopen is defined by ISO 9899 and the Single > > UNIX Specfication, which AIX has adhered to for well over a decade. > > I meant no disrespect to big blue :) I worked there for a > half-decade, and also with them on standards for a lot longer... > > > int main(void) {fopen("/usr/local/ssl/openssl.cnf", "rb"); > > perror("fopen"); > > And what happens if some of the directories on the path don't exist? Depends on which of the following happens first: - open(2) encounters a missing directory: ENOENT. - open(2) encounters a non-traversable directory: EACCES. (I wrote "EPERM" in an earlier note, but I don't think that's even a real errno value name. Duh.) - open(2) gets all the way to the file but doesn't have sufficient permission: ENOENT. - Some other I/O error occurs (broken NFS mount, etc): some other errno value, or possibly a hang, eg in the case of some NFS mounts. SUSv3 lets fopen set EACCES, EINTR (if open is "slow" and gets interrupted by a signal), EISDIR, ELOOP, EMFILE, ENAMETOOLONG, ENFILE, ENOENT, ENOSPC (should only happen for file creation), ENOTDIR (if you have a non-directory as a non-terminal path component), ENXIO (trying to open a special node in an unsupported way), EOVERFLOW, EROFS, EINVAL, ENOMEM, and ETXTBSY. A quick look at apps/openssl.c suggests that it'll abort if it gets anything other than CONF_R_NO_SUCH_FILE from ERR_GET_REASON(ERR_peek_last_error()) after NCONF_load fails. That doesn't clarify things much, though I'd suggest that it might be worth suppressing this behavior via an option. If the user knows there's no configuration file, the following should work (under suitable shells): OPENSSL_CONF=/dev/null openssl ... Just let openssl open /dev/null as its config file. It'll get EOF immediately (as if openssl.cnf existed and was empty) and should trundle along happily. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
