trustedCertificates from LeshanServerBuilder doesn't allow subtypes of Certificate

[AlexITC]

Problem:

The field LeshanServerBuilder#trustedCertificates doesn't allow to specify subtypes of Certificate, I need to cast my types just to comply with value type.

Solution

Modify the field to type to allow subtypes of Certificate, one way could be to use List<? extends Certificate> trustedCertificates.

We could keep backwards compatibility, in case this is viable, I can upload a pull request with the changes.

[sbernard31]

it sounds a good idea.

I suppose if we change this for trustedCertificates, we also need to change it for certificateChain

I look at the underlying DTLS library (scandium) and it seems that only X509Certificate (and subclasses) was supported.

Maybe we should change List<? extends X509Certificate> trustedCertificates. to be consistent ?

[AlexITC]

Sounds perfect, I'll upload a pull request later.

[AlexITC]

I didn't change the type of trustedCertificates to X509Certificate to not introduce breaking API changes.

[sbernard31]

API break is not really an issue, if we really think the new one is better.

You previously talk about using List instead of Array. Is there any reason to finally use Array ?

I don't know what could be the best choice,

• java keystore returns Arrays,
• but often you want to manipulate it, like in demo and so you go with List.

[AlexITC]

The reason was to not break API compatibility, do you think it would be better to use the list?

I would be happy to switch it.

[sophokles73]

Is there a reason why you would want to change the trust anchor (the argument for using a List instead of an array) once it has been established?
If at all, we should change it to a Set, I guess, since we do not need duplicates in it ...

[sbernard31]

what do you mean by "once it has been established" ?

[sophokles73]

Well, the trust anchor is explicitly configured by a user of the library, i.e. the user establishes the trust anchor by setting the trustedCertificates property. After that, why should it be changed? That would actually be a problem from a security standpoint, wouldn't it?

[sbernard31]

Ok I see.
Don't worry, if we change array to collection, it will just be about builder API not about internal structure. By the way the internal DtlsConnectorConfig.builder make a copy of this so now way to modify it afterwards. (it internally creates an arrayList from the array then recreate an array :))

Often in leshan we use 2 kinds of signature (collection+vargs) for convenience :
(e.g. in LwM2mObject)

 public LwM2mObject(int id, Collection<LwM2mObjectInstance> instances) {
 }
 public LwM2mObject(int id, LwM2mObjectInstance... instances) {
 }

I don't know if is it worth it ?

[sbernard31]

It seems there is no strong reason/opinion to go to collection for now.
So let's keep on array, if this little modification helps scala users. (even if this is a bit strange for java users as the 2 signatures seems to do the same thing in java)

This is not set in stone and could be changed later if needed.
So I will merge #419 soon if there is no objection.

[sbernard31]

Fixed by #419