Attention to Debian users;

I've prepared the fixed package and also contacted to Debian Security Team for
an urgent security upload.  Since then you may wish to update your package from
the following URL:

  http://l10n-turkish.alioth.debian.org/debian/elog_2.5.7+r1558-1_i386.deb

Or you can also make an update via apt-get by adding the below line to your
'/etc/apt/sources.list' file:

  deb http://l10n-turkish.alioth.debian.org/debian/ ./

> 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.

FYI, Debian package has already been compiled with this flag.

 -- Recai Oktas, Maintainer of Debian package

The above made statement is not true any more. Mainly due to the large CERN experiments, some speed improvements have been made in late 2007. So elog runs fine at least up to 100000 entries. The startup time might be a bit slow, since it parses all entries there, but beyond the maybe 20s startup time, there is not a big difference when browsing entries. The only peoblem left is if you try to search some text through 100000 entries, this could be a bit slow. I have not tried anhything beyond 100000 entries, because this was not requested so far. If logooks become too big, the entreis could be split into several logbooks. Even if there are several logbooks with 100000 entries each, the access time should not be slower than if there would be one logbook with 100000 entries.

If you've upgraded from an elog 2.x version to an 3.x version, then all entries of a logbook will be moved into subfolder, one for each year.

If you then switch back to the 2.x version of elog, it'll not find any entries.

You can move them back to the folder for the logbook (one directory up) and they'll be found again after the next restart of elog.

Cheers, Andreas

> 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. 

That's strange. I just tried myself (by accident I have the same versions of Chrome and OSX) and it just worked fine. The fckedit code has not change a long time, so I guess it's not related to the exact version of 
elogd. Anyhow I want to switch to ckedit when I get some time, which maybe fixes the problem. What happens if you try to write in this forum, do you have the same problem? Sometime the fcdedit code take 
quite long time to load when accessed remotely. If your browser gives up, you might hat to click on "reload". In chrome there is also the "Developer tools" window, which shows you all HTTP requests and 
responses on the network. Otherwise I run out of ideas what could be different for you compared to me.

Cheers,
Stefan

> > 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. 
> 
> That's strange. I just tried myself (by accident I have the same versions of Chrome and OSX) and it just worked fine. The fckedit code has not change a long time, so I guess it's not related to the exact version of 
> elogd. Anyhow I want to switch to ckedit when I get some time, which maybe fixes the problem. What happens if you try to write in this forum, do you have the same problem? Sometime the fcdedit code take 
> quite long time to load when accessed remotely. If your browser gives up, you might hat to click on "reload". In chrome there is also the "Developer tools" window, which shows you all HTTP requests and 
> responses on the network. Otherwise I run out of ideas what could be different for you compared to me.
> 
> Cheers,
> Stefan

Later on, I tried the prescription pointed to in that thread that says in scripts/fckeditor/editor/js/fckeditorcode_gecko.js to replace

FCKTools.FixDocumentParentWindow = function(A){ if (A.document) A.document.parentWindow=A; for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};

with: 

FCKTools.FixDocumentParentWindow = function(A){try{ if (A.document) A.document.parentWindow=A;} catch(e){};for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};

and after I got all my brackets straight, my pages were visible.  I'm still not sure when this turned up, since I use my elog every day (hour) and so I'd hardly miss it when I upgraded various things, although I don't watch Chrome updating itself that closely.

Have a good holiday!