(ITS#5073) Syncrepl spinlock
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.3.37
OS: Linux
URL:
Submission from: (NULL) (71.202.148.128)
If you create a syncrepl master that serves the "" base, and then set up a
syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on
the master, the replica will sit at 100% CPU, endlessly trying to add nothing.
--Quanah
15 years, 1 month
(ITS#5072) Possibly incorrect certificateExactAssertion()
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.35)
Submitted by: ando
A certificate in certificateExactAssertion GSER form should be something like
(wrapped for readability)
{
serialNumber 3,
issuer rdnSequence:email=ca@example.com,cn=example ca,o=example,st=xx,c=us
}
according to RFC4523 & RFC3687, as far as I understand it. However, OpenLDAP
HEAD uses the form
{
serialNumber 3,
issuer "email=ca(a)example.com,cn=example ca,o=example,st=xx,c=us"
}
Note the quotes around the DN and the missing "rdnSequence:" prefix.
p.
15 years, 1 month
Re: (ITS#5069) SyncRepl on request
by bgmilne＠staff.telkomsa.net
On Wednesday 01 August 2007 23:53:22 hadmut(a)danisch.de wrote:
> Full_Name: Hadmut Danisch
> Version: 2.3.35
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (85.180.64.215)
>
>
> This is an enhancement request:
>
> When having a distributed LDAP structure with a master and several SyncRepl
> clients, the clients can do the SyncRepl only on fixed refresh intervals
> (e.g. type=refreshOnly,
> interval=00:00:20:00)
>
> However, there are many situations where this is inappropriate, e.g. on
> dial-on connections, roaming notebooks, and things like that.
>
> Therefore, slapd should have a client mode where the SyncRepl process is
> performed only on request, but then immediately. There should be an
> external trigger to pull, e.g. send a signal oder do a special LDAP
> request. slapd should then start a SyncRepl.
>
> E.g. this could be put in scripts run at connect-time (pppd provides that
> kind of scripting), or when notebook autoconfiguration detects (e.g. with
> tools like guessnet) that it is connected to the home network to update
> it's local slapd.
While I'm not saying this feature should not be implemented, I note that there
are other solutions for doing off-line authentication on (e.g.) laptops that
don't expose the whole DIT (but only credentials that have already been used
on the client).
15 years, 1 month
Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it
Kurt Zeilenga wrote:
> This and other RFC 4511 BER restrictions do not apply to
> BER/DER-encoded attribute values, such as certificates.
A cleaner and simpler solution is in HEAD for those serials that fit
into a long long, when it's available. Otherwise, arbitrary precision
support is required (OpenSSL's bignum, GNU's GMP or so).
Please test.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 1 month
Re: (ITS#5071) ;binary issue
by kurt＠OpenLDAP.org
On Aug 2, 2007, at 11:01 PM, ando(a)sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD/re23
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (81.72.89.40)
>
>
> I've noticed an issue related to operating on certificates with/
> without ;binary,
> as detailed in the table below
>
> slapadd filter requested attrs
>
> | ;binary | no ;binary | ;binary |
> no ;binary
> -------------+--------------+--------------+--------------
> +---------------
> ;binary | results | results | returned | returned
> -------------+--------------+--------------+--------------
> +---------------
> no ;binary | no results | results | not returned | returned
>
> So it seems that if data is loaded with ;binary then search
> operations work
> regardless of having specified ;binary in search filters or in
> requested
> attributes, while if data is loaded without, then search operations
> only work if
> ;binary is omitted. RFC 4523 states that ;binary MUST be used when
> transferring
> certificates, so perhaps slapd should be either liberal enough to
> allow any
> combination, or strict enough to prevent those data types from
> working without
> ;binary.
The bug is in allowing a certificate to be loaded without ;binary.
-- Kurt
15 years, 1 month
(ITS#5071) ;binary issue
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
I've noticed an issue related to operating on certificates with/without ;binary,
as detailed in the table below
slapadd filter requested attrs
| ;binary | no ;binary | ;binary | no ;binary
-------------+--------------+--------------+--------------+---------------
;binary | results | results | returned | returned
-------------+--------------+--------------+--------------+---------------
no ;binary | no results | results | not returned | returned
So it seems that if data is loaded with ;binary then search operations work
regardless of having specified ;binary in search filters or in requested
attributes, while if data is loaded without, then search operations only work if
;binary is omitted. RFC 4523 states that ;binary MUST be used when transferring
certificates, so perhaps slapd should be either liberal enough to allow any
combination, or strict enough to prevent those data types from working without
;binary.
p.
15 years, 1 month
Re: (ITS#5070) Issues in X.509 certificate parsing
by kurt＠OpenLDAP.org
On Aug 2, 2007, at 10:48 PM, ando(a)sys-net.it wrote:
> ando(a)sys-net.it wrote:
>
>> I've an issue with X.509 certificate parsing in HEAD/re24. The
>> certificate,
>> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa
>> and HEAD fails
>> to parse it because it is an integer with length equal to 9, which
>> is larger
>> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:
>> 254. The DER
>> encoded value is: 2 9 0 200 91 154 221 234 191 249 250.
>> Seems to be time
>> to get past the sizeof(ber_int_t) limitation...
>
> ... which would violate RFC 4511 where it states that INTEGER means
> from
> 0 up to 2^31-1...
This and other RFC 4511 BER restrictions do not apply to
BER/DER-encoded attribute values, such as certificates.
> I have a simple solution for this problem, at the
> cost of partially violating rfc 4523: if an integer is larger than
> 2^31-1, it could be represented in the certificateExactMatch
> normalization in hexadecimal form, much like OpenSSL does. This would
> increase interoperability with OpenSSL and be at least self-
> consistent,
> since all serialNumbers that large would be consistently expanded that
> way. Another solution, preserving the decimal representation, would
> probably require some arbitrary precision support from external
> libraries. If there's consensus, I'd post my simple patch.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati(a)sys-net.it
> ---------------------------------------
>
>
>
15 years, 1 month
Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate,
> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails
> to parse it because it is an integer with length equal to 9, which is larger
> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER
> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time
> to get past the sizeof(ber_int_t) limitation...
... which would violate RFC 4511 where it states that INTEGER means from
0 up to 2^31-1... I have a simple solution for this problem, at the
cost of partially violating rfc 4523: if an integer is larger than
2^31-1, it could be represented in the certificateExactMatch
normalization in hexadecimal form, much like OpenSSL does. This would
increase interoperability with OpenSSL and be at least self-consistent,
since all serialNumbers that large would be consistently expanded that
way. Another solution, preserving the decimal representation, would
probably require some arbitrary precision support from external
libraries. If there's consensus, I'd post my simple patch.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 1 month
(ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
I've an issue with X.509 certificate parsing in HEAD/re24. The certificate,
according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails
to parse it because it is an integer with length equal to 9, which is larger
than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER
encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time
to get past the sizeof(ber_int_t) limitation...
p.
15 years, 1 month
