[Touch-packages] [Bug 1550643] [NEW] Please backport OpenSSL SNI signature algorithms fix.
Public bug reported: If an OpenSSL consumer uses SSL_set_SSL_CTX (very commonly done with SNI), OpenSSL 1.0.1i and earlier lose internal state relating to TLS 1.2 which causes it to forget the peer's digest preferences. The end result is such servers will *only* sign SHA-1 ServerKeyExchanges in TLS 1.2, even if the peer advertises other hashes or even doesn't advertise SHA-1 at all. See: https://rt.openssl.org/Ticket/Display.html?id=3560 https://bugzilla.redhat.com/show_bug.cgi?id=1150033 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4e05aedbcab7f7f83a887e952ebdcc5d4f2291e4 http://www.ietf.org/mail-archive/web/tls/current/msg19195.html Glancing at packages.ubuntu.com, this seems to affect Ubuntu vivid and below. It would be greatly appreciated if you would backport this fix to all applicable releases so Ubuntu servers do not become the limiting factor in someday removing SHA-1 here. The links above should have reproduction steps you can use to confirm the bug and test the fix. (Note that it requires a build of OpenSSL 1.0.2 to confirm the bug. OpenSSL 1.0.1's s_client doesn't print the necessary information.) ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1550643 Title: Please backport OpenSSL SNI signature algorithms fix. Status in openssl package in Ubuntu: New Bug description: If an OpenSSL consumer uses SSL_set_SSL_CTX (very commonly done with SNI), OpenSSL 1.0.1i and earlier lose internal state relating to TLS 1.2 which causes it to forget the peer's digest preferences. The end result is such servers will *only* sign SHA-1 ServerKeyExchanges in TLS 1.2, even if the peer advertises other hashes or even doesn't advertise SHA-1 at all. See: https://rt.openssl.org/Ticket/Display.html?id=3560 https://bugzilla.redhat.com/show_bug.cgi?id=1150033 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4e05aedbcab7f7f83a887e952ebdcc5d4f2291e4 http://www.ietf.org/mail-archive/web/tls/current/msg19195.html Glancing at packages.ubuntu.com, this seems to affect Ubuntu vivid and below. It would be greatly appreciated if you would backport this fix to all applicable releases so Ubuntu servers do not become the limiting factor in someday removing SHA-1 here. The links above should have reproduction steps you can use to confirm the bug and test the fix. (Note that it requires a build of OpenSSL 1.0.2 to confirm the bug. OpenSSL 1.0.1's s_client doesn't print the necessary information.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1550643/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1399044] Re: Alt-tab in unity only raises one window of a multi-window application
You can, but that's not the point. In most systems, alt-tab naturally forms an LRU ordering, which means you can switch between two applications very quickly. This behavior means that LRU is broken on multimonitor. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1399044 Title: Alt-tab in unity only raises one window of a multi-window application Status in Unity: New Status in unity package in Ubuntu: New Bug description: Borrowing from OS X rather than Windows, Unity makes Alt-Tab switch by application rather than by window. However, unlike OS X, Unity only raises one window, seemingly selected at random, when you Alt-Tab to an application with multiple windows. This makes it extremely difficult to Alt-Tab quickly between two applications when using two monitors. If I have two monitors with: Monitor 1: Chrome + Terminal + Emacs Monitor 2: Chrome Now, focus the Chrome in monitor 1. Alt-Tab to the Terminal. Try to Alt-Tab back to monitor 1's Chrome. Even if the mouse is on the left half, only monitor 2's Chrome raises. This behavior makes window management very frustrating; it breaks LRU and makes it hard to flip between two windows. It's also hard to tell if anything even happened, so I lose track of what app I switched to. To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1399044/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
