I guess that this is mine.

Steve, can this be rechecked by OCI, the report is about 1.2.1 which is ancient

Chris, when you have a chance, would you confirm whether or not this problem has
been fixed?

If this hasn't been fixed, can then a regression be delivered? That way it is
much easier to see that this is broken, and when someone has time to work on the
fix, we can clearly see if things are working again

I will simply have to take some guesses as to what the original report means.  At first glance, it appears 
that this might mean that, if SERVER_AND_CLIENT is specified as the SSL authentication method, then 
there is some kind of failure if one tries to perform a set_policy_overrides() on the Quality of Protection for 
an individual Object Reference

I will try to look at it in my spare time and either come up with a variant of an existing test or a completely 
new test.

Spent a little more time looking at this and discussing, and the original report is ambiguous as to 
whether it's talking about the problem occurring from the server or from the client's perspective (or 
both).

It looks like what it wants is to be able to have SERVER_AND_CLIENT specified in the .conf, but then be 
able to get the equivalent of authenticate=NONE on a per-object basis.  Authentication is different from 
QoP, so I think we're talking about tweaking policies related to the Security::EstablishTrust policy.

It doesn't look like there's a test for this in the DOC repo, although there is an example created for the 
TAO Developer's Guide: Security/PolicyControllingApp.  We might be able to massage that example into 
a test.

The only problem I can foresee is that a lot of the SecurityLevel1 and SecurityLevel2 code has been 
foresaken in favor of SecurityLevel3.  But, the SecurityLevel3 implementation isn't as complete as the 
SecurityLevel1/2 code was.

It will take some time to figure out what to do, exactly.