full-disclosure - Re: [caudium-devel] [SECUNIA] Regarding Secunia Advisory SA13040

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] [day] [month] [year] [list]

Message-ID: <20041222141222.GA12308@beowulf.thanes.org>
From: grendel at caudium.net (Marek Habersack)
Subject: Re: [caudium-devel] [SECUNIA] Regarding Secunia
	Advisory SA13040

On Wed, Dec 22, 2004 at 02:47:30PM +0100, Thomas Kristensen scribbled:
> Hi Xavier,
> 
> The information in Secunia Advisory SA13040 is based on your own
> Changelog at Sourceforge.
> 
> SA13040:
> http://secunia.com/SA13040
> 
> On 30th November you wrote to Secunia that this only affected the 1.4
> branch. One hour later Secunia updated the advisory to reflect this and
> you received an answer with a confirmation that we had updated the
> advisory.
You should have done that in the first place - before posting any
information about bugs. By releasing such erroneous advisories you do a
malservice to both the vendors and the community. One effect of your
advisory was that nessus started flagging all scanned machines running
Caudium as vulnerable. That, for some people, generated costs in real money
- all because of your lack of willingness to provide the community with the
accurate and trustworthy information. Personally, I will regard any other
advisory from Secunia as unreliable.

> 
> If you spotted any other omissions back then, you could have contacted
> us again - obviously you didn't.
>
> 
> Additionally, any information listed in product changelogs is considered
> public knowledge. Naturally, we don't contact vendors before issuing
> advisories based on information in their own changelogs / release notes.
Do you find is as natural not to perform any tests to confirm your advisory?
Also, is it customary to release advisories about non-released or
development projects that are moving targets? I suppose we will have to
forget about the OSS rule "release soon, release often" - since any bug in a
development (CVS/SVN/Arch/whatever) version will be considered a serious
security threat.
 
> Also, we are not going to remove this advisory, as it is based on your
> own information. However, if you have any relevant additional
> information, we will naturally review them and update the advisory
> accordingly.
I can see a splendid opportunity to fool Secunia. I will start putting false
changelog entries in our repositories announcing all kinds of grave and
serious errors. I would love if other vendors start doing that as well - I
wonder how would you, as professionals, look if it started to turn out that
your "advisories" are cut-and-paste's from vendor development changelogs -
untested, unconfirmed, unchecked.

> 
> Kind regards,
best regards and I hope you will take the time during the upcoming holidays
to think about the way you do your work - since it is affecting other
people's work, you are obliged to take every step and measure to prevent
unreliable information from coming out from you.

And a single note below - please don't take what I wrote personally. Treat
it as something coming from professional to professional.

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20041222/4dc3bc2e/attachment.bin