From owner-freebsd-security Mon Jul 20 19:38:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21130 for freebsd-security-outgoing; Mon, 20 Jul 1998 19:38:29 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from pobox.com (jaresh-26.mdm.mke.execpc.com [169.207.81.154]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA21118 for ; Mon, 20 Jul 1998 19:38:18 -0700 (PDT) (envelope-from hamilton@pobox.com) Message-Id: <199807210238.TAA21118@hub.freebsd.org> Received: (qmail 1478 invoked from network); 20 Jul 1998 21:40:35 -0500 Received: from localhost (HELO pobox.com) (127.0.0.1) by localhost with SMTP; 20 Jul 1998 21:40:35 -0500 To: Brett Glass cc: "Matthew N. Dodd" , "Christopher G. Petrilli" , "Gentry A. Bieker" , security@FreeBSD.ORG Subject: Re: Why is there no info on the QPOPPER hack? In-reply-to: Your message of "Mon, 20 Jul 1998 17:52:20 MDT." <199807202352.RAA27271@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Jul 1998 21:40:35 -0500 From: Jon Hamilton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199807202352.RAA27271@lariat.lariat.org>, Brett Glass wrote: } Thousands (maybe tens or hundreds of thousands) of systems have been } potentially compromised because that code was in the FreeBSD Ports } library. I'd find it hard to believe that such a scheme would do } anything but improve the odds that the hole would be closed. I still think you're just ranting. What does it mean to "have been potentially compromised" anyway? } And, no, CVSup is not an answer. On production machines, you don't } want to CVSup to the latest version -- you just want to pick up } known good patches for significant problems. Maybe you've been working too long and too hard cleaning up after your breakin. CVSup would work fine for what you're talking about, you'd just have to have a different tag which only got "known good patches for significant problems". Of course, this would still have the problem of being a "pull" model, so you'd have to check "often enough". You'd also have to be damn sure you trusted the person doing the checkins, and you'd have to be sure that you were in fact talking to the server you decided to trust. And you'd have to be certain that you trusted the patch as applied, both that it solved the problem it was meant to solve, and that it didn't introduce some other bogosity. Most of these should be red flags shouting out that you don't really want to automate this process, but I don't imagine that'll slow you down much. I don't have solutions to all those problems, but then again I'm not the one jumping up and down saying that we've got to have solutions to this problem affecting "maybe tens or hundreds of thousands" of systems. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message