Attention is currently required from: Bluca, selvanair.
2 comments:
Patchset:
> But I get the feeling that you are not really interested in any solution that would actually impro […]
There are multiple way that I can see that are better suited to solve the problem of supporting longer username/passwords in OpenVPN. They would have many advantages over the approach that you are trying to force in here. They would have only the one downside of not working with the Azure OpenVPN implementation.
This is not the first patch/protocol change that has been rejected by the OpenVPN maintainers that is in use for the protocol. See the xor patch for another example.
I understand that this is frustrating for you but maybe you should complain to Microsoft instead.
With a pre-a7f80d402f server there was no helpful message with a patched client, so I've now added it.
And while you consider that behaviour completely acceptable and the problem that your patch introduces, I really don't like adding another obscure way an OpenVPN connection can fail. While it might be a not be a big deal for you, you also do not need to debug and support OpenVPN.
The error reporting from a7f80d402f doesn't trigger in any combination.
To trigger the error reporting of a7f80d402f in earlier version you need a client compiled with --enable-pkcs11 against a server without --enable-pkcs1, ie only accepting passwords of 128 bytes or shorter. As these are not common, as you noticed, it took quite a long time to actually this situation being properly recognised and fixed.
To view, visit change 1622. To unsubscribe, or for help writing mail filters, visit settings.