> Well, I bit the bullet and fixed all of these warnings. Took me like two days of work, but now should be fine.
> You might want to test it again.

Done. Only 2 sprintf() overruns remain, see below.

> I only have gcc 9.2.0, there it compiles now without warning.

Ubuntu LTS 20.04 is GCC 9.3.0. (And incoming Debian-11 based Ubuntu LTS 22.04 likely to be GCC 10.something).

If you do not have access, I can create an account for you on daq00.triumf.ca.

daq00:elog$ make
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -c -o mxml.o 
mxml/mxml.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -w -c -o crypt.o 
src/crypt.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -c -o strlcpy.o 
mxml/strlcpy.cxx
type git &> /dev/null; if [ $? -eq 1 ]; then REV="unknown" ;else REV=`git log -n 1 --pretty=format:"%ad - %h"`; fi; echo \#define 
GIT_REVISION \"$REV\" > src/git-revision.h
git is /usr/bin/git
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elog 
src/elog.cxx mxml.o crypt.o strlcpy.o -lssl
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -w -c -o auth.o 
src/auth.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elogd 
src/elogd.cxx auth.o mxml.o crypt.o strlcpy.o -lssl
src/elogd.cxx: In function ‘void show_elog_list(LOGBOOK*, int, int, int, BOOL, char*)’:
src/elogd.cxx:21676:42: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21676 |                sprintf(str, "Time format %s", attr_list[i]);
      |                                          ^~
In file included from /usr/include/stdio.h:867,
                 from src/elogd.h:42,
                 from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination 
of size 1600
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.cxx:21660:42: warning: ‘%s’ directive writing up to 149999 bytes into a region of size 1588 [-Wformat-overflow=]
21660 |                sprintf(str, "Date format %s", attr_list[i]);
      |                                          ^~
In file included from /usr/include/stdio.h:867,
                 from src/elogd.h:42,
                 from src/elogd.cxx:38:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 13 and 150012 bytes into a destination 
of size 1600
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -o elconv 
src/elconv.cxx -lssl



daq00:elog$ gcc -v
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) 

> I fixed these as well, please have a look again. BTW, midas had a few of these as well.

confirmed. elog commit d828aa58305ee8ce2ae882c0ff3c34cfa66650e5

K.O.

Something is not right with the elog account activation, I get the email
for "Registration request for ELOG logbook "haicu"", but when I follow the given URL,
I get "Invalid activation code". Account activation requests go to two people,
so maybe the other one already activate this user, in which case I expect a message "user already active".
When I check the elog config, I see that the user indeed is already active. And if I rerun
this URL I still get "Invalid activation code", and this time I definitely expect "user already active".

https://daq00.triumf.ca/elog-haicu/haicu/?cmd=Activate&new_user_name=fujiwara&code=-1904103410&unm=Olchansk

K.O.

we had an elog with only one logbook and one password file,
we added a second logbook with a second password file and everything broke.

specifically, login to the original logbook stopped working,
username and password is accepted, elog.log says "user accepted", but I am presented
with the login dialog again, ad infinitum, and cannot access the elog.

solution seems to be to "delete all cookies" (which is excessive,
google chrome wants to delete all cookies for *.triumf.ca,
which will log me out from everywhere I am logged in and probably
erase/reset web site preferences everywhere).

manually deleting just the elog session cookie also seems to work, though.

this suggests that there is a bug in elog, where on successful login,
it fails to create a new authentication cookie, but reuses an old
cookie, which is no longer valid, for whatever reason (that would
be a different bug, why adding one more logbook invalidates
existing logins?).

K.O.

> Something is not right with the elog account activation...

I did a test:
- register as new user "test", web page says "request for approval sent..." (good)
- check elog config, user "test" is present, "active" set to "no" (good)
- open the "approve/activate" URL, get "Invalid activation code" (should say: "activated successfully!")
- check elog config, user "test" now has "active" set to "yes" (good, "approve/activate" URL worked)
- open the "approve/activate" URL again, again "Invalid activation code" (should say: "already activated!")

additional test:
- from the elog config, user "test", set active to "no", save.
- open the "approve/activate" URL, get "Invalid activation code" (good, this time)
- check elog config, user "test" is still inactive (good)

So it looks like the "approve/activate" URL works correctly - only the first time it is accessed - but
returns wrong message "invalid activation code" instead of "success".

K.O.
 

The CVEs you refer to are very old and have been fixed a long time ago.

Please refer to:
https://www.tenable.com/security/research/tra-2019-53

This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.

Note that the elog git history does not refer to these CVEs because
they were fixed before the CVE number was assigned, per "Disclosure Timeline"
in the above document. The relevant commits are listed under "Additional References".

K.O.

> > > The CVEs you refer to are very old and have been fixed a long time ago.
> 
> Am I wrong that the windows executable version on the site is dated 2018? 3.1.4-2?

I confirm. Windows executables at https://elog.psi.ch/elog/download/windows/
and Debian packages at https://packages.debian.org/search?keywords=elog all
appear to be older than the cve fixes.

I trust Stefan is reading this thread and will do something about it. My vote would
be to remove the download link to the windows executables and ask Debian to remove
the elog package. I think they have a way for upstream developers (Stefan) to request
removal of unmaintained out-of-date insecure versions of their stuff. ROOT
was in the same situation years ago, the Debian package for ROOT was very old version,
also built incorrectly, and everybody complained to us that our stuff does
not work (midas, rootana, etc).

K.O.

"file not found" should return http code 404. elogd returns code 200 together
with a page containing text "404 not found". This pollutes the browser cache
with wrong content (in this case, we are trying to load a css file, and the browser
is trying to use text "404 not found" as if it were a css. bad. file not found
should return http code 404. K.O.

in example below, response "HTTP/1.1 200 Document follows" should be "HTTP/1.1 404 ..."

to reproduce, through the https proxy:

daq00:~$ curl -v https://daq00.triumf.ca/elog-midas/Midas/zzz.css
*   Trying 142.90.111.168:443...
...
> GET /elog-midas/Midas/zzz.css HTTP/1.1
...
< HTTP/1.1 200 Document follows
< Date: Thu, 17 Mar 2022 23:40:04 GMT
< Server: ELOG HTTP 3.1.4-2e1708b5
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Content-Type: text/html;charset=ISO-8859-1
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< 
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Connection #0 to host daq00.triumf.ca left intact
daq00:~$ 

directly:

daq00:~$ curl -v http://localhost:9080/Midas/zzz.css
*   Trying 127.0.0.1:9080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9080 (#0)
> GET /Midas/zzz.css HTTP/1.1
> Host: localhost:9080
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 Document follows
< Server: ELOG HTTP 3.1.4-2e1708b5
< Content-Type: text/html;charset=ISO-8859-1
< Connection: Close
< 
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Closing connection 0
daq00:~$