Hello, > This Symantec posting contains minimal security information. In December > 2000[1] @stake modified their Bugtraq postings to include a small amount > of security information and a link back to the @stake website where the > full advisory resided. The intention was to have a bit more control over > the way people viewed the advisories. They would be viewed on the @stake > website only and not serve as content for for-profit advertising supported > websites. The advisory could also be updated if there were errors or > updates and it would serve as the canonical reference. > > Elias Levy, the Bugtraq moderator at the time, rejected the posting on the > grounds that it contained minimal security information. His reasoning was > that forcing people to go to an additional website was inconvenient and > that if the advisory website ever went away the original advisory would be > lost. He had a good point and @stake changed back to the old format. > > One of the ironies of the security world is Symantec purchased > SecurityFocus and then later @stake. After purchasing @stake, Symantec > removed the @stake advisory archive, thus bringing Elias' fear to reality. > > Elias' reasoning still holds true today. Companies come and go, are > acquired or change course. Symantec should post its full advisories to > the list and so should everyone else. > > -Chris > > 1. Bugtraq: Administrivia & AOL IM Advisory, > http://seclists.org/bugtraq/2000/Dec/0197.html I had initially addressed a personal response to Chris Wysopal describing the policy with regards to this subject, but I see that this has made the rounds so I feel that it is necessary to respond to the list in an effort to clear things up. It is normally our policy to restrict postings that contain very little content and refer readers to an external site to get more information. I do agree with the original sentiment that the list should be the canonical source of information about the vulnerabilities that are posted to it. Asides from the SecurityFocus vulnerability database, there are a number of other entities which use the list as a common point of reference (such as Mitre's CVE dictionary and the OSVDB, among others), so it is my intent that Bugtraq can continue to serve as an authoritative archive for vulnerability reports. This is why on many occasions I have rejected posts that contain too little information or where most of the information is hosted on external site. In enacting this type of policy, there is always the risk that such posts will not be resent, or that they will be delayed -- and this is a risk I have taken in numerous instances to uphold the policy that Bugtraq posts should serve as a canonical and complete reference for a reported vulnerability -- of course this is not always the case as many posters do not continue to post updates after the initial report, but to the extent that I can control this, I will endeavor to do so. This being said, there are some occasions where exceptions have been made. Notably, if I feel that a vulnerability was important enough or high priority enough to go to the list immediately. Though this example predates the list handover, this was the case with the initial report of the WMF SetAbortProc vulnerability in December of 2005, which was a one-liner pointing towards an exploit that compromised a fully patched Windows box. There is also the exception that was made in regards to Symantec advisories. Symantec product security used to post entire advisories to the list, but at some point a few months ago, their advisory publishing processes had changed. The side effect of this change in process was that the full advisories that were being sent to the list had broken signatures. So we tried various methods to fix the process so that the advisories would arrive with their signatures intact. Eventually, we opted for shorter advisories since this was less error prone. I rationalized this exception to myself by considering that this information would be hosted on the Symantec product security advisories page for the long term and did not really feel that there was an imminent threat to the information disappearing any time soon. However, Chris has made some good points, and so have requested that the Symantec advisories contain more content, and it has been agreed that Symantec will not be excepted from this policy in the future. In short, I do believe that the concerns expressed by Chris Wysopal are legitimate, and there is always the risk of "information decay" as sites disappear. This is actually a real issue that we have experienced in maintaining the SecurityFocus vulnerability database and I personally sympathize with anybody who is tasked with maintaining a large amount of historical data that depends on external sources that are constantly disappearing or moving around. It is unfortunate what happened to the @stake advisory archive, and also that many other forums have disappeared over the years. -- Dave McKinney Symantec keyID: BF919DD7 key fingerprint = 494D 6B7D 4611 7A7A 5DBB 3B29 4D89 3A70 BF91 9DD7
