Valerie Bubb Fenwick writes: > > Seems like a mistake that these sorts of bugs can't be viewed via > > bugs.opensolaris.org ... > > Hi Jim - > > It's because it's tagged as a security vulnerability. Unfortunately, our > process
Yeah, I know how it ended up this way. It still seems broken to me, as we send out these scary-looking notices to the field, and then the recipients (particularly those participating in the OpenSolaris effort, and thus presumably _developers_) can't get to the necessary background information. > "security" - there's no distinguishing between "resolved & now okay to > publish" > and "still in progress/don't publish yet". Right. Even in that case, and even if we think that hiding this information is a good idea, it'd make sense to publish the "fixed in" information, as that's rather important for users. (Yes, in this case, the user could have deduced that bit of data from the alert, if read correctly. That's beside the point.) > It's tricky, even, to figure this out programitically, because we use a > single CR > for tracking issues accross multiple releases - so something may be > "resolved" for > one release, but not for all affected releases so we wouldn't be able to > publish > yet. And, some affected releases may not get patched (for example, many years > past > EOSL). It is something we've started talking about, but no good solutions > have > been proposed at this point. Fortunately (?), the MR data seem to be obscured in bugs.opensolaris.org anyway. Of course, those who are really curious can always go look at the Mercurial repository and examine the exact code changes made for the associated CR, so it's not as though we're hiding much information. We're just making it harder to use and driving up the cost by providing one-off answers to those who call and ask. :-/ -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677