From owner-freebsd-ports@FreeBSD.ORG Fri Feb 13 04:41:50 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A99EB16A4CE; Fri, 13 Feb 2004 04:41:50 -0800 (PST) Received: from postman.arcor.de (newsread1.arcor-online.net [151.189.0.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2299B43D1F; Fri, 13 Feb 2004 04:41:50 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-184-227.reverse.qdsl-home.de [212.202.184.227]) (authenticated bits=0)i1DCfktw029971 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Feb 2004 13:41:48 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1Arcdd-0006D5-7x; Fri, 13 Feb 2004 13:41:45 +0100 Message-ID: <402CC60C.1000803@fillmore-labs.com> Date: Fri, 13 Feb 2004 13:41:48 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Ion-Mihai Tetcu References: <20040212144522.GB20647@madman.celabo.org> <20040212173817.7315b7d1@it.buh.cameradicommercio.ro> <402C2A1C.4010202@fillmore-labs.com> <20040213114956.36b25b44@it.buh.cameradicommercio.ro> In-Reply-To: <20040213114956.36b25b44@it.buh.cameradicommercio.ro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: "Jacques A. Vidrine" cc: ports@FreeBSD.org Subject: Re: security issues in ports: portaudit and VuXML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2004 12:41:50 -0000 Ion-Mihai Tetcu wrote: > On Fri, 13 Feb 2004 02:36:28 +0100 > Oliver Eikemeier wrote: > >>[...] >> >>As far as I understand the focus of portaudit and VuXML, they are >>complementing projects. >> >>In the current state portaudit uses a simple flat file database since >>I needed something to start with and wanted a format that is common to >>port committers(similar to MOVED), but the system is more or less >>database format agnostic. Because the distribution file is a simple >>tar file it is easy to distribute the VuXML database along with the >>flat file database, or even add signatures. >> >>If we decide that the VuXML format is better suited for the job than a >>flat file database it is easy to integrate it into portaudit in the >>long run, I have to look into security/vuxml to see what is the best >>way to synchronize the databases. > > I suggest it's now the time to do that. Both ideas are good, but keeping > to different databases means updating to different files, which means > they would get out of sync. See the example on the end. Thats what the conversion tools should be good for. >>[...] >>Currently portaudit is in a development and learning phase, and issues >>I'm working on are: >> >>- a better distribution system, e.g. a script that finds the nearest >>mirror of the database and fetches the file from there, not from a >>random location, integrating PR 62655. >>- a checksum system the checks if a new database is available by just >>fetching a md5 sum or a date and not the whole database, like the way >>clamav does it. > > ;) The idea came when I've exhausted my bandwidth with other traffic and > a nice three screens cron email came in with "fetch: timeout ..". I'm > not at all happy with fetch, which fails more often that it should , > although DES's recent commit improves it it a lot. > > I vote for (at least) md5. If someone manages to screw his local > database this will assure it is corrected on the first run. > > An other idea would be using cvsup against > security/portaudit/database/auditfile.txt, since the dailly changes are > not big. So we could have: > > [...] > > The "local" idea: if you cvsup daily you probably have the right > database in ports. > Shouldn't security/portaudit/database/auditfile.txt actualy be > security/portaudit/database/auditfile.tbz ? Or better yet > DISTFILES=auditfile.tbz The idea is nice, but: - portaudit is designed to work *with* a current ports tree (or a ports tree at all), so it may be integrated in the base system - ports/security/portaudit/database/auditfile.txt is *not* the authorative source, it is the file I *currently* use to generate the database, but this may change (e.g. merging VuXML in the generated output) - the .tbz file is generated dynamically and shouldn't be in CVS >>- a push mechanism that informs systems (by email?) that an updated >>database is available instead of waiting for the next scheduled check. > > Store somewhere DB_md5 and check once an hour. I don't see how it can be > done by email (or any other push); I have servers that do not receive > emails. On the other hand the email should be gpg signed (and this > complicates the hole thing) as the email To: address will be public so > anyone could nicely bomb portaudit_updates@my.domain Using the push mechanism is of course optional, but it is a nice way to trigger an update on hosts that would otherwise refresh their database every five days. No real need to PGP sign the mails though, since 1.) it is easy to protect the list and 2.) the only attack I can think of is a DoS attack against the update servers. The push message should only contain a trigger that a new version is available, not the update itself. >>- integration of the system into pkg_add of sysutils/pkg_install-devel > > It would be nice, indeed. Working on that. > [...] Thanks for the feedback. net/gaim is an unfortunate example, since we needed some tries to get it right. I guess I just change the line to <0.75_6 in portaudit since it is not really beneficial to allow 0.75_4... Lets see how we can integrate VuXML. Anyone a VuXML -> flat XSLT style sheet? -Oliver