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: <CANn89iLkpP42EFRGmFUsSQv+ufNA=4VmSp6-1NJBBpm0kTjw7w@mail.gmail.com>
Date: Wed, 25 Sep 2024 21:01:23 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Joe Damato <jdamato@...tly.com>, Eric Dumazet <edumazet@...gle.com>, 
	"David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org, 
	Willem de Bruijn <willemb@...gle.com>, Jonathan Davies <jonathan.davies@...anix.com>, eric.dumazet@...il.com
Subject: Re: [PATCH net 2/2] net: add more sanity checks to qdisc_pkt_len_init()

On Wed, Sep 25, 2024 at 8:55 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Wed, Sep 25, 2024 at 8:24 PM Joe Damato <jdamato@...tly.com> wrote:
> >
>
> >
> > > git log --oneline --grep "sanity check" | wc -l
> > > 3397
> >
> > I don't know what this means. We've done it in the past and so
> > should continue to do it in the future? OK.
>
> This means that if they are in the changelogs, they can not be removed.
> This is immutable stuff.
> Should we zap git history because of some 'bad words' that most
> authors/committers/reviewers were not even aware of?
>
> I would understand for stuff visible in the code (comments, error messages),
> but the changelogs are there and can not be changed.
>
> Who knows, maybe in 10 years 'Malicious packet.' will be very offensive,
> then we can remove/change the _comment_ I added in this patch.

BTW, I looked at https://en.wikipedia.org/wiki/Sanity_check
and the non inclusive part is at the very end of it.

I would suggest moving it at the beginning of the article to clearly
educate all potential users.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