openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 11 Feb '12

11 Feb '12

Kurt Zeilenga wrote: > > On Feb 10, 2012, at 8:44 AM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: >>> >>>> When searching for Chinese names in the "to:" field under Thunderbird, I see >>>> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >>>> is because the "mail" attribute in core.schema is of type "IA5 String" but the >>>> Chinese name falls outside the character set. >>> >>> No, it's because Thunderbird failed to convert the email address to form >>> expected. It should have applied the "To Ascii" conversion as defined in >>> the EIA and IDNA specs. >> >> Do you mean RFC 3490 to 3492? > > I mean whatever the spec are. I don't follow the either the DNS or email > spaces closely, so I don't know off hand what the specs are... > But I do know enough that international of both rely on applications > encoding UTF-8 into ASCII for use in DNS and Email protocols, and by > extension LDAP. Please give a reference for this statement. Especially how the "To Ascii" conversion should be made. You know that I'm always eager to get things right in web2ldap. It was easy to add the methods sanitizeInput() and formValue() to the relevant plugin class which encodes and decodes to IDNA for domain attributes. Relevant here seems RFCs 5890-5895. Strictly speaking I simply assume here that the LDAP string format is IDNA encoding because the attributes (e.g. 'associatedDomain' etc.) are of LDAP syntax IA5String and so there's no other way to do it. But AFAIK there's no formal spec saying so. Dealing with attribute 'mail' seems to me somewhat more complicated. Yesterday I tried to find relevant RFCs in rfc-index.txt which define the "To Ascii" conversion you mentioned. So far I came up with this for e-mail headers (and in turn e-mail addresses) which uses UTF-8: 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT=27945 bytes) (Updates RFC2045, RFC2822) (Status: EXPERIMENTAL) 5336 SMTP Extension for Internationalized Email Addresses. J. Yao, Ed., W. Mao, Ed.. September 2008. (Format: TXT=48110 bytes) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL) 5337 Internationalized Delivery Status and Disposition Notifications. C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT=36324 bytes) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL) Maybe I'm misreading http://tools.ietf.org/html/rfc5335#section-4.1 but I think they use UTF-8. Coming back on-topic for this ITS I agree that the LDAP syntax for 'mail' should not be changed because it would open a can of worms and the OpenLDAP ITS is definitely the wrong place to define the LDAP string format for Internationalized Email Addresses. Ciao, Michael.

1 0

