full-disclosure - Beta Advisories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: poof at fansubber.com (Poof)
Subject: Beta Advisories

Well, I'm personally all for announcing a beta advisory. However, when I'm 
all for it is as follows:

Example. Eudora posts a PUBLIC beta on their website. Then fine, announce 
the bug anywhere. However, when it's private. It should go the normal bug 
ways. To the devs so they can fix it. Fine, it may take a build or two. But 
it'll be fixed.

Also, I do consider gmail slightly private as it IS 'invite only'. So yes, 
you should wait before reporting this. On betas the devs are usually extra 
busy as they're currently having to write code everywhere. They're not just 
lounging around waiting for bug reports.

~
Yes, I know this isn't written very well... However...

>
> Yes, and the OIS guidelines are thinly veiled "Oh please don't tell the
> world that we have had this bug for 6 months...we'll look bad" methods for
> being able to quash the full disclosure model and take the  pressure of
> "respond to me, get it fixed, or thr world is going to know about it" off
> the vendors.  Do you really think that the vendors will expend resources
> to fix things just because it is "the right thing to do"?   Please tell me
> you're not that naive...please.
>
> I'm not advocating playing bombs away, sneak attacking a vendor by issuing
> a 0-day disclosure publicly.  I sure as hell am saying that a vendor
> knowing the vuln will in fact be disclosed after a reasonable period of
> time, fixed or not, has certainly motivated more than a few to get the fix
> done prior to taking a public black eye.
>
> Bart Lansing
> Manager, Desktop Services
> Kohl's IT
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2342 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040706/c879bf47/smime.bin