Marc Becker

According to build logs, `pkcs11-helper 1.22` fails to detect EC support in `OpenSSL 1.1.x` library. `OpenVPN 2.4.4` used `OpenSSL 1.0.x`. @dwmw2 seems to affect Fedora as well (see `build.log` files):...

The `pkcs11-helper`/`OpenSSL` combination in current `OpenVPN 2.5 beta` [releases](https://openvpn.net/community-downloads/) should support EC operations. @uriseja can you (or anyone else with a EC-capable token) verify this fixes the problem? Test exposure...

The *middle* part of this change (use calls to register/set-provider-property/initialize) is now part of [master](/OpenVPN/openvpn/commit/45d9b0210a22353e587c29c5d3c3990346a4a189)/[2.6](/OpenVPN/openvpn/commit/0236518cee65cc3d1da8d57b1d7785ecb2663a23) in a way that does not break when compiled with with `pkcs11-helper` releases before `v1.28`...

@dsommers if the code for the *config restructure* is not too complex, it might be nice use named entities, like `pkcs11-helper` already does internally (can be ignored in an alternative...

Since it's a violation of security (to a varying degree, the file/config may be on an encrypted file system), it may be nice to go the full way of ```...

For me, it just felt like this should behave more like a config option that supports inline PIN data. The triplet (`pkcs11-provider`, `pkcs11-id`, `pkcs11-pin`) is then contained without external dependencies....

OpenVPN uses an [out-of-date](https://github.com/OpenVPN/openvpn-build/pull/110) patch set which is bound to fail when maxing out certain token attribute entries, [16-byte](https://community.openvpn.net/openvpn/ticket/1075) serials being the most common case. This was my [first problem](https://github.com/OpenVPN/openvpn-build/pull/172)...

The [menioned](#issuecomment-459986080) problems with `OpenVPN` should be [fixed](https://community.openvpn.net/openvpn/ticket/1075) by updated patch used in current builds for Windows. Update of included `pkcs11-helper` version also addresses [EC support detection](/OpenVPN/openvpn-build/issues/168) problem and adds...

The Git OAuth2 flow has (currently) no way to properly detect/communicate [token expiration](1408). Using a *personal access token* might for now be the better alternative.

@r-hans after a closer look, the bug you observe here is likely **specific** to the `BitBucket` provider. The code _might_ have an issue with **not** indicating `false` after dummy API...