| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68843
|
Wed Sep 12 15:57:31 2018 |
 | Allen Tuttle | AllenEmail@wavecable.com | Bug report | Linux | 3.1.3 | Re: Compile issues on Fedora withe current elog source | A quick test suggests I can't just replace sprintf with snprintf.
Original error:
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
New error:
src/elogd.c:4503:24: warning: passing argument 2 of ‘snprintf’ makes integer from pointer without a cast [-Wint-conversion]
snprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~
In file included from src/elogd.h:42:0,
from src/elogd.c:38:
/usr/include/stdio.h:340:12: note: expected ‘size_t {aka long unsigned int}’ but argument is of type ‘char *’
extern int snprintf (char *__restrict __s, size_t __maxlen,
| Allen Tuttle wrote: |
|
I would like to try the new code, I don't see it on elog/download/tar/.
Do you keep updates elsewhere like on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
|
68842
|
Wed Sep 12 15:25:07 2018 |
| Allen Tuttle | AllenEmail@wavecable.com | Bug report | Linux | 3.1.3 | Re: Compile issues on Fedora withe current elog source | I would like to try the new code, I don't see it on elog/download/tar/.
Do you keep updates elsewhere like on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
Draft
|
Wed Sep 12 15:20:11 2018 |
| Allen Tuttle | AllenEmail@wavecable.com | Bug report | Linux | 3.1.3 | Re: Compile issues on Fedora withe current elog source | I don't see the update on elog/download/tar/.
Do you keep builds elsewhere, perhaps on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
68840
|
Wed Sep 12 11:10:18 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.3 | Re: Compile issues on Fedora withe current elog source | This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan |
|
68839
|
Tue Sep 11 19:46:40 2018 |
 | Allen Tuttle | AllenEmail@wavecable.com | Bug report | Linux | 3.1.3 | Compile issues on Fedora withe current elog source | Tried compiling on FC27 and 28, both result in binaries but with serious issues; writing data larger than then allowed.
Example output:
make
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -c -o mxml.o mxml/mxml.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o crypt.o src/crypt.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o regex.o src/regex.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -c -o strlcpy.o mxml/strlcpy.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -o elog src/elog.c mxml.o crypt.o regex.o strlcpy.o -lssl
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o auth.o src/auth.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -o elogd src/elogd.c auth.o mxml.o crypt.o regex.o strlcpy.o -lssl
src/elogd.c: In function ‘el_retrieve’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve_attachment.part.30’:
src/elogd.c:4764:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4764:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_submit.constprop’:
src/elogd.c:4894:29: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4894:7: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_submit’:
src/elogd.c:4894:29: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4894:7: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘show_download_page’:
src/elogd.c:14775:32: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:14775:10: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘search_last_reply’:
.
.
.
Anyone aware of a cure? |
|
68838
|
Tue Aug 28 23:38:55 2018 |
| Andrew Wade | awade@caltech.edu | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? | It does indeed seem to be a cookie stripping issue. I just need to figure out how to get Nginx to forward these properly.
Thanks for the help.
| Stefan Ritt wrote: |
|
Actually this forum works through an Apache reverse proxy with authentication and it works, so I suspect that the problem has to do with jwilder/nginx-proxy. Since we don't have this here, all I can propose is that you do debugging yourself. Run elogd with the -v flag so that you see all requests coming from the user through the proxy. Compare the requests through Apache and Nginx to see if any argumets are stripped or mangled. Upon successful login, elog sets a cookie with a unique session-ID (the cookie name is "sid") to the browser. If you proxy strips that cookie, you would land on the login page. Maybe look in that direction.
Stefan
| Andrew Wade wrote: |
|
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
| Stefan Ritt wrote: |
|
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
| Andrew Wade wrote: |
|
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
|
|
68837
|
Mon Aug 27 13:07:28 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2 | Re: Entry size too large for email notification | That's how it is implemented. If you use
Max email attachment size = 1000000
then attachments below 1 MB are sent as attachments, and if the attachment is above 1 MB, then only a link to the attachment in the elog is sent.
Stefan
| Lars Martin wrote: |
|
Wouldn't it make sense for ELog (by default) to still notify, but not send the attachments by e-mail if the size limit is reached?
| Andreas Luedeke wrote: |
|
Hi Jacky,
if I read the source code correctly then the maximum size of a base64 encoded email is hard coded to be 10 MB in elogd.h (recompile after changing it):
#define MAX_CONTENT_LENGTH 10*1024*1024
But I think that an 2.2 MB image should easily fit into that.
Andreas
| Jacky Li wrote: |
|
Hi,
I am doing an inline image that is about 2.2 MB. When I do a submit, I got the following message:
Error sending Email via <i>"<email server>"</i>: Entry size too large for email notification.
May I know what is the limit of the entry size and how do I change it? Thank you.
Jacky
|
|
|
|
|
68836
|
Mon Aug 20 12:42:24 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? | Actually this forum works through an Apache reverse proxy with authentication and it works, so I suspect that the problem has to do with jwilder/nginx-proxy. Since we don't have this here, all I can propose is that you do debugging yourself. Run elogd with the -v flag so that you see all requests coming from the user through the proxy. Compare the requests through Apache and Nginx to see if any argumets are stripped or mangled. Upon successful login, elog sets a cookie with a unique session-ID (the cookie name is "sid") to the browser. If you proxy strips that cookie, you would land on the login page. Maybe look in that direction.
Stefan
| Andrew Wade wrote: |
|
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
| Stefan Ritt wrote: |
|
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
| Andrew Wade wrote: |
|
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
|