On Mon, Jul 24, 2017 at 1:20 PM, Benoît Canet <ben...@scylladb.com> wrote:
> > Hi Nadav, > > I want to define a course of action with this last patch. > > The source of the problem is the mismatch between host openssl and > external openssl. > > It force us to upgrade LuaSec in the first place. Also if we rely always > on the host openssl > it will create issues because different host release will have different > openssl version. > > Hence I think it's better to simply make the OSv build totally idependant > from the host openssl > version by _always_ relying on external's openssl. > external's openssl is an antique snapshot that Avi took two years ago from Fedora 21. The first question is, even if this still works, how long will this it still work? Eventually, this antique library will not work with Gcc 9 or whatever, and then we'll be forced to upgrade. Morever, the problem that prompted your opinion now is an example where some software (luasec) cannot be compiled with the new library, so a two-year-old library is beneficial But, in practice, wouldn't the opposite case be more likely? I.e., new software that users will want to run on OSv may need a recent version of a library, and not some 5-year-old version (which we'll have in 3 more years). Not to mention, that nobody wants to run an old version of a library, even if it still runs - especially security-related library which may (?) have received security updates over the last two years. This brings another issue, which a user recently noticed (I think it was on the mailing list): What if OSv's pre-packaged "cli" package which, by using the "openssl" module, gets one version of OpenSSL, but a different user application gets a different version of openssl - e.g., the application runs "ldd" and copies the newest libraries from the host? In such a case, the two applications cannot be run together on the same VM (the two libraries will have conflicting symbol names. this will sometimes work, but sometimes not). > > This way no LuaSec upgrade required and it will compile and run easilly on > all host version. > The luasec upgrade is a bit ugly, but why is it a big problem? > > What do you think of this ? > First of all, whatever we do, we must NOT have the current situation where luasec is compiled using the host's OpenSSL header files, but then a different version of the OpenSSL library is installed in the image. We can fix it in one of two mutually-exclusive ways, both fairly simple and I think both will work well 1. Change the "openssl" module to find and upload the host's OpenSSL libraries, not those from external/. 2. Change the build in modules/lua to take the OpenSSL headers from external, not the host. I personally prefer option 1 but I'm also fine with option #2 which you seem to prefer. I think that as our openssl library continues to age and not get updated, we'll be forced to switch to option 1, but it doesn't mean we can't stay with option 1 for now. If you want to see my long-term vision, see https://github.com/cloudius-systems/osv/issues/743 (about eliminating external/ altogether). https://github.com/cloudius-systems/osv/issues/821 (about running applications compiled with different libraries than the OSv kernel) Again, it doesn't mean we need to do this now. I'll leave it up to you to decide. > > Best regards > > Benoît > > 2017-07-24 12:11 GMT+02:00 Benoît Canet <ben...@scylladb.com>: > >> >> >> 2017-07-24 8:02 GMT+02:00 Nadav Har'El <n...@scylladb.com>: >> >>> >>> On Sat, Jul 22, 2017 at 1:51 PM, Benoît Canet < >>> benoit.canet.cont...@gmail.com> wrote: >>> >>>> The LuaRock repository is not up to date. >>>> >>> >>> Hi, >>> >>> I am far from a Lua or LuaRock expert, but a quick look in >>> https://luarocks.org/modules/brunoos/luasec >>> shows me that they *do* have version 0.6-1, which apparently is the same >>> version you downloaded. >>> Maybe you just had to update the "0.5" number? Did you try that? >>> >> >> If you look at the release data of 0.6-1 you will see it one year old. >> >> Only the github master is up to date. >> >> >>> >>> Use the github repository. >>>> >>>> Signed-of-by: Benoît Canet <ben...@scylladb.com> >>>> --- >>>> modules/lua/Makefile | 8 ++++++-- >>>> 1 file changed, 6 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/modules/lua/Makefile b/modules/lua/Makefile >>>> index 64ea4170..c4c80144 100644 >>>> --- a/modules/lua/Makefile >>>> +++ b/modules/lua/Makefile >>>> @@ -121,9 +121,13 @@ LuaSec: $(CDIR)/ssl.lua >>>> $(CDIR)/ssl.lua: $(LUA_ROCKS_BIN) >>>> # Workaround because LuaRocks ignores /lib64 >>>> ifneq ("$(wildcard /usr/lib64/libssl.so*)", "") >>>> - out/bin/luarocks install LuaSec 0.5 OPENSSL_LIBDIR=/usr/lib64 >>>> + rm -rf luasec >>>> + git clone https://github.com/brunoos/luasec.git >>>> + cd luasec && ../out/bin/luarocks make luasec-0.6-1.rockspec >>>> OPENSSL_LIBDIR=/usr/lib64 >>>> else >>>> - out/bin/luarocks install LuaSec 0.5 >>>> + rm -rf luasec >>>> + git clone https://github.com/brunoos/luasec.git >>>> + cd luasec && ../out/bin/luarocks make luasec-0.6-1.rockspec >>>> endif >>>> >>>> ## >>>> -- >>>> 2.13.3 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "OSv Development" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to osv-dev+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
