LuaRocks query: LuaSec compiler warnings...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LuaRocks query: LuaSec compiler warnings...

sur-behoffski
G'day,

I'm not authorised to use a more direct path, so I'm trying the general lua-l
list to raise an issue regarding compiler warnings in the rock luasec:

I get a slew of warnings when installing luasec along the lines of:

> src/options.c:41:43: warning: ‘%.35s’ directive writing up to 35 bytes into a region of size 25 [-Wformat-overflow=]
>          sprintf(msg, "unsupported option `%.35s'", name);
>                                            ^~~~~
> In file included from /usr/include/stdio.h:862:0,
>                  from /usr/include/lua5.1/lauxlib.h:13,
>                  from src/options.c:7:
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 22 and 57 bytes into a destination of size 45
>    return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        __bos (__s), __fmt, __va_arg_pack ());
>        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't know how potentially damaging these warnings are; I merely not that newer
C compilers (here, gcc-7.4 under Linux Mint 19.1):

         gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0

gcc has, over the course of the last few releases (6.x up to the current 9.x)
become better at code flow analysis, and, as a benefit, become more picky at
identifying potential C coding mistakes, such as buffer overflow.  (Misleading
indentation, of the kind that caused the Apple "goto fail;" bug, is another
one.)

I'm reporting this diagnostic to this list, when I'm a bit of a "babe in arms"
regarding bug reporting and tracking, and so:

1. If there is suitable project site, with an issue tracker, please "TELL ME
WHERE TO GO"!.

2. In the absence of Item 1, could someone please address these compiler
warnings?  I'm striving to work in a world where I can wind up the compiler
warnings to "-Wall -Wextra -Wpedantic" and still have zero warnings.  This
is inspired, in part, from my experience in working in a company that was
striving (and succeeded) to produce an extremely-reliable product (the test
team had tools to insert *every* possible error return into *every* actual
system call, and these were all part of the regression test rig); a second
reason is that I desire to have the extended Lua ecosystem that I use,
including but not limited to LuaRocks, to be a +zero-warnings" system.

I'm also inspired partially by Gerard Holzmann's "Mars Code" approach:

         https://www.usenix.org/conference/hotdep12/workshop-program/presentation/Holzmann

in which his team managed to produce several million lines of code -- far
too many to be reviewed manually -- and was successful in producing the
software portion of a hardware/software/remote system that achieved a very
complex goal.

Coding standards, static and dynamic review tools, and continuous
integration featured in his approach.

My hope is to be a "devil's advocate" at times when I see code that falls
below extremely high standards -- and standards that are being lifted in an
incremental fashion as compiler technology improves.  I do not claim to be
a saint myself -- and so would only point out cases where fixed are close
to trivial.

So, feedback on this message, my experience with LuaSec, and any other
issue raised by this message is welcome.  I ultimately hope that the
extended Lua community benefits from my actions; this is not something
that I always achieve.

cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

Reply | Threaded
Open this post in threaded view
|

Re: LuaRocks query: LuaSec compiler warnings...

Daurnimator
On Wed, 16 Oct 2019 at 05:42, sur-behoffski <[hidden email]> wrote:
> 1. If there is suitable project site, with an issue tracker, please "TELL ME
> WHERE TO GO"!.

https://github.com/brunoos/luasec/issues

Reply | Threaded
Open this post in threaded view
|

Re: LuaRocks query: LuaSec compiler warnings...

sur-behoffski
In reply to this post by sur-behoffski
Daurnimator wrote:
 >> 1. If there is suitable project site, with an issue tracker, please "TELL ME
 >> WHERE TO GO"!.
 >
 > https://github.com/brunoos/luasec/issues
 >

Thanks for that... Real World issues, plus VM/Distro/other distractions,
plus "OS-supplied-LuaRocks versus self-installed-LuaRocks" issues, all
conspired against me.

