On 2013-09-30 at 22:34 +0100, Jeremy Harris wrote: > On 30/09/13 21:45, Jeremy Harris wrote: > > The testsuite threw me an error for testcase 2025: > > > > tls_require_ciphers invalid: > > gnutls_priority_init(!RSA_AES_256:DES-CBC3-SHA) failed at offset 0, > > "!RSA_AES.." failed: The request is invalid. > > It's possible that something's changed on my test system; > this particular testcase is failing for all the build > versions I've tried so far...
That string doesn't pass gnutls_priority_init() testing for me. This is the only 20?? test using tls_require_ciphers; the others are all "encrypted = ..." checks, which are Exim doing list matching of the string from the middle colon-separated section of tls_in.cipher. It seems strange that this test is unmodified from 2006; I know we ran the GnuTLS tests for the 4.80 release, so any changes caused by switching to GnuTLS priority strings should have been exposed then. Aha, I see that this was a known-broken test at the time: ----------------------------8< cut here >8------------------------------ 2025 is known broken, I thought I'd commented upon it in a previous mail. I saw this when testing before the RC cut and after a little prodding decided to skip it. Previously I thought that it was that we were expanding the available cipher suites, so the previous assumptions within the more restricted set didn't hold. Instead, the new start-up check is revealing that the string used for the test just is not accepted by GnuTLS as a priority string. This is the big backwards-compatibility break. Fortunately, I suspect that very few people ever actually set tls_require_ciphers, so the fallout won't be too bad. But we do need to figure out the idea behind this test so that we can properly test it in the new world order. ----------------------------8< cut here >8------------------------------ So, my fault that this is still lingering. Sorry. Looks like the point of the test was just to confirm that tls_require_ciphers is honoured, so I've no idea what the point behind the conditional expansion of the string is, based upon the source address. For the only _stated_ purpose of the test, you should just be able to pick a new priority string, to reflect the as-of-4.80 state of option parsing, to confirm no regressions beyond the stated compatibility break in 4.80. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
