| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66661
|
Thu Jan 7 21:22:09 2010 |
 | Aaron Couture | acouture@lanl.gov | Bug report | Linux | rev2280 | Re: Problem with CRYPT+SSL and elog command line entries |
| I Aaron Couture wrote: |
|
I have attached a possible patch--basically pirated from elogd.c Because strlcpy needed for the crypt cares about size, do_crypt needed the size, which had not been a concern for base64_encode in elog.c As a result, base64_encode changed slightly as well. I think the implementation places a limit of 32 characters on passwords, which seemed to already be the limit in elogd.c The elog.c limit appeared to be 80 characters. I tested both SSL and SSL+CRYPT for commandline elog entries with both a logbook specific write password as well as username/password combo in a password file.
AJC
I am in the process of setting up a new ELOG logbook. I checked out rev2280 from svn.savannah.psi.ch. I knew I wanted to encrypt passwords, so when I compiled, I used flags
USE_SSL=1
and
USE_CRYPT=1
I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25
Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs. Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.
/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>
Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but
elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine -m Sampleinfo.txt -x -n 1
failed with
Error: Invalid user name or password
I got the same behaviour when I used a logbook with a user/password pair defined in a password file.
When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg
I then recompiled elog with
USE_SSL=1
USE_CRYPT=
And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password). Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true. elogd.c defined different behaviour if USE_CRYPT is defined.
Thanks,
Aaron Couture
|
|
| Attachment 1: elogc.patch
|
64c64
< void base64_encode(char *s, char *d)
---
> void base64_encode(unsigned char *s, unsigned char *d, int size)
66a67
> unsigned char *p;
68c69
< pad = 3 - strlen(s) % 3;
---
> pad = 3 - strlen((char *) s) % 3;
70a72
> p = d;
86a89,90
> if (d - p >= size - 3)
> return;
92a97,106
> void do_crypt(char *s, char *d, int size)
> {
> #ifdef HAVE_CRYPT
> strlcpy(d, crypt(s, "el"), size);
> #else
> base64_encode((unsigned char *) s, (unsigned char *) d, size);
> #endif
> }
>
>
382c396
< char str[256], *ph, *ps;
---
> char str[256], encrypted_passwd[32], *ph, *ps;
422,423c436,437
< base64_encode(passwd, str);
< sprintf(request + strlen(request), "wpwd=%s;", str);
---
> do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "wpwd=%s;", encrypted_passwd);
439,440c453,454
< base64_encode(upwd, str);
< sprintf(request + strlen(request), "upwd=%s;", str);
---
> do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "upwd=%s;", encrypted_passwd);
628c642
< char host_name[256], boundary[80], str[80], *p, *old_encoding;
---
> char host_name[256], boundary[80], str[80], encrypted_passwd[32], *p, *old_encoding;
801c815
< base64_encode(upwd, str);
---
> do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
803c817
< "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, str);
---
> "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, encrypted_passwd);
885,886c899,900
< base64_encode(passwd, str);
< sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", str);
---
> do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", encrypted_passwd);
|
|
66663
|
Fri Jan 8 18:26:56 2010 |
| Aaron Couture | acouture@lanl.gov | Bug report | Linux | rev2280 | Re: Problem with CRYPT+SSL and elog command line entries |
| Aaron Couture wrote: |
|
| I Aaron Couture wrote: |
|
There was some sloppiness in the original patch--__USE_XOPEN wasn't defined, but worked when elog wasn't compiled alone. Now the appropriate ifndef/define statements are in elog.c
I have attached a possible patch--basically pirated from elogd.c Because strlcpy needed for the crypt cares about size, do_crypt needed the size, which had not been a concern for base64_encode in elog.c As a result, base64_encode changed slightly as well. I think the implementation places a limit of 32 characters on passwords, which seemed to already be the limit in elogd.c The elog.c limit appeared to be 80 characters. I tested both SSL and SSL+CRYPT for commandline elog entries with both a logbook specific write password as well as username/password combo in a password file.
AJC
I am in the process of setting up a new ELOG logbook. I checked out rev2280 from svn.savannah.psi.ch. I knew I wanted to encrypt passwords, so when I compiled, I used flags
USE_SSL=1
and
USE_CRYPT=1
I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25
Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs. Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.
/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>
Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but
elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine -m Sampleinfo.txt -x -n 1
failed with
Error: Invalid user name or password
I got the same behaviour when I used a logbook with a user/password pair defined in a password file.
When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg
I then recompiled elog with
USE_SSL=1
USE_CRYPT=
And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password). Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true. elogd.c defined different behaviour if USE_CRYPT is defined.
Thanks,
Aaron Couture
|
|
|
| Attachment 1: elogc.patch
|
26a27,30
> #ifndef __USE_XOPEN
> #define __USE_XOPEN /* needed for crypt() */
> #endif
>
64c68
< void base64_encode(char *s, char *d)
---
> void base64_encode(unsigned char *s, unsigned char *d, int size)
66a71
> unsigned char *p;
68c73
< pad = 3 - strlen(s) % 3;
---
> pad = 3 - strlen((char *) s) % 3;
70a76
> p = d;
86a93,94
> if (d - p >= size - 3)
> return;
92a101
>
182a192,201
>
> void do_crypt(char *s, char *d, int size)
> {
> #ifdef HAVE_CRYPT
> strlcpy(d, crypt(s, "el"), size);
> #else
> base64_encode((unsigned char *) s, (unsigned char *) d, size);
> #endif
> }
>
382c401
< char str[256], *ph, *ps;
---
> char str[256], encrypted_passwd[32], *ph, *ps;
422,423c441,442
< base64_encode(passwd, str);
< sprintf(request + strlen(request), "wpwd=%s;", str);
---
> do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "wpwd=%s;", encrypted_passwd);
439,440c458,459
< base64_encode(upwd, str);
< sprintf(request + strlen(request), "upwd=%s;", str);
---
> do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "upwd=%s;", encrypted_passwd);
628c647
< char host_name[256], boundary[80], str[80], *p, *old_encoding;
---
> char host_name[256], boundary[80], str[80], encrypted_passwd[32], *p, *old_encoding;
801c820
< base64_encode(upwd, str);
---
> do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
803c822
< "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, str);
---
> "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, encrypted_passwd);
885,886c904,905
< base64_encode(passwd, str);
< sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", str);
---
> do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
> sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", encrypted_passwd);
|
|
66669
|
Mon Jan 11 17:10:31 2010 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.7.8 | Re: Any way to paste clipboard into entry? | > > > > Is there any way to directly paste an image from a Windows clipboard into an elog entry page? It's obvious
> > > > for uploading a file, but many of my users say that they never make a file, they just want to paste in an image
> > > > already onscreen.
> > >
> > > This is a limitation of the FCKEditor used inside ELOG, and actually of the whole browser concept under Windows.
> > > There are some extensions to Firefox which let your paste an image as an attachment, but none for doing this right
> > > into the text body. For some discussion about this have a look at
> > >
> > > http://forums.developer.mindtouch.com/showthread.php?t=188
> > >
> > > for example.
> >
> > Hmmm. Well, does that mean that it is easier under Linux? I have to confess I couldn't figure that out either. But
> > I'd be delighted to have Yet Another Reason to tell the users that "it works under Linux, maybe you should switch...."
>
> I'm not sure, but I doubt that it would work under Linux. It's a general security issue: If your browser has free access to
> your clipboard, then what happens if you for example copy-and-paste a password in some application, then forget your password
> in the clipboard, then you surf to a malicious website, and a script on that site grabs your clipboard contents? This would
> be a severe security hole on ANY operating system.
Hi there,
In a linux installation straight out of the box, I can cut-and-paste text from the mailer program (a stand-alone one called
XCmail), from an xterm or similar into elog with no trouble. I've not tried an image, I just attach them as I use plain encoding.
Don't know how it would work if it were on a properly secure linux box. |
|
66671
|
Tue Jan 12 12:31:20 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | rev2280 | Re: Problem with CRYPT+SSL and elog command line entries |
| I Aaron Couture wrote: |
|
I have attached a possible patch--basically pirated from elogd.c Because strlcpy needed for the crypt cares about size, do_crypt needed the size, which had not been a concern for base64_encode in elog.c As a result, base64_encode changed slightly as well. I think the implementation places a limit of 32 characters on passwords, which seemed to already be the limit in elogd.c The elog.c limit appeared to be 80 characters. I tested both SSL and SSL+CRYPT for commandline elog entries with both a logbook specific write password as well as username/password combo in a password file.
|
Great! Thanks a lot for your patch. I appreciate if people not only come up with problems, but have already the solution. I committed your patch to the distribution, so it will be included in the next version.
- Stefan |
|
66675
|
Wed Jan 13 10:59:44 2010 |
 | David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 2.7.8 | Proxy Error | Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
