Re: [Openvpn-devel] [PATCH] Add ability to specify initialize flags for pkcs11 provider
Hi, On Thu, Sep 30, 2021 at 7:34 AM Petr Mikhalicin via Openvpn-devel < openvpn-devel@lists.sourceforge.net> wrote: > New pkcs11-helper interface allows to setup pkcs11 provider via > properties: > https://github.com/alonbl/pkcs11-helper/commit/b78d21c7e26041746aa4ae3d08b95469e1714a85 > > Also pkcs11-helper added ability to setup init args for pkcs11 provider: > > https://github.com/alonbl/pkcs11-helper/commit/133f893e30856eba1de715ecd6fe176722eb3097 > > Signed-off-by: Petr Mikhalicin > Sorry for the long delay in getting back on this. I somehow also missed the related discussion on Trac ( https://community.openvpn.net/openvpn/ticket/1453) I don't quite understand the need for exposing "init-args" to the user. The only two supported flags in the cryptoki docs are related to the use of threads. But we are the application and we should know what flags to pass --- not the user --- isn't it? If CKF_OS_LOCKING_OK is required, can't we just set it unconditionally? That said, OpenVPN2 is single threaded, so why is there a "bug in openvpn" related to the use of pkcs11 library from multiple threads referred to in the trac ticket? Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix error message about extended errors for IPv4-only sockets.
Hi, On Sun, Jun 19, 2022 at 11:38:17AM +0200, Arne Schwabe wrote: > > #if EXTENDED_SOCKET_ERROR_CAPABILITY > > /* if the OS supports it, enable extended error passing on the socket > > */ > > -set_sock_extended_error_passing(sock->sd); > > +set_sock_extended_error_passing(sock->sd, sock->info.af); > > #endif > > } > > > > I have to NACK this patch. sock->info.af is not the actual address > familiy but the family we want to use and it might be 0 if there is no > udp4/udp6 in the config file. > > For a client you can look at sock->info.lsa->actual.dest if that is > defined. For a server we seem to actually override/set that info.af > value according to my debugger but with a client I get 0 in that value. > It looks that set_mtu_discover_type in the same function has the same > problem, so it is easy to this mistake. So how do we know if this is a v4 or v6 socket, in a client? Phrased differently - I could do a v2 which will just ignore this particular errno value. Maybe not "as clean" as not calling the "wrong" setsockopt() in the first place, but will keep the log free of non-useful error messages just fine... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix error message about extended errors for IPv4-only sockets.
#if EXTENDED_SOCKET_ERROR_CAPABILITY /* if the OS supports it, enable extended error passing on the socket */ -set_sock_extended_error_passing(sock->sd); +set_sock_extended_error_passing(sock->sd, sock->info.af); #endif } I have to NACK this patch. sock->info.af is not the actual address familiy but the family we want to use and it might be 0 if there is no udp4/udp6 in the config file. For a client you can look at sock->info.lsa->actual.dest if that is defined. For a server we seem to actually override/set that info.af value according to my debugger but with a client I get 0 in that value. It looks that set_mtu_discover_type in the same function has the same problem, so it is easy to this mistake. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
