On Sun, Jul 27, 2008 at 10:22:48PM +0200, Petter Reinholdtsen wrote:
> tags 473796 + patch
> thanks
> Here is what I believe is the correct patch to solve this problem. It
> is from upstream. I'm testing this patch in Debian Edu now.
Did you see that this bug is already tagged 'pending'?
--
S
tags 473796 + patch
thanks
Here is what I believe is the correct patch to solve this problem. It
is from upstream. I'm testing this patch in Debian Edu now.
diff -u openldap-2.4.10/debian/patches/series
openldap-2.4.10/debian/patches/series
--- openldap-2.4.10/debian/patches/series
+++ openlda
[Steve Langasek]
> But that is not the definition of 'grave'. *OpenLDAP* is still very
> usable, it just happens to not work in the Debian Edu use case.
OK, I see that point. It only break for those with rules in
slapd.conf to limit access using the SSL bit length.
> I fully intend for this bug
severity 473796 important
thanks
On Sun, Jul 13, 2008 at 08:50:19AM +0200, Petter Reinholdtsen wrote:
> severity 473796 grave
> This issue break Debian Edu completely
But that is not the definition of 'grave'. *OpenLDAP* is still very usable,
it just happens to not work in the Debian Edu use ca
severity 473796 grave
thanks
This issue break Debian Edu completely, as all user logins and LDAP
updates are denied. Because the issue affect other packages, I raise
the severity to grave. In Debian Edu, access to the usre password and
updates require 128 bit encryption, and this is impossible t
--On Monday, June 30, 2008 2:29 PM -0700 Quanah Gibson-Mount
<[EMAIL PROTECTED]> wrote:
--On Monday, June 30, 2008 2:26 PM -0700 Quanah Gibson-Mount
<[EMAIL PROTECTED]> wrote:
This suggests to me that the SSF values haven't been properly
normalized for GNUtls. Doesn't the "128" mean, roughly
--On Monday, June 30, 2008 2:22 PM -0700 Quanah Gibson-Mount
<[EMAIL PROTECTED]> wrote:
--On Sunday, June 29, 2008 1:12 AM -0700 Steve Langasek
<[EMAIL PROTECTED]> wrote:
I.e., the TLS SSF is 32. So no value > 32 will ever work.
This suggests to me that the SSF values haven't been properly
--On Monday, June 30, 2008 2:26 PM -0700 Quanah Gibson-Mount
<[EMAIL PROTECTED]> wrote:
This suggests to me that the SSF values haven't been properly normalized
for GNUtls. Doesn't the "128" mean, roughly, a symmetric cipher with
keylength of 128? Surely the user's "TLSCipherSuite
TLS_RSA_AES
--On Sunday, June 29, 2008 1:12 AM -0700 Steve Langasek <[EMAIL PROTECTED]>
wrote:
I.e., the TLS SSF is 32. So no value > 32 will ever work.
This suggests to me that the SSF values haven't been properly normalized
for GNUtls. Doesn't the "128" mean, roughly, a symmetric cipher with
keylengt
On Thu, Apr 03, 2008 at 12:28:56PM -0700, Quanah Gibson-Mount wrote:
> > ok, more testing, more news:
> >>> now with the slapd 2.4.7 package (with gnutls) this seems to force
> >>> client-certs, too. a TLS query without client-cert won't work - but
> >>> commenting the 'security' line out results
--On Thursday, April 03, 2008 3:41 PM +0200 [EMAIL PROTECTED] wrote:
ok, more testing, more news:
now with the slapd 2.4.7 package (with gnutls) this seems to force
client-certs, too. a TLS query without client-cert won't work - but
commenting the 'security' line out results in working TLS and
ok, more testing, more news:
now with the slapd 2.4.7 package (with gnutls) this seems to force
client-certs, too. a TLS query without client-cert won't work - but
commenting the 'security' line out results in working TLS and working
non-TLS queries.
The default behavior when TLS is enabled is
On Wed, Apr 02, 2008 at 02:34:12AM +0200, [EMAIL PROTECTED] wrote:
> now with the slapd 2.4.7 package (with gnutls) this seems to force
> client-certs, too. a TLS query without client-cert won't work - but
> commenting the 'security' line out results in working TLS and working
> non-TLS queries.
T
ok, more testing, more results ;)
why i wasn't able to get any working setup in my test-setup turned out
to be a very stupid (brown-paperbag-level) user-error - i just missed
that there was an old .ldaprc hanging around... :)
but the initial problem i had in a production setup is still there:
i'
On Tue, Apr 01, 2008 at 07:39:17PM +0200, [EMAIL PROTECTED] wrote:
> lenny amd64
> libgnutls26 2.2.2-1
> doing a TLS query (-Z or -ZZ) will fail:
> ldap_start_tls: Connect error (-11)
Can you try with some more debugging options? Unfortunately the default
error codes from ldapsearch are not ver
Package: slapd
Version: 2.4.7-6.1
lenny amd64
libgnutls26 2.2.2-1
doing a TLS query (-Z or -ZZ) will fail:
ldap_start_tls: Connect error (-11)
gnutls-cli says:
[EMAIL PROTECTED]:~$ gnutls-cli-debug host -p 389
Resolving 'host'...
Connecting to '127.0.1.1:389'...
Checking for TLS 1.1 support..
16 matches
Mail list logo
