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>] [day] [month] [year] [list]
From: kiwi at oav.net (Xavier Beaudouin)
Subject: Re: [caudium-devel] [SECUNIA] Regarding Secunia
	Advisory SA13040



D?but du message r?exp?di? :

> De: Marek Habersack <grendel@...dium.net>
> Date: 22 d?cembre 2004 15:12:22 GMT+01:00
> ?: caudium-devel@...dium.net
> Cc: kiwi@...dium.net, vuln@...unia.com, vulnwatch@...nwatch.org, Full 
> Disclosure <full-disclosure@...ts.netsys.com>
> Objet: R?p : [caudium-devel] [SECUNIA] Regarding Secunia Advisory 
> SA13040
> R?pondre ?: caudium-devel@...dium.net
>
> 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
>
--
Xavier Beaudouin - Unix System Administrator & Projects Leader.
President of Kazar Organization : http://www.kazar.net/
Please visit http://caudium.net/, home of Caudium & Camas projects



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