On 01/10/2020 18:36, Simon Matter wrote: >> From what I recall from the last review years ago, the behavior was also >> not >> well defined in restart scenarios (--up-restart) - where the script might >> be >> run with different privileges, the --chroot might also change things. >> Which >> makes this patch very fragile for users. >> >> All of these issues are avoided with the --management and >> --management-hold. > > How do all these issues affect --up-pre but not the existing --down-pre? > Why was --down-pre never removed over all the years if it makes things so > fragile for users?
Several reasons. We don't want to break backwards compatibility. So removing an option which has existed since 2004 is not acceptable unless it is really security sensitive (see the discussion on this list regarding another patch where I suggested, to remove --udp-mtu - which was also rejected). Secondly, --down-pre has a deterministic behavior. If you use --chroot and/or --user/--group, the --down script is run under the same conditions whether you use --up-restart or not. And, since we still have not heard any convincing arguments why --management with --management-hold cannot work for your use case, nothing has changed since the Trac discussions years ago. We don't want to easily add a feature only 3 people have requested during a time span of 7 years, where one of them already confirmed the management approach worked [1]. <https://community.openvpn.net/openvpn/ticket/284#comment:17> Adding new options and features means we need to commit to support them for quite a long time; regardless of the patch complexity. So a new feature or option really needs to have a reasonable amount of users and solves a problem which cannot be solved through other reasonable ways. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
