Re: [Openvpn-devel] building HEAD + openssl 1.1 api fails @ "crypto.c:823:32: error: invalid application of ???sizeof??? to incomplete type ???cipher_ctx_t"

[David S. <op...@sf...>]

On 28/03/17 14:47, Gert Doering wrote:
> Hi,
> 
> On Tue, Mar 28, 2017 at 02:35:59PM +0200, David Sommerseth wrote:
>> On 28/03/17 14:21, Gert Doering wrote:
>>> On Tue, Mar 28, 2017 at 02:11:26PM +0200, David Sommerseth wrote:
>>>>> That's great!  This way, 2.4 does not have to change it's behaviour.
>>>>> Still, I think it makes sense to deprecate --ns-cert-type, and remove it
>>>>> in favour or --remote-cert-tls in openvpn 2.5.
>>>>
>>>> Based on the feedback and discussions in Fedora regarding to us removing
>>>> --tls-remote .... I actually think 2.5 is too early.  
>>>
>>> Nobody suggested removing --remote-cert-tls.
>>
>> I don't think I tried to say that :)  I mentioned --tls-remote in v2.4
>> as that caused quite some noise.  I actually had to add a patch in the
>> EPEL packages for EL6+EL7 bringing it back again, to ease these complaints.
> 
> Ah, *that* one.  I see.  So "the last time we deprecated and removed 
> one of our zillion stale options, people complained, so we're not going
> to do it again"?

Nope.  We will deprecate features in the future too.  But we should be
far more careful and not even expect users to turn around as quick as we
really want.

> We need to communicate better what might affect users in new versions, so
> they can test and complain/adjust in time (like, the stricter CRL handling
> in 2.4, and - obviously - the --tls-remote bit)

Absolutely!  The --tls-remote feature was deprecated for 3(!) years, and
still people didn't catch it.  In fact NetworkManager guys implemented
the initial fix for it sometime in late last autumn, iirc.  But we only
listed it as deprecated in the man-page, no log warnings.  And we added
a note about it in Changes.rst, which also arrived fairly late in the
2.4 cycle.

I have a *hope* that annoying users with M_WARN in the log files will
help a bit.  As well as stating it clearly in the man pages, wiki pages,
Changes.rst.

<sarcasm>
If the log part is not enough as it is today, we might need to consider
a new M_DEPRECATED which makes it even more obvious ... like this:

   DEPRECATED: ******************************************
   DEPRECATED: *** Option --x-y is deprecated
   DEPRECATED: *** This option will be removed in v2.z
   DEPRECATED: ******************************************

Perhaps with a 1 minute start-up delay.

If someone is not able to catch that one ... then I have no don't know
what else can work.
</sarcasm>

>>>> and get in touch
>>>> with at least NetworkManager guys to ensure they have time to implement
>>>> a solution when this goes away.  So I think 2.6 is more realistic.
>>>
>>> Shouldn't be so hard to do a string-substitution in NM...   with
>>> 60b23236329e6921729f51e7689042a29c794a6b, this is really straightforward
>>
>> If the behaviour is really close by doing a substitution, this should be
>> good enough.  --tls-remote to --verify-x509-name is more complicated,
>> due to character remapping and such ugly details.
> 
> Indeed.
> 
> So - this is something people need to test on their client/server certs.  
> 
> Initially, it broke for ours (because the CA sets "more bits than needed",
> and that confused the ku test on equality), but with the new check 
> "at least these bits, more are OK" all is fine.
> 
>>> (unless your certs are really, *really* weird, providing a proper 
>>> nsCert extention, but no proper keyUsage/extKeyUsage extentions).
>>
>> Well, despite weirdness occurring (Way too) often, I think we can live
>> with that noise if we have given enough time to adopt.  As long as we
>> have a real and solid argument they have been doing things wrong in the
>> beginning.
> 
> Indeed, again ;-)

:)


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc