linux-kernel - Re: wpa supplicant/ipw3945, ESSID last char missing

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:	Tue, 3 Oct 2006 12:00:41 -0400
From:	Theodore Tso <tytso@....edu>
To:	Dan Williams <dcbw@...hat.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, jt@....hp.com,
	Andrew Morton <akpm@...l.org>,
	Norbert Preining <preining@...ic.at>, hostap@...oo.com,
	linux-kernel@...r.kernel.org, ipw3945-devel@...ts.sourceforge.net
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

On Tue, Oct 03, 2006 at 10:12:59AM -0400, Dan Williams wrote:
> I'd point out here that one is not breaking the _distro_, as long as we
> assume that distros are internally consistent (which one of the major
> points of a distro!).  What's getting broken is people who
> install/replace distro-provided software with their own bits.  In the
> first case, the distro people are responsible to making sure that
> breakage does not occur, and that distro users are not affected.  In the
> second case, that responsibility falls to the user who
> installed/replaced the distro-provided software, precisely because that
> software is no longer distro provided.

I'm using short-hand here.  When I say breaking the _distro_, what I
mean is that we are breaking the ability for users of that distro to
test development kernels, which is generally considered a good thing
by the kernel development community.  

One could make the case that telling them that they have to download
something relatively trivial, like wireless tools, is less of a big
deal than something huge and very painful to build and replace, like
glibc (with udev, hal, et. al, probably falling somewhere in between
these two extremes), but up until now, the goal that kernel
development has made is that we add new interfaces, but we try
extremely hard not to break existing interfaces without a lot of
notice.  

Consider that that the normal, MINIMUM waiting period for *removing*
an interface or functionality is six months.  I would argue that this
means that we should be waiting that long before making
backwards-incompatible changes to an interface should be at least that
long.

> Yes, nl80211/cfg80211 (sent to netdev@ last week) is the likely
> successor.  Please, if you have suggestions for ABI/API-proofability,
> review the patch and post suggestions!  We all know a carefully designed
> is not just about the code, but about the semantics, structures, etc as
> well.  It would be quite valuable to have everyone's input to make sure
> it's as future-proof as possible.

As a suggestion, has someone written up the a formal interface
specification?  If so, posting that for review along with the code
might be a good idea.  

Regards,

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/