Activity log for bug #1834340

Date Who What changed Old value New value Message
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