Added the following

[darkedges]

Added the following

• excludeCNFromSans to provide the same functionality as the UI to bypass an issue I am having with HC Vault Sign operation and SubjectDN greater than 63 characters in CSR
  Updated the following tests to remove the issues reported by Checkstyle
• AuthBackendTokenTests
• TransitApiTest

This relates to

• missing option exclude_cn_from_sans when requesting a signed certificate #244
• using a CN of length >65 throws an idna: invalid label error hashicorp/vault#11721

[edmundham]

Hello vault-java-driver team, can someone look into merging this and have this released?

[steve-perkins]

I was the primary (almost sole) contributor to this project when I worked at BetterCloud, but I resigned from there in late 2019. Initially there was discussion about a transition plan, but then a funny little thing happened in early 2020...

By the time the world settled back down, there had been a lot of turnover, and I just no longer had the connections at BetterCloud that I once did. My sense is that there is no interest there in continuing this without me driving it. And I have no personal interest in maintaining a fork, because my only use of Vault these days is by way of Vault Agent Injector in a Kubernetes environment.

My recommendation would be to either:

1. Migrate to Vault Agent Injector, if that's an option for your use case,
2. Migrate to Spring Vault, if you are open to Spring (it MAY be possible separate the pure Vault bits from the Spring dependency, I'm not sure), or
3. Just fall back to interacting with the Vault through vanilla REST calls.

Of course, the community launching a fork is also an option. But I think you'd be on your own, with no one upstream either blessing or opposing it.

[edmundham]

@steve-perkins , thank you so much for your fast reply. I'll definitely look for the other options then :)

[tledkov]

@henryx
@darkedges
I've forked the project as io.github.jopenlibs:vault-java-driver - as the first project of the simple github organization https://github.com/jopenlibs.

Now I really need in small bugfix and few simple improvements.
Also I'll provide write/maintain rights for any developer who interest in the project. I guess it is better than a lot of individual forks with short life time. It seems to me that the advantage of the organization is that when changing the developer, it will not be necessary to change the group of deployed artifacts.

@steve-perkins Do you have any objections? Blessing? A parting word? %)
The library is very useful for integration services run on bare-metal without Kuber hosts, when adding spring dependencies is not an option for a project.

Now I've fixed the issue with /sys/wrapping/unwrap endpoint (it is blocker for my integration) and publish artifacts at the staging repo.

I'm going to release 5.2.0 soon...