(ITS#7161) ppolicy pwdFailureTime resolution should be better than 1 second
by jeffreyc＠ucsc.edu 10 Feb '12

10 Feb '12

Full_Name: Jeffrey Crawford Version: 2.4.26 OS: FreeBSD 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (169.233.231.78) Note: The following was copied from my mailing list question and it was suggested that it be made an enhancement request: Hello Everyone, I'm having trouble enforcing our password policy for login attempts within a particular time frame. After looking into the issue a little further it seems to stem from the fact that the operational attribute pwdFailureTime can only resolve time down to the second. so if there are three Bind attempts within a single second we only get a single pwdFailureTime entry for that time. Our policy is geared more to try and prevent brute force attacks since this instance of the ldap server will be available publicly. However someone can continuously try to bind and not lock the account for as many seconds as is defined in the pwdMaxFailure attribute in the policy definition. For example: if the following account locking configs are set pwdMaxFailure: 10 pwdFailureCountInterval: 3600 pwdLockout: TRUE pwdLockoutDuration: 30 If I try to lock my account by providing the incorrect credentials 11 times, it didn't lock if my 11 attempts were shorter than 10 seconds, I then tried 100 in a for loop which finished in 7 seconds, it still didn't lock. I looked at the account and counted the number of pwdFailureTime's and found 7. I then place a one second sleep between each bad bind attempt and low an behold it would lock as expected. Therefore there seems to be a limitation of pwdFailureTime to only resolve down to the second and its inability to store the same time multiple times. I'm not sure if this is expected behavior, but it makes locking policies against brute force attacks more difficult to fend against. I did a quick look to see if there was a way of delaying a incorrect credential bind so it wouldn't return for at least a second, but didn't see one. If such a config exists it might help if someone can point me to it. Thanks Jeffrey Crawford

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by Kurt＠OpenLDAP.org 10 Feb '12

10 Feb '12

On Feb 10, 2012, at 8:44 AM, Michael Ströder wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: >> >>> When searching for Chinese names in the "to:" field under Thunderbird, I see >>> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >>> is because the "mail" attribute in core.schema is of type "IA5 String" but the >>> Chinese name falls outside the character set. >> >> No, it's because Thunderbird failed to convert the email address to form >> expected. It should have applied the "To Ascii" conversion as defined in >> the EIA and IDNA specs. > > Do you mean RFC 3490 to 3492? I mean whatever the spec are. I don't follow the either the DNS or email spaces closely, so I don't know off hand what the specs are... But I do know enough that international of both rely on applications encoding UTF-8 into ASCII for use in DNS and Email protocols, and by extension LDAP. -- Kurt

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 10 Feb '12

10 Feb '12

Kurt(a)OpenLDAP.org wrote: > On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: > >> When searching for Chinese names in the "to:" field under Thunderbird, I see >> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >> is because the "mail" attribute in core.schema is of type "IA5 String" but the >> Chinese name falls outside the character set. > > No, it's because Thunderbird failed to convert the email address to form > expected. It should have applied the "To Ascii" conversion as defined in > the EIA and IDNA specs. Do you mean RFC 3490 to 3492? Could you please give an exact reference to a spec which says something about the local part of e-mail addresses? Ciao, Michael.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by michael＠stroeder.com 10 Feb '12

10 Feb '12

Kurt(a)OpenLDAP.org wrote: > On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: > >> When searching for Chinese names in the "to:" field under Thunderbird, I see >> asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This >> is because the "mail" attribute in core.schema is of type "IA5 String" but the >> Chinese name falls outside the character set. > > No, it's because Thunderbird failed to convert the email address to form > expected. It should have applied the "To Ascii" conversion as defined in > the EIA and IDNA specs. Glancing over RFC 5335 and RFC 5336 the situation is not so clear since there are UTF-8 headers introduced therein. Also both RFCs have status EXPERIMENTAL. Any other specs I should read? Ciao, Michael.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by Kurt＠OpenLDAP.org 10 Feb '12

10 Feb '12

On Feb 7, 2012, at 1:03 PM, alfiej(a)opera.com wrote: > When searching for Chinese names in the "to:" field under Thunderbird, I see > asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This > is because the "mail" attribute in core.schema is of type "IA5 String" but the > Chinese name falls outside the character set. No, it's because Thunderbird failed to convert the email address to form expected. It should have applied the "To Ascii" conversion as defined in the EIA and IDNA specs. There is no need to change the mail attribute or introduce a replacement. Directory applications (including email clients) should just do the proper conversions. Anyways, as Quannah notes, this is an IETF issue, not an OpenLDAP specific issue. -- Kurt

1 0

Re: (ITS#7158) Fix a crash in back-sql
by h.b.furuseth＠usit.uio.no 08 Feb '12

08 Feb '12

On Wed, 8 Feb 2012 20:51:09 GMT, masarati(a)aero.polimi.it wrote: > Can you upload the patch according to > > <http://www.openldap.org/devel/contributing.html#submitting>? No need, I can import it as is. Or if you were thinking of copyright, a 1-line change copying what other backends do is too small to qualify for copyright protection. -- Hallvard

1 0

Re: (ITS#7158) Fix a crash in back-sql
by masarati＠aero.polimi.it 08 Feb '12

08 Feb '12

Can you upload the patch according to <http://www.openldap.org/devel/contributing.html#submitting>? p.

1 0

Re: (ITS#7158) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

--MP_/Wr2d6pq0nQnGt242LBgpB0j Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Atttached a patch that fixes it. --MP_/Wr2d6pq0nQnGt242LBgpB0j Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=0001-back-sql-fix-initialization-of-ODs.patch =46rom 8d912bc51853ff6b060522664383387749b7c9cd Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Timo=3D20Ter=3DC3=3DA4s?=3D <timo.teras(a)iki.fi> Date: Wed, 8 Feb 2012 11:20:15 +0200 Subject: [PATCH] back-sql: fix initialization of ODs MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Timo Ter=C3=A4s <timo.teras(a)iki.fi> --- servers/slapd/back-sql/init.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/servers/slapd/back-sql/init.c b/servers/slapd/back-sql/init.c index f6cf346..055380f 100644 --- a/servers/slapd/back-sql/init.c +++ b/servers/slapd/back-sql/init.c @@ -114,6 +114,7 @@ backsql_db_init( } =20 bd->be_private =3D bi; + bd->be_cf_ocs =3D bd->bd_info->bi_cf_ocs; =20 Debug( LDAP_DEBUG_TRACE, "<=3D=3Dbacksql_db_init()\n", 0, 0, 0 ); =20 --=20 1.7.9 --MP_/Wr2d6pq0nQnGt242LBgpB0j--

1 0

(ITS#7159) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

Full_Name: Timo Teräs Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.235.194) The back-sql crashes on startup with following backtrace: #0 0x0000045655d11efc in config_generic_wrapper () #1 0x0000045655d1187e in read_config_file () #2 0x0000045655d08fb6 in read_config () #3 0x0000045655cffc15 in main () This is because the be_cf_ocs is not initialized properly.

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012