Debian Bug report logs - #702976
epiphany-browser: domainname not checked on https

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: epiphany-browser: domainname not checked on https

Date: Wed, 13 Mar 2013 17:29:16 +0100

Package: epiphany-browser
Version: 3.4.2-2.1
Severity: critical
Tags: security
Justification: breaks unrelated software


Hi.

Marking this as critical/breask-unrealted-software, as it may allow
attackers to spoof people into downloading forged software/etc.


It seems that epiphany does at least not check the domainname correctly
when connection to a site via https.

For example, when I go to:
https://physik.lmu.de/~mitterer/
it redirects me automatically to
https://homepages.physik.uni-muenchen.de/~mitterer/
without any complaining.

The certificate presented by that server, is however only issued
for the CN homepages.physik.uni-muenchen.de.

That means that an attacker can easily redirect me to a site with
a valid cert, which is under his control.


Cheers,
Chris.


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages epiphany-browser depends on:
ii  dbus-x11                   1.6.8-1
ii  epiphany-browser-data      3.4.2-2.1
ii  gnome-icon-theme           3.4.0-2
ii  gsettings-desktop-schemas  3.4.2-3
ii  iso-codes                  3.41-1
ii  libavahi-client3           0.6.31-2
ii  libavahi-common3           0.6.31-2
ii  libavahi-gobject0          0.6.31-2
ii  libc6                      2.13-38
ii  libcairo2                  1.12.2-3
ii  libgdk-pixbuf2.0-0         2.26.1-1
ii  libgirepository-1.0-1      1.32.1-1
ii  libglib2.0-0               2.33.12+really2.32.4-5
ii  libgnome-keyring0          3.4.1-1
ii  libgtk-3-0                 3.4.2-6
ii  libice6                    2:1.0.8-2
ii  libnotify4                 0.7.5-2
ii  libnspr4                   2:4.9.5-1
ii  libnspr4-0d                2:4.9.5-1
ii  libnss3                    2:3.14.2-1
ii  libnss3-1d                 2:3.14.2-1
ii  libpango1.0-0              1.30.0-1
ii  libseed-gtk3-0             3.2.0-2
ii  libsm6                     2:1.2.1-2
ii  libsoup-gnome2.4-1         2.38.1-2
ii  libsoup2.4-1               2.38.1-2
ii  libsqlite3-0               3.7.15.2-1
ii  libwebkitgtk-3.0-0         1.8.1-3.4
ii  libx11-6                   2:1.5.0-1
ii  libxml2                    2.8.0+dfsg1-7+nmu1
ii  libxslt1.1                 1.1.26-14

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20130119
ii  evince           3.4.0-3.1
ii  yelp             3.4.2-1+b1

Versions of packages epiphany-browser suggests:
ii  epiphany-extensions  3.4.0-2

-- no debconf information

Message #10 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Vincent Danen <vdanen@redhat.com>

To: 702976@bugs.debian.org

Subject: CVE-2010-3312

Date: Wed, 13 Mar 2013 11:58:02 -0600

This issue was given the name CVE-2010-3312 quite a while ago.  See
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3312 for more info.

-- 
Vincent Danen / Red Hat Security Response Team 

Message #17 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Sébastien Villemot <sebastien@debian.org>

To: Vincent Danen <vdanen@redhat.com>, 702976@bugs.debian.org

Subject: Re: Bug#702976: CVE-2010-3312

Date: Wed, 13 Mar 2013 22:12:25 +0100

[Message part 1 (text/plain, inline)]

Le mercredi 13 mars 2013 à 11:58 -0600, Vincent Danen a écrit :
> This issue was given the name CVE-2010-3312 quite a while ago.  See
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3312 for more info.

