Sun Support's habit of publicizing private bug reports

July 13, 2010

I was reminded today of one of the reasons that I am not too fond of Sun Support, by encountering this bug entry through a message in the ZFS mailing list.

This is a public OpenSolaris bug report. Except it is not; almost all of the text is an email message from me to Sun Support that was one part of our ongoing adventure with FAULTED ZFS spares. We have a commercial Sun support contract and we made our bug reports via it (and worked on Sun Support through it). We were very definitely not reporting this bug publicly, and my email was not written for public consumption, or even for consumption without the entire previous email conversation.

(It should go without saying that the 'work around' in that report is in fact completely bogus and inapplicable to our situation. Sun later admitted that there was a race condition adding the same spare disk to multiple ZFS pools in Solaris 10 Update 6, which is perhaps mostly fixed in S10U8.)

Yet there it is, posted publicly, including an URL that was very much intended only for Sun's internal consumption and which reveals a directory that contains (well, contained) configuration information for some of our internal systems.

This is not the first time I have seen Sun Support take our bug reports and post them (or elements of them) into public places. A previous bug report of ours was sent to one of the OpenSolaris web forums in a slightly redacted form; we discovered this by later searching for other people having the same problem. And if they've done it at least twice for us, I'm sure that they've done it for other people too.

Of course, we have never been warned that this would happen with our bug reports or even informed about it. Nor has anyone from Sun Support ever asked us what we consider internal information that cannot be publicly disclosed. And yes, our bug report contains potentially sensitive information; for example, I'm sure that there are environments where the ZFS pool names are sensitive because they refer to things such as non-public projects.

(I want to make it clear that I do not object to public bug databases as such. What I object to is the surprise appearance of private bug reports in those public bug databases. It is especially aggravating in this situation because Sun blew off that particular bug report message, so they were not even tracking what they considered an actual bug here.)

Of course this behavior may have changed now that it is Oracle Support (assuming that you can get support at all).

Written on 13 July 2010.
« Single-level list flattening in Python
The challenges of shared spares in RAID arrays »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jul 13 18:11:09 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.