To obtain the newest source code of ELOG, go to the CVS repository at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src

It contains usually the newest bug fixes, which will show up in the next 
realease. On the other hand it can also contain some new features, which 
are not yet fully tested, so care should be taken when using it. The 
revision comments usually explain what is new in that revision.

Dear ELOG users,

It has been brought to my attention that ELOG has a vulnerability through
which one can obtain a remote shell (meaning to log in to your machine
through elog). There is even an exploit available which demonstrates that
both for linux and windows.

This is a severe security problem for all logooks which can be seen from
outside, even if they have password protection on. I strongly recommened to
upgrade to elog version 2.5.7 as soon as possible if you run a public elog
server.

Here is some explanation for the technically interested:

The problem arises from a strcpy() in the decode_post() routine, which
triggers a buffer overflow when attachment file names longer than 256
characters are submitted. I replaced (hopefully) all strcpy() with strlcpy()
to fix this problem, but if someone sees a location which I have missed,
please tell me.

The second vulnerability had to do with write passwords. If you put a "write
password = xxx" statement into your config file, it was still possible to
download the config file with a special hand-written URL, and decode the
write password, which is usually only base-64 encoded unless you haven't
compiled elog with the -DHAVE_CRYPT flag. I have changed that so if a write
password is present, the download is only possible when this password is
submitted in each request. If this has some effects on synchronizing of
logbooks, please let me know.

Stefan Ritt

Hi, All.  We have been successfully using ELOG in a limited deployment for a couple years now.  However, we are about to embark on a new project that could run for up to 10 years, and are wondering what sort of scalability we can expect from ELOG.

Are there any problems we can expect to run into as the number of entries grow?  I see in a previous thread that "elog runs fine for a few 10000 entries. At 100000 entries it starts getting slow."  Is this still the case, or have any improvements been made?  What sort of problems would we expect to run into?  Any examples of existing large deployments would be very useful.

Many thanks,

Devin 

I have been using elog for over 10 years. Suddenly my elog installation has changed (probably from a recent update. My /etc/elogd.cfg has changed to the original demo configuration. Even after changing it to my configuration from backup none of the entries for the logbooks apper even though the tabs for the logboos are ther all logbooks are empty. I have looced at the logbook files and the entries seem to be there but are not showing on the web interface. Has something changed? Is there a new location for the logbooks and other files? Is there a change from the 32-bit to the 64-bit version that will cause this. I am running CentOS 7 fully patched and updated. Will there be a CentOS 8 compatible version?

• Use the new ViewCVS gateway. This gateway now can also directly produce tarballs for the current repository snapshot
  
• Use anonymous Subversion access:
  
  svn checkout svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/elog/trunk elog
  svn@midas.psi.ch's password: svn
  (you might have to enter the password several times...)
  svn checkout svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
  svn@midas.psi.ch's password: svn
  (you might have to enter the password several times...)
  

Recently I have had problems with ELOG not accepting the certificates (in this case from https://letsencrypt.org/) probably due to the old version of the SSL library of the binary distribution for Windows.
I have tried to follow the instructions to set up ELOG to work with Apache but they are probably old.
I have a simple solution for the Apache installation of XAMPP, the example is for two separate logbooks using each its own ELOG service on the same server:

1. I have set up the two ELOG to run as http://my.server.example.com:8080/ and as http://my.server.example.com:8081/

2. in c:\xampp\apache\conf\httpd.conf I have enabled the following (I am not sure if all the modules are really needed but this works for me):

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module modules/mod_headers.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so

3. still in c:\xampp\apache\conf\httpd.conf, at the very end of the file I added the following:

ProxyRequests off

Redirect permanent /app1 https://my.server.example.com/app1/
ProxyPass /app1/ http://my.server.example.com:8080/
ProxyHTMLURLMap http://my.server.example.com:8080 /app1

Redirect permanent /app2 https://my.server.example.com/app2/
ProxyPass /app2/ http://my.server.example.com:8081/
ProxyHTMLURLMap http://my.server.example.com:8081 /app2

This way I can now connect to the two ELOG using https://my.server.example.com/app1/ and https://my.server.example.com/app2/ without troubles and no additional setting to either the configuration files of ELOG nor any need for virtual hosts, ...

I hope this might be of use.

In the past couple of days, I seem to have developed a problem with making entries into elog's displayed with Chrome (the latest, 31.0.1650.63) on 
Mac OS (10.9.1, the latest).  The problem occurs with attempting to edit or enter HTML encoded pages with fckedit; although pages render correctly 
in list mode, if you try to edit or enter an entry, the page is blank, the cursor is missing, you can't see text or type new text.  I ran elogd -v by hand, 
and there were no obvious problems, and I looked at the developer consoles in Chrome, and the only place I see any hint of what the problem might 
be is the Javascript console which says this:

event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
Uncaught SecurityError: Blocked a frame with origin "http://localhost:8080" from accessing a frame with origin "chrome-
extension://pioclpoplcdbaefihamjohnefbikjilc".  The frame requesting access has a protocol of "http", the frame being accessed has a protocol of 
"chrome-extension". Protocols must match.
 fckeditorcode_gecko.js:36

It works ok in Safari, but it would be nice to use Chrome, and it was working ok until recently.  I don't think the problem occurred when I updated to 
Mac OS 10.9.1, but I don't keep careful track of the Chrome version.  It's not critical, but I pretty much exhausted what I knew how to debug.  I have 
close to the latest elog (2.9.2-2455), although I see the same phenomenon on this elog (.2.9.2-2475) and I think it's related to this thread:

http://productforums.google.com/forum/#!msg/maps/hQhwWA56NbA/2XL35dU7le4J

I tried the prescription in the October 22 entry, but it didn't seem to help, although I wasn't sure I had really tested it with compressed javascript and 
cache and what have you.

The ELOG repository has been moved from Subversion to GIT. While the old repository will be visible for some time, all new development is done on the GIT repository. To download the repository, do a

git clone https://bitbucket.org/ritt/elog.git
git clone https://bitbucket.org/tmidas/mxml.git


or access it online at https://bitbucket.org/ritt/elog/

/Stefan