[Mageia-dev] (second attempt) suggesting sectool be dropped

Fri Nov 18 14:38:53 CET 2011

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
+