| 2019-06-26 14:43:58 |
pataquets |
bug |
|
|
added bug |
| 2019-06-26 14:44:53 |
pataquets |
description |
After upgrading from PHP5 to PHP7, calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are related issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
After upgrading from PHP5 to PHP7.2 (Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are related issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-06-26 14:44:58 |
pataquets |
description |
After upgrading from PHP5 to PHP7.2 (Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are related issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are related issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-06-26 14:45:39 |
pataquets |
description |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are related issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-06-26 14:54:25 |
pataquets |
bug task added |
|
php-imap (Ubuntu) |
|
| 2019-06-26 15:03:27 |
pataquets |
description |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
With PHP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-07-02 08:21:58 |
Launchpad Janitor |
php-imap (Ubuntu): status |
New |
Confirmed |
|
| 2019-07-02 08:21:58 |
Launchpad Janitor |
uw-imap (Ubuntu): status |
New |
Confirmed |
|
| 2019-08-05 04:57:33 |
David Zuelke |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041 |
|
| 2019-08-05 04:57:33 |
David Zuelke |
attachment added |
|
uw-imap-sni.patch https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5280829/+files/uw-imap-sni.patch |
|
| 2019-08-05 08:23:38 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2019-08-05 08:23:46 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2019-08-05 14:34:07 |
David Zuelke |
attachment added |
|
new patch, RFC6066 compliant https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5280961/+files/uw-imap-sni.patch |
|
| 2019-08-05 16:53:36 |
David Zuelke |
attachment removed |
uw-imap-sni.patch https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5280829/+files/uw-imap-sni.patch |
|
|
| 2019-08-06 20:42:17 |
David Zuelke |
attachment added |
|
uw-imap-sni.v3.patch https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5281308/+files/uw-imap-sni.v3.patch |
|
| 2019-08-08 23:48:01 |
Mauricio Faria de Oliveira |
php-imap (Ubuntu): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-08-08 23:48:04 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-08-13 16:41:43 |
Mauricio Faria de Oliveira |
description |
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (161 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
[Test Case]
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundreds of (161)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 161 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-08-13 16:43:46 |
Mauricio Faria de Oliveira |
description |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (161 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
[Test Case]
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundreds of (161)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 161 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (161 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
Output with '-noservername':
verify error:num=18:self signed certificate
verify error:num=62:Hostname mismatch
Verification error: Hostname mismatch
Output with '-servername imap.gmail.com'
Verification: OK
Verified peername: imap.gmail.com
[Test Case]
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundreds of (161)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 161 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-08-13 16:49:49 |
Mauricio Faria de Oliveira |
description |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (161 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
Output with '-noservername':
verify error:num=18:self signed certificate
verify error:num=62:Hostname mismatch
Verification error: Hostname mismatch
Output with '-servername imap.gmail.com'
Verification: OK
Verified peername: imap.gmail.com
[Test Case]
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundreds of (161)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 161 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (167 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
Output with '-noservername':
verify error:num=18:self signed certificate
verify error:num=62:Hostname mismatch
Verification error: Hostname mismatch
Output with '-servername imap.gmail.com'
Verification: OK
Verified peername: imap.gmail.com
[Test Case]
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundred+ of (167)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 167 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-08-13 16:59:29 |
Mauricio Faria de Oliveira |
description |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (167 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
Output with '-noservername':
verify error:num=18:self signed certificate
verify error:num=62:Hostname mismatch
Verification error: Hostname mismatch
Output with '-servername imap.gmail.com'
Verification: OK
Verified peername: imap.gmail.com
[Test Case]
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundred+ of (167)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 167 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
[Impact]
* Users of libc-client2007e (e.g., php7.x-imap) can no longer
connect to GMail on Bionic and later, after introduction of
TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).
* GMail requires Server Name Indication (SNI) to be set when
TLSv1.3 is used, otherwise the server provided certificate
fails verification in the client and connection is aborted.
* The fix is to set SNI to the hostname that the client will
perform verification on. The change is only enabled if the
client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
support) so not to affect pre- TLSv1.3 support's behavior.
* However it is functional nonetheless if the client is built
with OpenSSL 1.1.1 or later but an earlier TLS version ends
up used due to the handshake/negotiation/server TLS support
(e.g., TLSv1.2); this shouldn't be a problem per test below.
* Regression testing happened with a crawled list of IMAP/POP
SSL servers (167 servers), and no regressions were observed.
Actually, one more email provider/server has been fixed too.
* OpenSSL-only demonstration with -(no)servername:
$ echo QUIT \
| openssl s_client \
-connect imap.gmail.com:993 \
-verify_hostname imap.gmail.com \
-noservername `# or -servername imap.gmail.com` \
-tls1_3 -brief 2>&1 \
| grep -i ^verif
Output with '-noservername':
verify error:num=18:self signed certificate
verify error:num=62:Hostname mismatch
Verification error: Hostname mismatch
Output with '-servername imap.gmail.com'
Verification: OK
Verified peername: imap.gmail.com
[Test Case]
* Commands:
$ sudo apt install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
$ sudo apt install php7.2-cli php7.2-imap
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
* Before:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
* After:
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username:
^C
$ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0
* Regression testing scripts/results are provided in attachments/comments.
[Regression Potential]
* Theoretically possible, but not observed in hundred+ of (167)
IMAP/POP SSL servers.
* The change sends additional data (SNI) from client to server
when connecting, if built with OpenSSL 1.1.1 or later, which
is in the specification, so should be handled by the server.
* The risk is servers that misbehave when provided such info
(not observed in the 167 server test).
* Less likely are servers that do not recognize the server name
identified (this also not observed in test and unlikely since
the client usually reaches the server by public/known address).
* Even less likely are servers whose provided certificate doesn't
contain the server name identified (again not observed and it's
in the server, not client, to provide a certificate for address
it doesn't recognize).
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Reverse build dependencies have been patched for No Change Rebuilds
and (re)built correctly on all architectures in Launchpad PPA for
all affected releases (eoan, disco, bionic).
[Original Description]
After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.
Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786
OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947
Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail. |
|
| 2019-08-13 17:00:15 |
Mauricio Faria de Oliveira |
attachment added |
|
lp1834340-test-scripts.tar.xz https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282369/+files/lp1834340-test-scripts.tar.xz |
|
| 2019-08-13 17:01:40 |
Mauricio Faria de Oliveira |
attachment added |
|
uw-imap_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282370/+files/uw-imap_eoan.debdiff |
|
| 2019-08-13 17:01:53 |
Mauricio Faria de Oliveira |
attachment added |
|
uw-imap_disco.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282371/+files/uw-imap_disco.debdiff |
|
| 2019-08-13 17:02:16 |
Mauricio Faria de Oliveira |
attachment added |
|
uw-imap_bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282372/+files/uw-imap_bionic.debdiff |
|
| 2019-08-13 17:03:51 |
Mauricio Faria de Oliveira |
attachment added |
|
asterisk_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282373/+files/asterisk_eoan.debdiff |
|
| 2019-08-13 17:04:06 |
Mauricio Faria de Oliveira |
attachment added |
|
asterisk_disco.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282374/+files/asterisk_disco.debdiff |
|
| 2019-08-13 17:04:21 |
Mauricio Faria de Oliveira |
attachment added |
|
asterisk_bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282375/+files/asterisk_bionic.debdiff |
|
| 2019-08-13 17:04:37 |
Mauricio Faria de Oliveira |
attachment added |
|
mailsync_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282376/+files/mailsync_eoan.debdiff |
|
| 2019-08-13 17:04:54 |
Mauricio Faria de Oliveira |
attachment added |
|
mailsync_disco.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282377/+files/mailsync_disco.debdiff |
|
| 2019-08-13 17:05:09 |
Mauricio Faria de Oliveira |
attachment added |
|
mailsync_bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282378/+files/mailsync_bionic.debdiff |
|
| 2019-08-13 17:05:27 |
Mauricio Faria de Oliveira |
attachment added |
|
prayer_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282379/+files/prayer_eoan.debdiff |
|
| 2019-08-13 17:05:39 |
Mauricio Faria de Oliveira |
attachment added |
|
prayer_disco.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282380/+files/prayer_disco.debdiff |
|
| 2019-08-13 17:05:56 |
Mauricio Faria de Oliveira |
attachment added |
|
prayer_bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282381/+files/prayer_bionic.debdiff |
|
| 2019-08-13 17:06:20 |
Mauricio Faria de Oliveira |
php-imap (Ubuntu): status |
Confirmed |
Invalid |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Disco |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
uw-imap (Ubuntu Disco) |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
php-imap (Ubuntu Disco) |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
uw-imap (Ubuntu Eoan) |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
php-imap (Ubuntu Eoan) |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
uw-imap (Ubuntu Bionic) |
|
| 2019-08-13 17:07:02 |
Mauricio Faria de Oliveira |
bug task added |
|
php-imap (Ubuntu Bionic) |
|
| 2019-08-13 17:07:13 |
Mauricio Faria de Oliveira |
php-imap (Ubuntu Disco): status |
New |
Invalid |
|
| 2019-08-13 17:07:19 |
Mauricio Faria de Oliveira |
php-imap (Ubuntu Bionic): status |
New |
Invalid |
|
| 2019-08-13 17:07:27 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu Eoan): status |
Confirmed |
In Progress |
|
| 2019-08-13 17:07:31 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-08-13 17:07:35 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-08-13 17:07:39 |
Mauricio Faria de Oliveira |
php-imap (Ubuntu Eoan): assignee |
Mauricio Faria de Oliveira (mfo) |
|
|
| 2019-08-13 17:07:41 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu Disco): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-08-13 17:07:44 |
Mauricio Faria de Oliveira |
uw-imap (Ubuntu Bionic): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-08-13 17:10:37 |
Mauricio Faria de Oliveira |
summary |
Possible regression on libssl upgrade when using TLSv1.3 |
Regression for GMail after libssl upgrade with TLSv1.3 |
|
| 2019-08-13 17:11:03 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber STS Sponsors |
| 2019-08-13 18:00:21 |
Eric Desrochers |
bug task added |
|
asterisk (Ubuntu) |
|
| 2019-08-13 18:00:42 |
Eric Desrochers |
bug task added |
|
mailsync (Ubuntu) |
|
| 2019-08-13 18:00:51 |
Eric Desrochers |
bug task added |
|
prayer (Ubuntu) |
|
| 2019-08-14 15:33:49 |
Dan Streetman |
tags |
patch |
patch sts sts-sponsor sts-sponsor-ddstreet |
|
| 2019-08-14 18:42:48 |
Dan Streetman |
bug task added |
|
uw-imap (Debian) |
|
| 2019-08-14 21:41:09 |
Launchpad Janitor |
uw-imap (Ubuntu Eoan): status |
In Progress |
Fix Released |
|
| 2019-08-20 16:19:06 |
Brian Murray |
uw-imap (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
| 2019-08-20 16:19:20 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-08-20 16:19:22 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-08-20 16:19:30 |
Brian Murray |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-disco |
|
| 2019-08-20 16:24:33 |
Brian Murray |
uw-imap (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-08-20 16:24:47 |
Brian Murray |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-disco |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-bionic verification-needed-disco |
|
| 2019-08-20 19:27:43 |
Mauricio Faria de Oliveira |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-bionic verification-needed-disco |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-bionic verification-needed verification-needed-disco |
|
| 2019-08-20 19:28:36 |
Mauricio Faria de Oliveira |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-bionic verification-needed verification-needed-disco |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-bionic verification-done-disco verification-needed |
|
| 2019-08-20 19:28:45 |
Mauricio Faria de Oliveira |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-bionic verification-done-disco verification-needed |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done verification-done-bionic verification-done-disco |
|
| 2019-08-29 07:55:29 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-08-29 08:05:34 |
Launchpad Janitor |
uw-imap (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-08-29 08:31:45 |
Launchpad Janitor |
uw-imap (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-08-29 12:53:50 |
Mauricio Faria de Oliveira |
attachment removed |
asterisk_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5282373/+files/asterisk_eoan.debdiff |
|
|
| 2019-08-29 12:55:39 |
Mauricio Faria de Oliveira |
attachment added |
|
asterisk_eoan.debdiff https://bugs.launchpad.net/ubuntu/+source/uw-imap/+bug/1834340/+attachment/5285634/+files/asterisk_eoan.debdiff |
|
| 2019-08-29 17:47:48 |
Launchpad Janitor |
prayer (Ubuntu Eoan): status |
New |
Fix Released |
|
| 2019-08-29 17:57:53 |
Launchpad Janitor |
mailsync (Ubuntu Eoan): status |
New |
Fix Released |
|
| 2019-08-29 21:20:23 |
Launchpad Janitor |
asterisk (Ubuntu Eoan): status |
New |
Fix Released |
|
| 2019-09-02 16:04:41 |
Bug Watch Updater |
uw-imap (Debian): status |
Unknown |
Fix Released |
|
| 2019-09-05 11:34:28 |
Eric Desrochers |
asterisk (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-09-05 11:34:49 |
Eric Desrochers |
asterisk (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-09-05 11:34:49 |
Eric Desrochers |
asterisk (Ubuntu Disco): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:35:08 |
Eric Desrochers |
asterisk (Ubuntu Bionic): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:37:11 |
Eric Desrochers |
mailsync (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-09-05 11:37:11 |
Eric Desrochers |
mailsync (Ubuntu Bionic): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:37:39 |
Eric Desrochers |
mailsync (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-09-05 11:37:39 |
Eric Desrochers |
mailsync (Ubuntu Disco): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:37:56 |
Eric Desrochers |
prayer (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-09-05 11:37:56 |
Eric Desrochers |
prayer (Ubuntu Bionic): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:38:07 |
Eric Desrochers |
prayer (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-09-05 11:38:07 |
Eric Desrochers |
prayer (Ubuntu Disco): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:39:21 |
Eric Desrochers |
asterisk (Ubuntu Eoan): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:39:31 |
Eric Desrochers |
prayer (Ubuntu Eoan): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-05 11:39:40 |
Eric Desrochers |
mailsync (Ubuntu Eoan): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2019-09-07 20:40:54 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-09-11 18:30:46 |
Steve Langasek |
asterisk (Ubuntu Bionic): status |
In Progress |
Incomplete |
|
| 2019-09-11 18:37:25 |
Steve Langasek |
mailsync (Ubuntu Bionic): status |
In Progress |
Incomplete |
|
| 2019-09-17 18:07:09 |
Mauricio Faria de Oliveira |
asterisk (Ubuntu Bionic): status |
Incomplete |
Invalid |
|
| 2019-09-17 18:07:26 |
Mauricio Faria de Oliveira |
asterisk (Ubuntu Disco): status |
In Progress |
Invalid |
|
| 2019-09-17 18:07:38 |
Mauricio Faria de Oliveira |
mailsync (Ubuntu Bionic): status |
Incomplete |
Invalid |
|
| 2019-09-17 18:07:50 |
Mauricio Faria de Oliveira |
mailsync (Ubuntu Disco): status |
In Progress |
Invalid |
|
| 2019-09-17 18:08:03 |
Mauricio Faria de Oliveira |
prayer (Ubuntu Bionic): status |
In Progress |
Invalid |
|
| 2019-09-17 18:08:15 |
Mauricio Faria de Oliveira |
prayer (Ubuntu Disco): status |
In Progress |
Invalid |
|
| 2019-10-09 18:50:48 |
Dan Streetman |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done verification-done-bionic verification-done-disco |
bionic-openssl-1.1 patch sts sts-sponsor sts-sponsor-ddstreet verification-done verification-done-bionic verification-done-disco |
|
| 2020-10-23 13:26:51 |
Martin PANEL |
bug |
|
|
added subscriber Martin PANEL |
