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
