> No, if it's file permissions you get EPERM. EACCESS is weirder things like
> opening a directory fopen(), see
> https://msdn.microsoft.com/en-us/library/5814770t.aspx
Ah, thanks. Okay, we can fix that :)
___
openssl-users mailing list
To unsubscrib
On 23 January 2015 at 17:22, Salz, Rich wrote:
> Thanks for the links. I understand it's a real issue. The concern is
> will windows return EACCESS for cases when there really is access denied?
>
>
No, if it's file permissions you get EPERM. EACCESS is weirder things like
opening a directory f
> Or are we talking about something other than OPENSSL_config() exiting
> when the config file cannot be read?
It's a variant of this. File not existing is silently ignored. Windows will
return EACCESS if the drive isn't ready, and that is not silently ignored. The
concern is if windows will
On Fri, Jan 23, 2015 at 05:22:22PM +, Salz, Rich wrote:
> Thanks for the links. I understand it's a real issue. The
> concern is will windows return EACCESS for cases when there really
> is access denied?
I think we're asking the wrong questions here. Whatever the error,
the decision to co
Thanks for the links. I understand it's a real issue. The concern is will
windows return EACCESS for cases when there really is access denied?
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
The ones I can find are:
http://rt.openssl.org/Ticket/Display.html?id=3263
http://rt.openssl.org/Ticket/Display.html?id=2644
http://rt.openssl.org/Ticket/Display.html?id=3488
Two which seem to be suggesting the same fix. I'm also aware of bugs in
the Qt bug tracker, my work's internal bug tracker
On Fri, Jan 23, 2015 at 04:06:47PM +, Richard Moore wrote:
> > This is an interesting one because the problem is clear - the openssl
> > utility exits if it gets any error other than "file doesn't exist" trying
> > to open its configuration file - but the solution is not.
>
> The real problem
> There's been a patch that's been ignored in the bug tracker for ages to at
> least minimise this problem on Windows by treating EACCESS the same as EPERM
> to handle the case of removable disks.
Do you know the ticket number? I vaguely recall it but can't find immediately
find it. I know wh
On 23 January 2015 at 15:04, Michael Wojcik
wrote:
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> > Of Koehne Kai
> > Sent: Friday, January 23, 2015 04:03
> > To: openssl-users@openssl.org
> > Subject: Re: [openssl-users] missing defa
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Koehne Kai
> Sent: Friday, January 23, 2015 04:03
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes
> failure on AIX, warning on al
/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 defaul
auses
> 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 de
> 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 a
> 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/l
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich
> Sent: Thursday, January 22, 2015 13:22
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes
> failure on AIX, war
+-+-+-+-+-+-+-+-+-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Michael Wojcik
Sent: Thursday, January 22, 2015 4:16 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
(Apologies
users] missing default /usr/local/ssl/openssl.cnf causes
failure on AIX, warning on all others
Thank you Rich.
The sentence you couldn't understand is my bad, s/b:
"In fact, on some, even non-AIX hosts, permissions would suggest that the
permission error should be returned."
D
Salz, Rich
Sent: Thursday, January 22, 2015 1:22 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
> None of the hosts we've visited have /usr/local/ssl, not to mention the
> actual default fil
> None of the hosts we've visited have /usr/local/ssl, not to mention the
> actual default file. In fact, on some, even non-AIX hosts, permissions would
> suggest that the permission should be returned.
Not sure what that last sentence means.
> Should this be happening? Is AIX simply less for
Hi. I'm running openssl CLI 1.0.1j (for example) on a bunch of different unix
platforms. On all of them, the default missing /usr/local/ssl/openssl.cnf
causes a warning, but the CLI continues to initialize and opens the command
line. We've known about this behavior since first incorporating
20 matches
Mail list logo
