On 14/04/2021 11:29, Arne Schwabe wrote:
>
>>
>>> + if (options->chroot_dir == NULL || in_chroot ||
>>> options->crl_file_inline)
>>> + {
>>> + tls_ctx_reload_crl(new_ctx, options->crl_file,
>>> options->crl_file_inline);
>>> + }
>>> + else
>>> + {
>>> + struct gc_arena gc = gc_new();
>>> + struct buffer crl_file_buf =
>>> prepend_chroot(options->chroot_dir, options->crl_file, &gc);
>>> + tls_ctx_reload_crl(new_ctx, BSTR(&crl_file_buf),
>>> options->crl_file_inline);
>>> + gc_free(&gc);
>>> + }
>>
>> Arne: any opinion on using c->c2.gc here? init_ssl() is invoked once per
>> instance and re-invoked upon SIGUSR1. I believe it is fine to use the
>> c2's gc?
>>
>
> I would prefer a local gc here. It is easier to see that the memory can
> be freed right now and we don't add this unecessary depenendency on c2.
> Also c2 is not clear on renegotiations, so we will collect one string
> per renegotiation here.
This routine is invoked upon SIGUSR1, not upon renegotiation. And I
believe c2 is cleaned upon SIGUSR1. SO I would consider this memory
allocation the same as other options we have.
However, I do agree with your point that limiting the scope is better.
Regards,
--
Antonio Quartulli
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
