[11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env

[David Alvarez]

Hi Martin,

Thanks for taking a look.

I assume you mean [1] and [2].

These are not used for registering aliases. [1] is the path used to 
register a new service and [2] is used to register an attribute. They 
both fetch the legacyMap because they can also be used to modify an 
existing value (either the class for an algorithm or the value of an 
attribute).

It seems to me that registering an alias for a service you have not 
registered is a fairly valid scenario (and that is the one mentioned in 
the ticket). But I'm not sure if the other two scenarios should be 
considered too. In theory, only the one registering the service should 
be setting the class or attribute values.

In any case, my opinion can be swayed if other people think we should 
support modifying these through the legacy api too.

David

--
[1] 
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/e872676174c7/src/java.base/share/classes/java/security/Provider.java#l1212
[2] 
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/e872676174c7/src/java.base/share/classes/java/security/Provider.java#l1237

On 2020-09-22 07:44, Martin Balao wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi,
> 
> Thanks for having a look at this.
> 
> On Fri, Sep 18, 2020 at 8:01 PM David Alvarez <alvdavi at amazon.com> wrote:
>> Please review the following patch for 8250787, a p2 present in
>> 11.0.9-oracle we are still missing.
>>
>> webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8250787
>>
>> The problem is related to the registration of aliases in the
>> java.security.Provider. Provider holds two maps, one for services
>> registered using the old Provider.put (legacyMap) method and one for
>> holding services registered with the newer Provider.putService
>> (serviceMap). It seems that has been the case since 1.5, but it was not
>> a problem until recently, as the default services were still added using
>> the old Provider.put. JDK-7092821 [1] changed that, making the default
>> providers use Provider.putService instead of Provider.put, and
>> uncovering this latent problem.
>>
>> The fix is a small one, make sure that parseLegacyPut looks into both
>> maps when adding a new alias. Patch pases jdk tier1 and tier2 and a test
>> is included.
>>
> 
> I've seen that entries from the legacyMap are also retrieved in 2
> additional paths within Provider::parseLegacyPut. Don't we need to get
> the Service from the new map if the previous fails? Looks to me that
> these 2 additional paths are different ways of describing the alias.
> 
> Thanks,
> Martin.-
>