On 18/11/11 10:37, Colin Guthrie wrote:
'Twas brillig, and Claire Robinson at 17/11/11 12:49 did gyre and gimble:
On 17/11/11 10:26, Michael scherer wrote:
On Tue, Nov 15, 2011 at 11:39:29AM +0100, Florian Hubold wrote:
Am 15.11.2011 07:29, schrieb Michael Scherer:
Le lundi 14 novembre 2011 à 22:09 -0800, Robert M. Riches Jr. a écrit :
(New list subscriber...needed to fix registered email address to
post...)
I was asked to submit this suggestion to the mailing list:
As a Mageia user, I believe msec was much better off with_OUT_
sectool. In its present state, sectool is BADLY broken. It
whines for pages about file permissions that are exactly as they
should be.
Can you be more specific ?
It think he means this: https://bugs.mageia.org/show_bug.cgi?id=2808
or https://bugs.mageia.org/show_bug.cgi?id=2255#c21 or
https://bugs.mageia.org/show_bug.cgi?id=2255#c22
I've also become supportive of this, sectool is basically duplicating
partly msec functionality, there was no adaption for Mageia,
currently it's
checking on Mageia with the upstream Fedora configuration.
Honestly this should have been done when importing it, as
tmb already mentioned. msec should be patched to not require it.
When we can't even get our default security tool to work properly,
what's the point in adding a second one which needs even more
maintenance?
As you say, the question is again "why was it uploaded in the first
place".
It seems some packages were uploaded, and there seemed to have not enough
tests. While that's hard or impossible to avoid totally, that's not
really
the way to achieve a good distribution :/
I neither use msec or sectool, so I personnaly do not care that much.
Afaik, sectool was created by a ex mandriva/mandrake guy ( vincent
danen ),
because he was ( rightfully ) wanting to rewrite msec, who is/was
a mess of bash + python + perl code ( and rather ugly code, afaik,
last time
I took a look ), but if msec is supported, and sectool is not, then I
guess
we could drop. However, I still think we should first attempt to
collaborate
and fix it. ( ie, always have the reflex of "try to fix and
collaborate" ).
As one of the people who tested it and the one who filed the bug linked
to above which expresses the need for it to be configured, I object to
this being blamed on QA! It seems we are kicked whenever anything is wrong.
I believe it is assigned to those higher up to provide a proper
configuration.
The bug was dated 22nd September and as yet no configuration exists.
That does not reflect well on the distribution, not that QA haven't
performed sufficient testing, which we obviously did.
Knowing misc a little bit I don't think for a second he was intending to
blame QA team here.
More the initial "blind import" (which was a hard time to do overly much
testing as I'm sure all will agree!) without properly checking things then.
So please don't take it personally, I really don't think he was
targeting you :)
Col
A bug was created for the issues found during testing to be resolved. No
new issues have arisen since then.
What is being discussed now are only the issues raised by QA at the time
showing, if anything, that testing was quite thoroughly completed. No
extra testing time was necessary.
I don't take this personally and I hope you will see this correction of
the facts in the same light. This is the second time in a week though
that QA has had to offer corrections against the assumption of a level
of neglect.
Claire
