| 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 |
|
974
|
Mon Mar 7 16:05:22 2005 |
 | Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | rev. 1.51 | Display <attribute> do erroneously encoded |
Display subject = <b>$subject</b>
is printed to the browser encoded, so that it is diplayed as is.. |
|
982
|
Mon Mar 14 21:11:11 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | rev. 1.51 | Re: Display <attribute> do erroneously encoded | >
> Display subject = <b>$subject</b>
>
> is printed to the browser encoded, so that it is diplayed as is..
I fixed that in revision 1.587. Note however that you should do the formatting
of attributes better using the CSS functionality, since it gives you more
possibilities. See for example the subject of this forum, which has it's own
CSS class "subjname", which has a larger font size. You select your own class like
Format Subject = 0, subjname, subjvalue
in the configuration file. Then add the classes into the CSS file.
Now elog shows each attribute which contains a "<b>" encoded (as HTML). But if you
want to write a subject line like "For bold use <b> in HTML", then the "<b>"
triggers the HTML display, so it is not written as is, which is not what you want in
that case. Since there is no switch "Submit as HTML text" for the attributes, it is
hard for elog to "guess" if you want HTML encoded or not. |
|
1277
|
Mon Jul 18 10:16:35 2005 |
 | Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | rev 1.703 | Display Subject and HTML tags, regression | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
|
1278
|
Mon Jul 18 18:36:32 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | rev 1.703 | Re: Display Subject and HTML tags, regression |
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
this patch should fix the problem .. a little bug still remain, if you insert some allowed HTML tags in the subject this is detected by is_html() so the Display Attribute and the Link is not applied .. the result is that the HTML is working but no elog featur is applied |
|
1286
|
Wed Jul 20 22:28:14 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | rev 1.703 | Re: Display Subject and HTML tags, regression |
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
rev. 1.707 makes it work again  |
|