Dependency provenance concerns

[renatoathaydes]

Hello, I am writing on behalf of my employer: https://curity.io/ (our former CEO, Travis, has previously contributed to this project).

We use java-webauthn-server in our product and wanted to ask a few questions about this project's dependencies.

As of version 2.6.0, this project depends on these libraries:

+--- com.upokecenter:cbor:4.5.6
|    +--- com.github.peteroupc:numbers:1.8.2
|    \--- com.github.peteroupc:datautilities:1.1.0

They do not seem to be owned by Yubico or any other related business, they are all authored by the same person: https://github.com/peteroupc

I could not find if there exists any relationship between them and Yubico, hence we would like to understand if you've been able to establish a trust relationship with them or verify their code.

As a fellow security company, we care deeply about our dependencies and hope that you do not mind us inquiring.

Thanks for your attention.

[emlun]

Hi! These were originally "inherited" from a dependency on COSE-JAVA. The COSE-JAVA dependency itself was dropped in version 2.5.1, but the com.upokecenter:cbor dependency remains since the library still needs to process CBOR and CBOR isn't as trivial to re-implement as the few COSE-JAVA features we were using. COSE-JAVA is maintained by the IETF COSE WG, so our trust in com.upokecenter:cbor extends originally from that. I have to admit we have not done a thorough review of com.upokecenter:cbor itself.

[renatoathaydes]

Thanks for the answer, that's very helpful.

I had a look at https://cbor.io/impls.html and the currently recommended library is indeed com.upokecenter:cbor.

While this project's license seems to match the BSD-2 license (correct?), the dependencies I mentioned above use UNLICENSE, which is not as widely known. This may also affect the usability of this project, I believe. We're investigating how to handle these issues, will let you know if we find anything relevant.

I've noticed that Jackson also support CBOR now: https://github.com/FasterXML/jackson-dataformats-binary

Would you be open for a contribution to attempt to replace com.upokecenter:cbor with com.fasterxml.jackson.dataformat:jackson-dataformats-binary (which uses Apache 2.0 license), given that this project already depends on Jackson libraries?

[emlun]

Would you be open for a contribution to attempt to replace com.upokecenter:cbor with com.fasterxml.jackson.dataformat:jackson-dataformats-binary (which uses Apache 2.0 license), given that this project already depends on Jackson libraries?

That's certainly a welcome idea, but I'm afraid it's not (fully) possible without a breaking API change, since the AuthenticatorData.getExtensions() method returns Optional<com.upokecenter.cbor.CBORObject>.

It should be possible to replace the implementation everywhere else, though, and transform only this particular return value to com.upokecenter.cbor.CBORObject. com.upokecenter:cbor would remain a compile-time API dependency, but would not be invoked at runtime unless that method is called.

I wouldn't like having to keep (possibly) two versions of the method until the next major release, but it's certainly worth considering.

So yes, you are certainly welcome to contribute towards the initiative! Note however that I can't promise anything about the eventual resolution - we may reject part or all of it in the end, and we might not (yet) be able to fully eliminate the dependency.

[renatoathaydes]

Oh good to know that. If that CBORObject class is simple enough, it may be possible to copy just that class into this project to avoid having a full dependency on the library.... given that is licensed under UNLICENSE I suppose that's not against the terms?! And then on a major release, you can remove that or replace that type.

I will try to find time to study this idea.