netdev - Re: [PATCH net-next 3/5] tcp: Print list of TFO-keys from proc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK6E8=cFc6Cce+SgHAgspfTah5ub_onw1zCbx3pGNrszZxN6XQ@mail.gmail.com>
Date:   Mon, 17 Dec 2018 15:49:10 -0800
From:   Yuchung Cheng <ycheng@...gle.com>
To:     Christoph Paasch <cpaasch@...le.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next 3/5] tcp: Print list of TFO-keys from proc

On Mon, Dec 17, 2018 at 3:35 PM Christoph Paasch <cpaasch@...le.com> wrote:
>
> On 17/12/18 - 08:52:22, Yuchung Cheng wrote:
> > On Sun, Dec 16, 2018 at 10:32 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
> > >
> > >
> > >
> > > On 12/14/2018 02:40 PM, Christoph Paasch wrote:
> > > > Print the list of the TFO-keys with a comma separated. For setting the
> > > > keys, we still only allow a single one to be set.
> > > >
> > >
> > > I wonder if some applications expecting current format could break
> > > after a formatting change.
> > I have the same concern as well. print the extra keys in a different
> > sysctl maybe? e.g. net.ipv4.tcp_fastopen_alt_keys
>
> True, some apps might break on that.
>
>
> Having a single place where all the keys are shown is still useful as that
> way the key-rotation can simply check the current keys in one place.
That's a good point - I am neutral now to use your existing proposal. Eric?

>
> I'm fine with adding net.ipv4.tcp_fastopen_key_list or something like that,
> if we want to keep sysctl-API stable.
>
>
> Christoph
>