Re: [Desktop-packages] [Bug 1647285] Re: SSL trust not system-wide
On Thu, 2020-03-19 at 09:44 +, Olivier Tilloy wrote: > It looks like symlinking firefox and thunderbird's own copies of > libnssckbi.so to the system-wide p11-kit-trust.so is the proper way to > fix this bug, as far as Mozilla's products are concerned. > > Before I proceed to doing this, I'd welcome comments from the security > team on this approach though, as I suspect I don't understand all the > implications. > > (an alternative would be building firefox/thunderbird against the > system-wide nss, but firefox currently requires 3.50, which isn't yet in > focal, and I suspect that requirement is being bumped often, so that > wouldn't really work with our distribution model) Right, don't bother trying to replace NSS just for this (although really, having a single version of NSS on the system *would* be nice). The interface to libnssckbi.so is a standard PKCS#11 library, and it's perfectly reasonable to replace that in each of firefox/thunderbird/chromium individually. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: Confirmed Status in firefox package in Ubuntu: Confirmed Status in nss package in Ubuntu: Confirmed Status in p11-kit package in Ubuntu: Fix Released Status in thunderbird package in Ubuntu: Confirmed Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
Now https://gitlab.gnome.org/GNOME/gnome-shell/issues/2105 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
Please test the Fedora 30 build with that commit reverted, at https://koji.fedoraproject.org/koji/taskinfo?taskID=36857342 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
That build seems not to fix it. I tried to build locally to bisect, but can't seem to get the local build to work at all. May have to leave this to the NM maintainers. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
According to https://bugs.launchpad.net/bugs/1609700 this bug has reoccurred in f30. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
*** Bug 1705711 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700]
I wonder if this regression is caused by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=009f7560867e939 ? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in Fedora: Confirmed Bug description: Happening again on Eoan 19.10! Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1838838] Re: username is not saved in openconnect connection dialog
** Package changed: network-manager-openconnect (Ubuntu) => gnome-shell (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1838838 Title: username is not saved in openconnect connection dialog Status in gnome-shell package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: Same issue as https://bugs.launchpad.net/ubuntu/+source/network- manager-openconnect/+bug/1609700 This was marked resolved. The report of its reappearance in Ubuntu 19.04 and 19.10 has not been acknowledged. This was working for me in 18.10, but a fresh install of 19.04 and 19.10 show that it is back. The password is saved when the option to save passwords is selected, but the username must be entered manually upon connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1838838/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1838838] Re: username is not saved in openconnect connection dialog
I moved it to NetworkManager because that's where the regression is. There's not a lot we can do about it in NetworkManager-openconnect. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1838838 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openconnect package in Ubuntu: Confirmed Bug description: Same issue as https://bugs.launchpad.net/ubuntu/+source/network- manager-openconnect/+bug/1609700 This was marked resolved. The report of its reappearance in Ubuntu 19.04 and 19.10 has not been acknowledged. This was working for me in 18.10, but a fresh install of 19.04 and 19.10 show that it is back. The password is saved when the option to save passwords is selected, but the username must be entered manually upon connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1838838/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1838838] Re: username is not saved in openconnect connection dialog
** Package changed: network-manager-openconnect (Ubuntu) => network- manager (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1838838 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Confirmed Bug description: Same issue as https://bugs.launchpad.net/ubuntu/+source/network- manager-openconnect/+bug/1609700 This was marked resolved. The report of its reappearance in Ubuntu 19.04 and 19.10 has not been acknowledged. This was working for me in 18.10, but a fresh install of 19.04 and 19.10 show that it is back. The password is saved when the option to save passwords is selected, but the username must be entered manually upon connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1838838/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1647285] Re: SSL trust not system-wide
@kvasko yes, it works here. Are you sure that's the version of libnssckbi.so that is being used? There are lots; I've replaced them all... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: Confirmed Status in nss package in Ubuntu: Confirmed Status in p11-kit package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Confirmed Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
I have worked out the problem with the new NetworkManager which required me to set ipv4.dns-priority=-1 (which, in turn, messes things up for those with fresh installs that don't get the new NetworkManager). The new NM sets ipv4.dns-search=~. automatically for full-tunnel VPNs but it doesn't also set ipv4.dns-priority=-1. This means that any DNS domain on a local network which isn't also explicitly matched by the VPN config, is considered "more specific" and gets used instead of the VPN. This is wrong; NetworkManager should also set ipv4.dns-priority=-1 for full-tunnel VPNs. The reason this was consistently problematic for our users is that we have set up /etc/dhcp/dhclient.conf to *override* the domains given by the local network to include the root of our corporate AD domain "DOM.COMPANY.COM", because various non-FQDN hostnames in AD would otherwise cause problems. This realisation does give me a way out of my current problem, until a newer version of NM correctly sets the priority automatically. Instead of manually configuring ipv4.dns-priority=-1 and breaking things for older NM, I can manually configure ipv4.dns- search=dom.company.com;company.com which works for everyone. And there *are* no other search domains which get leaked now, because our DHCP config doesn't let them get discovered. (Deliberately ignoring RDNSS here because if you live in the 21st century and have IPv6, you still get to use that anyway even when you're on a full-tunnel Legacy IP VPN. Nobody tell the IT folks please.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Any word on when this CVE will be fixed? In the meantime I have put the 1.10.14-0ubuntu2 package into an apt repository at http://david.woodhou.se/cve-2018-1000135/ for users who need it. I couldn't work out how to copy it into a PPA without rebuilding it. In the short term can someone please at least confirm that no new update will be shipped for Bionic which *doesn't* fix this, so that I don't have to play games with keeping a package in that repository "newer" than the latest in bionic-updates? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
> That's weird, do you understand why? The update was deleted so you should be > back to initial > situation, we had no change to the previous package build Other package changes? Certainly systemd-resolver although we don't use that (because of a previous VPN DNS leak problem) we use dnsmasq. My original thought was that it was the VPN config change that we'd made to cope with the new NM, but testing seems to show it isn't that. Now we have a failure mode which some people had *occasionally* reported before, where even VPN lookups which *must* go to the VPN, for the company domain, are not. This was just occasional before; now it seems to happen all the time. I haven't done a thorough investigation since just putting the updated NM back has been enough to fix it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Do we have any idea when this will be fixed? Most of my users used to get away with the DNS leakage and it was "only" a security problem but stuff actually worked. Then the NM and other updates were shipped, we set ipv4.dns-priority=-1 and ipv4.dns-search=~. and it all worked fine. Then the NM update was pulled, and new installations aren't working at all, even if we don't set the DNS config as described. There's nothing that works for us except "dig out the package that has now been unpublished, and install that". An ETA for having this properly working again would be very much appreciated. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
@ddstreet We don't use systemd-resolver here. It's fairly trivial to set up a VPN service; the openconnect 'make check' uses ocserv automatically, for example. You shouldn't have difficulty reproducing this locally. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Committed Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Committed Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
And (in case any of my colleagues are paying attention and inclined to do it before the next time I get to spend any real time in front of a computer, next week), without the dns-priority and dns-search settings that made it work again after the recent NM update. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Till, you want that for the case where dnsmasq is being used and is misbehaving? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
On the 1.10.14 regression simply making those dns-priority/dns- search settings the *default* behaviour for a full-tunnel VPN would appear to be the correct thing to do (i.e. use the DNS of a full-tunnel VPN for *all* lookups), and I think it should resolve the problems people were seeing. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
On the switch to using dnsmasq: that decision predates my tenure so I have limited visibility. I can try to get our IT team to expend effort in moving to systemd-resolved and see what breaks. It may even be completely unnecessary in xenial, and is merely inherited to make our bionic setups less different. I completely agree with the general observation that they should be filing bugs upstream and not working around them. But if I tell them that, I suspect they're going to point at this security regression in Xenial that still isn't fixed 14 months later, and tell me that working around things locally is much more effective. Right now, I don't know that I can tell them they're wrong. Let's show them the process works, *then* I'll tell them they have to use it :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Dammit, "completely unnecessary in bionic but inherited from xenial"... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
This is Bionic. After last week's update to 1.10.14-0ubuntu2 all my VPN users (who are using dnsmasq) reported that DNS supported working for them while they were on the VPN. Some internal names were looked up correctly, others weren't. I resolved it for them as follows: $ sudo nmcli con modify "$COMPANY VPN" ipv4.dns-priority -1 ipv4.dns- search ~. This matches the observations I made in comment #18 on 2019-02-04. I believe that with 1.10.6 all $company.com DNS did get sent to the VPN and it was lookups outside the company search domains which were leaked. So it was mostly functional, but insecure. Since 1.10.14 it got worse and many (but not all) of the $company.com lookups are being leaked too. Which is a functional problem. (For Xenial, my advice to users has been the same since March 2018 when this ticket was first filed: tell apt to hold network-manager_1.2.2-0ubuntu0.16.04.4_amd64.deb and don't let it get updated until/unless the regression is fixed.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Released Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
We aren't using systemd-resolver for various historical reasons; we are using dnsmasq which should be expected to work. It isn't, but we have manually added the dns-priority=-1;dns-search=~. settings which make it work, as an emergency deployment when the latest NM update broke things for everyone. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Released Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
These systems are using dnsmasq not systemd-resolver. This was done for historical reasons; I'm not sure of the specific bug which caused that choice. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Released Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
I am receiving reports that it isn't fixed in 18.04 either. Users are still seeing DNS lookups on the local network, until they manually edit the VPN config to include: [ipv4] dns-priority=-1 dns-search=~.; I thought that wasn't going to be necessary? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Released Status in systemd source package in Bionic: Triaged Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 543183]
Are you referring to my comment 16? You do need your distribution to
ship p11-kit-trust.so in place of Mozilla's libnssckbi.so, so it has a
consistent set of trusted CAs with the rest of the system.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/543183
Title:
Updating system certificates requires rebuild
Status in Mozilla Firefox:
Confirmed
Status in firefox package in Ubuntu:
Triaged
Status in firefox package in Fedora:
Won't Fix
Bug description:
Binary package hint: firefox
Hi,
Updating the list of trusted root certificate authorities across all users of
a system seems requires rebuilding a library. Non-root certificates may
similarly be impacted.
update-ca-certificates could be a mechanism to update the root
certificates used by firefox.
On a corporate install of firefox, currently the only options to adding an
internal root certificate authority are to:
* Hack it into the user creation script to extract a pre-created profile,
and update all the existing users profile directory. This bypasses the random
profile directory creation.
* Re-compile the shared library (.so) containing the root certificate
authorities (extra maintenance for dealing with ubuntu package updates).
* Have every user of the system go through a manual process of adding the
root certificate (most users don't know how).
* Use a plugin extension for firefox (do any exist?) that is automatically
used by all users (can this be done?)
* Have the root certificate signed at great expense by an external root
certificate authority already included. CaCert integration would lower the cost
but that seems far away, and is still an external authority. These root
certificates also might be limited to a single domain (wildcard certificate?)
or have other limitations ("low" expiry?, contractual restrictions...).
It seems unlikely that Mozilla will move away from having the root
certificates stored in the shared library as it would take some
control away from them. The shared libary method makes it harder for
malicious changes to be made, but only by adding the barier of
recompilation and installation of a shared library.
Thanks,
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/543183/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
@seb128 please see "In 16.04 the NetworkManager package used to carry this patch..." in the bug description above. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: * Impact When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not * Test case Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark) * Regression potential The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Is there a 16.04 package? This was a regression there caused by an earlier update. I have users reporting the same bizarre behaviour I wasn't able to clearly describe before — essentially, DNS being sent out seemingly random interfaces (sometimes VPN, sometimes local). My advice to just install this package *and* manually set dns-priority=-1,dns-search=~. and get on with life even though you really shouldn't have to manually set the latter, doesn't work for the 16.04 users... And yes, when other things stop being on fire I need to undo those settings and try to work out what's going wrong. We aren't using systemd-resolve here because historically it also hasn't worked right while dnsmasq did. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: * Impact When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not * Test case Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark) * Regression potential The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Not sure what happened there. It was looking up *some* names in the $COMPANY.com domain on the VPN, but others not, consistently. I couldn't see a pattern. I have manually set ipv4.dns-search="~." and ipv4.dns-priority=-1 and now it does seem to be behaving. However, this shouldn't be necessary. This VPN has non-split routing and shouldn't it have non-split DNS too, by default? I shouldn't have to change the configuration, just to get back to the secure behaviour which used to work. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: * Impact When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not * Test case Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark) * Regression potential The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
Hm, that didn't last long. Now it isn't looking up *anything* in the VPN domains. It's all going to the local VPN server. I don't know what changed. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: * Impact When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not * Test case Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark) * Regression potential The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
network-manager-1.10.14-0ubuntu1 does seem to fix the DNS problem here; thanks. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: * Impact When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not * Test case Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark) * Regression potential The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1647285] Re: SSL trust not system-wide
Any progress on fixing this? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: Confirmed Status in nss package in Ubuntu: Confirmed Status in p11-kit package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Confirmed Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1764877] Re: glamorgl Xv causes xvimagesink failure
** Description changed: - On Ubuntu 16.04 with xserver-xorg-1:7.7+13ubuntu3, xvimagesink fails for + On Ubuntu 16.04 with xorg-server-hwe-16.04-1.19.5, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1764877 Title: glamorgl Xv causes xvimagesink failure Status in xorg-server package in Ubuntu: New Bug description: On Ubuntu 16.04 with xorg-server-hwe-16.04-1.19.5, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1764877/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1764877] Re: glamorgl Xv causes xvimagesink failure
** Description changed: - On Ubuntu 16.04 with xserver-xorg-2:1.17.2-2, xvimagesink fails for + On Ubuntu 16.04 with xserver-xorg-1:7.7+13ubuntu3, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1764877 Title: glamorgl Xv causes xvimagesink failure Status in xorg-server package in Ubuntu: New Bug description: On Ubuntu 16.04 with xserver-xorg-1:7.7+13ubuntu3, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1764877/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1764877] [NEW] glamorgl Xv causes xvimagesink failure
Public bug reported: On Ubuntu 16.04 with xserver-xorg-2:1.17.2-2, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 ** Affects: xorg-server (Ubuntu) Importance: Undecided Status: New ** Tags: patch xenial -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1764877 Title: glamorgl Xv causes xvimagesink failure Status in xorg-server package in Ubuntu: New Bug description: On Ubuntu 16.04 with xserver-xorg-2:1.17.2-2, xvimagesink fails for certain sizes of image. Originally seen when receiving a meeting screen share in Pidgin, reproducible as follows: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,width=905,height=720 ! xvimagesink The problem is actually in glamor_xv.c, fixed by the following upstream patch: https://cgit.freedesktop.org/xorg/xserver/commit/?id=12a6b189fb17894d2c3851b70a396bbf41f444c6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1764877/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
This is CVE-2018-1000135. For some reason the 'Link to CVE' option above doesn't seem to work. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000135 ** CVE added: https://cve.mitre.org/cgi- bin/cvename.cgi?name=2018-1000135 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in network-manager package in Ubuntu: Confirmed Bug description: In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] [NEW] Full-tunnel VPN DNS leakage regression
*** This bug is a security vulnerability *** Public security bug reported: In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) ** Affects: network-manager (Ubuntu) Importance: High Status: Confirmed ** Tags: regression-update xenial ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in network-manager package in Ubuntu: Confirmed Bug description: In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 666446] Re: NetworkManager VPN should offer an option to use *only* VPN nameservers
I don't think this should be considered a 'feature request'. If you have a full-tunnel VPN, your employer will *expect* all your network traffic to go via the VPN as if you were dialled directly into the corporate network. Allowing some of the DNS traffic to "escape" to be seen by potentially malicious local DNS servers is utterly wrong. In particular I don't agree this is a 'feature request' for 16.04 because it *used* to work there. You fixed it once with this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch That patch got dropped in an update, so this isn't just a security problem but also a regression in 16.04. cf. https://bugzilla.gnome.org/show_bug.cgi?id=746422 https://bugzilla.redhat.com/show_bug.cgi?id=1553634 ** Bug watch added: GNOME Bug Tracker #746422 https://bugzilla.gnome.org/show_bug.cgi?id=746422 ** Bug watch added: Red Hat Bugzilla #1553634 https://bugzilla.redhat.com/show_bug.cgi?id=1553634 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/666446 Title: NetworkManager VPN should offer an option to use *only* VPN nameservers Status in NetworkManager: Confirmed Status in network-manager package in Ubuntu: Triaged Bug description: Binary package hint: network-manager If I configure a VPN in NetworkManger, the DNS servers I get via DHCP over that VPN connection are *prepended* to /etc/resolv.conf. This is good in that they get used first, but it's not quite enough. Here's the scenario: My two office DNS servers support DNSSEC validation. My ISP at home does not. When I connect to the VPN and try to resolve a name which fails DNSSEC validation (e.g. badsign-a.test.dnssec-tools.org), my office DNS servers return SERVFAIL (as per DNSSEC validation behavior). This causes libc to fail over to my ISP's DNS server. The result is that the domain name resolves, when it should fail. If this were a real attack instead of a test scenario, it'd have security implications. If I could make the VPN *replace* my DNS servers in /etc/resolv.conf, everything would work as expected. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: network-manager 0.8-0ubuntu3 [modified: usr/lib/NetworkManager/nm-crash-logger usr/lib/NetworkManager/nm-dhcp-client.action usr/lib/NetworkManager/nm-dispatcher.action usr/lib/NetworkManager/nm-avahi-autoipd.action] ProcVersionSignature: Ubuntu 2.6.32-25.45-generic 2.6.32.21+drm33.7 Uname: Linux 2.6.32-25-generic x86_64 Architecture: amd64 CRDA: Error: [Errno 2] No such file or directory Date: Mon Oct 25 13:32:47 2010 EcryptfsInUse: Yes InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100113) Keyfiles: Error: [Errno 2] No such file or directory ProcEnviron: Error: [Errno 13] Permission denied: '/proc/24718/environ' SourcePackage: network-manager To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/666446/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1752176] [NEW] Voice calls fail without gst-plugins-bad installed
Public bug reported: Pidgin requires the "liveadder" element from gstreamer1.0-plugins-bad, and has no error handling for the case where it isn't present: https://developer.pidgin.im/ticket/17290 Perhaps the package should depend on gstreamer1.0-plugins-bad to avoid this failure mode. ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1752176 Title: Voice calls fail without gst-plugins-bad installed Status in pidgin package in Ubuntu: New Bug description: Pidgin requires the "liveadder" element from gstreamer1.0-plugins-bad, and has no error handling for the case where it isn't present: https://developer.pidgin.im/ticket/17290 Perhaps the package should depend on gstreamer1.0-plugins-bad to avoid this failure mode. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1752176/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751037] Re: Mute status not updated
** Patch added: "0001-Pidgin-Indicate-mute-unmute-status-when-changed-remo.patch" https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751037/+attachment/5060325/+files/0001-Pidgin-Indicate-mute-unmute-status-when-changed-remo.patch -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751037 Title: Mute status not updated Status in pidgin package in Ubuntu: New Bug description: When I am on an audio call and the remote end mutes me, that is not correctly displayed in the local UI. Fixed in Pidgin 2.13 by #17273: https://developer.pidgin.im/ticket/17273 Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751046] Re: Pidgin rewrites buddy icons on each startup
** Patch added: "0001-Do-not-rewrite-custom-buddy-icons-already-in-the-cac.patch" https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751046/+attachment/5060328/+files/0001-Do-not-rewrite-custom-buddy-icons-already-in-the-cac.patch -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751046 Title: Pidgin rewrites buddy icons on each startup Status in pidgin package in Ubuntu: New Bug description: Every time Pidgin starts up, it rewrites all the buddy icon files for no good reason. Fixed in 2.13 by #17259: https://developer.pidgin.im/ticket/17259 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751046/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751039] Re: Search results in finch updated incorrectly
** Patch added: "0001-Fix-Finch-search-results-display-17238.patch" https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751039/+attachment/5060327/+files/0001-Fix-Finch-search-results-display-17238.patch -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751039 Title: Search results in finch updated incorrectly Status in pidgin package in Ubuntu: New Bug description: Finch doesn't clear the previous search results when they are updated in real time. Fixed upstream by #17238: https://developer.pidgin.im/ticket/17238 Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751039/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751038] Re: Labelled buttons missing from Pidgin search dialogs
** Patch added: "0001-Ensure-labelled-buttons-are-shown-for-search-results.patch" https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751038/+attachment/5060326/+files/0001-Ensure-labelled-buttons-are-shown-for-search-results.patch -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751038 Title: Labelled buttons missing from Pidgin search dialogs Status in pidgin package in Ubuntu: New Bug description: Pidgin fails to display buttons with custom labels in search dialogs. Fixed in 2.13 by #17188: https://developer.pidgin.im/ticket/17188 (by cherry-picking an existing fix from the master branch for #14821). Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751038/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751046] [NEW] Pidgin rewrites buddy icons on each startup
Public bug reported: Every time Pidgin starts up, it rewrites all the buddy icon files for no good reason. Fixed in 2.13 by #17259: https://developer.pidgin.im/ticket/17259 ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New ** Description changed: Every time Pidgin starts up, it rewrites all the buddy icon files for no good reason. - Fixed in 2.13 by #17259: https://developer.pidgin.im/ticket/17238 + Fixed in 2.13 by #17259: https://developer.pidgin.im/ticket/17259 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751046 Title: Pidgin rewrites buddy icons on each startup Status in pidgin package in Ubuntu: New Bug description: Every time Pidgin starts up, it rewrites all the buddy icon files for no good reason. Fixed in 2.13 by #17259: https://developer.pidgin.im/ticket/17259 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751046/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751038] [NEW] Labelled buttons missing from Pidgin search dialogs
Public bug reported: Pidgin fails to display buttons with custom labels in search dialogs. Fixed in 2.13 by #17188: https://developer.pidgin.im/ticket/17188 (by cherry-picking an existing fix from the master branch for #14821). Please could you pull this fix into the packages, even if 2.13 isn't released in time. ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751038 Title: Labelled buttons missing from Pidgin search dialogs Status in pidgin package in Ubuntu: New Bug description: Pidgin fails to display buttons with custom labels in search dialogs. Fixed in 2.13 by #17188: https://developer.pidgin.im/ticket/17188 (by cherry-picking an existing fix from the master branch for #14821). Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751038/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751037] [NEW] Mute status not updated
Public bug reported: When I am on an audio call and the remote end mutes me, that is not correctly displayed in the local UI. Fixed in Pidgin 2.13 by #17273: https://developer.pidgin.im/ticket/17273 Please could you pull this fix into the packages, even if 2.13 isn't released in time. ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751037 Title: Mute status not updated Status in pidgin package in Ubuntu: New Bug description: When I am on an audio call and the remote end mutes me, that is not correctly displayed in the local UI. Fixed in Pidgin 2.13 by #17273: https://developer.pidgin.im/ticket/17273 Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1751039] [NEW] Search results in finch updated incorrectly
Public bug reported: Finch doesn't clear the previous search results when they are updated in real time. Fixed upstream by #17238: https://developer.pidgin.im/ticket/17238 Please could you pull this fix into the packages, even if 2.13 isn't released in time. ** Affects: pidgin (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pidgin in Ubuntu. https://bugs.launchpad.net/bugs/1751039 Title: Search results in finch updated incorrectly Status in pidgin package in Ubuntu: New Bug description: Finch doesn't clear the previous search results when they are updated in real time. Fixed upstream by #17238: https://developer.pidgin.im/ticket/17238 Please could you pull this fix into the packages, even if 2.13 isn't released in time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1751039/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1647285] Re: SSL trust not system-wide
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741005 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704180 https://lists.freedesktop.org/archives/p11-glue/2013-June/000331.html ** Bug watch added: Debian Bug tracker #741005 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741005 ** Bug watch added: Debian Bug tracker #704180 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704180 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: New Status in nss package in Ubuntu: New Status in p11-kit package in Ubuntu: New Status in thunderbird package in Ubuntu: New Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 420411] Re: vpn connection handshake times out too soon
This appears to still be broken in 16.04. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/420411 Title: vpn connection handshake times out too soon Status in network-manager package in Ubuntu: Confirmed Bug description: Binary package hint: network-manager-openvpn NetworkManager only waits 40 seconds for the VPN to come up. This is too short when using a slow connection as for instance a 64kbps GPRS connection. Calling openvpn manually also timeouts sometimes with the default timeout (60s?), but I am able to override it using the "connect- timeout" option in the configuration file and solve the problem. ProblemType: Bug Architecture: i386 Date: Fri Aug 28 10:55:21 2009 DistroRelease: Ubuntu 9.10 Package: network-manager-openvpn 0.7.1-0ubuntu2 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-7.27-generic SourcePackage: network-manager-openvpn Uname: Linux 2.6.31-7-generic i686 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/420411/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1647285] Re: SSL trust not system-wide
I believe NSS wants these patches backported from 3.30: https://bugzilla.mozilla.org/show_bug.cgi?id=1334976 Firefox has its own copy of NSS which I think as of Firefox 54 should be fine. Thunderbird also needs fixing, I think. ** Bug watch added: Mozilla Bugzilla #1334976 https://bugzilla.mozilla.org/show_bug.cgi?id=1334976 ** Also affects: thunderbird (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1647285 Title: SSL trust not system-wide Status in ca-certificates package in Ubuntu: New Status in nss package in Ubuntu: New Status in p11-kit package in Ubuntu: New Status in thunderbird package in Ubuntu: New Bug description: When I install a corporate CA trust root with update-ca-certificates, it doesn't seem to work everywhere. Various things like Firefox, Evolution, Chrome, etc. all fail to trust the newly-installed trusted CA. This ought to work, and does on other distributions. In p11-kit there is a module p11-kit-trust.so which can be used as a drop-in replacement for NSS's own libnssckbi.so trust root module, but which reads from the system's configured trust setup instead of the hard- coded version. This allows us to install the corporate CAs just once, and then file a bug against any package that *doesn't* then trust them. See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for some of the historical details from when this feature was first implemented, but this is all now supported upstream and not at all distribution-specific. There shouldn't be any significant work required; it's mostly just a case of configuring and building it to make use of this functionality. (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1651847] [NEW] Cannot decrypt S/MIME messages
Public bug reported: In Ubuntu 16.04 with Evolution 3.18, I obtained a new S/MIME cert from Comodo and sent myself an encrypted email. Evolution can't decrypt its own message, reporting 'Could not parse S/MIME message: security library: invalid algorithm. (-8186) - Decoder failed'. The same message could be decrypted OK by Evolution 3.22 on Fedora 25. A reply sent from there could also not be decrypted by Ubuntu's version. ** Affects: evolution (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evolution in Ubuntu. https://bugs.launchpad.net/bugs/1651847 Title: Cannot decrypt S/MIME messages Status in evolution package in Ubuntu: New Bug description: In Ubuntu 16.04 with Evolution 3.18, I obtained a new S/MIME cert from Comodo and sent myself an encrypted email. Evolution can't decrypt its own message, reporting 'Could not parse S/MIME message: security library: invalid algorithm. (-8186) - Decoder failed'. The same message could be decrypted OK by Evolution 3.22 on Fedora 25. A reply sent from there could also not be decrypted by Ubuntu's version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1651847/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609700] Re: username is not saved in openconnect connection dialog
This is actually a NetworkManager bug. As noted in bug 1648905 it's fixed upstream by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-2=bb45adeda0bf427ada23b09daf970b0757e82d60 ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Bug watch added: Red Hat Bugzilla #1332491 https://bugzilla.redhat.com/show_bug.cgi?id=1332491 ** Also affects: fedora via https://bugzilla.redhat.com/show_bug.cgi?id=1332491 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1609700 Title: username is not saved in openconnect connection dialog Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openconnect package in Ubuntu: Confirmed Status in Fedora: Unknown Bug description: Hi, I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty! This happens for a SSLVPN configuration. For another VPN config (don't know which type) everything is ok. openconnect: 7.06-2build2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1609700/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648905] Re: VPN username and settings not saved
*** This bug is a duplicate of bug 1609700 *** https://bugs.launchpad.net/bugs/1609700 Actually, this is probably a duplicate of bug 1609700 ** This bug has been marked a duplicate of bug 1609700 username is not saved in openconnect connection dialog -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1648905 Title: VPN username and settings not saved Status in network-manager package in Ubuntu: Fix Committed Bug description: The OpenConnect VPN auth-dialog doesn't remember usernames and other settings. See discussion (and fix) in https://bugzilla.redhat.com/show_bug.cgi?id=1332491 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1648905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648905] Re: VPN username and settings not saved
When do we get a fix for 16.04? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1648905 Title: VPN username and settings not saved Status in network-manager package in Ubuntu: Fix Committed Bug description: The OpenConnect VPN auth-dialog doesn't remember usernames and other settings. See discussion (and fix) in https://bugzilla.redhat.com/show_bug.cgi?id=1332491 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1648905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648905] [NEW] VPN username and settings not saved
Public bug reported: The OpenConnect VPN auth-dialog doesn't remember usernames and other settings. See discussion (and fix) in https://bugzilla.redhat.com/show_bug.cgi?id=1332491 ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1648905 Title: VPN username and settings not saved Status in network-manager package in Ubuntu: New Bug description: The OpenConnect VPN auth-dialog doesn't remember usernames and other settings. See discussion (and fix) in https://bugzilla.redhat.com/show_bug.cgi?id=1332491 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1648905/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 893024] Re: Support 802.1x auth requirement detection and fallback
https://bugzilla.gnome.org/show_bug.cgi?id=723084 ** Bug watch added: GNOME Bug Tracker #723084 https://bugzilla.gnome.org/show_bug.cgi?id=723084 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/893024 Title: Support 802.1x auth requirement detection and fallback Status in network-manager package in Ubuntu: Triaged Bug description: NetworkManager asks for 802.1x user name and password when there is no 802.1x support on switch port. Background: We use 802.1x wired authentication on our campus network. NetworkManager does not fall back nicely when connecting to a non- authenticated switch. What happens: NetworkManager asks for user name and password when "Use 802.1x security" is selected in the connection editor and the computer is connected to an unauthenticated port. What should happen: Network manager should notice that the port is not access-controlled and do one of the following: (1) ask for connecting unauthenticated or (2) connect unauthenticated without asking. There should be a setting for selecting #1 or #2. Now the user is asked about information which has no effect on completing the connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/893024/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648616] Re: Firefox uses its own version of NSS, incompatible with system version
Setting aside the wisdom of that response, and my surprise at discovering that the distribution even *permits* you to ship your own copy of certain libraries — *especially* security-critical libraries — in your own package instead of using the system's version doesn't that mean you should be shipping your own version of things like certutil and modutil, given that you now not only have your own copy of the libraries, but you even have a speshul different database format to the one that the system NSS uses, so you aren't even compatible with /usr/bin/certtool. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1648616 Title: Firefox uses its own version of NSS, incompatible with system version Status in firefox package in Ubuntu: Invalid Status in thunderbird package in Ubuntu: New Bug description: Because of bug 1647285 I need to install corporate SSL CAs into the database of each NSS-using application individually. Unfortunately it doesn't seem to work for Firefox. Not only does Firefox ship with its *own* version of NSS instead using the system's version, but it even seems to be configured very differently. Firefox appears to use the legacy Berkeley DB database for its softokn, in key3.db/cert8.db. However, the system's certutil won't work with that legacy format: $ certutil -d ~/.mozilla/firefox/default.default/ -L certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. I can force it to use the SQL database in key4.db/cert9.db by running with NSS_DEFAULT_DB_TYPE=sql, and then I *can* install trusted CAs with certutil. But actually, it's much simpler to just make a symlink from firefox's own special copy of the SSL trust roots in libnssckbi.so, to the system's p11-kit-trust.so — thus making Firefox honour the system trust configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1648616/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648616] Re: Firefox uses its own version of NSS, incompatible with system version
** Also affects: thunderbird (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1648616 Title: Firefox uses its own version of NSS, incompatible with system version Status in firefox package in Ubuntu: Invalid Status in thunderbird package in Ubuntu: New Bug description: Because of bug 1647285 I need to install corporate SSL CAs into the database of each NSS-using application individually. Unfortunately it doesn't seem to work for Firefox. Not only does Firefox ship with its *own* version of NSS instead using the system's version, but it even seems to be configured very differently. Firefox appears to use the legacy Berkeley DB database for its softokn, in key3.db/cert8.db. However, the system's certutil won't work with that legacy format: $ certutil -d ~/.mozilla/firefox/default.default/ -L certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. I can force it to use the SQL database in key4.db/cert9.db by running with NSS_DEFAULT_DB_TYPE=sql, and then I *can* install trusted CAs with certutil. But actually, it's much simpler to just make a symlink from firefox's own special copy of the SSL trust roots in libnssckbi.so, to the system's p11-kit-trust.so — thus making Firefox honour the system trust configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1648616/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1648616] [NEW] Firefox uses its own version of NSS, incompatible with system version
Public bug reported: Because of bug 1647285 I need to install corporate SSL CAs into the database of each NSS-using application individually. Unfortunately it doesn't seem to work for Firefox. Not only does Firefox ship with its *own* version of NSS instead using the system's version, but it even seems to be configured very differently. Firefox appears to use the legacy Berkeley DB database for its softokn, in key3.db/cert8.db. However, the system's certutil won't work with that legacy format: $ certutil -d ~/.mozilla/firefox/default.default/ -L certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. I can force it to use the SQL database in key4.db/cert9.db by running with NSS_DEFAULT_DB_TYPE=sql, and then I *can* install trusted CAs with certutil. But actually, it's much simpler to just make a symlink from firefox's own special copy of the SSL trust roots in libnssckbi.so, to the system's p11-kit-trust.so — thus making Firefox honour the system trust configuration. ** Affects: firefox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1648616 Title: Firefox uses its own version of NSS, incompatible with system version Status in firefox package in Ubuntu: New Bug description: Because of bug 1647285 I need to install corporate SSL CAs into the database of each NSS-using application individually. Unfortunately it doesn't seem to work for Firefox. Not only does Firefox ship with its *own* version of NSS instead using the system's version, but it even seems to be configured very differently. Firefox appears to use the legacy Berkeley DB database for its softokn, in key3.db/cert8.db. However, the system's certutil won't work with that legacy format: $ certutil -d ~/.mozilla/firefox/default.default/ -L certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. I can force it to use the SQL database in key4.db/cert9.db by running with NSS_DEFAULT_DB_TYPE=sql, and then I *can* install trusted CAs with certutil. But actually, it's much simpler to just make a symlink from firefox's own special copy of the SSL trust roots in libnssckbi.so, to the system's p11-kit-trust.so — thus making Firefox honour the system trust configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1648616/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 893024] Re: Support 802.1x auth requirement detection and fallback
Is there an upstream bug/RFE filed for this? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/893024 Title: Support 802.1x auth requirement detection and fallback Status in network-manager package in Ubuntu: Triaged Bug description: NetworkManager asks for 802.1x user name and password when there is no 802.1x support on switch port. Background: We use 802.1x wired authentication on our campus network. NetworkManager does not fall back nicely when connecting to a non- authenticated switch. What happens: NetworkManager asks for user name and password when "Use 802.1x security" is selected in the connection editor and the computer is connected to an unauthenticated port. What should happen: Network manager should notice that the port is not access-controlled and do one of the following: (1) ask for connecting unauthenticated or (2) connect unauthenticated without asking. There should be a setting for selecting #1 or #2. Now the user is asked about information which has no effect on completing the connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/893024/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 543183]
FWIW the trust issue has mostly been solved. Fedora for example ships p11-kit-trust.so as a replacement for NSS's libnssckbi.so. It provides all the trust roots in the place that NSS *expects* them to come from. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/543183 Title: Updating system certificates requires rebuild Status in The Mozilla Firefox Browser: Confirmed Status in firefox package in Ubuntu: Triaged Status in firefox package in Fedora: Unknown Bug description: Binary package hint: firefox Hi, Updating the list of trusted root certificate authorities across all users of a system seems requires rebuilding a library. Non-root certificates may similarly be impacted. update-ca-certificates could be a mechanism to update the root certificates used by firefox. On a corporate install of firefox, currently the only options to adding an internal root certificate authority are to: * Hack it into the user creation script to extract a pre-created profile, and update all the existing users profile directory. This bypasses the random profile directory creation. * Re-compile the shared library (.so) containing the root certificate authorities (extra maintenance for dealing with ubuntu package updates). * Have every user of the system go through a manual process of adding the root certificate (most users don't know how). * Use a plugin extension for firefox (do any exist?) that is automatically used by all users (can this be done?) * Have the root certificate signed at great expense by an external root certificate authority already included. CaCert integration would lower the cost but that seems far away, and is still an external authority. These root certificates also might be limited to a single domain (wildcard certificate?) or have other limitations (low expiry?, contractual restrictions...). It seems unlikely that Mozilla will move away from having the root certificates stored in the shared library as it would take some control away from them. The shared libary method makes it harder for malicious changes to be made, but only by adding the barier of recompilation and installation of a shared library. Thanks, Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/543183/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
