| 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);
|
|
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 |
|
954
|
Sun Feb 20 15:30:04 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | Linux | 2.5.7 | Re: Problem with 'Show Attributes' option | > There is a problem with the 'Show Attributes' option
> causing the 'Format ...' options to be ignored.
>
> See attachment for patch.
Thanks a lot. I applied your patch and committed the changes to CVS. |
|
66712
|
Thu Feb 18 13:21:15 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
|
66713
|
Thu Feb 18 15:37:07 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.
Soren |
|
66749
|
Fri Mar 12 09:27:25 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.
Soren
|
Indeed it was the JavaScript line
if (document.form1.Number.value != '- garder les valeurs d'origine -') {
which caused the trouble. The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to
if (document.form1.Number.value != "- garder les valeurs d'origine -") {
and now it should work fine. |
|
66759
|
Sun Mar 14 20:57:26 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.
Soren
|
Indeed it was the JavaScript line
if (document.form1.Number.value != '- garder les valeurs d'origine -') {
which caused the trouble. The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to
if (document.form1.Number.value != "- garder les valeurs d'origine -") {
and now it should work fine.
|
Thanks a lot for changing that. Now French should work as well.
Soren |
|