From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 07DB1138A1A for ; Wed, 21 Jan 2015 20:44:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94CF8E088C; Wed, 21 Jan 2015 20:44:56 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0447DE0869 for ; Wed, 21 Jan 2015 20:44:55 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so10877500pab.12 for ; Wed, 21 Jan 2015 12:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3kFDKsFylKZ392EcJuj0LL9sfFkGZW7jPSzdB9u5Fy8=; b=AuB4cm63/FROrePuZAe1MAohMRMmGeBnue3vyJCaAP5KQqQmw+J6VeR/nHTEkcWEqj 7USfh7OkE9Lw0fceb1DLoorYBauEwx1T3xA/deBKaHsGrlPD2JLHOM72ffu2g8A8AfPp W3lb3mCxiimfl9apNlcUgRHC4CUYes8jkvK4eOcUZ55eBMKsqM4LAI8iI8gX3gvqy3ye cgSYEUgMuqMyMc9z1mcl9oiednxrhHE1ygeQpOp4fF9UR1AKxL5Unzkktsfrmfx3IBXV UMKszcJd+lg4v3WqQ896VK4bWOP646O540e9qSx1V6ljZ7pwtp21Tj3Rr4RiursaAc31 2+1w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.68.193.135 with SMTP id ho7mr65642367pbc.103.1421873094970; Wed, 21 Jan 2015 12:44:54 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.70.1.103 with HTTP; Wed, 21 Jan 2015 12:44:54 -0800 (PST) In-Reply-To: <54C007DE.306@gentoo.org> References: <20150114034323.GA22358@comet.hsd1.mn.comcast.net> <54B7D189.1000108@gentoo.org> <20150115191001.GD22358@comet.hsd1.mn.comcast.net> <54BF2444.20106@gentoo.org> <54BFD57E.3020704@hasufell.de> <54C007DE.306@gentoo.org> Date: Wed, 21 Jan 2015 15:44:54 -0500 X-Google-Sender-Auth: c0yN-BEX3tjrFJlvxqxlT_TQKec Message-ID: Subject: Re: [gentoo-project] Some focus for Gentoo From: Rich Freeman To: hasufell Cc: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 31d8bceb-e182-4bee-aa7f-2abe270c323d X-Archives-Hash: 47260dab9d1c8439f82500c9b63b23c6 On Wed, Jan 21, 2015 at 3:11 PM, hasufell wrote: > Rich Freeman: >> On Wed, Jan 21, 2015 at 11:36 AM, Julian wrote: >>> >>> We would need much better tools and PM support for overlays. I've talked >>> about this too and there are examples of at least two distros that are >>> running a more decentralized model: >>> 1. NixOS, also see my thread on nix-dev about how they want to ensure >>> focus [0] >> >> I still don't get how NixOS avoids some fundamental issues. As I >> understand it they assign a unique ID to every build of everything, >> and the dependencies are expressed in the same way. So, my build 123 >> of appfoo v1.1 depends on build 456 of libz v2. Your package might >> depend on build 457 of libz v2, and that is fine since both versions >> will be installed side-by-side. Then we get to have two copies of >> libz in RAM and maybe build 456 has a security vulnerability. It is >> better than static linking, but not by far. >> > > All copies are known to the PM. That's nothing like bundles libs or > static linkage. It's probably a triviality to develop a tool that checks > for vulnerable libraries (not sure if there already is one). I'm not saying that anything bundles libs. My understanding is that packages are basically all content-hashed and all dependencies including linking is against one of these. So, if you want you can have 14 versions of the same library with the same SONAME and completely different ABI/APIs and it will all work, because each package is linked against the EXACT library it was built against. Two packages can still share the same library (in disk and in RAM), but they could also use two different libraries which on most other distros would collide (identical version, SONAME, etc). So, when you use a package you're using the exact same code the maintainer uses, including all the libraries. I'm sure this breaks down at some point - you can't have 47 different versions of dbus all running at the same time if you want processes to actually talk to each other. You obviously can only run one kernel at a time, and there is only one port 80/25/etc on the system unless you run every process in its own namespace. I don't see how you'd check for vulnerable libraries other than using heuristics (ie actually run the exploit against the library). If ANYBODY can create a repository, and a repository can contain any number of builds of any number of versions of zlib, then how could you possibly tell whether any particular build is patched for any particular vulnerability otherwise? Certainly you could offer a tool that checks for known-vulnerable versions from a selection of supported repositories. Such a model also only promotes choice to a degree. You can choose to use Fred's version of libfoo, and Tony's version of java, but you can't use them together unless tony also chooses to support this configuration. Tony's java could very well link to Sam's libfoo and you don't like that version of it, but java isn't all that popular these days so beggars can't be choosers. With Gentoo you can mix/match dependencies but the same thing that allows that to work will also cause the system to break horribly when somebody changes an ABI without changing an SONAME and so on. > > My point was: it's not enough talking about "what should we focus on?". > How do you implement that focus? I do agree with this, which is one of my concerns with the original post. We can certainly talk about what we should focus on, but the only thing as a Council we really have the power to do is to forbid people from working on other things, or to expel hot air. The latter can accomplish some good, but not much. > > What's your idea there, except of keeping status quo which clearly does > not work since even gentoo oldtimers seem to realize something is going > wrong? > If I had solutions I'd be posting them. Apologies if it seems like I'm nitpicking. The thing is that while the status quo has some clear deficiencies, in some ways it is also the best Gentoo has really ever been. Or put another way, where else are we going to go? Maybe that is why so many of us that seem to have so much conflict with each other all stick around. -- Rich