[openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since 20160521

Tue May 24 15:15:52 UTC 2016

In message <20160524142412.GA6384 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 08:24:12 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> On Tue, May 24, 2016 at 12:26:02PM +0200, Richard Levitte wrote:
doctor> > In message <20160524070954.GA17442 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 01:09:55 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
doctor> > 
doctor> > doctor> On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
doctor> > doctor> > In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
doctor> > doctor> > 
doctor> > doctor> > doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > when executing
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > during the test phase, it looks as if the test hangs.
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > Please look into this.
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> This issue now exists in 20160523 .
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> Please look into this showstopper.
doctor> > doctor> > 
doctor> > doctor> > Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
doctor> > doctor> > FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
doctor> > doctor> > (BSD-x86_64, which is what ./config gives me automagically, and no
doctor> > doctor> > extra options), please remind me of yours.
doctor> > doctor> >
doctor> > doctor> 
doctor> > doctor> All right,  what changed between 20160520 and 20160521 ?
doctor> > doctor> 
doctor> > doctor> Simple question.  That is the source of the showstopper.
doctor> > 
doctor> > I'm attaching the only change that I can think makes a difference.
doctor> > Try a 'patch -R -p1 < xopen_source.patch' and see if that changes
doctor> > anything.
doctor> > 
doctor> > I don't think we're going to back off from that change, so if you can
doctor> > help us figure out what goes wrong with it on your system and how to
doctor> > improve the change, that's be great.
doctor> > 
doctor> > Cheers,
doctor> > Richard
doctor> > 
doctor> > -- 
doctor> > Richard Levitte         levitte at openssl.org
doctor> > OpenSSL Project         http://www.openssl.org/~levitte/
doctor> 
doctor> > commit e10b54ca32280d9fec20085f404dcdcf2217c90e
doctor> > Author: Andy Polyakov <appro at openssl.org>
doctor> > Date:   Mon May 16 16:44:33 2016 +0200
doctor> > 
doctor> >     rand/randfile.c: remove _XOPEN_SOURCE definition.
doctor> >     
doctor> >     Defintions of macros similar to _XOPEN_SOURCE belong in command line
doctor> >     or in worst case prior first #include directive in source. As for
doctor> >     macros is was allegedly controlling. One can argue that we are
doctor> >     probably better off demanding S_IS* macros but there are systems
doctor> >     that just don't comply, hence this compromise solution...
doctor> >     
doctor> >     Reviewed-by: Rich Salz <rsalz at openssl.org>
doctor> >     (cherry picked from commit 2e6d7799ffc47604d06e0465afeb84b91aff8006)
doctor> > 
doctor> > diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c
doctor> > index 9537c56..76bdb9a 100644
doctor> > --- a/crypto/rand/randfile.c
doctor> > +++ b/crypto/rand/randfile.c
doctor> > @@ -56,11 +56,6 @@
doctor> >   * [including the GNU Public Licence.]
doctor> >   */
doctor> >  
doctor> > -/* We need to define this to get macros like S_IFBLK and S_IFCHR */
doctor> > -#if !defined(OPENSSL_SYS_VXWORKS)
doctor> > -# define _XOPEN_SOURCE 500
doctor> > -#endif
doctor> > -
doctor> >  #include <errno.h>
doctor> >  #include <stdio.h>
doctor> >  #include <stdlib.h>
doctor> > @@ -80,6 +75,29 @@
doctor> >  #ifndef OPENSSL_NO_POSIX_IO
doctor> >  # include <sys/stat.h>
doctor> >  # include <fcntl.h>
doctor> > +/*
doctor> > + * Following should not be needed, and we could have been stricter
doctor> > + * and demand S_IS*. But some systems just don't comply... Formally
doctor> > + * below macros are "anatomically incorrect", because normally they
doctor> > + * would look like ((m) & MASK == TYPE), but since MASK availability
doctor> > + * is as questionable, we settle for this poor-man fallback...
doctor> > + */
doctor> > +# if !defined(S_ISBLK)
doctor> > +#  if defined(_S_IFBLK)
doctor> > +#   define S_ISBLK(m) ((m) & _S_IFBLK)
doctor> > +#  elif defined(S_IFBLK)
doctor> > +#   define S_ISBLK(m) ((m) & S_IFBLK)
doctor> > +#  elif defined(_WIN32)
doctor> > +#   define S_ISBLK(m) 0 /* no concept of block devices on Windows */
doctor> > +#  endif
doctor> > +# endif
doctor> > +# if !defined(S_ISCHR)
doctor> > +#  if defined(_S_IFCHR)
doctor> > +#   define S_ISCHR(m) ((m) & _S_IFCHR)
doctor> > +#  elif defined(S_IFCHR)
doctor> > +#   define S_ISCHR(m) ((m) & S_IFCHR)
doctor> > +#  endif
doctor> > +# endif
doctor> >  #endif
doctor> >  
doctor> >  #ifdef _WIN32
doctor> > @@ -151,8 +169,8 @@ int RAND_load_file(const char *file, long bytes)
doctor> >  #endif
doctor> >      if (in == NULL)
doctor> >          goto err;
doctor> > -#if defined(S_IFBLK) && defined(S_IFCHR) && !defined(OPENSSL_NO_POSIX_IO)
doctor> > -    if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
doctor> > +#if defined(S_ISBLK) && defined(S_ISCHR) && !defined(OPENSSL_NO_POSIX_IO)
doctor> > +    if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
doctor> >          /*
doctor> >           * this file is a device. we don't want read an infinite number of
doctor> >           * bytes from a random device, nor do we want to use buffered I/O
doctor> 
doctor> The patch worked.  What is next?

So I understand correctly, it works when the patch is reversed (that's
what -R does), right?  Good, that gives us a point.  However, that
commit is there for a reason, so like I said, if you can help us
figure out what goes wrong on your system, everyone will be happier.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/