The 'Security Digest' Archives (TM)

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #108 [Security Mailing List] (1 message, 1392 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/108.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: verber@diplodocus.cis.ohio-state.edu (Mark A. Verber)
To: phage
Date: Fri 10:10:39 04/11/1988 EST
Subject: Security Mailing List
References: [Thread Prev: 067] [Thread Next: 037] [Message Prev: 024] [Message Next: 025]

The security mailing list died about a year ago due primarily to
inactivity.  With the recent FTP problems, the virus attack, and the
general growth of the Internet I think it is about time for the list
to return.  I would suggest the following:

#1. Create Restricted Mailing List

With the old security mailing list the only requirement was an OK from
the root of the system (other than home computers).  I would like to
suggest that there would be a trusted group of people to start the
mailing list (mabye start with phage@purdue).  People would need
someone who was on the list already to vouch for them, an OK from the
person's home root, and that their name be circulated to the mailing
list to see if anyone objects.  I am suggesting these additional
requirements because I know of people (now in retrospect) that
shouldn't have been on the old list who would not qualify with these
additional requirements.  I would also suggest that there are no
aliases (i.e. postmaster@moby.foo.bar) but mail would be sent to
individuals only.

#2. Security Repository

The are a number of sites who don't have source, yet they want holes
fixes.  For some problems, it is easy enough to patch a binary with
adb, but for other problems that is not enough.  I would suggest a
ftp site on the Internet that would keep binaries to patched programs.
I would suggest Sun-3, Sun-4, and Vaxen binaries.  Possibly other
machines (i.e. Pyramid, Sequent, Encore, HP) if there seems to be enough
of an interest.

#3. Get Vendors Involved

There should be at least one rep. from each major UNIX box vendor who
would be responsible for get fixes into release software.  This
doesn't seem to be much of a priority with vendors right now.  I think
we should collectively scream bloody murder until the see a bit more
responsiveness from our friends.

#4. Hole List

I think it *might* be a good idea to develop a list of security holes
that should be checked.  This list should have a very limited
circulation.  This list should not live on the same machine as the
security mailing list of the archives.  It should be mailed from a
system other than it's home (otherwise that machine become a prime
spot for breaking).  On the other hand, having such a list might be
too risky.

Cheers,
Mark A. Verber
Ohio State Univ.

END OF DOCUMENT