Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 274 of 807  Not logged in ELOG logo
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