Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
In message <20170301221703.tfwpu%stef...@sdaoden.eu> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmesosaid: steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere steffen> (i think that would well be worth in entry in INSTALL), and steffen> i really would have sworn that it worked in the past. I was actually surprised to find this undocumented. I could have sworn I'd done so, but apparently, I only did in a commit message: commit fad599f7f147ee71e5581211fb654c2c8c491cd8 Author: Richard Levitte Date: Wed Oct 12 17:05:35 2016 +0200 Remove automatic RPATH - add user rpath support Make Configure recognise -rpath and -R to support user added rpaths for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the Unix Makefile, which the users can use as follows: ./config [options] -Wl,-rpath,\$(LIBRPATH) Reviewed-by: Rich Salz I'll go add a note now... Sorry Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
Hello. Richard Levittewrote: |In message <20170301221703.tfwpu%stef...@sdaoden.eu> on Wed, 01 Mar \ |2017 23:17:03 +0100, Steffen Nurpmeso said: | |steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere |steffen> (i think that would well be worth in entry in INSTALL), and |steffen> i really would have sworn that it worked in the past. | |I was actually surprised to find this undocumented. I could have |sworn I'd done so, but apparently, I only did in a commit message: | |commit fad599f7f147ee71e5581211fb654c2c8c491cd8 |Author: Richard Levitte |Date: Wed Oct 12 17:05:35 2016 +0200 | |Remove automatic RPATH - add user rpath support | |Make Configure recognise -rpath and -R to support user added rpaths |for OSF1 and Solaris. For convenience, add a variable LIBRPATH \ |in the |Unix Makefile, which the users can use as follows: | |./config [options] -Wl,-rpath,\$(LIBRPATH) | |Reviewed-by: Rich Salz | |I'll go add a note now... Thank you very much. Have a good time. --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)
Hello. I am sorry, but i have no github account. Maybe it is possible to have some @bug address which creates issues automatically? I see this on ? openssl version OpenSSL 1.0.2k 26 Jan 2017 ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version OpenSSL 1.1.0 25 Aug 2016 ? openssl verify -verbose -CAfile SOME-FILE SOME-CERT SOME-FILE: OK ? openssl verify -verbose -CApath SOME-FILE SOME-CERT error 20 at 0 depth lookup:unable to get local issuer certificate I look into apps/apps.c, but i cannot tell why this does not bail out when the directory is found to be a file. Ciao, --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)
> I am sorry, but i have no github account. Maybe it is possible to have some > @bug address which creates issues automatically? Nah, too much spam will happen :( Posting to openssl-dev is fine. > ? openssl version > OpenSSL 1.0.2k 26 Jan 2017 > ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version > OpenSSL 1.1.0 25 Aug 2016 So this happens on both 1.0.2 and 1.1.0? Does the following patch fix it for 1.1.0? ; git diff diff --git a/apps/opt.c b/apps/opt.c index 499a0b5..4547da1 100644 --- a/apps/opt.c +++ b/apps/opt.c @@ -661,7 +661,8 @@ int opt_next(void) return -1; case '<': /* Input file. */ -if (strcmp(arg, "-") == 0 || app_access(arg, R_OK) >= 0) +if (strcmp(arg, "-") == 0 +|| (!app_isdir(arg) && app_access(arg, R_OK) >= 0)) break; BIO_printf(bio_err, "%s: Cannot open input file %s, %s\n", -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
Oh, hello again, now i finally have updated (without "make tests?") and it seems i now have to fill in $LD_LIBRARY_PATH to get running: $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl ... libssl.so.1.1 => not found libcrypto.so.1.1 => not found This is new behaviour, until now the installation was always self-contained when configured via ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared I think this should at least be noted in CHANGES or so. Ciao, --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
> This is new behaviour, until now the installation was always self-contained > when configured via > > ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared Did you install the libraries in a standard place? > I think this should at least be noted in CHANGES or so. I don't think so. I think the libs weren't installed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)
Sorry for the late reply, this really is a slow machine (and i cleanup again completely anything once it is installed, _and_ the tests compile a long time even if not run).. "Salz, Rich"wrote: |> I am sorry, but i have no github account. Maybe it is possible to \ |> have some |> @bug address which creates issues automatically? | |Nah, too much spam will happen :( Posting to openssl-dev is fine. Ok, good. |> ? openssl version |> OpenSSL 1.0.2k 26 Jan 2017 |> ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version |> OpenSSL 1.1.0 25 Aug 2016 | |So this happens on both 1.0.2 and 1.1.0? | |Does the following patch fix it for 1.1.0? No, not that i know. But this -- thanks -- lead me to the following, which is the KISS that you want? Ciao! diff --git a/apps/apps.c b/apps/apps.c index 216bc797d..3afbbaef2 100644 --- a/apps/apps.c +++ b/apps/apps.c @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char *CApath, int noCAfile, i if (lookup == NULL) goto end; if (CApath) { -if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { +if (!app_isdir(CApath) || +!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { BIO_printf(bio_err, "Error loading directory %s\n", CApath); goto end; } --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
"Salz, Rich"wrote: |> This is new behaviour, until now the installation was always self-contain\ |> ed |> when configured via |> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared | |Did you install the libraries in a standard place? | |> I think this should at least be noted in CHANGES or so. | |I don't think so. I think the libs weren't installed. Yes, also in my opinion the old behaviour was much, much better. --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)
> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmesowrote: > > No, not that i know. But this -- thanks -- lead me to the > following, which is the KISS that you want? > Ciao! > > diff --git a/apps/apps.c b/apps/apps.c > index 216bc797d..3afbbaef2 100644 > --- a/apps/apps.c > +++ b/apps/apps.c > @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char > *CApath, int noCAfile, i > if (lookup == NULL) > goto end; > if (CApath) { > -if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { > +if (!app_isdir(CApath) || > +!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) > { > BIO_printf(bio_err, "Error loading directory %s\n", CApath); > goto end; > } We may need to be careful. With OpenSSL <= 1.0.2, one way to suppress the built-in default CApath was to set "-CApath" to a non-existent directory. Users may have scripts relying on this behaviour. Now with 1.1.0 on some platforms OpenSSL already rejects non-existent directories, and we also provide a "-no-CAfile" option, but this change will extend the change to what is likely our most popular platform. So it will at least deserve a comment in the "NEWS"/"CHANGES" files. -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
In message <20170301165032.8jhwg%stef...@sdaoden.eu> on Wed, 01 Mar 2017 17:50:32 +0100, Steffen Nurpmesosaid: steffen> "Salz, Rich" wrote: steffen> |> This is new behaviour, until now the installation was always self-contain\ steffen> |> ed steffen> |> when configured via steffen> |> steffen> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared steffen> | steffen> |Did you install the libraries in a standard place? steffen> | steffen> |> I think this should at least be noted in CHANGES or so. steffen> | steffen> |I don't think so. I think the libs weren't installed. steffen> steffen> Yes, also in my opinion the old behaviour was much, much better. I very much disagree. We have had bug reports as well as cases of our own because a new compilation that you want to test picked up previously installed versions of the libraries (usually an older version). The reason for doing so previously was because we installed the libraries in non-standard locations by default. Since OpenSSL 1.1.0 and on is installing in standard locations by default, we don't have to use these mechanisms for a default build. With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they are different) or whatever isn't really our decision to make, but the decision of the packager or the individual user, so we've handed the decision to you. For the GNU toolchain, I'd recommend configuring with something like this (from memory, I might be fuzzy in the details): -Wl,--enable-new-dtags -rpath '$(LIBRPATH)' LIBRPATH is a convenience Makefile variable that gets correctly set to the configured shared library installation directory, meant for exactly this sort of situation. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
Good evening. Viktor Dukhovniwrote: |> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso wrote: |> |> $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl |> ... |> libssl.so.1.1 => not found |> libcrypto.so.1.1 => not found |> |> This is new behaviour, until now the installation was always |> self-contained when configured via |> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared | |I sure hope that "$()" was in fact "${}", the former only |works in Makefiles, and means something quite different |in POSIX shells. No it is a snippet from a makefile, of course. |You need an "RPATH" setting in the linker flags for the shared |libraries to be found in in $PREFIX/lib. Perhaps: If my tortured ears finally hear, then. You are saying this never was standard behaviour? Oh!?! Well, then i am sorry, it could indeed be that i never ran the binaries in there, but only use this one for v1.1.0 link testing, and then, there, the linker path is adjusted automatically (by my configuration script). It may be a crappy comment, but if i ldd(1) ~/usr/opt/.ressl/bin/openssl then this just works, and the make rule is almost identical: libressl: cd libressl.tar_bomb_git &&\ if [ -f NULL ]; then git checkout `cat NULL`; fi &&\ ./configure --prefix=$(MYPREFIX) &&\ make &&\ make check &&\ $(SUDO) make install;\ { git clean -fxd; git reset --hard HEAD;\ git checkout arena-manager-null; } >/dev/null But thanks, i did not know that i can pass additional flags to ./config! Thanks to Matt Caswell i think, if i recall correctly, i now know about "make install_sw && make install_ssldirs", and maybe in a not too distant future i get it right! --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)
Hello again, Viktor Dukhovniwrote: |> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso wrote: |> No, not that i know. But this -- thanks -- lead me to the |> following, which is the KISS that you want? ... |> diff --git a/apps/apps.c b/apps/apps.c |> index 216bc797d..3afbbaef2 100644 |> --- a/apps/apps.c |> +++ b/apps/apps.c |> @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, \ |> const char *CApath, int noCAfile, i |> if (lookup == NULL) |> goto end; |> if (CApath) { |> -if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM))\ |> { |> +if (!app_isdir(CApath) || |> +!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_P\ |> EM)) { |> BIO_printf(bio_err, "Error loading directory %s\n", \ |> CApath); |> goto end; |>} | |We may need to be careful. With OpenSSL <= 1.0.2, one way to suppress the |built-in default CApath was to set "-CApath" to a non-existent directory. |Users may have scripts relying on this behaviour. Now with 1.1.0 on some |platforms OpenSSL already rejects non-existent directories, and we also |provide a "-no-CAfile" option, but this change will extend the change to |what is likely our most popular platform. | |So it will at least deserve a comment in the "NEWS"/"CHANGES" files. I understand that this is a "lingering" configuration, which is inspected on the fly as a last (or second last, if there is SSL_CTX_set_default_verify_paths(3). In fact i don't know, the documentation is horrific! E.g., just today i have implemented some *{smime,ssl}-ca-flags*, mostly to be able to provide X509_V_FLAG_PARTIAL_CHAIN, but you know you can't find just any X509_STORE_set_flags(_not_ 3) at all, it is, again, _horrific_. I for one, as someone unrelated, now that you have so many sponsors, i really wonder why you don't spend a little bit of money to some crypto nerd student(s) who really need(s) it in order to improve it. Really, and honestly.) resort. But for an application that does a one-shot check i would at least expect a message that leads into the right direction, at least with -verbose. I for one _of course_ looked for X509_LOOKUP_add_dir() first, but i gave up after the second indirection. If you would ask me, i surely would add a X509_FILETYPE_CHECK_OR_ERROR or similar flag to get the synchronous checks. But who am i. --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations
Hello, Richard Levittewrote: |In message <20170301165032.8jhwg%stef...@sdaoden.eu> on Wed, 01 Mar \ |2017 17:50:32 +0100, Steffen Nurpmeso said: | |steffen> "Salz, Rich" wrote: |steffen> |> This is new behaviour, until now the installation was \ |always self-contain\ |steffen> |> ed |steffen> |> when configured via |steffen> |> |steffen> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared |steffen> | |steffen> |Did you install the libraries in a standard place? |steffen> | |steffen> |> I think this should at least be noted in CHANGES or so. |steffen> | |steffen> |I don't think so. I think the libs weren't installed. |steffen> |steffen> Yes, also in my opinion the old behaviour was much, much better. | |I very much disagree. We have had bug reports as well as cases of our |own because a new compilation that you want to test picked up |previously installed versions of the libraries (usually an older |version). The reason for doing so previously was because we installed |the libraries in non-standard locations by default. That unpuzzles me a little bit -- this behaviour did exist. Good. |Since OpenSSL 1.1.0 and on is installing in standard locations by |default, we don't have to use these mechanisms for a default build. |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they |are different) or whatever isn't really our decision to make, but the |decision of the packager or the individual user, so we've handed the |decision to you. | |For the GNU toolchain, I'd recommend configuring with something like |this (from memory, I might be fuzzy in the details): | |-Wl,--enable-new-dtags -rpath '$(LIBRPATH)' | |LIBRPATH is a convenience Makefile variable that gets correctly set to |the configured shared library installation directory, meant for |exactly this sort of situation. The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes, when i reported the dynamic link test failures a while back i have seen that and also added support for this new linker flag to my software. It is i think off-topic that now new environment variables come up that makes me wonder why the LD_PRELOAD .. DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared deprecated. LIBRPATH i did not know about yet, thanks for the pointer, i will read about it. Yes, i mean, i just didn't know this, it is not mentioned anywhere (i think that would well be worth in entry in INSTALL), and i really would have sworn that it worked in the past. Thank you, and Ciao! --steffen -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev