[Touch-packages] [Bug 2056556] [NEW] apt-add-repository incorrectly forces lowercase
Public bug reported: I have a local APT repository with a non-lowercase suite identifier. apt-add-repository always forces it into lowercase, which causes apt to emit warnings when it notices the mismatch: $ sudo apt-add-repository "deb http://example.com/deb FooBar Baz" Repository: 'deb http://example.com/ foobar Baz' Description: Archive for codename: foobar components: Baz More info: http://example.com/ Adding repository. Press [ENTER] to continue or Ctrl-c to cancel. (...) $ sudo apt update (...) W: Conflicting distribution: http://example.com/deb foobar InRelease (expected foobar but got FooBar) ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2056556 Title: apt-add-repository incorrectly forces lowercase Status in software-properties package in Ubuntu: New Bug description: I have a local APT repository with a non-lowercase suite identifier. apt-add-repository always forces it into lowercase, which causes apt to emit warnings when it notices the mismatch: $ sudo apt-add-repository "deb http://example.com/deb FooBar Baz" Repository: 'deb http://example.com/ foobar Baz' Description: Archive for codename: foobar components: Baz More info: http://example.com/ Adding repository. Press [ENTER] to continue or Ctrl-c to cancel. (...) $ sudo apt update (...) W: Conflicting distribution: http://example.com/deb foobar InRelease (expected foobar but got FooBar) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2056556/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754075] Re: apt-setup uses apt-key but probably should not anymore
Any progress on this? This is a serious regression for us which makes preseed substantially less functional in bionic... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1754075 Title: apt-setup uses apt-key but probably should not anymore Status in apt-setup package in Ubuntu: Confirmed Status in gnupg package in Ubuntu: Confirmed Status in gnupg2 package in Ubuntu: Confirmed Bug description: In di if the kernel is in a private PPA we seed di using d-i apt-setup/local0/key string http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search= this used to work in xenial, but in bionic this fails and therefore apt update fails in base-installer. May be because add-apt-key is not installed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/1754075/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1449001] [NEW] systemd-resolved: please do not use Google public DNS by default
Public bug reported: systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers. systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user. $ cat /etc/systemd/resolved.conf (...) # Entries in this file show the compile time defaults. (...) #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::8844 This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd-resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5). I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish. Steps to reproduce: 1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*) 2. Reboot, or otherwise clear relevant state 3. sudo service systemd-resolved start 4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf 5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter. This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco d'Itri: "Short summary: have a resolv.conf file or use DHCP"). I would argue that it's safest not to have fallback DNS servers configured at all by default. ** Affects: systemd Importance: Unknown Status: Unknown ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Bug watch added: Debian Bug tracker #761658 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 ** Also affects: systemd via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1449001 Title: systemd-resolved: please do not use Google public DNS by default Status in systemd: Unknown Status in systemd package in Ubuntu: New Bug description: systemd-resolved will fall back to Google public DNS (8.8.8.8, etc.) in the absence of other configured DNS servers. systemd-resolved is not enabled by default in Ubuntu 15.04, but it is installed by default and will behave in this way if enabled by the user. $ cat /etc/systemd/resolved.conf (...) # Entries in this file show the compile time defaults. (...) #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::8844 This raises privacy concerns since in the event of accidental misconfiguration DNS queries will be sent unencrypted across the internet, and potentially also security concerns given systemd- resolved does not perform DNSSEC validation and is not particularly well hardened against malicious responses e.g. from a MITM (http://www.openwall.com/lists/oss-security/2014/11/12/5). I believe that it would be better to fail safe if no DNS server is configured -- i.e. have DNS lookups fail; it's better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish. Steps to reproduce: 1. Remove existing DNS configuration (from /etc/network/interfaces, /etc/resolv.conf, /etc/resolvconf/resolv.conf.d/*) 2. Reboot, or otherwise clear relevant state 3. sudo service systemd-resolved start 4. Note that Google's servers are listed in /run/systemd/resolve/resolv.conf 5. If systemd-resolved is enabled in /etc/nsswitch.conf (it isn't by default), observe that DNS lookups probably still work, and queries are being sent to one of Google's servers Possible workaround/bugfix: ship a resolved.conf which clears the FallbackDNS parameter. This issue has been discussed in the Debian BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658). My interpretation of the Debian package maintainer's position is that a user concerned with the privacy implications shouldn't let systemd get into a state where it uses the fallback DNS servers (quoting Marco
[Touch-packages] [Bug 1350220] Re: hibernation fails because chvt hangs
There's a race in chvt (see my comment at https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/1351564/comments/4) which may be to blame. I suspect something on my system (Nvidia driver?) is almost always winning this race, so chvt almost always blocks and I can't suspend. Perhaps pm-utils should use another more-reliable way of blanking the screen? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pm-utils in Ubuntu. https://bugs.launchpad.net/bugs/1350220 Title: hibernation fails because chvt hangs Status in “pm-utils” package in Ubuntu: Confirmed Bug description: EDIT : initial title was "hibernation fails because 99video does not terminate" When I initiate an hibernation on my computer, the following frequently happens (about 50% of the time) : 1. screen goes black (normal) ; 2. instead of showing the progress of the writing of RAM to disk in console mode, the screen remains black ; 3. the screensaver prompt for login appears ; 4. after returning to desktop, I see that the network card is not functioning ; 5. /var/log/pm-suspend.log last line is "Running hook /usr/lib/pm-utils/sleep.d/99video hibernate hibernate:". Indeed, a ps -ef | grep 99video shows that the /usr/lib/pm- utils/sleep.d/99video script is still running. If I kill this script, pm-utils logs "/usr/lib/pm- utils/sleep.d/99video hibernate hibernate: Returned exit code 143.", aborts hibernation and then runs the hooks for thaw. I can then try again to hibernate, and it works : I never had this bug trigger twice in a row. This bug did not occur when I was running Ubuntu 12.04 and the corresponding kernels (but back then I was also using the video card driver from AMD's website instead of fglrx-updates). EDIT : further debugging (PM_DEBUG=true) shows that the blocking point in 99video is "chvt 63". I tried to hibernate with --quirk-no-chvt. This allows the script 99video to terminate and the hibernation process itself to engage. However, my hibernation module, /usr/lib/pm-utils/module.d/hibernate, does a chvt 63 too, which is not controlled by the --quirk-no-chvt. So I experienced again a return to desktop with a chvt process not progressing. I killed it and hibernation took place, without any visual clue. On booting the system again, thaw took place correctly but the system was not usable because I did not get access to a console (graphical or text). Indeed, the pm-suspend.log shows that chvt 8 did not return. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: pm-utils 1.4.1-13ubuntu0.1 ProcVersionSignature: Ubuntu 3.13.0-32.57~ppa1-generic-tuxonice 3.13.11.4 Uname: Linux 3.13.0-32-generic-tuxonice x86_64 NonfreeKernelModules: fglrx ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: XFCE Date: Wed Jul 30 08:47:17 2014 InstallationDate: Installed on 2014-07-18 (11 days ago) InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2) PackageArchitecture: all SourcePackage: pm-utils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/1350220/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1351564] Re: chvt sometimes hangs, causing hibernation to fail
chvt makes two ioctl calls, one to change the VT and one to wait for the new VT to become active. There's a race condition here; if something changes the VT back before the second ioctl, chvt will block indefinitely (or until something else changes to the correct VT). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kbd in Ubuntu. https://bugs.launchpad.net/bugs/1351564 Title: chvt sometimes hangs, causing hibernation to fail Status in “kbd” package in Ubuntu: Confirmed Bug description: This is probably in relation with bug #1350220, which deals with a failure in hibernation. It appears that this is caused by chvt not terminating a some points in the hibernation scripts. Yet I do not know whether the scripts or chvt are to blame. When I initiate an hibernation on my computer, the following frequently happens (about 50% of the time) : 1. screen goes black (normal) ; 2. instead of showing the progress of the writing of RAM to disk in console mode, the screen remains black ; 3. the screensaver prompt for login appears ; 4. after returning to desktop, I see that the network card is not functioning. Further debugging (PM_DEBUG=true) shows that the blocking point lies in 99video and is "chvt 63". I tried to hibernate with --quirk-no- chvt. This allows the script 99video to terminate (because it does not try a chvt 63) and the hibernation process itself to engage. However, my hibernation module, /usr/lib/pm-utils/module.d/hibernate, does a chvt 63 too, which is not controlled by the --quirk-no-chvt. So I experienced again a return to desktop with a chvt process not progressing. I killed it and hibernation took place, without any visual clue. On booting the system again, thaw took place correctly but the system was not usable because I did not get access to a console (graphical or text). Indeed, the pm-suspend.log shows that chvt 8 did not return. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: kbd 1.15.5-1ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-32.57~ppa1-generic-tuxonice 3.13.11.4 Uname: Linux 3.13.0-32-generic-tuxonice x86_64 NonfreeKernelModules: fglrx ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Aug 2 09:52:13 2014 InstallationDate: Installed on 2014-07-18 (14 days ago) InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2) SourcePackage: kbd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/1351564/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
