Re: Midori for Squeeze
On Mon, 18 Oct 2010 19:03:45 +0200, Moritz Muehlenhoff wrote:
> In gmane.linux.debian.devel.release, you wrote:
> > On 17/10/2010 22:08, Moritz Muehlenhoff wrote:
> >> Hi Ryan/release team,
> >>
> >> During my review of open security issues I noticed that the
> >> version of Midori currently in Squeeze still has broken
> >> HTTPS support. (#582213)
> >
> > This bug is only about packaging a new upstream release, maybe you were
> > referring to #595813 ? Though afair midori in squeeze does support https
> > (meaning, it can connect to an https website).
>
> I'm referring to http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;bug=582213:
>
> | it would be really nice to get 0.2.6 into squeeze. 0.2.5 introduced
> | basic HTTPS certificate validation support, which is essential to do
> | any serious HTTPS stuff which isn't only snakeoil security, like online
> | banking. Previous midori releases supported HTTPS, but don't validate
> | the server certificate against root certificates.
>
> >> We shouldn't ship a browser with the state as-is. We could
> >> either drop it or update to the version currently in sid?
> >
> > The version currently in sid is already outdated though (I've made some
> > packaging for 0.2.8 but didn't upload yet, still not sure about taking
> > over maintainership...)
> >
> > In any case, the https support by midori is working but not really
> > satisfying. The browser can connect to https website, and in recent
> > versions even change the url bar color, but that's all. There's no
> > configuration support, no way to add an AC or a client certificate, no
> > way to see the certificate a website is using.
> >
> > Some might think that makes the browser unusable and unsuitable for
> > Squeeze, I'm not so sure. It's a shame the browser doesn't have a real
> > https support, but it's still working and is a nice little browser. I
> > don't think it should be installed by default but it's still useful in a
> > stable release (imho).
>
> Weööll, ie HTTPS support is so limited, it's unlikely to be used
> anyway, so we might just as well leave the current version in.
Should the NEWS.Debian file state this to increase the likeliness of
users being aware of the limitations?
Mike
Reply to: