An ELOG vulnerability has been reported, thanks to Asif Akbar of Trend Micro Security Researchworking with Trend Micro's Zero Day Initiative:

https://www.zerodayinitiative.com/advisories/ZDI-20-252/

The issue has been fixed in the current release 3.1.4-033e292 and in the RPM http://elog.psi.ch/elog/download/RPMS/elog-latest.x86_64.rpm

Best,
Stefan

Hi Stefan

we are running elog

Hi Everyone,

I tried using this $@MID@$ in JS as a variable and cannot doit. I researched a little and found no answer on special character usage. If anyone knows, please lemme know. I also tried breifly in Elogd to change it to something like just MID, but need a better editor as  (Kate) is not saving the program back in correct iso (character) format. So I thought I'd pose the question in the meanwhile.

Thanks, John

No idea what you are talking about. $@MID@$ is used in the database files to indicate the start of a new message. It is not used on any elog web page. If you want to put the message ID on your web page, you should use the variable "$message id" as written in the documentation. You say JS, where is your JS running? You wrote a JS program to work on the raw elog database files? Or you wrote an extension to run in your browse? You have to be a bit clearer.

Stefan

Dear all,

First, many thanks for creating and sharing this great tool which is ELOG! Our users are very happy with it!

I have few questions about inserting images into the entries.

From time to time our users insert them directly in the editor what leads to encoding the whole image in the HTML log file and the images does not appear in the attachments list. Saving and further editing of such entries slows down the whole ELOG server which uses 100% of CPU.

I'm not sure how they do it Ctrl+C & Ctrl+V, drag & drop, etc.. What I know is that if they add it using the "Insert image" action in the editor there are no problems and the images are properly listed in the attachments.

I read in the docs:

uploading or downloading an attachement file is a single request, and causes the entire file to be loaded in server memory while the request is being processed.
This is not normally a problem for the sort of short, text-mode entries ELOG is designed to support. However, if a user starts to upload or download a large attachment file (or image) over a slow link, all other users on that ELOG server will have to wait for that transfert to finish before they can access any logbook on that server. This is why there is a low limit on the size of attachments, and why ELOG should not be used to distribute large files under intensive multi-user conditions.

but I think this is not our case. Here I talk about wrongly inserting a single image of 700KiB.

So, I'm asking:

1. Is the behavior that we observe something already detected? If yes, which are exactly the wrong ways of inserting the images?
2. Is it fixed in newer ELOG versions?
3. Is it possible to disable the wrong ways of inserting the images in order to avoid such problems?

Many thanks in advance for your help!

I found the most limiting factor of ELOG to be the file access. ELOG stores all entries in files and therefore has a lot of disk access.

We found that an AFS directory for ELOG is unusable. We tried to store our logbooks on NFS, and it was barely usable but slow. Now we use a local disk on the server, that works fine.

If you want to speed up ELOG the best approach is a dedicated server with a local SSD storage.

Would it be possible to create a new command "List format <attribute> = <css_class_name>,<css_class_value>,<width>,<size>", or is there another way to achieve this?

Okay, found some solution for my problem:

And file themes/default/pikett.css contains:

That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:

And a quick check in the source code shows some bad code:

L7615: function "show_html_header"

Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].

The bug is still present in elog-3.1.4-611489b