From owner-freebsd-pkg@freebsd.org Tue Apr 19 22:52:15 2016 Return-Path: Delivered-To: freebsd-pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95709B14FF7 for ; Tue, 19 Apr 2016 22:52:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26526128A; Tue, 19 Apr 2016 22:52:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id u3JMq1hR002419; Wed, 20 Apr 2016 01:52:01 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 20 Apr 2016 01:52:01 +0300 (MSK) From: Dmitry Morozovsky To: Matthew Seaman cc: Vsevolod Stakhov , freebsd-pkg@freebsd.org Subject: Re: Intrusion Detection using pkg? In-Reply-To: <5714BE83.1060909@FreeBSD.org> Message-ID: References: <5714BA56.50704@highsecure.ru> <5714BE83.1060909@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 20 Apr 2016 01:52:03 +0300 (MSK) X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:52:15 -0000 On Mon, 18 Apr 2016, Matthew Seaman wrote: [snip] > > Unfortunately, after years of useless discussion we have no sane > > signatures scheme in pkg, and I have no desire to continue these > > discussions I'm afraid. > > I believe the current package signature stuff serves its purpose, which > is to verify that the package tarball in question originated from an > identified and trusted source and hasn't subsequently been tampered > with. Which is fine, but there's a definite use-case for going further... Well, I suppose we have usual problem here: "doing security well is a pain, and doing it bad is simple and lead to false sense of security" (smilies at will) For all years being a system admin and/or architect I'm thinking about non-controversal (and useful) model of PKI or something similar, but still failed :( Which set of data are we going to protect? And how to protect the point for protection (both reliably and useful for day-to-day procedures)? Well, I also suppose this could be more a matter for -security@ also... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------