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]
Date: Fri, 29 Dec 2023 15:52:00 -0700
From: David Ahern <dsahern@...nel.org>
To: Dan Moulding <dan@...m.net>, alexhenrie24@...il.com
Cc: bagasdotme@...il.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 pabeni@...hat.com, regressions@...ts.linux.dev
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short
 lifetimes generating when they shouldn't, causing applications to fail

On 12/29/23 11:33 AM, Dan Moulding wrote:
> I think a maintainer will probably need to make a call here and decide
> how to proceed.
> 
>> TEMP_PREFERRED_LIFETIME is an administratively set variable: The user
>> can change it to whatever they want whenever they want, and the
>> operating system can adjust it automatically too.
> 
> Agreed. And the behavior it seems you really want is to prevent the
> user from administratively setting it to a value that is lower than
> REGEN_ADVANCE, so that it won't stop generating new temporary
> addresses altogether.
> 
> But preventing the user from configuring it to a value that is too low
> is different from generating new temporary addresses with preferred
> lifetimes that are greater than the currently configured value of
> TEMP_PREFERRED_LIFETIME. I still believe it would be better, and would
> be in conformance with the RFC, to simply not allow the user to
> configure a too-short TEMP_PREFERRED_LIFETIME instead of tinkering
> with the lifetimes of generated temporary addresses.
> 
>> It's fine to revert the commit for version 6.7 (after all, I think
>> everyone wants a break for the holidays). Hopefully by version 6.8 we
>> can agree on a way to support users who want to randomize their IPv6
>> address as frequently as the network allows.
> 
> FWIW, I think the desired effect you are seeking makes sense and is
> the right thing to do. I'm just not convinced this is the correct way
> to do it. But I'm not a maintainer and also not an expert in IPv6, so
> I'm definitely not the right person to make that call.
> 

Send a revert before 6.7 is released which will most likely be this
weekend.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