Just in case others are interested, the "show" command lists the
specified rock's home page:

         $ luarocks show luasec

         LuaSec 0.8.1-1 - A binding for OpenSSL library to provide TLS/SSL communication over LuaSocket.

         This version delegates to LuaSocket the TCP connection establishment between
         the client and server. Then LuaSec uses this connection to start a secure
         TLS/SSL session.

         License:          MIT
         Homepage:         https://github.com/brunoos/luasec/wiki
         Installed in:     /usr/local

         [...]

Thanks to Daurnimator for putting me straight.

cheers,

s-b etc.

Reply | Threaded
Open this post in threaded view
|

Re: LuaRocks query: LuaSec compiler warnings...

Bruno Silvestre-2
In reply to this post by sur-behoffski
This problem came from LuaSocket. Luarocks is installing it as dependency.

from LuaSocket 3.0-RC1, file src/option.c:40,41
        char msg[45];
        sprintf(msg, "unsupported option `%.35s'", name);

It was fixed in 'master' branch:
      char msg[57];
      sprintf(msg, "unsupported option `%.35s'", name);

regards
--
bruno

On Wed, Oct 16, 2019 at 12:42 AM sur-behoffski
<[hidden email]> wrote:

>
> G'day,
>
> I'm not authorised to use a more direct path, so I'm trying the general lua-l
> list to raise an issue regarding compiler warnings in the rock luasec:
>
> I get a slew of warnings when installing luasec along the lines of:
>
> > src/options.c:41:43: warning: ‘%.35s’ directive writing up to 35 bytes into a region of size 25 [-Wformat-overflow=]
> >          sprintf(msg, "unsupported option `%.35s'", name);
> >                                            ^~~~~
> > In file included from /usr/include/stdio.h:862:0,
> >                  from /usr/include/lua5.1/lauxlib.h:13,
> >                  from src/options.c:7:
> > /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 22 and 57 bytes into a destination of size 45
> >    return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
> >           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >        __bos (__s), __fmt, __va_arg_pack ());
> >        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I don't know how potentially damaging these warnings are; I merely not that newer
> C compilers (here, gcc-7.4 under Linux Mint 19.1):
>
>          gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
>
> gcc has, over the course of the last few releases (6.x up to the current 9.x)
> become better at code flow analysis, and, as a benefit, become more picky at
> identifying potential C coding mistakes, such as buffer overflow.  (Misleading
> indentation, of the kind that caused the Apple "goto fail;" bug, is another
> one.)
>
> I'm reporting this diagnostic to this list, when I'm a bit of a "babe in arms"
> regarding bug reporting and tracking, and so:
>
> 1. If there is suitable project site, with an issue tracker, please "TELL ME
> WHERE TO GO"!.
>
> 2. In the absence of Item 1, could someone please address these compiler
> warnings?  I'm striving to work in a world where I can wind up the compiler
> warnings to "-Wall -Wextra -Wpedantic" and still have zero warnings.  This
> is inspired, in part, from my experience in working in a company that was
> striving (and succeeded) to produce an extremely-reliable product (the test
> team had tools to insert *every* possible error return into *every* actual
> system call, and these were all part of the regression test rig); a second
> reason is that I desire to have the extended Lua ecosystem that I use,
> including but not limited to LuaRocks, to be a +zero-warnings" system.
>
> I'm also inspired partially by Gerard Holzmann's "Mars Code" approach:
>
>          https://www.usenix.org/conference/hotdep12/workshop-program/presentation/Holzmann
>
> in which his team managed to produce several million lines of code -- far
> too many to be reviewed manually -- and was successful in producing the
> software portion of a hardware/software/remote system that achieved a very
> complex goal.
>
> Coding standards, static and dynamic review tools, and continuous
> integration featured in his approach.
>
> My hope is to be a "devil's advocate" at times when I see code that falls
> below extremely high standards -- and standards that are being lifted in an
> incremental fashion as compiler technology improves.  I do not claim to be
> a saint myself -- and so would only point out cases where fixed are close
> to trivial.
>
> So, feedback on this message, my experience with LuaSec, and any other
> issue raised by this message is welcome.  I ultimately hope that the
> extended Lua community benefits from my actions; this is not something
> that I always achieve.
>
> cheers,
>
> sur-behoffski (Brenton Hoff)
> programmer, Grouse Software
>