Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 274 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  66724   Wed Feb 24 15:54:40 2010 Question Ulf Helmerssonulfhe@ifm.liu.seBug reportOtherV2.7.8-227Show Attributes

 This programing have stoped working, I guess after last update.

Elog is running on Solaris.

Ulf Helmersson

 

 

 

Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}

{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format

{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding

{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter

{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book

{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent

 

  66754   Fri Mar 12 12:59:25 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportOtherV2.7.8-227Re: Show Attributes

Ulf Helmersson wrote:

 This programing have stoped working, I guess after last update.

Elog is running on Solaris.

Ulf Helmersson

 

 

 

Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}

{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format

{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding

{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter

{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book

{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent

 

The option

Show Attributes =

has been changed to

Show Attributes Edit =

to distinguish between normal entry display an edit mask. So please adjust your configuration file and everything will be fine again.

  66921   Wed Oct 27 23:43:37 2010 Question Morion Blackmorion.estariol@gmail.comQuestionOther2.8.0Can anyone help compile ELog 2.8.0 on SunOS 5.11?

 I have server with SunOS 5.11:

uname -a

SunOS *** 5.11 snv_134 i86pc i386 i86pc

 

when I try to compile ELog I get error:

gmake

gcc  -DHAVE_SSL -w -c -o crypt.o src/crypt.c

gcc  -DHAVE_SSL -I../mxml -o elog src/elog.c crypt.o -lsocket -lnsl -lssl

Undefined                       first referenced

 symbol                             in file

MAX                                 crypt.o

MIN                                 crypt.o

mempcpy                             crypt.o

_ast_strtoul                        crypt.o

_ast_realloc                        crypt.o

ld: fatal: symbol referencing errors. No output written to elog

collect2: ld returned 1 exit status

gmake: *** [elog] Error 1

 
 
Can anyone help to compile Elog?

  66938   Tue Nov 16 10:00:48 2010 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.8.0Re: Can anyone help compile ELog 2.8.0 on SunOS 5.11?

Morion Black wrote:

 I have server with SunOS 5.11:

 

uname -a

SunOS *** 5.11 snv_134 i86pc i386 i86pc

 

when I try to compile ELog I get error:

 

gmake

gcc  -DHAVE_SSL -w -c -o crypt.o src/crypt.c

gcc  -DHAVE_SSL -I../mxml -o elog src/elog.c crypt.o -lsocket -lnsl -lssl

Undefined                       first referenced

 symbol                             in file

MAX                                 crypt.o

MIN                                 crypt.o

mempcpy                             crypt.o

_ast_strtoul                        crypt.o

_ast_realloc                        crypt.o

ld: fatal: symbol referencing errors. No output written to elog

collect2: ld returned 1 exit status

gmake: *** [elog] Error 1

 
 
Can anyone help to compile Elog?

 

 

The crypt.c file is not from me, so there might be some issues on other OSes. I defined now at least MIN/MAX by hand, and also removed mempcpy. The new version is attached. Can you try again to compile it? The strtoul and realloc are nomal C functions, maybe you have to add some other libraries for linking, but I'm not an expert for SunOS. 

Attachment 1: crypt.c
/* SHA256-based Unix crypt implementation.
   Released into the Public Domain by Ulrich Drepper <drepper@redhat.com>.
   Adapted for MS Windows by Stefan Ritt <stefan.ritt@psi.ch> 
   $Id: crypt.c 2334 2010-11-16 08:59:45Z ritt $ */

#ifdef _MSC_VER
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define __alignof__(x) sizeof(x)
#define alloca(x) malloc(x)
#define ERANGE 34

typedef unsigned int uint32_t;
#else
#include <errno.h>
#include <limits.h>
#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/param.h>
#include <sys/types.h>
#endif

#ifndef MAX
#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)<(y)?(x):(y))
#endif
      
/* Structure to save state of computation between the single steps.  */
struct sha256_ctx {
   uint32_t H[8];

   uint32_t total[2];
   uint32_t buflen;
   char buffer[128];            /* NB: always correctly aligned for uint32_t.  */
};


#if __BYTE_ORDER == __LITTLE_ENDIAN
# define SWAP(n) \
    (((n) << 24) | (((n) & 0xff00) << 8) | (((n) >> 8) & 0xff00) | ((n) >> 24))
#else
# define SWAP(n) (n)
#endif


/* This array contains the bytes used to pad the buffer to the next
   64-byte boundary.  (FIPS 180-2:5.1.1)  */
static const unsigned char fillbuf[64] = { 0x80, 0 /* , 0, 0, ...  */  };


/* Constants for SHA256 from FIPS 180-2:4.2.2.  */
static const uint32_t K[64] = {
   0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5,
   0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
   0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3,
   0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
   0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
   0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
   0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7,
   0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
   0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13,
   0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
   0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3,
   0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
   0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5,
   0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
   0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
   0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
};


/* Process LEN bytes of BUFFER, accumulating context into CTX.
   It is assumed that LEN % 64 == 0.  */
static void sha256_process_block(const void *buffer, size_t len, struct sha256_ctx *ctx)
{
   const uint32_t *words = buffer;
   size_t nwords = len / sizeof(uint32_t);
   uint32_t a = ctx->H[0];
   uint32_t b = ctx->H[1];
   uint32_t c = ctx->H[2];
   uint32_t d = ctx->H[3];
   uint32_t e = ctx->H[4];
   uint32_t f = ctx->H[5];
   uint32_t g = ctx->H[6];
   uint32_t h = ctx->H[7];

   /* First increment the byte count.  FIPS 180-2 specifies the possible
      length of the file up to 2^64 bits.  Here we only compute the
      number of bytes.  Do a double word increment.  */
   ctx->total[0] += len;
   if (ctx->total[0] < (int) len)
      ++ctx->total[1];

   /* Process all bytes in the buffer with 64 bytes in each round of
      the loop.  */
   while (nwords > 0) {
      uint32_t W[64];
      unsigned int t;
      uint32_t a_save = a;
      uint32_t b_save = b;
      uint32_t c_save = c;
      uint32_t d_save = d;
      uint32_t e_save = e;
      uint32_t f_save = f;
      uint32_t g_save = g;
      uint32_t h_save = h;

      /* Operators defined in FIPS 180-2:4.1.2.  */
#define Ch(x, y, z) ((x & y) ^ (~x & z))
#define Maj(x, y, z) ((x & y) ^ (x & z) ^ (y & z))
#define S0(x) (CYCLIC (x, 2) ^ CYCLIC (x, 13) ^ CYCLIC (x, 22))
#define S1(x) (CYCLIC (x, 6) ^ CYCLIC (x, 11) ^ CYCLIC (x, 25))
#define R0(x) (CYCLIC (x, 7) ^ CYCLIC (x, 18) ^ (x >> 3))
#define R1(x) (CYCLIC (x, 17) ^ CYCLIC (x, 19) ^ (x >> 10))

      /* It is unfortunate that C does not provide an operator for
         cyclic rotation.  Hope the C compiler is smart enough.  */
#define CYCLIC(w, s) ((w >> s) | (w << (32 - s)))

      /* Compute the message schedule according to FIPS 180-2:6.2.2 step 2.  */
      for (t = 0; t < 16; ++t) {
         W[t] = SWAP(*words);
         ++words;
      }
      for (t = 16; t < 64; ++t)
         W[t] = R1(W[t - 2]) + W[t - 7] + R0(W[t - 15]) + W[t - 16];

      /* The actual computation according to FIPS 180-2:6.2.2 step 3.  */
      for (t = 0; t < 64; ++t) {
         uint32_t T1 = h + S1(e) + Ch(e, f, g) + K[t] + W[t];
         uint32_t T2 = S0(a) + Maj(a, b, c);
         h = g;
         g = f;
         f = e;
         e = d + T1;
         d = c;
         c = b;
         b = a;
         a = T1 + T2;
      }

      /* Add the starting values of the context according to FIPS 180-2:6.2.2
         step 4.  */
      a += a_save;
      b += b_save;
      c += c_save;
      d += d_save;
      e += e_save;
      f += f_save;
      g += g_save;
      h += h_save;

      /* Prepare for the next round.  */
      nwords -= 16;
   }

   /* Put checksum in context given as argument.  */
   ctx->H[0] = a;
   ctx->H[1] = b;
   ctx->H[2] = c;
   ctx->H[3] = d;
   ctx->H[4] = e;
   ctx->H[5] = f;
   ctx->H[6] = g;
   ctx->H[7] = h;
}


/* Initialize structure containing state of computation.
   (FIPS 180-2:5.3.2)  */
static void sha256_init_ctx(struct sha256_ctx *ctx)
{
   ctx->H[0] = 0x6a09e667;
   ctx->H[1] = 0xbb67ae85;
   ctx->H[2] = 0x3c6ef372;
   ctx->H[3] = 0xa54ff53a;
   ctx->H[4] = 0x510e527f;
   ctx->H[5] = 0x9b05688c;
   ctx->H[6] = 0x1f83d9ab;
   ctx->H[7] = 0x5be0cd19;

   ctx->total[0] = ctx->total[1] = 0;
   ctx->buflen = 0;
}


/* Process the remaining bytes in the internal buffer and the usual
   prolog according to the standard and write the result to RESBUF.

   IMPORTANT: On some systems it is required that RESBUF is correctly
   aligned for a 32 bits value.  */
static void *sha256_finish_ctx(struct sha256_ctx *ctx, void *resbuf)
{
   /* Take yet unprocessed bytes into account.  */
   uint32_t bytes = ctx->buflen;
   size_t pad;
   unsigned int i;

   /* Now count remaining bytes.  */
   ctx->total[0] += bytes;
   if (ctx->total[0] < bytes)
      ++ctx->total[1];

   pad = bytes >= 56 ? 64 + 56 - bytes : 56 - bytes;
   memcpy(&ctx->buffer[bytes], fillbuf, pad);

   /* Put the 64-bit file length in *bits* at the end of the buffer.  */
   *(uint32_t *) & ctx->buffer[bytes + pad + 4] = SWAP(ctx->total[0] << 3);
   *(uint32_t *) & ctx->buffer[bytes + pad] = SWAP((ctx->total[1] << 3) | (ctx->total[0] >> 29));

   /* Process last bytes.  */
   sha256_process_block(ctx->buffer, bytes + pad + 8, ctx);

   /* Put result from CTX in first 32 bytes following RESBUF.  */
   for (i = 0; i < 8; ++i)
      ((uint32_t *) resbuf)[i] = SWAP(ctx->H[i]);

   return resbuf;
}


static void sha256_process_bytes(const void *buffer, size_t len, struct sha256_ctx *ctx)
{
   /* When we already have some bits in our internal buffer concatenate
      both inputs first.  */
   if (ctx->buflen != 0) {
      size_t left_over = ctx->buflen;
      size_t add = 128 - left_over > len ? len : 128 - left_over;

      memcpy(&ctx->buffer[left_over], buffer, add);
      ctx->buflen += add;

      if (ctx->buflen > 64) {
         sha256_process_block(ctx->buffer, ctx->buflen & ~63, ctx);

         ctx->buflen &= 63;
         /* The regions in the following copy operation cannot overlap.  */
         memcpy(ctx->buffer, &ctx->buffer[(left_over + add) & ~63], ctx->buflen);
      }

      buffer = (const char *) buffer + add;
      len -= add;
   }

   /* Process available complete blocks.  */
   if (len >= 64) {
/* To check alignment gcc has an appropriate operator.  Other
   compilers don't.  */
#if __GNUC__ >= 2
# define UNALIGNED_P(p) (((uintptr_t) p) % __alignof__ (uint32_t) != 0)
#else
# define UNALIGNED_P(p) (((uintptr_t) p) % sizeof (uint32_t) != 0)
#endif
      if (UNALIGNED_P(buffer))
         while (len > 64) {
            sha256_process_block(memcpy(ctx->buffer, buffer, 64), 64, ctx);
            buffer = (const char *) buffer + 64;
            len -= 64;
      } else {
         sha256_process_block(buffer, len & ~63, ctx);
         buffer = (const char *) buffer + (len & ~63);
         len &= 63;
      }
   }

   /* Move remaining bytes into internal buffer.  */
   if (len > 0) {
      size_t left_over = ctx->buflen;

      memcpy(&ctx->buffer[left_over], buffer, len);
      left_over += len;
      if (left_over >= 64) {
         sha256_process_block(ctx->buffer, 64, ctx);
         left_over -= 64;
         memcpy(ctx->buffer, &ctx->buffer[64], left_over);
      }
      ctx->buflen = left_over;
   }
}


/* Define our magic string to mark salt for SHA256 "encryption"
   replacement.  */
static const char sha256_salt_prefix[] = "$5$";

/* Prefix for optional rounds specification.  */
static const char sha256_rounds_prefix[] = "rounds=";

/* Maximum salt string length.  */
#define SALT_LEN_MAX 16
/* Default number of rounds if not explicitly specified.  */
#define ROUNDS_DEFAULT 5000
/* Minimum number of rounds.  */
#define ROUNDS_MIN 1000
/* Maximum number of rounds.  */
... 275 more lines ...
  67006   Fri Feb 4 00:11:09 2011 Question T. Ribbrockemgaron+elog@ribbrock.orgQuestionOther2.8.1Strange problem with dates - need debugging help

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated...

 

  67007   Fri Feb 4 10:20:12 2011 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.8.1Re: Strange problem with dates - need debugging help

T. Ribbrock wrote:

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated... 

The problem is most probably related to the time zone. elogd contains a function:


/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}
 
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
 
|| defined(__OpenBSD__)
 
if the pre-compiler directive __FreeBSD__ is not defined on your system. The result of the function should be the time zone in seconds relative to GMT. So for central Europe, it should give "-3600".
 
Let me know if you find something out, I can then include it in the distribution.
 
Best regards,
 
  Stefan
  67008   Fri Feb 4 11:52:45 2011 Agree T. Ribbrockemgaron+elog@ribbrock.orgQuestionOther2.8.1Re: Strange problem with dates - need debugging help

Stefan Ritt wrote:

The problem is most probably related to the time zone. elogd contains a function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}
 
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
 
|| defined(__OpenBSD__)
 
if the pre-compiler directive __FreeBSD__ is not defined on your system.
[...]
 

 BINGO! That was it - thank you! I've added the || defined(__OpenBSD__) in the place you described above and now the dates are correct. While I was at it, I also had a look at what other ifdefs there are for FreeBSD and the only other one I found was also in elogd.c:

#if defined (_BSD_VA_LIST_) && defined (__FreeBSD__)

I'm far from being a C programmer, but I did some quick and dirty compile tests with various ifdefs set and apparently, _BSD_VA_LIST_ is not set on OpenBSD, so I guess that this statement does not need modification. I will keep my eyes peeled for strange behaviour, though...

Cheerio,

Thomas

P.S.: One thing I noticed is that the OpenBSD variant of gcc throws these warnings when compiling elogd.c:

gcc -g -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_SSL -I../mxml -o elogd src/elogd.c crypt.o regex.o mxml.o strlcpy.o -lcrypto -lssl
/tmp//ccHhMZfy.o(.text+0xd2f): In function `int_vasprintf':
src/elogd.c:826: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//ccHhMZfy.o(.text+0xae8): In function `xstrdup':
src/elogd.c:736: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccHhMZfy.o(.text+0x13c7): In function `my_shell':
src/elogd.c:1197: warning: sprintf() is often misused, please use snprintf()
/tmp//ccHhMZfy.o(.text+0xf0ae): In function `el_correct_links':
src/elogd.c:5178: warning: strcat() is almost always misused, please use strlcat()

I'm not certain whether this is specific to this gcc variant, but I seem to remember that the OpenBSD folks added some extra warnings and suchlike as part of their overall code audit, so I thought I'd mention it.

  67009   Fri Feb 4 23:48:54 2011 Warning T. Ribbrockemgaron+elog@ribbrock.orgBug reportOther2.9.0-2384Odd bug with conditional and required attributes

I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):

; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no

; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?

The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.

Cheerio,

Thomas

P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice!

ELOG V3.1.5-3fb85fa6