Security issues are not public until they are released, and then nobody
generally remembers to go back and make them public. This is not
“security by obscurity” even if left blocked from the public, though, as
this is not a way to ensure security but just a way to keep issues from
being exploited before a patch is released.
Good luck.
On 01/06/2011 10:06 AM, geuder wrote:
>
> When installing security fixes to one of my OpenSUSE 11.3 systems, there
> was a fix to openssl.
>
> The description said:
>
>> For more information about bugs fixed by this update please visit this
>> website:
>> • https://bugzilla.novell.com/show_bug.cgi?id=657663.
>
> However, this bug report seems to be read-protected:
>
>> You are not authorized to access bug #657663.
>
> I hope this is just some mistake and not some general “security by
> obscurity” policy.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
OK, but I clicked the link from a publicly released patch
So you say this is not a an exceptional case and people at SUSE seem to be aware of the problem. I think it shows a lack of respect for the user / community, if you routinely put URLs into the patch description although the target is read-protected.
Of course it’s only human that nobody remembers to do it manually. But it shouldn’t be to difficult to write a script that ensures that the protection of the bug report is changed as soon as the patch goes public. Or the other way round doesn’t put the patch to the general repo until the bug report has been opened. Whatever is easier and suits your processes.
If somebody thinks this not feasible / worth doing then I’d suggest to change the patch description to better reflect the truth:
< For more information about bugs fixed by this update please visit this website:
> We don’t give further comments about security fixes.
> I think it shows a lack of respect for the user
> / community, if you routinely put URLs into the patch description
> although the target is read-protected.
Well, not really - we all make mistakes, and it seems that this may well
be the case in this instance. Never attribute to malice that which may
well be attributable to forgetfulness.
In other words, just because it wasn’t made readable doesn’t mean that
was ever the intention or that it was done intentionally. ab’s saying
essentially the same thing - someone most likely made a mistake. That
someone is only human, just like the rest of us.
fix bug [bnc#657663]
CVE-2010-4180
for CVE-2010-4252,no patch is added(for the J-PAKE
implementaion is not compiled in by default).
</quote>
Looks like it may not have been an issue as a result. I’m using OpenSUSE
11.3 x86_64, btw, w/OpenSSL 1.0.0.
Good luck.
On 01/06/2011 12:50 PM, Jim Henderson wrote:
> On Thu, 06 Jan 2011 19:36:02 +0000, geuder wrote:
>
>> I think it shows a lack of respect for the user
>> / community, if you routinely put URLs into the patch description
>> although the target is read-protected.
>
> Well, not really - we all make mistakes, and it seems that this may well
> be the case in this instance. Never attribute to malice that which may
> well be attributable to forgetfulness.
>
> In other words, just because it wasn’t made readable doesn’t mean that
> was ever the intention or that it was done intentionally. ab’s saying
> essentially the same thing - someone most likely made a mistake. That
> someone is only human, just like the rest of us.
>
> Jim
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On 2011-01-06 20:50, Jim Henderson wrote:
> On Thu, 06 Jan 2011 19:36:02 +0000, geuder wrote:
>
>> I think it shows a lack of respect for the user
>> / community, if you routinely put URLs into the patch description
>> although the target is read-protected.
>
> Well, not really - we all make mistakes, and it seems that this may well
> be the case in this instance. Never attribute to malice that which may
> well be attributable to forgetfulness.
I have reported a similar issue with another security update in a major
bugzilla, because the report was locked. This bugzilla has not even
answered in months.
Which I consider bad policy, lack of respect, whatever.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
The internal process requires us to put bugnumbers into all the patches.
Unfortunately we cannot make all security bugs public, and making the others public is an additional manual screening process. We however try to make as much of them public as possible.
> Unfortunately we cannot make all security bugs public, and making the
> others public is an additional manual screening process. We however try
> to make as much of them public as possible.
I understand, but…
In that case, the bugzilla number should not be listed in the update
report, as we can not read it, anyway. It is a waste of time for us users.
At a minimum, list those bugzillas in a list with a warning that they are
restricted, and give a link to something else that we can read instead,
that justifies that particular update.
IMO, the proper solution would be to have an open, public, bugzilla report,
with the information that can be disclossed, and this bugzilla points to
the reserved one. Only the open version should be listed in the update
advisory.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
True. I’m aware that there are numerous resources to find out more. There is the changelog in the RPM package, the CVE number and last but not least this is open source, so just read the source
My point was just: If you write into a patch description: See http://foo.bar for more info, the target page should not read: “not authorized”
Yep, Access Denied is readable now. Thanks for prompt action.
Fully agree, that’s why I wrote I’d hope it’s just a mistake in my first post.
However, ab’s answer looked to me like this although not being policy, is a known problem:
And if “nobody generally remembers” to do something users need, then it’s time to write a script, if you care about them.
(Yes, I admit that I was readily in semi-attack mood when posting. Which you should never be when posting on the net. Closed security bug reports even after releasing a fix are a common problem with many software suppliers, and I have been angry before. But the fact that this bug report was opened within less than a day after my posting shows that SUSE is still positioned at the better end.)