Timebombs in testsuite

[Andreas Metzler]

Hello,

I have just seen that 2.8.4 cannot be built (well checked) successfull
anymore, since a certificate expired 2009-10-19. (This is fixed in
2.8.5 prerelease). I think this is the third time something like this
happened, and browsing over the buildlog the next instances will happen
soon:

Certificate 0: subject `C=US,ST=New Jersey,L=Weehawken,O=Citigroup,OU=whg-oak6,CN=www.citibank.com', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using RSA-SHA, activated `2008-08-29 00:00:00 UTC', expires `2010-08-29 23:59:59 UTC', SHA-1 fingerprint `8b410d9cf13f191596a65f1f77580ddfa37aba49'

        Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
        Adding certificate 2...done

        Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
        Adding certificate 1...done

        Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'

Can these be handled proactively before they actually break?

thanks, cu andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Andreas Metzler <ametzler@...> writes:

> Hello,
>
> I have just seen that 2.8.4 cannot be built (well checked) successfull
> anymore, since a certificate expired 2009-10-19. (This is fixed in
> 2.8.5 prerelease). I think this is the third time something like this
> happened, and browsing over the buildlog the next instances will happen
> soon:
...
> Can these be handled proactively before they actually break?

Good point.  I'm thinking of using something like the patch below.
Thoughts?

/Simon

diff --git a/tests/chainverify.c b/tests/chainverify.c
index 19b27eb..13d4710 100644
--- a/tests/chainverify.c
+++ b/tests/chainverify.c
@@ -32,6 +32,21 @@
 #include <gnutls/gnutls.h>
 #include <gnutls/x509.h>
 
+/* GnuTLS internally calls time() to find out the current time when
+   verifying certificates.  To avoid a time bomb, we hard code the
+   current time.  This should work fine on systems where the library
+   call to time is resolved at run-time.  */
+time_t
+time (time_t *t)
+{
+  time_t then = 1256803113;
+
+  if (t)
+    *t = then;
+
+  return then;
+}
+
 /* *INDENT-OFF* */
 
 /* Triggers incorrect verification success on older versions */


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Andreas Metzler]

On 2009-10-29 Simon Josefsson <simon@...> wrote:
> Andreas Metzler <ametzler@...> writes:
[cert expiry timebomb]
> ...
> > Can these be handled proactively before they actually break?

> Good point.  I'm thinking of using something like the patch below.
> Thoughts?

> /Simon

> diff --git a/tests/chainverify.c b/tests/chainverify.c
> index 19b27eb..13d4710 100644
> --- a/tests/chainverify.c
> +++ b/tests/chainverify.c
> @@ -32,6 +32,21 @@
>  #include <gnutls/gnutls.h>
>  #include <gnutls/x509.h>

> +/* GnuTLS internally calls time() to find out the current time when
> +   verifying certificates.  To avoid a time bomb, we hard code the
> +   current time.  This should work fine on systems where the library
> +   call to time is resolved at run-time.  */
> +time_t
> +time (time_t *t)
> +{
> +  time_t then = 1256803113;
> +
> +  if (t)
> +    *t = then;
> +
> +  return then;
> +}
> +
>  /* *INDENT-OFF* */

>  /* Triggers incorrect verification success on older versions */

Works for me. Applied and uploaded to Debian.

thanks, cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel