The problems came from the French accents and the German umlauts. I changed the XML
charset, so this should be fine now. New version is under CVS.

> I included the HTML result so you can "visualize" what's going on (this may 
> also be on the avant browser side !).

I believe it is on the avant browser side. Below is the same shown in the
SharpReader browser, where everything is displayed correctly.

> i am trying to implement ssl features on our logbooks. however, it seems
> that stunnel has drastically changed their program and the usual startup
> procedures listed on the elog page don't work.
> so, what is the new method for getting elog set up with stunnel?

stunnel is kind of a deprecated feature. Better use the SSL proxy of Apache,
as written in the elog admin guide. If someone else figures out how to use the
more revent stunnel, I'm willing to update the documentation.

> I needed the export feature and could not find documentation on it in the latest 
> version. I finally read the code and added Find Menu Text = <filename>
> where filename had the tags XML, CSV1, and CSV2
> This always exports all records. Shouldn't it just export the records appearing in 
> the window?

Exporting workes as follows: Click on "Find", and switch the radio button to XML or CSV.
If you click on "Search", you will be prompted where to save the resulting "export.xml"
or "export.csv". I did this through the search page because you can then specify som
filters, in order not to export all records.

> (BTW, the XML export is not valid. Internet Explorer complains about the first line)

The XML charset in the first line was missing. I fixed that, new version under CVS. Or
you can manually change the first line to

<?xml version="1.0" encoding="ISO-8859-1"?>

> BTW,
> Is there any way to turn off the Text column at the right side of the list?

Summary lines = 0

> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication.  One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache.  This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache.  In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.  

That sounds to me like a great idea. If anybody gets this working, people would be
grateful if this could be submitted to the "Contributions" section of this forum.

<SELECT NAME="lid" multiple size="5">

Oh, nice, I didn't know of that. However, I prefer to have multiple options to be selected
with individual check boxes, this saves more vertical window space. So I added that
functionality to the find page. If more than one option of a MOptions attribute are
selected, they are or'ed together during the search. You can try that in this forum with
the "OS" for example.

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