-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> Hi, > > On Tue, Oct 07, 2014 at 12:56:55PM -0500, Jon Ciesla wrote: >> On Tue, Oct 7, 2014 at 8:23 AM, David Sommerseth < >> openvpn.l...@topphemmelig.net> wrote: >> >>> From: David Sommerseth <dav...@redhat.com> >>> >>> In systemd after version 216, systemd-ask-password will support --echo >>> which will avoid masking the user input. As OpenVPN uses this mechanism >>> collecting usernames when systemd is available, this will avoid the > [..] >> >> ACK. Enables systemd features on systemd systems, and looks like a no-op >> on non-systemd systems. > > Now this is getting interesting. I had a LONG discussion with David on > IRC today, as I do not like where this is going - it's very very specific > code (not only "linux specific" but "linux with systemd"), and the more I > think about the less I'm convinced that we really want to have this inside > OpenVPN, depend on particular versions of systemd in our source (yet > another #ifdef that will turn into dead code in a few years), or link > against a systemd library. > > OTOH, having a *generic* mechanism to run an external "askpass" mechanism > - which could then be something x11-ssh-askpass, for example, on systems > that are not Linux or have no systemd, is something I'd find generically > useful. On systemd systems, this would then point to systemd, of course. > > So this might be "./configure --enable-ask-pass=$my_program", which > could then be /usr/sbin/systemd-askpass, or something private to OpenVPN > which would check if systemd is running, and if yes, call systemd-askpass > and if not, call "whatever makes sense on that particular environment" > (if $DISPLAY, call ssh-askpass, otherwise, not). It seems the systemd controversy has now reached OpenVPN :). I also would prefer a generic mechanism which could then utilize systemd or whatever. Any ideas how much (more) work would that require? > > > Now, the really interesting thing about this is that we have an ACK for > a patch which is not without religion around it - from someone who has > never sent an ACK or a patch before. So, do I take any ACK, no matter > who sent it? Do we require ACKs to come from people that have actual > experience with the code, and are willing to work on the code when these > bits need maintenance in the future? "This is the material where project > forks are made from"... Very good questions. Perhaps the simplest solution is to give a NACK to the patch to negate the ACK. I don't think an ACK should mean the code _must_ go to the repository _if_ somebody objects it. > > So fully independent from the patch at hand we have some discussion to > do - and we might want to postpone this particular topic and patchset > to the face to face meeting, as things tend to get out of hand when > discussed purely by mail / IRC. That makes sense given that the Munich hackthon is only about one month away. - -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQ031UACgkQwp2X7RmNIqNWvwCg3+ZCc0Y9vWGXEbP6x1iN32fD b1QAoJLhluPl033np8OTQHXpKjcO/YO0 =IS4U -----END PGP SIGNATURE-----
