ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #108 [Security Mailing List] (1 message, 1392 bytes)
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
From: [email protected] (Mark A. Verber)
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 [email protected]). 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. [email protected]) 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
|ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved.|