User: Password:
|
|
Subscribe / Log in / New account

A longstanding GnuTLS certificate validation botch

A longstanding GnuTLS certificate validation botch

Posted Mar 7, 2014 12:20 UTC (Fri) by nix (subscriber, #2304)
In reply to: A longstanding GnuTLS certificate validation botch by peter-b
Parent article: A longstanding GnuTLS certificate validation botch

Well, yes. The unit tests you'd use in conjunction with this one would be some evil thing that hooked up an LD_PRELOADed malloc() which listened to environment variables to tell it when to report failure ('make the Nth malloc fail', something like that), then iterated through all possible single-malloc-failure cases: probably the wrapper would signal via a special message on stderr or something when the 'Nth malloc' counter got high enough that it was never reached during program execution. Then you'd run your entire testsuite under such a failure-iterator, looking for abnormal failures (coredumps, etc: exit()s are probably expected, except in deep library code), and wait a very very long time.


(Log in to post comments)

A longstanding GnuTLS certificate validation botch

Posted Mar 7, 2014 16:44 UTC (Fri) by jwakely (guest, #60262) [Link]

I've always thought this was a far better solution (but have never actually used it): http://blogs.gnome.org/otte/2007/11/03/robustness-testing/

A longstanding GnuTLS certificate validation botch

Posted Mar 8, 2014 23:13 UTC (Sat) by nix (subscriber, #2304) [Link]

Oh, that's *neat*. You'd need to do a bit more work to make it work for threaded programs, programs with children, network state and the like, but it's still neat!

(I wonder if CRIU could be leveraged for this instead of a simple fork()?)


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds