REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

Tomas Mraz tmraz at redhat.com
Wed Sep 22 15:01:02 UTC 2010


On Wed, 2010-09-22 at 16:09 +0200, drago01 wrote: 
> On Wed, Sep 22, 2010 at 3:34 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> 
> >> > This example is IMO wrong:
> >> > - WebKit requires an update to solve a security problem. This requires
> >> > updating Midori to a version with some minor menu layout changes. This
> >> > would be a judgement call based on how intrusive the changes are
> >> > (removing the File menu would be rude, but moving the plugin
> >> > configuration menu item would be acceptable).
> >> > In this case even major changes in user experience are justified -
> >> > knowingly insecure web browser just should not be used.
> >>
> >> That isn't any different than the firefox example on the page i.e
> >> already covered.
> > Yes, and that's the reason the example is wrong and it should be
> > removed.
> 
> Not sure I follow you here ... you point out a problem and a solution
> which is _exactly the same_ as the people who drafted the proposal
> though about and now you say "it is wrong and should be removed".
I say that the example of Webkit should be removed because if it is not
possible to backport the security patch and due to the version update
Midori has to be updated to a new version regardless of the changes of
user experience. The part of the example "judgement call based on how
intrusive the changes are" does not make any sense. We just cannot keep
the old insecure version regardless on how intrusive the changes are.

> What do you propose instead? Shipping insecure browsers?  Let me quote
> you "knowingly insecure web browser just should not be used."
> 
> In case you didn't get what the example is trying to say "in such
> cases changes like that are justified" .
No, it doesn't say that, quite opposite of that.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



More information about the devel mailing list