Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 689 of 807  Not logged in ELOG logo
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  66826   Tue May 18 16:40:15 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportAllsvnRe: attachment filename bug & Makefile issue
> If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt."  Also, this effects
> the file's displayed "Uploaded" time.  It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"

Arghh! Why did you choose such a filename? This is the ELOG internal file format, which is YYMMDD_HHMMSS_name.ext. 
For internal reasons (mainly for synchronization) the system checks every file name, and if it contains 6 numbers 
followed by a "_" followed by 6 other numbers it thinks it's a valid date/time and uses that. Your time is however 
0.0.0000, that's why it gets converted to some date in 1999. Do you absolutely need this functionality? While I can 
easily remove the interpretation of the date, it would break the synchronization functionality and I would have to 
find some other method to pass the file date/time, which would be quite some work. So if it's not too important for 
you, I would like to keep it as it is.

> Makefile has the line:
> 
> # flag for SSL support
> USE_SSL    = 1
> 
> However setting USE_SSL = 0 does not prevent the openssl libraries from being used.  Same issue with USE_CRYPT.
>  You have to comment them out.
> 
> Lines 76-85 of Makefile should be replaced with this:
> 
> ifdef USE_SSL
> ifneq ($(USE_SSL), 0)
> CFLAGS += -DHAVE_SSL
> LIBS += -lssl
> endif
> endif
> 
> ifdef USE_CRYPT
> ifneq ($(USE_CRYPT), 0)
> CFLAGS += -DHAVE_CRYPT
> LIBS += -lcrypt
> endif
> endif

The original idea was that one outcomments the whole line, like

#USE_SSL = 1

which always worked, but I agree that your solution is more general, so I changed the official Makefile. Thanks for 
that.
  66827   Tue May 18 21:17:35 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Stefan Ritt wrote:

Ok, now I got it! The problem was that you used "Guest menu commands = ..." and I did not. So the behavior is different with that option, which is why I could not reproduce your problem initially. Now I could reproduce it and the cleanest fix is this:
--- elogd.c     (revision 2294)
+++ elogd.c     (working copy)
@@ -15704,7 +15704,7 @@
          fgets(pwd, sizeof(pwd), stdin);
          while (pwd[strlen(pwd) - 1] == '\n' || pwd[strlen(pwd) - 1] == '\r')
             pwd[strlen(pwd) - 1] = 0;
-      } else if (status != 200 && status != 302) {
+      } else if (status != 200 && status != 302 && status != 404) {
          xfree(buffer);
          *strchr(str, '?') = 0;

which is just accept the 404 response and not abort the cloning process.


Yup. My settings are:
Guest menu commands = List, Last 10, Find, Login, Help
Guest List Menu commands = List, Last 10, Find, Login, Help

Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?

-- rouilj
  66828   Wed May 19 09:57:50 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:
Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?


Well, why don't you give it a try and let me know if the is any problem left?
  66829   Thu May 20 03:37:59 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Stefan Ritt wrote:

John Rouillard wrote:
Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?


Well, why don't you give it a try and let me know if the is any problem left?


Sorry to report that it fails same as originally with:
  Received invalid response from elogd server at http://example.org:8080/Discussion/

However there was a fuzz of 12 lines when I applied the patch, but I think it got the right line.

-- rouilj
  66830   Thu May 20 04:33:07 2010 Reply A. Martinamartin@example.comBug reportAllsvnRe: attachment filename bug & Makefile issue


> > If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt."  Also, this effects
> > the file's displayed "Uploaded" time.  It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"
> 
> Arghh! Why did you choose such a filename? This is the ELOG internal file format, which is YYMMDD_HHMMSS_name.ext. 
> For internal reasons (mainly for synchronization) the system checks every file name, and if it contains 6 numbers 
> followed by a "_" followed by 6 other numbers it thinks it's a valid date/time and uses that. Your time is however 
> 0.0.0000, that's why it gets converted to some date in 1999. Do you absolutely need this functionality? While I can 
> easily remove the interpretation of the date, it would break the synchronization functionality and I would have to 
> find some other method to pass the file date/time, which would be quite some work. So if it's not too important for 
> you, I would like to keep it as it is.
> 

Thank you for your response.  

I can certainly use another filename, but I'm curious why elog doesn't convert the filename "000000_000000_file.txt" to
"YYMMDD_HHMMSS_000000_000000_file.txt" when it gets uploaded.  All other files are automatically prepended with this
string.  Manually renaming the file and then editing the elog entry via text editor seems to fix the file.

thanks,
amartin
  66847   Sat Jun 12 05:55:39 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:

Sorry to report that it fails same as originally with:
  Received invalid response from elogd server at http://example.org:8080/Discussion/


I pulled svn revision 2299 from svn and built it on both server and client side. It is working
properly now.

Thanks for the patch.

-- rouilj
  66857   Thu Jul 22 16:59:00 2010 Warning Chuck BrostBrost_chuck@solarturbines.comBug reportWindows2.7.8More adventures with SSL

Stefan,

Everything has been working great since we last spoke (Version 2.7.8), until InfoSec decided to change how the Certs were created.  Now they come with a little bit of code in the .key file before the Hash.. when I put the new .CRT and .KEY in the SSL folder I am asked on starting Elogd to provide a "PEM PassPhrase".  As you can expect, if you do not enter one, or the incorrect one, it does not just turn off SSL, it exits the program.  The key begins like this in the new versions:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,ACF4A8B263EAA51D

(that little encode piece on the end is not the actual one in the key.  I am assuming it is a passphrase key so it will know what the right passphrase is that should be entered.

We are assuming that this is the "Install password" they have set up to use to install the certs on all of the IIS servers we have.  If that is indeed the case.. Does elog save this passphrase somewhere?  does Elog save it in the registry? does it save it encrypted? Or with access security permissions set on the keys?  I have a feeling that the answer to most of this is probably "no", but to know where we go from here, that is the place to start.

Thanks

Chuck

  66862   Wed Jul 28 16:38:07 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportWindows2.7.8Re: More adventures with SSL

Chuck Brost wrote:

Stefan,

Everything has been working great since we last spoke (Version 2.7.8), until InfoSec decided to change how the Certs were created.  Now they come with a little bit of code in the .key file before the Hash.. when I put the new .CRT and .KEY in the SSL folder I am asked on starting Elogd to provide a "PEM PassPhrase".  As you can expect, if you do not enter one, or the incorrect one, it does not just turn off SSL, it exits the program.  The key begins like this in the new versions:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,ACF4A8B263EAA51D

(that little encode piece on the end is not the actual one in the key.  I am assuming it is a passphrase key so it will know what the right passphrase is that should be entered.

We are assuming that this is the "Install password" they have set up to use to install the certs on all of the IIS servers we have.  If that is indeed the case.. Does elog save this passphrase somewhere?  does Elog save it in the registry? does it save it encrypted? Or with access security permissions set on the keys?  I have a feeling that the answer to most of this is probably "no", but to know where we go from here, that is the place to start.

Thanks

Chuck

The pass phrase should not be stored anywhere for security reasons. Actually ELOG cannot stored it encrypted, because strong encryption is a one-way encryption which cannot be reverted, so ELOG would have to store it in plain text, which is not good. Actually all SSL web servers have this problem. See for example:

http://www.akadia.com/services/ssh_test_certificate.html

In Step 3 they tell you how to remove the pass phrase for Apache. The same holds true for ELOG.

ELOG V3.1.5-3fb85fa6