netdev - Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

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:	Thu, 24 May 2012 15:58:16 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	David Miller <davem@...emloft.net>
CC:	<jon.maloy@...csson.com>, <netdev@...r.kernel.org>,
	<tipc-discussion@...ts.sourceforge.net>, <ying.xue@...driver.com>,
	<erik.hugne@...csson.com>, <allan.stephens@...driver.com>,
	<maloy@...jonn.com>
Subject: Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label

[Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label] On 21/05/2012 (Mon 02:39) David Miller wrote:

> From: Jon Maloy <jon.maloy@...csson.com>
> Date: Mon, 21 May 2012 01:59:12 -0400
> 
> > With the latest series of patches from Paul Gortmaker and Allan
> > Stephens TIPC is now functionally mature and stable enough to
> > justify removal of the EXPERIMENTAL label.
> > 
> > Signed-off-by: Jon Maloy <jon.maloy@...csson.com>
> 
> I'll let Paul Gortmaker decide whether this is warranted or
> not.

The EXPERIMENTAL thing has always been rather subjective, but
I'd like to see some level of confidence that a crafted up bogus
TIPC message can't be used to DOS a machine with active TIPC
connections before removing EXPERIMENTAL.  Maybe the current code
is OK as-is in this respect but I'd feel better knowing that it
had been audited with this exact kind of thing in mind.

> 
> I don't really want to all of a sudden start seeing patches from
> people like you and the windriver folks, who effectively wrote off
> upstream and left poor Paul Gortmaker holding the bag and having to
> take care of EVERYTHING.

To be fair, I should note that Al did a lot of work in the background
getting commits onto a modern baseline and answering all my questions
since the out of tree sourceforge mess was highlighted here on netdev.

> 
> You can't just do nothing for years, end up making someone else
> do it, then say "Hey here I am, I feel like submitting upstream
> patches now" after I've spent this entire time starting to trust
> Paul for TIPC patches.

I've been thinking about this off and on, and I'm wondering what to
suggest going forward.  Dealing with the backlog was largely going over
maintenance and bugfix type patches and sanitizing them for integration
upstream.  It largely boiled down to being able to tell a crap patch
from a good one that matched upstream expectations.  I figured I could
manage to not screw that up too badly, hence why I volunteered to assist
with the backlog.

But for new TIPC development features, future direction, and things like
that -- making the right call requires intimate understanding of TIPC
and its users, which is something that a maintainer should have but
something I know I don't have.  (A man has to know his limitations.)

In this context, I'm not talking about these three trivial patches; but
more complicated stuff that I imagine will be floated in the future.

To that end, I can still review and call out issues in a crap patch when
I see them.  But I'd like to see new stuff sent to netdev, so that folks
smarter than me have a chance to catch when a patch appears generally OK
but is architecturally the wrong direction etc.

Paul.

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html