> I would like to increase the spacing between 'MOptions' choices. I have
> created a new theme and have been playing with the CSS stylesheet. But can't
> find how to increase this spacing. Having lots of fun otherwise!

Intersting question (meaning: I don't have an answer... (;-) )

The class which applies there is "attribvalue". You can increase the padding for
that class, but that only increases the space between all options and the cell
border, but not between them. I could put each MOption in a separate cell of a
subtable. Then one could increase the padding between them, but the layout would
be fixed, meaning that they are always left-to-right. As you can see in this
forum, the MOptions nicely place below each other if the screen is too narrow.
This functionality would be lost.

Maybe someone else has a clever solution?

> I have defined a new field called "Record Date" to accept the dates from a
> previous logging system. I am not too concerned with the timestamp
> associated with these old imported entries. But for new entries...
> There is no way I am able enter/edit the time into my new field. They all
> show as having a time of 12:00. What am I doing wrong? Here is a portion of
> my config

Date is "date", and not "date-time" unfortunately. There is no way right now to
enter a time. I plan however to add a new format "datetime", which allows that
option. So stay tuned.

- Stefan

Stefan,

Oh. OK. I will keep tuned. It would be quite useful to have.

Mark
> > I have defined a new field called "Record Date" to accept the dates from a
> > previous logging system. I am not too concerned with the timestamp
> > associated with these old imported entries. But for new entries...
> > There is no way I am able enter/edit the time into my new field. They all
> > show as having a time of 12:00. What am I doing wrong? Here is a portion of
> > my config
> 
> Date is "date", and not "date-time" unfortunately. There is no way right now to
> enter a time. I plan however to add a new format "datetime", which allows that
> option. So stay tuned.
> 
> - Stefan

I implemented a "datetime" option which does exactly what you want. All you
need is a

Type Record Date = datetime

in your config file. The new option is present in version 2.5.8-2 and ready to
download.

Segmentation fault when searching for empty regex
--------------------------------------------------

Searching for a regex like 'm*', which also includes zero 'm's, an empty
expression is found indefinitely in 'highlight_searchtext(...)', which 
eventually results in an overflow of 'pt1'.  The patch below fixes this
particular problem, but I would guess there are many other regular 
expressions that would lead to an overflow of 'pt1', so its size
should definitely be checked before every 'strcpy(pt1,...)' and
the loop be aborted accordingly.  (Or 'pt1' should be allocated 
and enlarged dynamically.)

*** 14777,14782 ****
--- 14777,14784 ----
        if (status != REG_NOMATCH) {
           size = pmatch[0].rm_so;
  
+        if (size == 0) break; /* check for zero size -> infinite loop */
+ 
           /* copy first part original text */
           memcpy(pt1, pt, size);
           pt1 += size;
***************
*** 14788,14795 ****
--- 14790,14799 ----
           /* see also rsputs2(char* ) */
  
           if (hidden)
+          /* need to check size of pt1 !!! */
              strcpy(pt1,
"\001B\004style=\003color:black;background-color:#ffff66\003\002");
           else
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "<B style=\"color:black;background-color:#ffff66\">");
  
           pt1 += strlen(pt1);
***************
*** 14802,14814 ****
--- 14806,14821 ----
  
           /* add coloring 2nd part */
           if (hidden)
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "\001/B\002");
           else
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "</B>");
           pt1 += strlen(pt1);
        }
     } while (status != REG_NOMATCH);
  
+    /* need to check size of pt1 !!! */
     strcpy(pt1, pt);
  }

I applied a similar fix like you proposed, just omit highlighting at all if I get a
zero length match. Changes committed to CVS.

Hi,

I am an apache ignoramus who has been trying to follow these instructions on a Debian 3.1 box.  I got hung up for
the following reason.  I had to explicitly enable some apache features, which was a simple matter of making the
following symlinks in /etc/apache2/mods-enabled: 

	proxy.conf -> ../mods-available/proxy.conf
	proxy.load -> ../mods-available/proxy.load
	rewrite.load -> ../mods-available/rewrite.load
	headers.load -> ../mods-available/headers.load
	ssl.conf -> ../mods-available/ssl.conf
	ssl.load -> ../mods-available/ssl.load

Easy enough.  The default proxy.conf has sensible-looking warnings about not running your server as an open proxy.
 However, I wasn't able to tweak it to encrypted port forwarding from :443 to :8079.

What I've done that works is to add a local proxy section to the /etc/apache2/conf.d/elogredirect.conf by Damon
Nettles:

	<VirtualHost *:443>
		### ... everything else

		<Proxy *>
			Allow from all
		</Proxy>
	</VirtualHost>

I think, since this is in a subsection, that it only affects that virtual host.  But it'd be nice if someone who
actually understands this language would reassure me that I'm not setting myself up for some security hole.  At
any rate it took me long enough to figure this out that I thought I'd post a note in public, and this seems like
the forum to do so.

Thanks.

Rob

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