[Bug 991637] [NEW] unity launcher vanishes when switching to mirrored displays
Public bug reported: On a fresh install of Ubuntu 12.04, Unity 5.10.0-0ubuntu6, if I switch my display settings from non-mirrored to mirrored, the launcher vanishes. Note that I have the launcher auto-hide setting disabled, so it should always be visible. Steps to reproduce: * Open System Settings - Displays. * Ensure Mirror displays checkbox is unchecked, a resolution common to both monitors is selected, and launcher placement is set to All displays; if this was not previously true, click Apply and Keep these settings. * Check Mirror displays checkbox, and click Apply. * Unity launcher vanishes. The only way I've found to restore it is to switch back to non-mirrored mode. Other applications are affected by the switch to mirrored mode. If a window is maximized prior to the mirroring, often it will take up a narrow vertical strip (maybe 20 pixels wide) on the right side of the screen - de-maximizing restores restores it to a window, but re- maximizing restores it to the narrow vertical strip. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: unity 5.10.0-0ubuntu6 ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14 Uname: Linux 3.2.0-24-generic x86_64 ApportVersion: 2.0.1-0ubuntu7 Architecture: amd64 CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell] Date: Sun Apr 29 21:22:41 2012 EcryptfsInUse: Yes InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release amd64 (20120425) ProcEnviron: LANGUAGE=en_CA:en PATH=(custom, no user) LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: unity (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug precise -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/991637 Title: unity launcher vanishes when switching to mirrored displays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/991637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 991637] Re: unity launcher vanishes when switching to mirrored displays
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/991637 Title: unity launcher vanishes when switching to mirrored displays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/991637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610869] Re: mountall ignores nofail mount option
Ubuntu 10.11 Oneiric. The same fstab line that worked in 9.04 Jaunty for an external usb hard drive would give disk checking errors at boot in 10.11. nofail didn't change the behaviour, but nobootwait solved the problem. Thanks for your posts. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/610869 Title: mountall ignores nofail mount option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/610869/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302314] Re: Pidgin not using existing root TLS/SSL certificates for validation
If Pidgin doesn't know whether the certificate is valid or not, you could be vulnerable to a man-in-the-middle attack by blindly accepting it (at least that's my understanding). Mind you, accepting it yourself without any other knowledge would be no worse than what Pidgin was doing before version 1:2.4.1-1ubuntu2.2 was released (it was blindly accepting all certificates without asking - see bug 251304), but personally I'd rather not take that approach. I have found a simple workaround for login.live.com, that should be safe (as long as you trust the root certificates that Firefox uses). First, navigate Firefox to https://login.live.com/. For me, at least, Firefox accepts the certificate as being verified by VeriSign; you should bail out here if Firefox complains about an invalid certificate. View the page's certificate (right-click the page, select View Page Info, click the security icon, and click the View Certificate button). On the Details tab, click the Export... button. As of this point, I'm working from memory (don't have access to my home machine at the moment), so hopefully I get the details right. You'll want to save the certificate with a file name of login.live.com as type X.509 Certificate (PEM) (at the very least, I remember that the default type worked for me) in ~/.purple/ssl/certs. You might need to right-click in the file list and show hidden files to see the .purple directory in your home directory. I'm not sure about the exact path; it might have been ~/.purple/ssl/ca-certs instead. In any case, the directory should exist if you've started Pidgin before; you just need to drop in the certificate with a filename of the host it belongs to (no extra .pem extensions or anything like that). Once you've done all that, restart Pidgin and it should accept login.live.com. You may need to disable and re-enable your MSN account (in Accounts-Manage Accounts) if Pidgin doesn't bother trying to connect because it was previously deemed invalid. I'm sure you could use other tools, or browsers instead of Firefox, to export the certificate... but this approach worked for me. I hope this is helpful until an official fix is released. -- Pidgin not using existing root TLS/SSL certificates for validation https://bugs.launchpad.net/bugs/302314 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302314] Re: Pidgin not using existing root TLS/SSL certificates for validation
To correct my previous comment (https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/302314/comments/3), the path to place the login.live.com certificate (or any other certificate you want Pidgin to accept per-user) is ~/.purple/certificates/x509/tls_peers/ Sorry for the confusion. I was thinking of /etc/ssl/certs instead. You probably don't want to just dump certificates in there. To emphasize, making symlinks in your home directory or dumping trusted certificates in ~/.purple are just crude short-term workarounds to avoid accepting untrusted certificates because of a bug. They aren't long-term solutions. komputes: I haven't had any issues with rsi.hotmail.com, though according to http://developer.pidgin.im/ticket/6680 you might have offline messages that aren't getting through. Apparently MSN uses a different host and a different certificate for offline messages. Until an official fix for Ubuntu is released you could perform the Firefox workaround I suggested above for login.live.com with rsi.hotmail.com, or you could find another way to verify the certificate (there are some instructions on using openssl and a certificate in the Pidgin ticket; it appears to be out of date though), or you could just accept the certificate if you're feeling lucky (though I wouldn't recommend it). -- Pidgin not using existing root TLS/SSL certificates for validation https://bugs.launchpad.net/bugs/302314 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302314] Re: Pidgin not using existing root TLS/SSL certificates for validation
As an aside, if someone else who is affected by this bug attempts the workaround I provided in the bug description to connect to Google Talk, and Pidgin warns that the certificate presented by 'talk.google.com' claims to be from 'gmail.com' instead, you might be connecting to incorrect (obsolete?) ports. Go to Accounts-Manage, select your Google Talk account and click Modify, and on the Advanced tab, and try the following settings (they worked for me): Check Require SSL/TLS Check Force old (port 5223) SSL Uncheck Allow plaintext auth over unencrypted streams Uncheck Use GSSAPI (Kerberos v5) for authentication Set the Connect port to 443 Set the Connect server to talk.google.com I suppose this comment doesn't relate to this bug other than that I ran into the problem described in this comment while trying to work around the problem described by this bug. I hope it helps someone else. Sorry if this is the wrong place to post such a comment. -- Pidgin not using existing root TLS/SSL certificates for validation https://bugs.launchpad.net/bugs/302314 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302314] [NEW] Pidgin not using existing root TLS/SSL certificates for validation
Public bug reported: Binary package hint: pidgin After upgrading to Pidgin 1:2.4.1-1ubuntu2.2 for Ubuntu 8.04.1, attempting to connect to Google talk or MSN Messenger results in Pidgin asking me to verify that the SSL certificates provided are valid. While it is good that Pidgin is not blindly accepting invalid certificates anymore, some of the supposed invalid certificates are apparently issued by root certificates that are provided by the ca-certificates package. It would be an improvement if Pidgin had access to some root certificates to validate against so that users do not have to manually accept every certificate. I did a bit of Googling and found a Debian bug (http://bugs.debian.org /cgi-bin/bugreport.cgi?bug=492434) notes that Pidgin 2.4.1 does not look in /etc/ssl/certs for certificates - it looks in etc/ssl/certs (a relative path) instead. Later versions of Pidgin apparently support a --with-system-ssl-certs configure option, but the approach taken for that Debian bug was to apply a patch to fix the hardcoded path (see http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=32;filename=debian-ca- certs.patch;att=1;bug=492434). Below I have provided descriptions of what I expected to happen and what actually happens when I try to connect to Google Talk and MSN Messenger via Pidgin 1:2.4.1-1ubuntu2.2. --- When connecting to Google Talk: Expected behaviour: able to connect without any certificate warnings Actual behaviour: when attempting to connect, I receive the following prompt (buttons in brackets): Accept certificate for talk.google.com? The root certificate this one claims to be issued by is unknown to Pidgin. (View Certificate...) (Reject) (Accept) Workaround: since Pidgin is looking for etc/ssl/certs instead of /etc/ssl/certs, and since Pidgin's current working directory when launched from the applications menu is the user's home directory, if I create a symlink from ~/etc to /etc then Pidgin connects without asking me to validate the certificate (I assume this is due to it being able to validate the certificate). --- When connecting to MSN Messenger: Expected behaviour: able to connect without any certificate warnings Actual behaviour: when attempting to connect, I receive the following prompt (buttons in brackets): Accept certificate for nexus.passport.com? The root certificate this one claims to be issued by is unknown to Pidgin. (View Certificate...) (Reject) (Accept) Behaviour with the above workaround: after creating a symlink from ~/etc to /etc, I get the following prompt instead: Accept certificate for login.live.com? The root certificate this one claims to be issued by is unknown to Pidgin. (View Certificate...) (Reject) (Accept) It appears that with the symlink workaround, Pidgin is able to validate the certificate for nexus.passport.com, but not for login.live.com. There exists a closed Pidgin bug (http://developer.pidgin.im/ticket/7002) that claims that login.live.com is not accepted because the Ubuntu ca-certificates package is missing some root certificates that Pidgin supplies (but are apparently not distributed with Ubuntu's Pidgin package); Firefox, however, accepts the certificate presented by https://login.live.com... I'm not sure what that would imply. ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New ** Description changed: Binary package hint: pidgin After upgrading to Pidgin 1:2.4.1-1ubuntu2.2 for Ubuntu 8.04.1, attempting to connect to Google talk or MSN Messenger results in Pidgin asking me to verify that the SSL certificates provided are valid. While it is good that Pidgin is not blindly accepting invalid certificates anymore, some of the supposed invalid certificates are apparently issued by root certificates that are provided by the ca-certificates package. It would be an improvement if Pidgin had access to some root certificates to validate against so that users do not have to manually accept every certificate. - I did a bit of Googling and found that for Debian bug 492434 - (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492434) it was noted - that Pidgin 2.4.1 does not look in /etc/ssl/certs for certificates - - it looks in etc/ssl/certs (a relative path) instead. Later versions of - Pidgin apparently support a --with-system-ssl-certs configure option, - but the approach taken for that Debian bug was to apply a patch to fix - the hardcoded path (see http://bugs.debian.org/cgi- - bin/bugreport.cgi?msg=32;filename=debian-ca- + I did a bit of Googling and found a Debian bug (http://bugs.debian.org + /cgi-bin/bugreport.cgi?bug=492434) notes that Pidgin 2.4.1 does not look + in /etc/ssl/certs for certificates - it looks in etc/ssl/certs (a + relative path) instead. Later versions of Pidgin apparently support a + --with-system-ssl-certs configure option, but the approach taken for + that Debian bug was to apply a patch to fix the hardcoded path (see +
