Hello,
I maintain beanstalkd which is a message server of sorts. It recently
released a new version however some changes I'm not 100% sure about.
When compiling I got the following GCC error.
usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
specified bound 201 equals destination size [-Werror=stringop-
truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
(__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
Results via google says that strncpy needs to have the third argument
less than the 2nd, so I've got this patch, similar to others:
--- beanstalkd-1.12/tube.c.org 2020-06-10 09:37:35.129224346 -0600
+++ beanstalkd-1.12/tube.c 2020-06-10 09:37:42.761138035 -0600
@@ -12,7 +12,7 @@
if (!t)
return NULL;
- strncpy(t->name, name, MAX_TUBE_NAME_LEN);
+ strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
twarnx("truncating tube name");
You'll notice it was already checking the len-1 for null. Can anyone
verify that my change won't cause some un-intended bug I don't
understand?
Finally, they also now support socket activation. Which means I was
looking at .service file which I had setup to use a sysconfig
environment file. When I looked at it, I realized that the default was
to listen to 0.0.0.0 which means someone could install and if not
really careful / pre config or what not have a service listening where
they maybe don't want to. I was thinking of changing this to 127.0.0.1
with a note about how it should be modified. However I figure if I do
that, anyone with this installed and unmodified who gets the update
will suddenly have their service stop listening to the outside world.
What should be done then?
My thought is I leave it as 0.0.0.0 for all released versions (but what
about epel7) and then in rawhide change to 127.0.0.1. I just don't like
leaving the package like that for epel as well.
Any ideas/direction would be appreciated.
Sincerely,
--
Nathanael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
