From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3251 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Licensing. Date: Mon, 29 Apr 2013 17:50:37 -0500 Message-ID: <1367275837.18069.192@driftwood> References: <20130429204731.GZ20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1367275856 530 80.91.229.3 (29 Apr 2013 22:50:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 22:50:56 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3255-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 00:50:56 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UWwuN-0003Ap-5F for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 00:50:55 +0200 Original-Received: (qmail 1902 invoked by uid 550); 29 Apr 2013 22:50:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1891 invoked from network); 29 Apr 2013 22:50:52 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=3mIUxiD56GE3WtlDmYHUf2b7yQ4AIL4E8WqmcAIiww0=; b=E6m9fQpGwCE7ygpd9+HJvK+8VEJCUpaUtrOF5GYl/1OaJXrBaFbF4NuOEUq0W8safo ZfG4jemwnEvxTno3OcM1Smu3bJkV6Z5YYADyYWDZgil7l/fjpkjD3B7fpzl56m+okj6U 5dJpAEnDt+oGKirTCEWy43poc8NGPmAHFZduc+XCN7gKTpTgGNugv1bnJs1hihVPnVe7 Nv7HKwSsRa/uIdonrmbkwI87VCFkdHni+knC6oU84i5OcgslEMsmc++D8NfE2ZnBhSH0 Yxw3woAhJwSICwciFDtD16FhJdEL2UPQN/NckkOljIJrWbBGcgkZrYAhfGNBETmKdZL6 JuGQ== X-Received: by 10.229.72.130 with SMTP id m2mr747226qcj.122.1367275840797; Mon, 29 Apr 2013 15:50:40 -0700 (PDT) In-Reply-To: <20130429204731.GZ20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Mon Apr 29 15:47:31 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQkNRbMFc58zkiksgxOPTdG1KaKa8JH3lEHRb/DennRMK4ICQ/9FBO/yqWaBKl7qWeFbmRyR Xref: news.gmane.org gmane.linux.lib.musl.general:3251 Archived-At: On 04/29/2013 03:47:31 PM, Rich Felker wrote: > On Sun, Apr 28, 2013 at 04:34:38PM -0500, Rob Landley wrote: > > On 04/26/2013 01:11:07 AM, Igmar Palsenberg wrote: > > > > > >>>> incompatible licenses. The openssl library can't be used with > > >a GNU > > >>>> program unless there's a waiver for it because one of the > > >clauses in the > > >>>> openssl license goes against the GNU license principles. The > > >gnutls > > >>> Not _used_ but _distributed_. The GPL does not restrict use > > .... > > >> What about explicitly loading the library at run-time using > > >uselib(2) in a plug-in like fashion? Is that also considered > > >problematic from a GNU perspective? > > > > > >I consider this a grey area. I personally don't thing it is > > >considered a problem, > > >but there are a number of interesting (theoretical) scenario's : > > > > Um, back up: > > > > You know how cryptographers point and laugh at non-cryptographers > > trying to figure out whether something's breakable? > > > > You know how professional security auditors find most programmers' > > code appallingly insecure, and the best of us have to put out > > regular updates to fix exploits that we didn't personally find? > > > > Now imagine what lawyers think of programmers' legal theories. >=20 > Your analogy would hold more water if the majority of lawyers doing > software licenses had any clue about the law, but they don't. Nearly > everything ever written in a proprietary software license has no basis > in law; legally, such documents are not even licenses (a license gives > you permission to do something that would otherwise not be permitted > under the law; it doesn't take away your rights) but one-sided > contracts that are never signed and that offer the victim nothing of > value in exchange for surrendering their rights. Sturgeon's Law applies everywhere, yes. Lots of self-proclaimed domain =20 experts aren't. (And an MCSE doesn't qualify you do secure posix code.) > > Programming-side example: the /tmp dir has the sticky bit set other > > users running inotify to spot new files being created don't > > immediately delete them and replace with a symlink so your > > mknod/open pair is now accessing the wrong file. What your code is > > doing worked fine, but the context it was running in made it > > insecure. >=20 > I don't follow. Unless you do idiotic things (like omit O_EXCL) there > is nothing unsafe about properly-configured public temp directories. Agreed, but most programmers had somebody else set it up for them and =20 often don't know why they did it that way. (And then there's the =20 "predictable names" fun where "they can't stomp you" doesn't mean "you =20 can't me tricked into stomping them". Sure it's managable, but the =20 issue does exist.) The reason for that digression was it's a fairly simple, easily =20 explained example of "you don't just have to understand what _you_ did, =20 you have to understand the entire environment you did it in". > > Now imagine telling a lawyer that your license usage is > > unexploitable in all jurisdictions, and you know this because you > > read the license text and you're sure you're using it ok. (The best > > a lawyer or security professional can EVER say is "I can't spot > > where you screwed up".) >=20 > Even someone with no security skills at all can tell you there is no > vulnerability *in your code* if your code is: >=20 > int main() {} >=20 > Similarly, a non-lawyer can tell you there's no vulnerability in a > "0-clause" BSD license. I agree in principle, sure. (My friend Lamont "Piggy" Yaroll used an old unix system, beta of NeXT =20 I think, where /bin/true was a 0 byte file with the executable bit set. =20 That got interpreted as a shell script, does nothing, returns true. =20 Clever, eh? Until he used true in his /etc/profile, which loaded =20 /bin/sh, which parsed /etc/profile, which loaded /bin/sh... filled up =20 all memory, brought down the system. He filed a bug. Their bug =20 reporting system tried to calculate defect density in the file and =20 threw a division by zero exception. I mean, I break stuff all the time, =20 but I bow down to the master.) (The point of that digression was that I've hung around enough system =20 engineers and enough lawyers to wince when anybody says "there's no =20 vulnerability in X". Reflex at this point, sorry. "I don't see how =20 you'd exploit that" and "sucks less than the alternatives" are the best =20 I can do...) (The legal side of that includes software patents, disclaimer of =20 liability, the author's "moral rights" in Germany that they _couldn't_ =20 disclaim until the law changed in december 2007, the not QUITE fully =20 repealed US crypto export regulations, DMCA anti-circumvention =20 nonsense... A 0-clause BSD does indeed suck least as a clear attempt to =20 opt out, but IP law is inherently horrible for the forseeable future.) > The potential for vulnerability is only introduced with complexity. Complexity such as mixing multiple licenses in the same program, unless =20 they're all fully convertible to a single license. I've learned enough of this game that I don't want to play it anymore... > Anyway, this thread has gotten fairly off-topic. Agreed. Rob=