Hi David,

On Wed, May 25, 2016 at 12:17 PM, David Sommerseth <openvpn@sf.lists.
topphemmelig.net> wrote:

> On 25/05/16 17:27, Selva Nair wrote:
> >
> > Well, if a major rewrite of console input is planned, consider
> > replacing getpass() as well. It has arbitrary password length
> > limitations on some platforms. At the same time I'm not sure I
> > understand the need for this overhaul.
>
> Currently the interface is basically stdio/stdout.  But with a more
> modular API for querying user, you can enable more fancy ways of
> querying the user.  In the systemd team, they're talking about moving
> away from systemd-tty-ask-password's API to a DBus oriented API (but it
> is dragging, as they can't do that without kdbus in place for querying
> users at boot time).  The idea is that OpenVPN should be completely
> agnostic to if the user input is from a tty console or a fancy graphical
> GUI.  The OS/distribution just needs to support a method through this API.
>

Thanks for the explanation. Could be useful if it works well... Centralized
input facilities could have unwanted side effects -- for example, systemd
sometimes blasts messages to all logged in users when a password is
required which is kind of silly (probably there is a way to suppress it, I
haven't investigated).


>
> > Your patch has
> >
> > +#if SYSTEMD_VERSION > 216
> > +    if( echo )
> > +    {
> > +argv_printf_cat(&argv, "--echo");
> > +    }
> > +#endif
> >
> > How would such a compile time check be any useful -- the version will
> > have to be checked at run-time, isn't it?
> >
> > So, should I withdraw the patch or try to fix it by hacking up a
> > run-time version check?
>
> There exists no way to query at runtime which version systemd is running
> (or at least it didn't when I started poking at that).  And it was
> considered that if you have version newer than 216 you would never
> downgrade systemd, so a compile time check would generally be good
> enough.  This works at least very well in the RHEL/Fedora build
> environments where all builds happens in chroots managed by mock, where
> the buildroots have the same package versions installed as the
> distribution the build is targeted at.


Yeah, it looks good as most people install from distributions or build on
the target machine. No need to support folks like me who sometimes copy
binaries from one system to another at our own peril :)

I'll withdraw the patch.

Thanks,

Selva

Reply via email to