Re: [PATCH v2] CRL updater: Update script for OpenVPNs CRL

[ummeegge <ummeegge@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

Hi Michael,

Am Dienstag, den 13.02.2018, 16:21 +0200 schrieb Horace Michael:
> Hi Erik,
> 
> On February 13, 2018 12:00:12 PM GMT+02:00, ummeegge <ummeegge(a)ipfire
> .org> wrote:
> > 
> > Hi Michael,
> > 
> > Am Dienstag, den 13.02.2018, 08:07 +0200 schrieb Horace Michael:
> > > 
> > >  
> > > Please consider to add auth-nocache also in order to get rid of
> > > the
> > > warnings for caching credentials.
> > just to bear in mind, if we set auth-nocache and a user/password
> > authentication has been configured manually by the user (IPFire do
> > not
> > provides this currently), there is the need to authenticate again
> > after
> > a session key has been expired.
> If an IPFire user manually changed the standard configuration of
> OpenVPN and add passwd authentication then he/she should assume also
> the impact - entering the credentials on key renewing or changing the
> config and removal of --auth-nocache directive.
> 
The removal is kind of unpractical if we hardcode --auth-nocache it can
be indeed manually deleted in ovpnmain.cgi but it won´t be consistent
for coming updates.
If someone uses user/pwd auth via manual configuration it might be
easier for the first to add also --auth-nocache into the local configs
if wanted ? In some cases this might be also a problem e.g. for every
kind of automation (such as larger backups e.g.) whereby processes will
be stopped if no user interaction is made.

In my opinion there should be a checkbox for this available but this
kind of contradicts also the current usability for keeping it as easy
as possible even this option is for an default IPFire configuration
useless.

But this are only my two cents on this topic, if this is wanted from
the core developer side this should be made very quickly but i would
do/discuss this in an own topic but also after we have finished the
OpenVPN-2.4 update.
There is also the need to think about a lowered --script-security level
(from 3 to 2) which matches also this topic i think and also some other
possible (and already fixed) warnings --> https://bugzilla.ipfire.org/s
how_bug.cgi?id=11364 like e.g. the MTU warning which should also be
thinking about but also better tested...

Nevertheless it might be nice if you stay tuned in this topic.

Greetings,

Erik