On Thu, Sep 22, 2016 at 1:44 PM, David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:

> On 22/09/16 18:43, Selva Nair wrote:
> >
> > Also usernames > 64 bytes will break --username-as-common-name as
> > CN is limited to 64 bytes (could 64 code points, but it seems
> > openvpn interprets that as 64 bytes).
> >
> > So for most practical purposes, pkcs11-id appears to be limited to
> > ~240 bytes characters in the current code. Changing USER_PASS_LEN
> > to, say, 256 may be more sensible. That shouldn't break any
> > existing configs but may break some use cases where a long id is
> > supplied from the command line.
> Thank you for a thorough check-up!
> I have spotted a few places where 'struct userpass' have been declared
> as global variables, like in socks.c, proxy.c and ssl.c.  For

One could replace those static structs with static pointers to the struct
and allocate at first use.

I have no issues to set USER_PASS_LEN to 256 or 1024 or in between as
> long as we are confident we don't break anything.  But I think we
> could clean up several of these global variables too.

Code-wise, I do not think this will break anything. But any number less
than 4096 could potentially break some rare (?) use cases -- e.g.,
passwords/usernames/ids of length > 256 supplied from a file or command
line on clients (and matching server) with USER_PASS_LEN = 4096. At the
same time, anything more than 256 should also increase length of option
lines and option parameters.

I vote for 256.

That said I have no idea how long are typical pkcs11-ids. And, if pkcs11
URI is adopted, the string could get arbitrarily large depending on how
many attributes are included in the URI. In my view increasing the size to
4096 to support pkcs11-ids was the wrong approach in the first place.
Anything longer than OPTION_LINE_SIZE is better input as multiple lines and
parsed without using get_user_pass.

Openvpn-devel mailing list

Reply via email to