Releases?

[babisRoutis]

Are there any plans for publishing releases to maven central?

[JesusMcCloud]

While proper releases of this library would be preferable, we've incorporated the PKI part into WARDEN/WARDEN-roboto (both of which are on maven central) as a stop-gap solution. While you won't get the flashy new parser, we are working towards full support for that too.

[babisRoutis]

While proper releases of this library would be preferable, we've incorporated the PKI part into WARDEN/WARDEN-roboto (both of which are on maven central) as a stop-gap solution. While you won't get the flashy new parser, we are working towards full support for that too.

Dear @JesusMcCloud
Thank you for your reply. Roboto is under my radar 😄

[JesusMcCloud]

@babisRoutis KMP client code integrated with server-side validation just dropped: https://github.com/a-sit-plus/warden-supreme

[babisRoutis]

@babisRoutis KMP client code integrated with server-side validation just dropped: https://github.com/a-sit-plus/warden-supreme

Hi @JesusMcCloud
Thanks for this

FYI here

[sethmoo]

There are still a few features we're working on before we stamp a release.

The primary is a "quirks mode". In this mode, the verifier will allow for certain variances from the "ideal" certification chain. This is for clients that need to accept older devices that predate our more rigid key attestation verification tests that OEMs must adhere to (since Android 13).

@suzannajiwani is working on the quirks mode, and I think we'll be ready to publish a release along with a maven package after that lands.

[arontomori]

Hi,

Is there any update on the planned release and Maven Central publication of this library?

The last comment mentioned that the remaining work was the "quirks mode" implementation for older devices. Do you have an approximate timeline for the release, or is there perhaps a snapshot artifact available in the meantime?

Thanks!

[JesusMcCloud]

Some Quirk handling is already in the Code, and many other improvements landed since October, but it seems there are still open discussion points to be handled before a release (see #63).

Disclaimer: I am not affiliated with the Android team, just observing public activity on GitHub and occasionally analysing the code. Hence, I have no problem with shamelessly advertising our ready-to-use solution that you can find on maven central already 😉. It includes the PKIX cert path validator from this repo and is even more reobust wrt. handling botched attestation proofs.

[silvicir]

Hi there! Any updates?

[scordio]

Hi all, here is another interested party in having this library published on Maven Central 🙂

[sethmoo]

We've had a non-stop slow trickle of "just one more change" thinking on our end that has delayed the release.

Here's the plan:

1. @carmenyh will release an 0.9 Maven artifact ASAP. The library is stable and works. We hit it with a fair bit of QPS internally and are happy with the quality so there's no reason not to publish an artifact now so folks don't have to keep building from source.
2. 1.0 will be released "soon" after. The primary reason for the delay is that we're making a few changes that we want to bake for a bit in production. Once we're satisfied the metrics look good, we'll publish the 1.0. Note that there will almost certainly be a minor API change from 0.9 -> 1.0.

[scordio]

1.0 will be released "soon" after.

We currently have our "home-made" implementation (in Java) that we would like to replace with this library. I'd be happy to provide feedback on integrating 0.9 (once released) into our Java application and report back any friction we might spot.

If you aren't in a rush for 1.0, I'll only be able to provide feedback in the second half of August due to the summer holidays.

[sethmoo]

Working on it... #99

Releasing a Google-signed package is new to our team, so please have patience as we sort things out.

[KarolyNevelos]

Together with @scordio we tried to integrate the library into our existing Java library, and we have the following feedback:

• Is it possible to aim for a lower java version, than 21? Our current project is using java 11 only
• Is there any chance to change the api to use standard java Supplier functional interface? In that way we could avoid adding the kotlin-stdlib as a compile dependency.