gnutls-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SCM] GNU gnutls branch, master, updated. gnutls_2_11_6-80-gc75ffd3


From: Nikos Mavrogiannopoulos
Subject: [SCM] GNU gnutls branch, master, updated. gnutls_2_11_6-80-gc75ffd3
Date: Wed, 02 Feb 2011 09:21:15 +0000

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU gnutls".

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=c75ffd30e43b1baf7909cb3c190eeb31f1471ce7

The branch, master has been updated
       via  c75ffd30e43b1baf7909cb3c190eeb31f1471ce7 (commit)
      from  b7b633ee1397f6572748d4a291a4c3a30cc7678f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit c75ffd30e43b1baf7909cb3c190eeb31f1471ce7
Author: Nikos Mavrogiannopoulos <address@hidden>
Date:   Wed Feb 2 10:21:05 2011 +0100

    updated README on certificate verifications that fail.

-----------------------------------------------------------------------

Summary of changes:
 tests/x509paths/README |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/x509paths/README b/tests/x509paths/README
index e2e85b2..85532f6 100644
--- a/tests/x509paths/README
+++ b/tests/x509paths/README
@@ -19,14 +19,16 @@ not a real problem.
 Chain 15-18: We should succeed, the reason we don't is that we use
 memcmp for DN comparisons.
 
-Chain 19: I don't understand why this test should fail?  The chain
-seems fine to me.
+Chain 19: This requires advanced verification that we don't support
+yet. It requires to check that this path contains no revocation data.
+We shouldn't make these tests.
 
 Chain 28-29: We fail to check keyCertSign (non-)critical key usage in
 intermediate certificates.  XXX
 
 Chain 31-32: The CRL is issued by a issuer without CRLSign
 (non-)critical keyCertSign.  We don't check the CRL, so this is not a
-real problem.
+real problem. This is easier to be supported now with the trust_list
+that can verify CRLs on addition.
 
 Chain 54-63: We don't check path length constraints properly. XXX


hooks/post-receive
-- 
GNU gnutls



reply via email to

[Prev in Thread] Current Thread [Next in Thread]