netdev - Re: DCCP Deprecation

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: <20230710120101.4b6d78af@kernel.org>
Date: Mon, 10 Jul 2023 12:01:01 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: Gregorio Maglione <Gregorio.Maglione@...y.ac.uk>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Florian Westphal <fw@...len.de>,
 <netdev@...r.kernel.org>
Subject: Re: DCCP Deprecation

On Mon, 10 Jul 2023 11:22:53 -0700 Kuniyuki Iwashima wrote:
> From: "Maglione, Gregorio" <Gregorio.Maglione@...y.ac.uk>
> Date: Mon, 10 Jul 2023 12:06:11 +0000
> > Hi Kuniyuki,
> > 
> > I saw the deprecation notice on the DCCP. We are working with a multipath
> > extension of the protocol, and this would likely impact us in the
> > standardisation effort. Do you know whom I must contact to know how I can
> > volunteer to maintain the protocol, and  to get more information about
> > the maintenance process?  
> 
> I think it would be better to review others' patches or post patches before
> stepping up as a maintainer.

Yes, I think we should document the expectations more clearly. I asked
on workflows@ if others already have docs.

https://lore.kernel.org/workflows/20230710115239.3f9e2c24@kernel.org/T/#u

For DCCP specifically I think we'd like to see some effort around
improving syzbot testing and addressing the bugs?

> However, this repo seems to have a license issue that cannot be upstreamed
> as is.
> https://github.com/telekom/mp-dccp

Right, in theory maintenance of the code already upstream is orthogonal
to protocol extensions. But if there is no user of the pure upstream
code then it seems hard to justify the effort of keeping it.