Re: [Bug 932148] Re: Update failed, Have older hardware, OpenAFS and sun-java6
On 2/18/2012 11:41 PM, Tim wrote: Sorry for the delay. Is this still a problem when trying to update? I have not tried the update since the update generated the report. It is not clear what the information in the report was trying to say. lsb_release -a shows: No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 11.04 Release:11.04 Codename: natty Which I thought was done some time ago. but the bug report shows: UpgradeStatus: Upgraded to natty on 2012-02-14 (0 days ago) which says the day of the bug report. I thought I was doing an upgrading to Oneiric. Could it be the upgrade to Natty never completed correctly? --- Ubuntu Bug Squad volunteer triager http://wiki.ubuntu.com/BugSquad ** Changed in: update-manager (Ubuntu) Status: New = Incomplete -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/932148 Title: Update failed, Have older hardware, OpenAFS and sun-java6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/932148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 932148] [NEW] Update failed, Have older hardware, OpenAFS and sun-java6
Public bug reported: While trying an update, the update manager failed, ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: update-manager 1:0.150.5.1 ProcVersionSignature: Ubuntu 2.6.38-13.55-generic 2.6.38.8 Uname: Linux 2.6.38-13-generic i686 NonfreeKernelModules: openafs Architecture: i386 Date: Tue Feb 14 09:57:44 2012 GConfNonDefault: /apps/update-manager/check_new_release_ignore= /apps/update-manager/first_run=false /apps/update-manager/show_details=true /apps/update-manager/window_size=(1272,946) InstallationMedia: Ubuntu 9.10 Karmic Koala - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: update-manager UpgradeStatus: Upgraded to natty on 2012-02-14 (0 days ago) VarLogDistupgradeApttermlog: VarLogDistupgradeHistorylog: VarLogDistupgradeTermlog: ** Affects: update-manager (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 natty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/932148 Title: Update failed, Have older hardware, OpenAFS and sun-java6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/932148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 932148] Re: Update failed, Have older hardware, OpenAFS and sun-java6
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/932148 Title: Update failed, Have older hardware, OpenAFS and sun-java6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/932148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 664007] Re: Do not link with libpcsclite.so.1 but use dlopen() instead
** Also affects: wpasupplicant Importance: Undecided Status: New -- Do not link with libpcsclite.so.1 but use dlopen() instead https://bugs.launchpad.net/bugs/664007 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 664007] Re: Do not link with libpcsclite.so.1 but use dlopen() instead
I agree with Ludovic that the Ubuntu decision to relocate libpcsclite.so from /usr/lib to /lib was made to address a linking problem with wpa_supplicant, without regard to the effects it would have on the rest of the applications that use libpcsclite.so. The fix only solved the linking problem, it did not allow libpcsclite.so to be used, as it needs to communicate with pcscd that still depends on /usr/lib. There appears to be a number of solutions: (1) leave libpcsclite.so in /usr/lib and have wpa_supplicant use dlopen as suggested above, as it appearently does not need the library when loaded witout /usr being present. (2) Move libpcsclite.so to /lib, but also install symlinks from /usr/lib. (2a) If there is a need to have wpa_supplicant actually use libpcsclite.so without /usr being mounted, then pcscd and whatever else it depends on also needs to be move from /usr. -- Do not link with libpcsclite.so.1 but use dlopen() instead https://bugs.launchpad.net/bugs/664007 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
** Package changed: glibc (Ubuntu) = libnss-ldap (Ubuntu) -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libnss-ldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
A memory leak in libnss-ldap over time can cause the nscd process to grow extremely large. For example one nscd process that had been running for three months was using 6GB of swap! The problem is in the original Padl nss-ldap in at least versions 258, 261 and 265. Ubuntu Hardy uses 258, Karmic uses 261, and the Padl current release is 265. The ldap-nss.c do_init() may be called more then once, to initialize an ldap session and save the session in in __session.ls_conn and set the __session.ls_stat = LD_INITIALIZED But it does not check the state to see if has be initialized, and at line 1239: __session.ls_conn = NULL; The attached patch to to the libnss-ldap_261-2.1Ubuntu4 fixes the problem, by testing __session.ls_stat == LD_INITIALIZED The ldap-nss.c also has a patch to call do_close twice that I had previously turned it to Padl and is now in 265. For testing purposes, the patch also adds atexit(do_atexit); and a do_atexit routine to call do_close. This will then cause the last session to be be freed. This make it much easier to use valgrind to check for memory leaks. (in the nscd.c in lib6c the _exit was change to exit so the atexit would be called.) Debug versions of nscd and libnss-ldap where created, and and used with valgrind to track down the memory leaks. Attached is a script used with valgrind. The LD_PRELOAD was needed so dynamic libs would not be unloaded, and valgrind could find the symbol tables. ** Patch added: Don't leak ldap sessions http://launchpadlibrarian.net/41231340/ldap-nss.c.patch -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
** Patch added: Test patch for nscd to help with valgrind http://launchpadlibrarian.net/41231375/nscd.test.patch -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
** Attachment added: test script to us valgrind with nscd http://launchpadlibrarian.net/41231479/valgrind.nscd.exit.sh -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
** Package changed: glibc (Ubuntu) = libnss-ldap (Ubuntu) -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 292971] Re: nscd leaking memory using libnss-ldap
Also reported to original developers as bug #418 http://bugzilla.padl.com/show_bug.cgi?id=418 ** Bug watch added: PADL Bugzilla #418 http://bugzilla.padl.com/show_bug.cgi?id=418 -- nscd leaking memory using libnss-ldap https://bugs.launchpad.net/bugs/292971 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Copy of note sent on 1/8/2009:
Attached are the server cert (auth2.it.anl.gov), the intermediate cert
(f0a38a80.0)
and the CA self signed cert (7651b327.0) a debug version of verify.c
and partial output of an ldapsearch using the debug.c
My patch has been #if 0'ed out at line 151.
Lets refer to the cert chain as A, B and C. The OpenLDAP server (using
OpenSSL)
sends server cert A, intermediate cert B, and CA cert C.
The TLS_CACERT file has B and C.
The clist_size is then 3, and the code in _gnutls_x509_verify_certificate
around lines 443 drop it to 2, leaving the chain as A, B.
The tcase_size is 2.
_gnutls_verify_certificate2 at line 452 is called with cert B and
tcas with B and C and flags 0.
At line 265, find_issuer is called with B. It returns C.
check_is_ca is called at line 297, which fails
because there is no BasicConstraint. The if at 293 looks correct too.
*BUT* if one trusts both B and C, do we need to verify C?
Why does the code arount line 265 not stop after finding that B is in the tcas,
rather then looking for C, and then verifying it?
If I try it again with the TLS_CACERT file with only B,
it also fails because it can not find the issuer of B.
If the code around line 265 was modified if B was found in the tcas,
this shopuld also work.
Simon Josefsson wrote:
Douglas E. Engert deeng...@anl.gov writes:
This is also being submitted to https://bugs.launchpad.net/bugs
Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1,
ldaps: has stopped working. This looks like it is related to
the December changes that are also in gnutls-2.6.3. See attached
patch that should work in both.
ldapsearch -d 1 -H ldaps://...
TLS: peer cert untrusted or revoked (0x82)
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
The OpenLDAP ldap server certificate issued by Verisign is signed by:
Verisign_Intermediate-Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem
which is signed by:
Verisign_Class_3_Public_Primary_Certification_Authority.pem
Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0
Verisign_Class_3_Public_Primary_Certification_Authority.pem
is a self signed version 1 cert issued in 1996, with no extensions.
Do you have a complete chain that triggers this? It will help our
regression test suite.
I don't have f0a38a80.0 on my debian lenny system. Does it also lack a
basicConstraint? Does it use RSA-MDx? If yes, that would explain the
problem.
In lib/x509/verify.c gnutls_x509_crt_get_ca_status is called
but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no
Basic Constraint.
The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for
this return and if it is a self signed cert, will treat it as a CA.
The patch looks like it can be applied to 2.6.3 as well.
The patch seems too permissive to me: the intention is that V1 certs
should be rejected by GnuTLS unless GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
and/or GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are passed as flags.
Internally, GnuTLS by default enables the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag when called via
gnutls_certificate_verify_peers2. So I think GnuTLS should typically
accept this chain.
Indeed, looking at the code that invokes the function you patched:
if (!(flags GNUTLS_VERIFY_DISABLE_CA_SIGN)
!((flags GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) issuer_version == 1))
{
if (check_if_ca (cert, issuer, flags) == 0)
{
gnutls_assert ();
if (output)
*output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID;
return 0;
}
}
It seems that the code you patched should not have been invoked at all
if (flags GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) issuer_version == 1
is true (if I understand the logic correctly..). Could you debug why
this isn't the case? Maybe issuer_version is wrong?
A complete chain to reproduce this will let me debug it too.
/Simon
Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any
platform have no problems with this old cert.
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ,verify.c2009-01-06 14:02:41.0 -0600
+++ verify.c 2009-01-07 17:07:27.0 -0600
@@ -130,11 +130,20 @@
}
}
- if (gnutls_x509_crt_get_ca_status (issuer, NULL) == 1)
+ result = gnutls_x509_crt_get_ca_status (issuer, NULL);
+ if (result == 1)
{
result = 1;
goto cleanup;
}
+ /* Old self signed CA certs may not have basic constrant */
+ else if ((result == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE)
+ (gnutls_x509_crt_check_issuer(issuer, issuer) == 1))
+{
+ gnutls_assert ();
+ result = 1;
+ goto cleanup;
+}
else
gnutls_assert ();
___
Gnutls-devel
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Mathias Gug wrote: @Andy: Could you describe the X509 certs and CA you're using? We were using ldap and Verisign, and the root CA was a V2 from 1999 which signed an intermediate cert that signed the server certs. I submitted to gnutls a few changes to allow for stoping at the intermediate cert which I believe they added. In the meantime, we turned off cert checking, and have now replaced LDAP Verisign certs with certs issued localy. I will send you a copy of the note to gnutls from 1/8/2009 which has the certs. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Mathias Gug wrote: @Andy: Could you describe the X509 certs and CA you're using? We were using ldap and Verisign, and the root CA was a V2 from 1999 which signed an intermediate cert that signed the server certs. I submitted to gnutls a few changes to allow for stoping at the intermediate cert which I believe they added. In the meantime, we turned off cert checking, and have now replaced LDAP Verisign certs with certs issued localy. I will send you a copy of the note to gnutls from 1/8/2009 which has the certs. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Copy of note sent on 1/8/2009:
Attached are the server cert (auth2.it.anl.gov), the intermediate cert
(f0a38a80.0)
and the CA self signed cert (7651b327.0) a debug version of verify.c
and partial output of an ldapsearch using the debug.c
My patch has been #if 0'ed out at line 151.
Lets refer to the cert chain as A, B and C. The OpenLDAP server (using
OpenSSL)
sends server cert A, intermediate cert B, and CA cert C.
The TLS_CACERT file has B and C.
The clist_size is then 3, and the code in _gnutls_x509_verify_certificate
around lines 443 drop it to 2, leaving the chain as A, B.
The tcase_size is 2.
_gnutls_verify_certificate2 at line 452 is called with cert B and
tcas with B and C and flags 0.
At line 265, find_issuer is called with B. It returns C.
check_is_ca is called at line 297, which fails
because there is no BasicConstraint. The if at 293 looks correct too.
*BUT* if one trusts both B and C, do we need to verify C?
Why does the code arount line 265 not stop after finding that B is in the tcas,
rather then looking for C, and then verifying it?
If I try it again with the TLS_CACERT file with only B,
it also fails because it can not find the issuer of B.
If the code around line 265 was modified if B was found in the tcas,
this shopuld also work.
Simon Josefsson wrote:
Douglas E. Engert deeng...@anl.gov writes:
This is also being submitted to https://bugs.launchpad.net/bugs
Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1,
ldaps: has stopped working. This looks like it is related to
the December changes that are also in gnutls-2.6.3. See attached
patch that should work in both.
ldapsearch -d 1 -H ldaps://...
TLS: peer cert untrusted or revoked (0x82)
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
The OpenLDAP ldap server certificate issued by Verisign is signed by:
Verisign_Intermediate-Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem
which is signed by:
Verisign_Class_3_Public_Primary_Certification_Authority.pem
Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0
Verisign_Class_3_Public_Primary_Certification_Authority.pem
is a self signed version 1 cert issued in 1996, with no extensions.
Do you have a complete chain that triggers this? It will help our
regression test suite.
I don't have f0a38a80.0 on my debian lenny system. Does it also lack a
basicConstraint? Does it use RSA-MDx? If yes, that would explain the
problem.
In lib/x509/verify.c gnutls_x509_crt_get_ca_status is called
but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no
Basic Constraint.
The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for
this return and if it is a self signed cert, will treat it as a CA.
The patch looks like it can be applied to 2.6.3 as well.
The patch seems too permissive to me: the intention is that V1 certs
should be rejected by GnuTLS unless GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
and/or GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are passed as flags.
Internally, GnuTLS by default enables the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag when called via
gnutls_certificate_verify_peers2. So I think GnuTLS should typically
accept this chain.
Indeed, looking at the code that invokes the function you patched:
if (!(flags GNUTLS_VERIFY_DISABLE_CA_SIGN)
!((flags GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) issuer_version == 1))
{
if (check_if_ca (cert, issuer, flags) == 0)
{
gnutls_assert ();
if (output)
*output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID;
return 0;
}
}
It seems that the code you patched should not have been invoked at all
if (flags GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) issuer_version == 1
is true (if I understand the logic correctly..). Could you debug why
this isn't the case? Maybe issuer_version is wrong?
A complete chain to reproduce this will let me debug it too.
/Simon
Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any
platform have no problems with this old cert.
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ,verify.c2009-01-06 14:02:41.0 -0600
+++ verify.c 2009-01-07 17:07:27.0 -0600
@@ -130,11 +130,20 @@
}
}
- if (gnutls_x509_crt_get_ca_status (issuer, NULL) == 1)
+ result = gnutls_x509_crt_get_ca_status (issuer, NULL);
+ if (result == 1)
{
result = 1;
goto cleanup;
}
+ /* Old self signed CA certs may not have basic constrant */
+ else if ((result == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE)
+ (gnutls_x509_crt_check_issuer(issuer, issuer) == 1))
+{
+ gnutls_assert ();
+ result = 1;
+ goto cleanup;
+}
else
gnutls_assert ();
___
Gnutls-devel
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Mathias Gug wrote: One workaround is to put all of the CA certs in the trusted CA certificate file. Yes, that is what we have had to do. The real fix is to get the gnutls people to support certificate directories, like OpenSSL. Why the rush to convert to gnutls when it has so many issues. (Licencing issues are low on my list of reasons.) If the system running slapd is on hardy (or intrepid or jaunty) you should also add all of the CA certificates to the server certificate file - this is to workaround a bug where the slapd daemon doesn't send all of the CA certificates to the client. All or just the intermediate certificates? Another issue with gnutls, no intermediate file (or directory) of certificates. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Mathias Gug wrote: One workaround is to put all of the CA certs in the trusted CA certificate file. Yes, that is what we have had to do. The real fix is to get the gnutls people to support certificate directories, like OpenSSL. Why the rush to convert to gnutls when it has so many issues. (Licencing issues are low on my list of reasons.) If the system running slapd is on hardy (or intrepid or jaunty) you should also add all of the CA certificates to the server certificate file - this is to workaround a bug where the slapd daemon doesn't send all of the CA certificates to the client. All or just the intermediate certificates? Another issue with gnutls, no intermediate file (or directory) of certificates. -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Tried the Intrepid version, looks like it works. Thanks. Jamie Strandboge wrote: Dapper through Intrepid have been copied to -proposed now. ** Tags added: verification-needed -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Thanks. Jamie Strandboge wrote: Upstream released 2.4.3 to address both the vulnerability and the known regressions. Reviewing upstream's mailing list shows no regressions so far with this version. I've sync'd Jaunty with 2.4.2-6, which brings its patches in line with upstream 2.4.3, so I am marking Jaunty as 'Fix Released'. I have backported the relevant patches to Dapper through Intrepid, and am testing them now. I will upload them shortly for testing. ** Changed in: gnutls26 (Ubuntu Jaunty) Status: Triaged = Fix Released -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 305264] Re: gnutls regression: failure in certificate chain validation
Thanks. Jamie Strandboge wrote: Upstream released 2.4.3 to address both the vulnerability and the known regressions. Reviewing upstream's mailing list shows no regressions so far with this version. I've sync'd Jaunty with 2.4.2-6, which brings its patches in line with upstream 2.4.3, so I am marking Jaunty as 'Fix Released'. I have backported the relevant patches to Dapper through Intrepid, and am testing them now. I will upload them shortly for testing. ** Changed in: gnutls26 (Ubuntu Jaunty) Status: Triaged = Fix Released -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- gnutls regression: failure in certificate chain validation https://bugs.launchpad.net/bugs/305264 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 314915] [NEW] gnutls fails to use Verisign CA cert without a Basic Constraint
Public bug reported: Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1 ldaps: has stopped working. This looks like it is related to the December changes that are also in gnutls-2.6.3. ldapsearch -d 1 -H ldaps://... TLS: peer cert untrusted or revoked (0x82) ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The OpenLDAP ldap server certificate issued by Verisign is signed by: Verisign_Intermediate- Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem which is signed by: Verisign_Class_3_Public_Primary_Certification_Authority.pem Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0 Verisign_Class_3_Public_Primary_Certification_Authority.pem is a self signed version 1 cert issued in 1996, with no extensions. In lib/x509/verify.c gnutls_x509_crt_get_ca_status is called but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no Basic Constraint. The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for this return and if it is a self signed cert, will treat it as a CA. The patch looks like it can be applied to 2.6.3 as well. Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any platform have no problems with this old cert. ** Affects: gnutls13 (Ubuntu) Importance: Undecided Status: New -- gnutls fails to use Verisign CA cert without a Basic Constraint https://bugs.launchpad.net/bugs/314915 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 314915] Re: gnutls fails to use Verisign CA cert without a Basic Constraint
** Attachment added: T:\gnutls.verify.patch.txt http://launchpadlibrarian.net/20996163/T%3A%5Cgnutls.verify.patch.txt -- gnutls fails to use Verisign CA cert without a Basic Constraint https://bugs.launchpad.net/bugs/314915 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
