From owner-freebsd-security Sat Sep 30 8:38:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C5EFE37B502; Sat, 30 Sep 2000 08:38:42 -0700 (PDT) Received: from localhost (qunvwv@localhost [127.0.0.1] (may be forged)) by green.dyndns.org (8.11.0/8.11.0) with ESMTP id e8UFcb538293; Sat, 30 Sep 2000 11:38:38 -0400 (EDT) (envelope-from green@FreeBSD.org) Message-Id: <200009301538.e8UFcb538293@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jordan Hubbard Cc: Roman Shterenzon , Kris Kennaway , security@FreeBSD.org Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) In-Reply-To: Message from Jordan Hubbard of "Sat, 30 Sep 2000 01:05:23 PDT." <97960.970301123@winston.osd.bsdi.com> From: "Brian F. Feldman" Date: Sat, 30 Sep 2000 11:38:36 -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So, how about it? Should we set up a page so we have a URL to put in the > > Pine insecurity notice that shows, "you can live without Pine"? I'd propose > > the first two most popular mailers (it seems) after Pine: mutt and exmh. > > I seriously doubt anybody would be willing to go to that much trouble, > making this suggestion sort of a no-op at best. It seems to me that > we'll be getting just a tad like those 50's politicians who saw > communists under every bed if we're just going to start blacklisting > useful ports left and right without fixing them. If we can prove a > vulnerability (and not just the risk of one, since risks are > everywhere) then we should FIX the vulnerability and move on. We > don't have to get the changes taken back and we don't have to do > anything fancier than drop patches into the relevant ports > directories. > > - Jordan Who has the motivation (of any type) to find and fix the likely hundreds of security problems left, though? Kris marked it forbidden because it's just too much work that's never going to get done to have even a reasonable assurance of its safety. But, you propose actively finding which of those problems in the code are vulnerabilities -- that's even more work than just fixing them. If anyone wants to create a "secure pine" patchset, which will likely end up in the hundreds of kilobytes, I'm sure that would be a good reason to not mark pine as forbidden. Another possibility might be to force pine into a chroot... I guess the only good advice to give if you HAVE to run pine is to run it inside a jail. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message