Hi Steffan and thanks for the review,
On 06/07/18 04:22, Steffan Karger wrote:
>> +struct buffer
>> +keyfile_to_buffer(const char *file, int max_size, struct gc_arena *gc)
>> +{
>> +size_t size;
>> +struct buffer in = alloc_buf_gc(max_size, gc);
>> +int fd = platform_open(file,
Hi Antonio,
On 05-06-18 10:14, Antonio Quartulli wrote:
> In preparation to having tls-auth/crypt keys per connection
> block, it is important to ensure that such material is always
> reloaded upon SIGUSR1, no matter if `persist-key` was specified
> or not.
>
> This is required because when
Hi,
On 27/06/18 09:50, Antonio Quartulli wrote:
> Hi,
>
> On 27/06/18 05:33, David Sommerseth wrote:
>> On 05/06/18 10:14, Antonio Quartulli wrote:
>>> In preparation to having tls-auth/crypt keys per connection
>>> block, it is important to ensure that such material is always
>>> reloaded upon
Hi,
On 27/06/18 05:33, David Sommerseth wrote:
> On 05/06/18 10:14, Antonio Quartulli wrote:
>> In preparation to having tls-auth/crypt keys per connection
>> block, it is important to ensure that such material is always
>> reloaded upon SIGUSR1, no matter if `persist-key` was specified
>> or
On 05/06/18 10:14, Antonio Quartulli wrote:
> In preparation to having tls-auth/crypt keys per connection
> block, it is important to ensure that such material is always
> reloaded upon SIGUSR1, no matter if `persist-key` was specified
> or not.
Has this been tested with --chroot and
Hi,
On 05/06/18 16:14, Antonio Quartulli wrote:
> In preparation to having tls-auth/crypt keys per connection
> block, it is important to ensure that such material is always
> reloaded upon SIGUSR1, no matter if `persist-key` was specified
> or not.
>
> This is required because when moving from
In preparation to having tls-auth/crypt keys per connection
block, it is important to ensure that such material is always
reloaded upon SIGUSR1, no matter if `persist-key` was specified
or not.
This is required because when moving from one remote to the
other the key may change and thus the key