it is connected with the html coding? |
|
66677
|
Wed Jan 13 11:15:10 2010 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 2.7.8 | Re: Proxy Error | > Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> it is connected with the html coding?
Hi Stefan,
I now cannot even reply to you in the message id thread; I keep getting:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /elogs/Forum/.
Reason: Error reading from remote server
Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
Proxy Error, then that certainly will be something to do with the html coding.
And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
emails? |
|
66678
|
Wed Jan 13 11:17:39 2010 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 2.7.8 | Re: Proxy Error | > > Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> > without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> > it is connected with the html coding?
> Hi Stefan,
>
> I now cannot even reply to you in the message id thread; I keep getting:
>
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request POST /elogs/Forum/.
>
> Reason: Error reading from remote server
>
> Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
>
> It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
>
> However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
> Proxy Error, then that certainly will be something to do with the html coding.
>
> And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
> emails?
That is interesting. I can make 1 (one) submission to a thread which uses html coding, then I get hit by proxy errors.
But I can edit, play around or whatever if it is in plain coding. Yet to see how many emails were generated... |
|
66679
|
Wed Jan 13 11:19:59 2010 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 2.7.8 | Re: Proxy Error | > > > Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> > > without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> > > it is connected with the html coding?
> > Hi Stefan,
> >
> > I now cannot even reply to you in the message id thread; I keep getting:
> >
> > Proxy Error
> >
> > The proxy server received an invalid response from an upstream server.
> > The proxy server could not handle the request POST /elogs/Forum/.
> >
> > Reason: Error reading from remote server
> >
> > Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
> >
> > It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
> >
> > However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
> > Proxy Error, then that certainly will be something to do with the html coding.
> >
> > And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
> > emails?
>
> That is interesting. I can make 1 (one) submission to a thread which uses html coding, then I get hit by proxy errors.
> But I can edit, play around or whatever if it is in plain coding. Yet to see how many emails were generated...
Hi Stefan,
I only got one email in response to the second entry of this thread, no email was received after the edit of the entry. The
next email received was due to the third entry of this thread. |
|