On Fri, 28 Jan 2022 15:44:16 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: >> >>> 708: * Signature Schemes</a> section of the Java Cryptography >>> 709: * Architecture Standard Algorithm Name Documentation, and may also >>> 710: * include other signature schemes that the provider supports. >> >> There doesn't seem to be anything preventing a user from setting a bogus >> signature scheme (ex: named "foo") - which is neither a standard name or a >> provider specific name. >> I think the method may be too tightly specified, and you should make this >> more general and not put any constraints on the names of the signature >> schemes. (Although we should still link to the specification for a list of >> standard names). >> >> It would be useful to explain when this method returns pre-populated scheme >> names as supported by the underlying provider and when it may return an >> empty list. > > You should also define the interaction with the system properties (probably > as an @implNote). Does `getSignatureSchemes` ever return the value of the > system properties? Does the `setSignatureSchemes` API always override the > properties even if it is called by the provider? I asked a similar question about the System property interaction in the CSR and he has some answers there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252
