From owner-freebsd-questions@FreeBSD.ORG Tue Jan 15 18:14:46 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED841793 for ; Tue, 15 Jan 2013 18:14:45 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id B2790D07 for ; Tue, 15 Jan 2013 18:14:45 +0000 (UTC) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 2BFDAA71C61 for ; Tue, 15 Jan 2013 13:14:39 -0500 (EST) Received: (qmail 27274 invoked from network); 15 Jan 2013 18:14:38 -0000 Received: by simscan 1.4.0 ppid: 25867, pid: 27617, t: 0.2241s scanners: clamav: 0.88.2/m:52/d:10739 Received: from unknown (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Jan 2013 18:14:38 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.8]) by be-well.ilk.org (Postfix) with ESMTP id DEB3133C1D; Tue, 15 Jan 2013 13:14:32 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id 920FE39843; Tue, 15 Jan 2013 13:14:32 -0500 (EST) From: Lowell Gilbert To: n j Subject: Re: pkgng package repository tracking security updates References: <50F403C6.1030705@gmail.com> <50F4130A.5050105@freebsd.org> <50F4197E.8050003@infracaninophile.co.uk> <50F51DC7.4030300@freebsd.org> Date: Tue, 15 Jan 2013 13:14:32 -0500 In-Reply-To: (n. j.'s message of "Tue, 15 Jan 2013 10:33:55 +0100") Message-ID: <44zk0auxdj.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: User Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:14:46 -0000 n j writes: > On Tue, Jan 15, 2013 at 10:13 AM, Matthew Seaman wrote: > >> On 14/01/2013 22:44, n j wrote: >> > One thing to think about would be the option of port maintainers >> uploading >> > the pre-compiled package of the updated port (or if the size of the >> upload >> > is an issue then just the hash signature of the valid package archive so >> > other people with more bandwidth can upload it) to help the package >> > building cluster (at least for mainstream architectures). The idea behind >> > it being that the port maintainer has to compile the port anyway and pkg >> > create is not a big overhead. The result would be a sort of distributed >> > package building solution. >> >> >> Sorry. Distributed package building like this is never going to be >> acceptable. Too much scope for anyone to introduce trojans into >> packages. Building packages securely is a very big deal, and as recent >> events have shown, you can't take any chances. >> >> Cheers, >> >> Matthew >> > > I'd trust this system as far as I trust port maintainers right now. Well, almost. It would have to be cryptographically validated, which would be a bit of work to get right. > I > understand that a port maintainer can submit arbitrary MASTER_SITES in a > port Makefile which allows the maintainer to inject malware as they wish. > If I trust the port maintainer to make me download and build something > coming from e.g. http://samm.kiev.ua or http://danger.rulez.sk (just random > picks, no offense intended), then I'd trust that maintainer to upload the > package for me or submit a SHA256 hash that the correct package must have. > So if somebody else were to build the package, the server would accept the > upload only if it matches the hash. It's easier to sneak something into a binary than a source code package, although you can never be *completely* sure either way (c.f., Ken Thompson's classic speech "Reflections on Trusting Trust"). In practice, some amount of subterfuge would be required for the attacker to keep from being found out too soon to do much good; possibly quite a lot of subterfuge, if the port gets run on TrustedBSD systems or other forms of system auditing. Once anyone notices a problem, the port will be shut down quickly. > Am I overlooking something? Is there some kind of port verification by > someone from the team prior to accepting the port submission? Well, a committer has to check the port in personally, but deliberate sabotage could probably sneak by the committer most of the time. - Lowell