I don’t think this is the same issue. The problem reported here is
specifically about redirections, while CVE-2010-3312 (#564690 in Debian)
was about *never* verifying SSL certs (and is now fixed).

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Sébastien Villemot <sebastien@debian.org>

To: Vincent Danen <vdanen@redhat.com>

Cc: 702976@bugs.debian.org

Subject: Re: Bug#702976: CVE-2010-3312

Date: Wed, 13 Mar 2013 23:10:41 +0100

[Message part 1 (text/plain, inline)]

Le mercredi 13 mars 2013 à 15:59 -0600, Vincent Danen a écrit :
> * [2013-03-13 22:12:25 +0100] S?bastien Villemot wrote:
> 
> >Le mercredi 13 mars 2013 à 11:58 -0600, Vincent Danen a écrit :
> >> This issue was given the name CVE-2010-3312 quite a while ago.  See
> >> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3312 for more info.
> >
> >I don???t think this is the same issue. The problem reported here is
> >specifically about redirections, while CVE-2010-3312 (#564690 in Debian)
> >was about *never* verifying SSL certs (and is now fixed).
> 
> Well, the issue in our bugzilla is still not fixed in the latest Fedora
> version and since the bug is about epiphany not validating certificates
> in general.  Are you sure it's fixed?  If it's fixed in Debian but not
> upstream, then this should probably be classified as a separate issue
> (but from where I sit, we have 3.6.1 in Fedora 18 and it doesn't seem to
> do anything right with regards to SSL certificates).

In Debian, with version 3.4.2, visiting a site with an invalid SSL
certificate leads to the display of a broken-lock icon in the right
hand-side of the address bar. This was considered as sufficient for
Debian, see bug #603594 for more details on this.

OTOH, when I visit the URL reported by the submitter, I get the (normal)
lock icon, i.e. epiphany considers that the site is secure (even though
the certificate common name does not match the hostname typed by the
user).

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 702976@bugs.debian.org

Subject: Re: Bug#702976: epiphany-browser: domainname not checked on https

Date: Wed, 13 Mar 2013 23:23:22 +0100

Le mercredi 13 mars 2013 à 17:29 +0100, Christoph Anton Mitterer a
écrit :
> It seems that epiphany does at least not check the domainname correctly
> when connection to a site via https.
> 
> For example, when I go to:
> https://physik.lmu.de/~mitterer/
> it redirects me automatically to
> https://homepages.physik.uni-muenchen.de/~mitterer/
> without any complaining.

I don’t even see it as a bug. 
Epiphany treats the first site as a self-signed one, which thus has the
same level of security as a non-encrypted connection.

When you are redirected, however, it is the responsibility of the user
to check the domain name the connection is certified for. The fact that
a connection is encrypted does not mean anything else that “you are
actually connecting to this domain”. If you can’t trust the domain, you
can’t trust the connection.

You could argue that, when faced with a non-certified https connection,
epiphany should not follow redirections without a warning, but I’m not
even sure upstream would agree, and I definitely don’t think this is a
RC bug.

Cheers,
-- 
.''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #32 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Vincent Danen <vdanen@redhat.com>

To: S?bastien Villemot <sebastien@debian.org>

Cc: 702976@bugs.debian.org

Subject: Re: Bug#702976: CVE-2010-3312

Date: Wed, 13 Mar 2013 16:25:40 -0600

* [2013-03-13 23:10:41 +0100] S?bastien Villemot wrote:

>Le mercredi 13 mars 2013 à 15:59 -0600, Vincent Danen a écrit :
>> * [2013-03-13 22:12:25 +0100] S?bastien Villemot wrote:
>>
>> >Le mercredi 13 mars 2013 à 11:58 -0600, Vincent Danen a écrit :
>> >> This issue was given the name CVE-2010-3312 quite a while ago.  See
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3312 for more info.
>> >
>> >I don???t think this is the same issue. The problem reported here is
>> >specifically about redirections, while CVE-2010-3312 (#564690 in Debian)
>> >was about *never* verifying SSL certs (and is now fixed).
>>
>> Well, the issue in our bugzilla is still not fixed in the latest Fedora
>> version and since the bug is about epiphany not validating certificates
>> in general.  Are you sure it's fixed?  If it's fixed in Debian but not
>> upstream, then this should probably be classified as a separate issue
>> (but from where I sit, we have 3.6.1 in Fedora 18 and it doesn't seem to
>> do anything right with regards to SSL certificates).
>
>In Debian, with version 3.4.2, visiting a site with an invalid SSL
>certificate leads to the display of a broken-lock icon in the right
>hand-side of the address bar. This was considered as sufficient for
>Debian, see bug #603594 for more details on this.
>
>OTOH, when I visit the URL reported by the submitter, I get the (normal)
>lock icon, i.e. epiphany considers that the site is secure (even though
>the certificate common name does not match the hostname typed by the
>user).

Ahh, ok, understood.

Yeah, this might be a different problem although when I looked at the
examples you have, it was an actual redirect, so despite the user typing
one thing and then there being a redirect, the URL in the browser
matches the certificate.

I don't think I would consider that a security flaw.  Google Chrome
doesn't think so either.  For instance, I added a PHP script to redirect
from one valid HTTPS site to a completely different HTTPS site (using
the header() function) and Chrome still gives me the green padlock,
despite me typing one thing and ending up somewhere completely
different.

I wouldn't consider this a security flaw.  This is just how it works.
FWIW, Firefox acts the same way.  Visit
https://annvix.com/images/redirect.php and it will take you to github,
both HTTPS, no complaints.

-- 
Vincent Danen / Red Hat Security Response Team 

Message #37 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Vincent Danen <vdanen@redhat.com>

To: S?bastien Villemot <sebastien@debian.org>

Cc: 702976@bugs.debian.org

Subject: Re: Bug#702976: CVE-2010-3312

Date: Wed, 13 Mar 2013 15:59:50 -0600

* [2013-03-13 22:12:25 +0100] S?bastien Villemot wrote:

>Le mercredi 13 mars 2013 à 11:58 -0600, Vincent Danen a écrit :
>> This issue was given the name CVE-2010-3312 quite a while ago.  See
>> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3312 for more info.
>
>I don???t think this is the same issue. The problem reported here is
>specifically about redirections, while CVE-2010-3312 (#564690 in Debian)
>was about *never* verifying SSL certs (and is now fixed).

Well, the issue in our bugzilla is still not fixed in the latest Fedora
version and since the bug is about epiphany not validating certificates
in general.  Are you sure it's fixed?  If it's fixed in Debian but not
upstream, then this should probably be classified as a separate issue
(but from where I sit, we have 3.6.1 in Fedora 18 and it doesn't seem to
do anything right with regards to SSL certificates).

-- 
Vincent Danen / Red Hat Security Response Team 

Message #42 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 702976@bugs.debian.org

Subject: Re: Bug#702976: epiphany-browser: domainname not checked on https

Date: Thu, 14 Mar 2013 00:15:17 +0100

[Message part 1 (text/plain, inline)]

On Wed, 2013-03-13 at 23:23 +0100, Josselin Mouette wrote:
> I don’t even see it as a bug. 
Of course it is...
Otherwise I could easily mitm every connection... o.O

> Epiphany treats the first site as a self-signed one, which thus has the
> same level of security as a non-encrypted connection.
And Ephiphany silently accepts self-signeds one? Even then if cert and
domain don't match?

I can't quite follow your points...


> When you are redirected, however, it is the responsibility of the user
> to check the domain name the connection is certified for.
No... cause you can never now where a site redirects you or form which
other domains it loads objects... e.g. google.com and friends load a lot
of stuff from other google domains like gstatic or whatever.

https guarantees this cause you know the entry domain, and when
communication with that is valid (which epiphany apparently does not
check) you assume that your peer wouldn't redirect/lead you to other
domains (with valid certs) unless it's intended.
If you put that into the responsibility of the user the whole system
immediately fails.


Again,.... can't quite follow your points... just try it with one of the
other big browsers... they warn you before any redirect.



> You could argue that, when faced with a non-certified https connection,
> epiphany should not follow redirections without a warning, but I’m not
> even sure upstream would agree, and I definitely don’t think this is a
> RC bug.
Well... SSL useless... sounds like RC to me.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #54 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 702976@bugs.debian.org

Subject: re: epiphany-browser: domainname not checked on https

Date: Sat, 16 Mar 2013 16:04:38 -0400

control: tag -1 confirmed

On Wed, Mar 13, 2013 at 12:29 PM, Christoph Anton Mitterer  wrote:
> It seems that epiphany does at least not check the domainname correctly
> when connection to a site via https.
>
> For example, when I go to:
> https://physik.lmu.de/~mitterer/
> it redirects me automatically to
> https://homepages.physik.uni-muenchen.de/~mitterer/
> without any complaining.

I'll confirm that this is indeed an issue.  chromium/iceweasel do
detect this as badness, and appropriately warn the user, so epiphany's
behavior is certainly wrong.  However, webkit (and thus webkit-based
browsers) are not supported security-wise in debian (due to a lack of
an upstream security process):
http://www.debian.org/releases/testing/i386/release-notes/ch-information.en.html#browser-security

The bug severity was downgraded since due to that.

You may want to consider a CVE request.

Best wishes,
Mike

Message #61 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 702976@bugs.debian.org

Cc: jcristau@debian.org, team@security.debian.org

Subject: Re: epiphany-browser: domainname not checked on https

Date: Mon, 01 Jul 2013 15:38:13 +0200

[Message part 1 (text/plain, inline)]

severity 702976 critical
stop

Hi Julien.

I've just seen that you lowered the severity of this bug (already months
ago) without giving any further explanation (which I consider quite
rude, to be hones), and apparently without understanding it's
criticality at all...

As it was shown by examples, this bug breaks the whole point of SSL, ...
and it's quite shocking to see that such issues are not understood at
all by the relevant people and simple hide away (to "important"), given
that it makes one wonder, at how many other places in Debian the same
happens.


Next time when you blindly change the severity of security related issue
than please have a closer look.
The fact that this already has a CVE makes your severity-change even
more disturbing.


I'm adding the security team now, which I ask to investigate into
this,...
Unfortunately this totally broken version leaked into wheezy as well.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #68 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 702976@bugs.debian.org, jcristau@debian.org, team@security.debian.org, control@bugs.debian.org

Subject: Re: epiphany-browser: domainname not checked on https

Date: Tue, 2 Jul 2013 08:39:07 +0200

severity 702976 important
thanks

On Mon, Jul 01, 2013 at 03:38:13PM +0200, Christoph Anton Mitterer wrote:
> I'm adding the security team now, which I ask to investigate into
> this,...
> Unfortunately this totally broken version leaked into wheezy as well.

Michael Gilbert is a member of the Security Team and already commented:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702976#54

Cheers,
        Moritz

Message #75 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 702976@bugs.debian.org

Cc: team@security.debian.org

Subject: Re: epiphany-browser: domainname not checked on https

Date: Tue, 02 Jul 2013 14:35:15 +0200

[Message part 1 (text/plain, inline)]

On Tue, 2013-07-02 at 08:39 +0200, Moritz Muehlenhoff wrote: 
> severity 702976 important
Wow... must really look bad security wise in Debian...

Not only is it not obviously documented that webkit browsers are not
security supported at all
http://www.debian.org/security/
http://www.debian.org/security/faq
(assuming that any users would expect that stuff from main is not
supported, and would therefore even search for such exceptions).

But also you do hide away these bugs,... with higher severity people
would at least have a chance to notice it via apt-listbugs.

Apart from that, the severity simply does not fit as it's defined...

Really outrageous. Guess it becomes time that someone starts an
independent and uncensored security blog about Debian... o.O

Especially since there is an easy "fix" available, disable https in
epiphany.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #80 received at 702976@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 702976@bugs.debian.org, team@security.debian.org

Subject: Re: epiphany-browser: domainname not checked on https

Date: Tue, 2 Jul 2013 17:37:29 +0200

On Tue, Jul 02, 2013 at 02:35:15PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2013-07-02 at 08:39 +0200, Moritz Muehlenhoff wrote: 
> > severity 702976 important
> Wow... must really look bad security wise in Debian...
> 
> Not only is it not obviously documented that webkit browsers are not
> security supported at all
> http://www.debian.org/security/
> http://www.debian.org/security/faq
> (assuming that any users would expect that stuff from main is not
> supported, and would therefore even search for such exceptions).

It's in the release notes. Mike already quoted the link in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702976#54 , but 
apparently you didn't read it again...

> Really outrageous. Guess it becomes time that someone starts an
> independent and uncensored security blog about Debian... o.O

Talk is cheap. Submit a patch upstream if it's so important for you.

End of discussion for me.

Cheers,
        Moritz

Message #85 received at 702976-close@bugs.debian.org (full text, mbox, reply):

From: Wei Liu <liuw@liuw.name>

To: 702976-close@bugs.debian.org

Subject: Bug#702976: fixed in xautolock 1:2.2-5

Date: Tue, 15 Mar 2016 22:51:00 +0000

Source: xautolock
Source-Version: 1:2.2-5

We believe that the bug you reported is fixed in the latest version of
xautolock, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 702976@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Wei Liu <liuw@liuw.name> (supplier of updated xautolock package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 14 Mar 2016 18:28:56 +0000
Source: xautolock
Binary: xautolock
Architecture: source amd64
Version: 1:2.2-5
Distribution: unstable
Urgency: low
Maintainer: Wei Liu <liuw@liuw.name>
Changed-By: Wei Liu <liuw@liuw.name>
Description:
 xautolock  - Program launcher for idle X sessions
Closes: 702976 812760
Changes:
 xautolock (1:2.2-5) unstable; urgency=low
 .
   * Non-maintainer upolad
   * Update myself as maintainer (closes: #812760)
   * Update Recommends packages (closes: #702976)
   * Update to latest standard version 3.9.7
Checksums-Sha1:
 5edda9a83a69ca720051c8cd5dcc3b66908c9cf4 1714 xautolock_2.2-5.dsc
 fa21b7d3e0a731f91561b95d3ced1234600a8d8c 5444 xautolock_2.2-5.debian.tar.xz
 479988b8ba61197abe688e11053c8131f82e13e1 31092 xautolock-dbgsym_2.2-5_amd64.deb
 be74b588203fc4fd7b6a4e576c98c77bc130c018 30478 xautolock_2.2-5_amd64.deb
Checksums-Sha256:
 52c1ba60c592879b6e4afbcecf68b9fd44e3a86455861165f8938b6cb1a72587 1714 xautolock_2.2-5.dsc
 6a7ad00b0b01062927f10d995338836f535742e82092343cadc6ac6cc4644167 5444 xautolock_2.2-5.debian.tar.xz
 c90bf2bc94687878b548d42c8548c44ef7e89eac39629781c3d5858b5774ee78 31092 xautolock-dbgsym_2.2-5_amd64.deb
 11f0ba2048deaa6569ded272a7058af5f3109dbe07484a985026c69820eec582 30478 xautolock_2.2-5_amd64.deb
Files:
 5a89dbb72c1ceefd55e66af3b5d9ef29 1714 x11 optional xautolock_2.2-5.dsc
 7baeab37ba500ee67307cce7f7d9df50 5444 x11 optional xautolock_2.2-5.debian.tar.xz
 311a972c359229159d1f1a67ad110385 31092 debug extra xautolock-dbgsym_2.2-5_amd64.deb
 a91eeb5be494f4e859716097ff9c94e1 30478 x11 optional xautolock_2.2-5_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVuiNy/QbKGJYx7B5AQIUyBAAtCJOl66Q8Wcf3phx5i8zob70t7BtMYnP
dcF49b+ngL7C7Ep3ODEJZgNRKcgsB4C6n8ajX/zujjNa6G2lp6oy3DFO/h7+dWkR
YEguYRDMde4fUKIUDBnr53AlhucGiQmDJpTDMFiwvOsonuRt+5Zx57catFmxMeXG
+x95v6QyBlWtcvK7Xrkb3YOVGXOuc4zK6XIuv69YFcc+Yi9f6ZPZqSfJ5iFEcplf
kdNLHizip1UVfb6lQobzSGU/EwdZV44dC5bn72ubwN7XNhurX66GSwNNUwQvdECW
iDbrwSPQ5pocmlpOEPyQCChk26OWZvBNKmEOx+FWrtZ06vZcRRTh8vEk/Opsa2s/
My/w5dfDtgUKQX9iaIdQLlMhhlFEu3vKq5ObhAtEMgTrjxHSQ3Tlk0zGeyVgdCfy
HYUqPNuvlTMP69O3p55f5po5cmeeH0hbWMIEBDG9WpChOicieLkdWJrFNq5m8Dw/
CH+rac/pIe3/yWAM8AUSoAewx+PcUoFLNYmjy/mTrIiAmIfL185LPeM4bFS/Qe9X
KBQ235YUlG+7kG2IEEq6wyqwG5FLOJE1bM56rCfvj8b+KMSyROOgdZryK8gCuvs2
fLCZW1kNuDnA1usa3tNP5o9XOCFWyvA7V0oKTYAKGEM/IPR5+DnQT8UcnYrb8ULY
6tA8wuKBjnY=
=LSr1
-----END PGP SIGNATURE-----

Message #94 received at 702976@bugs.debian.org (full text, mbox, reply):

From: mcatanzaro@gnome.org

To: 702976@bugs.debian.org

Subject: Re: Bug#702976: fixed in xautolock 1:2.2-5

Date: Fri, 05 May 2017 17:30:55 -0500

FWIW I fixed this upstream three years ago. I know Wheezy was affected, 
but the version of Epiphany in Jessie should be fine.

(That said, I don't recommend using the version of Epiphany in Stretch, 
let alone Jessie.)

Message #99 received at 702976-done@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 702976-done@bugs.debian.org

Subject: Re: Bug#702976: epiphany-browser: domainname not checked on https

Date: Tue, 19 Mar 2019 10:19:12 +0000

Version: 3.14.1-1

On Fri, 05 May 2017 at 17:30:55 -0500, mcatanzaro@gnome.org wrote:
> FWIW I fixed this upstream three years ago. I know Wheezy was affected, but
> the version of Epiphany in Jessie should be fine.
> 
> (That said, I don't recommend using the version of Epiphany in Stretch, let
> alone Jessie.)

Closing as fixed in the version in jessie, thanks.

I've confirmed that the version of epiphany-browser proposed for
Debian 10 'buster' does the right thing:

    This Connection is Not Secure

    This does not look like the real
    https://foobar.hosted.pseudorandom.co.uk. Attackers might be trying
    to steal or alter information going to or from this site.

    ▼ Technical information
    This website presented identification that belongs to a different website.

Regards,
    smcv

Send a report that this bug log contains spam.