[Touch-packages] [Bug 1946499] Proposed package upload rejected

2021-10-20 Thread Robie Basak
An upload of gdebi to impish-proposed has been rejected from the upload
queue for the following reason: "Missing SRU information. This looks
like it wasn't intended for SRU, and the changes are now in Jammy?".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdebi in Ubuntu.
https://bugs.launchpad.net/bugs/1946499

Title:
  installation of deb-packages with gdebi-gtk shows "dpkg: error: unable
  to read filedescriptor flags for : Bad file descriptor" in gdebi terminal, package is not
  installed

Status in Ubuntu MATE:
  Invalid
Status in gdebi package in Ubuntu:
  Fix Released
Status in vte2.91 package in Ubuntu:
  Confirmed
Status in gdebi source package in Impish:
  Triaged

Bug description:
  Steps to reproduce:
  1. Install Ubuntu MATE 21.10
  2. Open Firefox, navigate to discord.com
  3. Download deb-file. At time of writing from the 
https://dl.discordapp.net/apps/linux/0.0.16/discord-0.0.16.deb link
  4. Open Caja in ~/Downloads folder and use GDebi to install the 
discord-0.0.16.deb file
  5. In the GDebi window click Install button

  Expected results:
  * Gdebi quietly install discord package, there are no error messages in its 
terminal

  Actual results:
  * Gdebi terminal shows the error in the last line

  ```
  Selecting previously unselected package gconf2-common.
  (Reading database ... 457178 files and directories currently installed.)
  Preparing to unpack .../0-gconf2-common_3.2.6-7ubuntu2_all.deb ...
  Unpacking gconf2-common (3.2.6-7ubuntu2) ...
  Selecting previously unselected package libgconf-2-4:amd64.
  Preparing to unpack .../1-libgconf-2-4_3.2.6-7ubuntu2_amd64.deb ...
  Unpacking libgconf-2-4:amd64 (3.2.6-7ubuntu2) ...
  Selecting previously unselected package gconf-service-backend.
  Preparing to unpack .../2-gconf-service-backend_3.2.6-7ubuntu2_amd64.deb ...
  Unpacking gconf-service-backend (3.2.6-7ubuntu2) ...
  Selecting previously unselected package gconf-service.
  Preparing to unpack .../3-gconf-service_3.2.6-7ubuntu2_amd64.deb ...
  Unpacking gconf-service (3.2.6-7ubuntu2) ...
  Selecting previously unselected package libappindicator1.
  Preparing to unpack 
.../4-libappindicator1_12.10.1+20.10.20200706.1-0ubuntu1_amd64.deb ...
  Unpacking libappindicator1 (12.10.1+20.10.20200706.1-0ubuntu1) ...
  Selecting previously unselected package libunwind-13:amd64.
  Preparing to unpack .../5-libunwind-13_1%3a13.0.0-2_amd64.deb ...
  Unpacking libunwind-13:amd64 (1:13.0.0-2) ...
  Selecting previously unselected package libc++abi1-13:amd64.
  Preparing to unpack .../6-libc++abi1-13_1%3a13.0.0-2_amd64.deb ...
  Unpacking libc++abi1-13:amd64 (1:13.0.0-2) ...
  Selecting previously unselected package libc++1-13:amd64.
  Preparing to unpack .../7-libc++1-13_1%3a13.0.0-2_amd64.deb ...
  Unpacking libc++1-13:amd64 (1:13.0.0-2) ...
  Selecting previously unselected package libc++1:amd64.
  Preparing to unpack .../8-libc++1_1%3a13.0-53~exp1_amd64.deb ...
  Unpacking libc++1:amd64 (1:13.0-53~exp1) ...
  Setting up libappindicator1 (12.10.1+20.10.20200706.1-0ubuntu1) ...
  Setting up gconf2-common (3.2.6-7ubuntu2) ...

  Creating config file /etc/gconf/2/path with new version
  Setting up libunwind-13:amd64 (1:13.0.0-2) ...
  Setting up libc++abi1-13:amd64 (1:13.0.0-2) ...
  Setting up libc++1-13:amd64 (1:13.0.0-2) ...
  Setting up libc++1:amd64 (1:13.0-53~exp1) ...
  Setting up gconf-service (3.2.6-7ubuntu2) ...
  Processing triggers for libc-bin (2.34-0ubuntu2) ...
  Processing triggers for sgml-base (1.30) ...
  Setting up libgconf-2-4:amd64 (3.2.6-7ubuntu2) ...
  Setting up gconf-service-backend (3.2.6-7ubuntu2) ...
  Processing triggers for libc-bin (2.34-0ubuntu2) ...
  dpkg: error: unable to read filedescriptor flags for : Bad file descriptor
  ```

  and as the result Discord package is not installed .

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: gdebi 0.9.5.7+nmu5ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
  Uname: Linux 5.13.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE
  Date: Fri Oct  8 18:17:36 2021
  InstallationDate: Installed on 2021-10-08 (0 days ago)
  InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Daily amd64 (20211008)
  PackageArchitecture: all
  SourcePackage: gdebi
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.default.apport:
   # set this to 0 to disable apport, or to 1 to enable it
   # you can temporarily override this with
   # sudo service apport start force_start=1
   enabled=0
  mtime.conffile..etc.default.apport: 2021-10-08T15:41:41.001986

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1946499/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More 

[Touch-packages] [Bug 1946096] Re: Apply upstream patches to fix problems for Foxconn and Quectel modems.

2021-10-20 Thread Robie Basak
SRU review

I don't see any explanation of what this is fixing, or why this is
needed, so cannot review if the proposed changes qualify for an SRU
under Ubuntu's policies.

Specifically I need an explanation of actual user impact, not just "fix
some problems". Further, note that the procedure says "Do not create a
meta-bug with a title like "Please SRU this" rather than using existing
bug reports". We need actual public bugs for each of the specific
problems that you're fixing. Each of those bugs should be linked from
the changelog, so we can ensure during SRU verification that each of
those issues have individually been verified fixed. Done properly, there
is then no need for a meta bug like this one.

See https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for full
details on what is expected.

The Focal upload is also missing a proper bug reference - the reference
given doesn't match the standard pattern so didn't get copied to the
Launchpad-Bugs-Fixed header.

I'm rejecting both the Hirsute and Focal uploads since both uploads need
their changelogs fixing to properly reference public bugs that contain
full SRU information.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/1946096

Title:
  Apply upstream patches to fix problems for Foxconn and Quectel modems.

Status in OEM Priority Project:
  In Progress
Status in modemmanager package in Ubuntu:
  Fix Committed

Bug description:
  [Impact]

  The following 2 modems need the ModemManager v1.16.6 suite to be patched from 
v1.18.2 to fix some problems(LP#1943774, LP#1943780):
  * Foxconn SDX55 T99W175 5G sub6 PCIE Modem
  * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem 

  The requested upstream patches are listed as below:
  * for Quectel EM160 4G
** 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/83ac82470589a3672092a0ba0be855093b1cf5e2
 
  * for Foxconn T99W175
** 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/21ae558fe3600c84b3ca7dcd9bf50a3ba576c7c9

**https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/76e700f4fd703f952208993330ab098305c13d6b
** 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/52bf2c641171ded9e617022f40497c8984520371
** 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/33e2b023ef01bea9da37ae2beb192f7d92bce47a
** 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/f72046701659073fbfa97516e155865647acb154
 

  
  [Test Plan]

  1. Install the Ubuntu image.
  2. Boot and login the system.
  3. Prepare the modem’s firmware and install the firmware upgrading 
application provided by Foxconn and Quectel
  4. Using the firmware upgrading application to upgrade the modem’s firmware 
  5. Verify if the modem’s firmware upgrading is successful
  6. Reboot 
  7. Verify if the upgraded modem firmware is still working

  
  [Where problems could occur]

  The requested upstream patches are for these 2 specific modems and the status 
information.
  This should not affect existing generic functions and other modems.

  
  [Other Info]

  The firmware and the upgrading application can be downloaded from the 
following link:
  * LP#1943774 for Quectel modems
  * LP#1943780 for Foxconn modems

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1946096/+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 1472288] Re: Add additional attributes in /etc/os-release

2021-10-14 Thread Robie Basak
Unsubscribing sponsors since there's no action to take unless my
question above is answered. Once done, please resubscribe ~ubuntu-
sponsors.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1472288

Title:
  Add additional attributes in /etc/os-release

Status in base-files package in Ubuntu:
  Confirmed

Bug description:
  Please add 'CPE_NAME' and 'BUILD_ID' to /etc/os-release.

  More at http://www.freedesktop.org/software/systemd/man/os-
  release.html.

  I'm not sure BUILD_ID should be something like 'vivid' etc, but it
  would be a nice use. Or introduce a new attribute/value pair like

  NICKNAME_ID="vivid"

  No rush. Thanks for adopting this convention so quickly.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: base-files 7.2ubuntu9
  Uname: Linux 4.1.0-rc5carif-7-ga8b253b x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jul  7 10:26:02 2015
  Dependencies:
   
  InstallationDate: Installed on 2014-11-04 (245 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  ProcEnviron:
   LANGUAGE=en_US
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: base-files
  UpgradeStatus: Upgraded to vivid on 2015-04-25 (73 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1472288/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved

2021-10-13 Thread Robie Basak
Hello Steve, or anyone else affected,

Accepted dnsmasq into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/dnsmasq/2.79-1ubuntu0.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: dnsmasq (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
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/1785383

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Fix Released
Status in dnsmasq package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released
Status in dnsmasq source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in dnsmasq source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in dnsmasq source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in dnsmasq source package in Impish:
  Fix Released
Status in systemd source package in Impish:
  Fix Released

Bug description:
  [Impact]

  dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
  empty answer for a domain it is authoritative for. systemd-resolved
  seems to get confused by this in certain circumstances; when using the
  stub resolver and requesting an address for which there are no 
  records, there can sometimes be a five second hang in resolution.

  [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # returns "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't.
  # does so with the -proposed package.
  -

  [Where problems could occur]

  Problems may occur in case a client queries dnsmasq and relies on
  EDNS0 not being available for behaving correctly. This covers cases
  where the software querying dnsmasq is buggy or misconfigured.

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

  Partial cherry-pick of upstream commit
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  The cherry-pick is partial because half if it is already in the
  package .diff we have in Bionic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1791958] Re: iptables-restore is missing -w option

2021-09-29 Thread Robie Basak
> I'll monitor the "-backports" discussion and let's see from there.

Looks like the backports pocket will be available again. I added bionic-
backports so that this request can be found from that end, since it
looks like backports was something being considered. I don't intend to
imply any particular opinion about the best route.

** Also affects: bionic-backports
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958

Title:
  iptables-restore is missing -w option

Status in Bionic Backports:
  New
Status in iptables package in Ubuntu:
  Confirmed

Bug description:
  For CRIU we need to have iptables version 1.6.2 which includes the
  '-w' option in iptables-restore.

  This is a request to update iptables to 1.6.2 in 18.10 and if possible
  backport the necessary changes to 18.04.

  The CRIU project gets right now many bug reports (mostly in the
  combination LXD + CRIU) due to the missing '-w' option in iptables-
  restore. Especially as 18.04 will be around for some time it would be
  good to have iptables-restore available with '-w'.

  This is one example bug report: https://github.com/checkpoint-
  restore/criu/issues/551

  But not only CRIU would benefit from this change. It seems also
  problematic with Kubernetes:
  https://github.com/kubernetes/kubernetes/pull/60978

  So if possible, please update iptables to 1.6.2 (or backport changes)
  to support -w in iptables-restore.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bionic-backports/+bug/1791958/+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 1940656] Re: Potential use after free bugs in 1.1.1

2021-09-14 Thread Robie Basak
Thanks Marc and Dimitri! With Marc's confirmation this is unblocked from
the SRU queue then.

But please don't assign me. Any member of the SRU team can process this.
Assigning individual SRU team members not part of the SRU process,
implies an implied lock that isn't there, and would only delay things
because I am not processing SRUs this week.

** Changed in: openssl (Ubuntu Focal)
 Assignee: Robie Basak (racb) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1940656

Title:
  Potential use after free bugs in 1.1.1

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  In Progress

Bug description:
  [Impact]

   * There have been multiple use-after-free bugs fixed in OpenSSL 1.1.1
  stable branches which have not yet been applied in Focal. They are
  difficult to reproduce, often require an engine to be used, and
  somehow fail, as these use-after-free bugs are all in error conditions
  and error paths. Usually fixing local configuration, and making engine
  available is the right solution. It is however better to return errors
  than crash. These patches are in 1.1.1h+ and openssl-3.

  [Test Plan]

   * The fixes were applied upstream without clear reproducers, or unit
  tests

   * Check that all autopkgtests pass and there no regressions

   * Configure and use openssl with any engine and ensure that it
  continues to work

  [Where problems could occur]

   * There will be behaviour change, such that multithreaded
  applications may now notice Null pointers from the openssl engine
  apis, when previously they saw valid pointers which were freed
  already. Meaning that on connection failures, daemon or application
  shutdowns, different messages might be generated i.e. invalid engine
  context, unallocated methods, instead of crashing with double free.

  [Other Info]

   * Multiple customers are using openssl 1.1.1 with engines these days,
  reporting various issues, it is better to have more resilient openssl
  w.r.t. engine use in case of engine missuse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+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 1940656] Re: Potential use after free bugs in 1.1.1

2021-09-01 Thread Robie Basak
Shouldn't these go into the security pocket? At the least I'd like an
explicit nak from the security team please.

** Changed in: openssl (Ubuntu Focal)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1940656

Title:
  Potential use after free bugs in 1.1.1

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Incomplete

Bug description:
  [Impact]

   * There have been multiple use-after-free bugs fixed in OpenSSL 1.1.1
  stable branches which have not yet been applied in Focal. They are
  difficult to reproduce, often require an engine to be used, and
  somehow fail, as these use-after-free bugs are all in error conditions
  and error paths. Usually fixing local configuration, and making engine
  available is the right solution. It is however better to return errors
  than crash. These patches are in 1.1.1h+ and openssl-3.

  [Test Plan]

   * The fixes were applied upstream without clear reproducers, or unit
  tests

   * Check that all autopkgtests pass and there no regressions

   * Configure and use openssl with any engine and ensure that it
  continues to work

  [Where problems could occur]

   * There will be behaviour change, such that multithreaded
  applications may now notice Null pointers from the openssl engine
  apis, when previously they saw valid pointers which were freed
  already. Meaning that on connection failures, daemon or application
  shutdowns, different messages might be generated i.e. invalid engine
  context, unallocated methods, instead of crashing with double free.

  [Other Info]

   * Multiple customers are using openssl 1.1.1 with engines these days,
  reporting various issues, it is better to have more resilient openssl
  w.r.t. engine use in case of engine missuse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+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 1940528] Proposed package upload rejected

2021-09-01 Thread Robie Basak
An upload of curl to focal-proposed has been rejected from the upload
queue for the following reason: "Quilt patch missing in series file".

** Changed in: curl (Ubuntu Focal)
   Status: Incomplete => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/1940528

Title:
  curl 7.68 does not init OpenSSL correctly

Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Bionic:
  New
Status in curl source package in Focal:
  Triaged

Bug description:
  [Impact]

   * curl 7.68 does not correctly use OpenSSL 1.1.0+ api to init OpenSSL
  global state prior to executing any OpenSSL APIs. This may lead to
  duplicate engine initiation, which upon engine unload may cause use-
  after-free or double-free of any methods that engine installs. This
  has been fixed in curl 7.74 by correctly calling OpenSSL init api
  prior to any other calls to OpenSSL apis.

  [Test Plan]

   * This should be reproducible with any engines that allocate &
  register methods, and free them upon engine unload. Then use curl with
  openssl backend to test for corrupted stack.

   * I.e. on arm64, compile and configure pka engine from
  
https://github.com/Mellanox/pka/commit/b0f32fa05298bf9e3997ea43fc1c11b90e0d662f
  (i.e. without the double-free protections proposed in
  https://github.com/Mellanox/pka/pull/37 ) on any arm64 hardware, there
  is no need for the engine to actually work or have access to anything,
  as the issue is reproducible when engine is enabled but cannot be
  effectively used.

   * curl any https website

  ...
  PKA_DEV: pka_dev_open_ring_vfio: error: failed to get ring 50 device name
  PKA_ENGINE: PKA instance is invalid
  PKA_ENGINE: failed to retrieve valid instance
  100   338  100   3380 0   3520  0 --:--:-- --:--:-- --:--:--  3520
  (exit status 0)

  is good output from fixed curl.

  Whereas:

  PKA_ENGINE: PKA instance is invalid
  PKA_ENGINE: failed to retrieve valid instance
  100   338  100   3380 0   1169  0 --:--:-- --:--:-- --:--:--  1169
  Segmentation fault (core dumped)
  (exit status non-zero)

  is bad output from currently broken curl.

  [Where problems could occur]

   * Correctly calling OpenSSL init function prior to any other OpenSSL
  apis changes the behaviour of the library slightly - specifically
  openssl configuration file and engines are initialised and loaded
  earlier, meaning that site-local customizations are applied correctly
  whenever using curl cli utility or libcurl4 (the openssl version of
  curl). This will make engine support working correctly across the
  board. However, if one has missconfigured openssl conf and
  missconfigured engines which are now actually attempted to be used one
  may experience unexpected behaviour changes (since potentially
  existing configuration was not actually taking effect).

  [Other Info]
   
   * References:
  https://github.com/curl/curl/commit/1835cb916e0d40eb8bc1165d5627a0b64f911bac
  https://github.com/openssl/openssl/issues/13548
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528/+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 1940999] Re: FTBFS against glibc 2.34

2021-08-27 Thread Robie Basak
Ah, sorry. I saw "disable-regex" and thought that was a description of
the resolution to the failing stack-overflow test!

If updating grep to 3.7 is the easiest way to fix the problem then we
can consider that. But since we're in Feature Freeze for Impish, this
needs an assessment for feature changes. I see you posted the changes
from 3.6 to 3.7. Does this mean you already made the assessment and if
so, what was your conclusion? If feature changes exist then we'll need a
freeze exception from the release team to proceed down this path.

> With the new information above, I think the way I have structured it
> matches the problem I'm trying to address - what do you think?

It's certainly closer but I still think it's a little misleading. Maybe
if we expanded the text it'd be closer. How about:

* New upstream version 3.7 to fix FTBFS (LP: #1940999)
* Add d/p/06-disable-test-regex.patch to disable failing test-regex

But in any case, we can leave it until we've concluded the question on
the best approach to take.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

2021-08-25 Thread Robie Basak
> +Last-Update: Aug-24-2021

This should use ISO format according to the spec please
(https://dep.debian.net/deps/dep3/)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

2021-08-25 Thread Robie Basak
Thank you for working on this!

> To address this I propose picking up the new version of grep.

But you're picking up the new version of grep and then also disabling
the failing test in that update. So why is the new version of grep
necessary at all? Can't you just disable the failing test in the current
version of grep in Impish?

> +  * New upstream version 3.7 (LP: #1940999)
> +  * Add d/p/06-disable-test-regex.patch to disable failing test-regex

This bug is entitled "FTBFS against glibc 2.34" so the bug reference
should go against the second item there, not the first. Placing the
reference against the first entry makes it sound like this bug is
tracking the update of grep to 3.7, but according to the bug title as it
is at the moment, that isn't what this bug is tracking.

Please avoid refreshing quilt patches unnecessarily. Refreshing is only
needed for conflicts and if fuzz appears. Otherwise, not refreshing them
minimises diff noise and thus helps with review. Additionally, if forced
to refresh I always use QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-
index" as documented at https://wiki.debian.org/UsingQuilt to reduce the
noise for next time.

It looks like fundamentally you're resolving the FTBFS by disabling the
failing test. But have you checked that the test is actually a false
positive? What if the test is working and picking up something that is
actually wrong with the new glibc? If you think it's a false positive
then I'd expect to see some explanation that it's a false positive and
why you think that, but I couldn't find anything. And if it is a false
positive, then a bug report to the test's origin (presumably upstream)
and a dep3 header linking to that would be appropriate.

> +Forwarded:   no - Debian not yet on glibc 2.34

It's still useful to forward, as Debian is expected to need that anyway.
I usually file such bugs in the Debian BTS explaining that it isn't
necessary to apply right now but will be useful in the future. However,
before forwarding, maybe we should get the fix right here first :)

** Tags added: ftbfs

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1472288] Re: Add additional attributes in /etc/os-release

2021-08-24 Thread Robie Basak
I'm just driving past the sponsorship queue.

How can we validate that the CPE_NAME you're adding is definitely the
correct one for us to use in Ubuntu?

Your debdiff doesn't include adding BUILD_ID, so maybe this bug needs
renaming to be specific to CPE_NAME? BUILD_ID sounds like something
based on the installer used - like /var/log/installer/media-info or
/etc/cloud/build.info. But that would mean that /etc/os-release could no
longer be a simple conffile and would have to be managed via a postinst
and ucf or something.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1472288

Title:
  Add additional attributes in /etc/os-release

Status in base-files package in Ubuntu:
  Confirmed

Bug description:
  Please add 'CPE_NAME' and 'BUILD_ID' to /etc/os-release.

  More at http://www.freedesktop.org/software/systemd/man/os-
  release.html.

  I'm not sure BUILD_ID should be something like 'vivid' etc, but it
  would be a nice use. Or introduce a new attribute/value pair like

  NICKNAME_ID="vivid"

  No rush. Thanks for adopting this convention so quickly.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: base-files 7.2ubuntu9
  Uname: Linux 4.1.0-rc5carif-7-ga8b253b x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jul  7 10:26:02 2015
  Dependencies:
   
  InstallationDate: Installed on 2014-11-04 (245 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  ProcEnviron:
   LANGUAGE=en_US
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: base-files
  UpgradeStatus: Upgraded to vivid on 2015-04-25 (73 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1472288/+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 1905285] Re: socket-activated sshd breaks on concurrent connections

2021-07-28 Thread Robie Basak
The upload looks fine, but do you have any plans to fix Hirsute?
Otherwise users upgrading from Focal up to Hirsute will be regressed
after this fix is landed. It should be trivial to also fix this in
Hirsute I think - and might even be beneficial to do first as a canary.

** Description changed:

  [Impact]
  
  Users of the systemd socket activated ssh service may experience a race
  condition that may lead an ssh instance to fail.
  
  The race condition happens when, for a running socket activated ssh
  service,
  
  an instance A is started, creating the RuntimeDirectory for the service;
  then
  
  an instance B is started, relying on the RuntimeDirectory created for
  instance A; then
  
  instance A halts, causing the RuntimeDirectory to be deleted.
  
  If, at this point, instance B has not chrooted into RuntimeDirectory
  yet, then instance B will fail.
  
  The proposed patch fixes the issue by preserving the RuntimeDirectory
  after an instance A of the socket activated ssh service halts.
  
  [Test Plan]
  
  1) Stop any running instances of ssh.
  `systemctl stop ssh`
  
  2) Start the socket activated ssh service.
  `systemctl start ssh.socket`
  
  3) Verify that no errors related to ssh were logged in /var/log/auth.log
  `cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or 
directory'`
  
  4) perform several ssh connections to the running server in a short time 
span. ssh-keyscan may help here.
  `ssh-keyscan localhost`
  
  5) Verify that errors related to ssh were logged in /var/log/auth.log
  `cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or 
directory'`
  
  6) Apply the proposed fix (make sure the socket activated service is
  restarted)
  
  7) repead step (4), then verify that no new entries were appended to the
  step (5) output
  
  [Where problems could occur]
  
  If the changes to the socket activated unit file are wrong, the socket
  activated service may fail to start after the package upgrade. In this
  case, we would need to instruct users to perform local changes to the
  unit file with possible additional fixes while a new version of the
  patch lands.
+ 
+ [racb] There might be cases where users are inadvertently depending on
+ the cleanup that will now be disabled - for example by a bug or
+ misconfiguration that would result in /run filling up otherwise. By
+ disabling systemd cleanup and relying solely on openssh for cleanup,
+ such a bug or misconfiguration may be exposed and cause problems on such
+ systems.
  
  [Other Info]
  
  This fix has been forwarded to Debian and accepted in
  https://salsa.debian.org/ssh-team/openssh/-/merge_requests/12
  
  [Original message]
  
  This is mostly the same issue as https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=934663.
  
  With the default configuration of openssh-server and systemd, sshd will
  complain and crash when multiple connections are made and terminated in
  a quick succession, e.g. with `ssh-keyscan`. It results in the following
  errors in /var/log/auth.log:
  
  ```
  Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port 
41460: no matching host key type found. Their offer: 
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
  Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312 
[preauth]
  Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file 
or directory [preauth]
  ```
  
  as well as e.g. missing responses in ssh-keyscan:
  
  ```
  $ ssh-keyscan -vvv {host}
  debug2: fd 3 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 2
  debug2: fd 4 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 4
  debug2: fd 5 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 8
  debug2: fd 6 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 32
  debug2: fd 7 setting O_NONBLOCK
  debug3: conalloc: oname {host} kt 64
  debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
  # {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
  debug3: send packet: type 20
  debug1: SSH2_MSG_KEXINIT sent
  debug3: receive packet: type 20
  debug1: SSH2_MSG_KEXINIT received
  debug2: local client KEXINIT proposal
  debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
  debug2: host key algorithms: 

[Touch-packages] [Bug 1937883] Re: ssh-agent Shielded Private Key Extraction

2021-07-26 Thread Robie Basak
** Information type changed from Public to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1937883

Title:
  ssh-agent Shielded Private Key Extraction

Status in openssh package in Ubuntu:
  New

Bug description:
  Possible vulnerability with an active proof of concept that may well
  become a CVE.

  ssh-agent Shielded Private Key Extraction

  https://security.humanativaspa.it/openssh-ssh-agent-shielded-private-
  key-extraction-x86_64-linux/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1937883/+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 1916651] Update Released

2021-07-22 Thread Robie Basak
The verification of the Stable Release Update for base-passwd has
completed successfully and the package is now being released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-passwd in Ubuntu.
https://bugs.launchpad.net/bugs/1916651

Title:
  asks about irc user home directory during upgrade

Status in base-passwd package in Ubuntu:
  Fix Released
Status in base-passwd source package in Hirsute:
  Fix Released
Status in base-passwd package in Debian:
  Fix Released

Bug description:
  [Test Case]
  1) On an Ubuntu 20.10 system edit your /etc/apt/sources.list file to have 
hirsute instead of groovy (this is the easiest way to verify the fix because 
the release upgrade process disables -proposed)
  2) Run apt-get update
  3) Execute 'sudo apt-get install base-passwd'

  With the version of base-passwd in the release component you'll
  receive a prompt about moving the 'irc' user's home directory from
  '/var/run/ircd' to '/run/ircd'.

  With the version of base-passwd from -proposed you will not receive a
  prompt and will instead see the following dpkg message:

  "Changing home-directory of irc from /var/run/ircd to /run/ircd"

  [Where Problems Could Occur]
  In the event that there is a logical error when checking for the irc user and 
its old home directory being /var/run/ircd a debconf prompt may not be 
presented when it really should be.

  [Original Description]
  Upgrading from groovy to hirsuite, base-passwd asks if the `irc` user's home 
directory should be moved from `/var/run/ircd` to `/run/ircd`.  Having no IRC 
server installed makes this very confusing, but appears harmless 
(https://askubuntu.com/questions/876975/user-irc-inside-of-default-ubuntu-16-04-server).
  Possibly caused by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946884, 
but can this not prompt the user for a decision?

  ProblemType: BugDistroRelease: Ubuntu 21.04
  Package: base-passwd 3.5.49
  ProcVersionSignature: Ubuntu 5.8.0-44.50-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: GNOME
  Date: Tue Feb 23 12:02:59 2021
  InstallationDate: Installed on 2019-08-17 (556 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190305.1)
  RebootRequiredPkgs:
   libc6
   libc6
   libssl1.1
   libssl1.1SourcePackage: base-passwd
  UpgradeStatus: Upgraded to hirsute on 2021-02-23 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-passwd/+bug/1916651/+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 1927078] Re: Don't allow useradd to use fully numeric names

2021-07-21 Thread Robie Basak
Hello Victor, or anyone else affected,

Accepted shadow into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/shadow/1:4.8.1-1ubuntu5.20.04.1 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: shadow (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1927078

Title:
  Don't allow useradd to use fully numeric names

Status in shadow package in Ubuntu:
  Fix Released
Status in shadow source package in Focal:
  Fix Committed
Status in shadow source package in Groovy:
  Won't Fix
Status in shadow source package in Hirsute:
  Fix Committed
Status in shadow source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * If a fully numeric username is created, it will cause
     problems with systemd. One example is that the user with
     this type of name can log in, but loginctl will not create
     a session for them.
   * This can also cause users to be unable to log in to a gdm
     environment

  [Test Case]

   * `useradd 123` (this command should succeed)
   * `userdel 123` to clean up the user that was just added
   * Install `shadow` from -proposed
   * `useradd 123` should now fail

  [Regression Potential]
   * If there were a logic error in the fix, it is possible
     that valid usernames would now be disallowed.
   * Many test cases have been added to ensure this is not
     the case, and --badnames would still provide a work-around
   * [racb] Users may have scripts that are currently using numeric usernames 
and these scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable behaviour such as 
systemd's behaviour described.

  [Original Description]

  Fully numeric names support in Ubuntu is inconsistent in Focal onwards
  because systemd does not like them[1] but are still allowed by default
  by useradd, leaving the session behavior in hands of the running
  applications. Two examples:

  1. After creating a user named "0", the user can log in via ssh or
  console but loginctl won't create a session for it:

  root@focal:/home/ubuntu# useradd -m 0
  root@focal:/home/ubuntu# id 0
  uid=1005(0) gid=1005(0) groups=1005(0)

  ..

  0@192.168.122.6's password:
  Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)

  Last login: Thu Apr  8 16:17:06 2021 from 192.168.122.1
  $ loginctl
  No sessions.
  $ w
   16:20:09 up 4 min,  1 user,  load average: 0.03, 0.14, 0.08
  USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
  0pts/0192.168.122.116:170.00s  0.00s  0.00s w

  And pam-systemd shows the following message:

  Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for 
user 0 by (uid=0)
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd 
initializing
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get 
user record: Invalid argument

  2. With that same username, every successful authentication in gdm
  will loop back to gdm again instead of starting gnome, making the user
  unable to login.

  Making useradd fail (unless --badnames is set) when a fully numeric
  name is used will make the default OS behavior consistent.

  [Other info]

  - Upstream does not support fully numeric usernames
  - useradd has a --badnames parameter that would still allow the use of these 
type of names

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : 

[Touch-packages] [Bug 1927078] Re: Don't allow useradd to use fully numeric names

2021-07-21 Thread Robie Basak
Unsubscribing sponsors.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1927078

Title:
  Don't allow useradd to use fully numeric names

Status in shadow package in Ubuntu:
  Fix Released
Status in shadow source package in Focal:
  In Progress
Status in shadow source package in Groovy:
  Won't Fix
Status in shadow source package in Hirsute:
  Fix Committed
Status in shadow source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * If a fully numeric username is created, it will cause
     problems with systemd. One example is that the user with
     this type of name can log in, but loginctl will not create
     a session for them.
   * This can also cause users to be unable to log in to a gdm
     environment

  [Test Case]

   * `useradd 123` (this command should succeed)
   * `userdel 123` to clean up the user that was just added
   * Install `shadow` from -proposed
   * `useradd 123` should now fail

  [Regression Potential]
   * If there were a logic error in the fix, it is possible
     that valid usernames would now be disallowed.
   * Many test cases have been added to ensure this is not
     the case, and --badnames would still provide a work-around
   * [racb] Users may have scripts that are currently using numeric usernames 
and these scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable behaviour such as 
systemd's behaviour described.

  [Original Description]

  Fully numeric names support in Ubuntu is inconsistent in Focal onwards
  because systemd does not like them[1] but are still allowed by default
  by useradd, leaving the session behavior in hands of the running
  applications. Two examples:

  1. After creating a user named "0", the user can log in via ssh or
  console but loginctl won't create a session for it:

  root@focal:/home/ubuntu# useradd -m 0
  root@focal:/home/ubuntu# id 0
  uid=1005(0) gid=1005(0) groups=1005(0)

  ..

  0@192.168.122.6's password:
  Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)

  Last login: Thu Apr  8 16:17:06 2021 from 192.168.122.1
  $ loginctl
  No sessions.
  $ w
   16:20:09 up 4 min,  1 user,  load average: 0.03, 0.14, 0.08
  USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
  0pts/0192.168.122.116:170.00s  0.00s  0.00s w

  And pam-systemd shows the following message:

  Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for 
user 0 by (uid=0)
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd 
initializing
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get 
user record: Invalid argument

  2. With that same username, every successful authentication in gdm
  will loop back to gdm again instead of starting gnome, making the user
  unable to login.

  Making useradd fail (unless --badnames is set) when a fully numeric
  name is used will make the default OS behavior consistent.

  [Other info]

  - Upstream does not support fully numeric usernames
  - useradd has a --badnames parameter that would still allow the use of these 
type of names

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+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 1927078] Re: Don't allow useradd to use fully numeric names

2021-07-21 Thread Robie Basak
Hello Victor, or anyone else affected,

Accepted shadow into hirsute-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/shadow/1:4.8.1-1ubuntu8.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: shadow (Ubuntu Hirsute)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-hirsute

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1927078

Title:
  Don't allow useradd to use fully numeric names

Status in shadow package in Ubuntu:
  Fix Released
Status in shadow source package in Focal:
  In Progress
Status in shadow source package in Groovy:
  Won't Fix
Status in shadow source package in Hirsute:
  Fix Committed
Status in shadow source package in Impish:
  Fix Released

Bug description:
  [Impact]

   * If a fully numeric username is created, it will cause
     problems with systemd. One example is that the user with
     this type of name can log in, but loginctl will not create
     a session for them.
   * This can also cause users to be unable to log in to a gdm
     environment

  [Test Case]

   * `useradd 123` (this command should succeed)
   * `userdel 123` to clean up the user that was just added
   * Install `shadow` from -proposed
   * `useradd 123` should now fail

  [Regression Potential]
   * If there were a logic error in the fix, it is possible
     that valid usernames would now be disallowed.
   * Many test cases have been added to ensure this is not
     the case, and --badnames would still provide a work-around
   * [racb] Users may have scripts that are currently using numeric usernames 
and these scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable behaviour such as 
systemd's behaviour described.

  [Original Description]

  Fully numeric names support in Ubuntu is inconsistent in Focal onwards
  because systemd does not like them[1] but are still allowed by default
  by useradd, leaving the session behavior in hands of the running
  applications. Two examples:

  1. After creating a user named "0", the user can log in via ssh or
  console but loginctl won't create a session for it:

  root@focal:/home/ubuntu# useradd -m 0
  root@focal:/home/ubuntu# id 0
  uid=1005(0) gid=1005(0) groups=1005(0)

  ..

  0@192.168.122.6's password:
  Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)

  Last login: Thu Apr  8 16:17:06 2021 from 192.168.122.1
  $ loginctl
  No sessions.
  $ w
   16:20:09 up 4 min,  1 user,  load average: 0.03, 0.14, 0.08
  USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
  0pts/0192.168.122.116:170.00s  0.00s  0.00s w

  And pam-systemd shows the following message:

  Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for 
user 0 by (uid=0)
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd 
initializing
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get 
user record: Invalid argument

  2. With that same username, every successful authentication in gdm
  will loop back to gdm again instead of starting gnome, making the user
  unable to login.

  Making useradd fail (unless --badnames is set) when a fully numeric
  name is used will make the default OS behavior consistent.

  [Other info]

  - Upstream does not support fully numeric usernames
  - useradd has a --badnames parameter that would still allow the use of these 
type of names

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net

[Touch-packages] [Bug 1927078] Re: Don't allow useradd to use fully numeric names

2021-07-21 Thread Robie Basak
** Description changed:

  [Impact]
  
-  * If a fully numeric username is created, it will cause
-problems with systemd. One example is that the user with
-this type of name can log in, but loginctl will not create
-a session for them.
-  * This can also cause users to be unable to log in to a gdm
-environment
+  * If a fully numeric username is created, it will cause
+    problems with systemd. One example is that the user with
+    this type of name can log in, but loginctl will not create
+    a session for them.
+  * This can also cause users to be unable to log in to a gdm
+    environment
  
  [Test Case]
  
-  * `useradd 123` (this command should succeed)
-  * `userdel 123` to clean up the user that was just added
-  * Install `shadow` from -proposed
-  * `useradd 123` should now fail
+  * `useradd 123` (this command should succeed)
+  * `userdel 123` to clean up the user that was just added
+  * Install `shadow` from -proposed
+  * `useradd 123` should now fail
  
  [Regression Potential]
-  * If there were a logic error in the fix, it is possible
-that valid usernames would now be disallowed.
-  * Many test cases have been added to ensure this is not
-the case, and --badnames would still provide a work-around
+  * If there were a logic error in the fix, it is possible
+    that valid usernames would now be disallowed.
+  * Many test cases have been added to ensure this is not
+    the case, and --badnames would still provide a work-around
+  * [racb] Users may have scripts that are currently using numeric usernames 
and this scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable behaviour such as 
systemd's behaviour described.
  
  [Original Description]
  
  Fully numeric names support in Ubuntu is inconsistent in Focal onwards
  because systemd does not like them[1] but are still allowed by default
  by useradd, leaving the session behavior in hands of the running
  applications. Two examples:
  
  1. After creating a user named "0", the user can log in via ssh or
  console but loginctl won't create a session for it:
  
  root@focal:/home/ubuntu# useradd -m 0
  root@focal:/home/ubuntu# id 0
  uid=1005(0) gid=1005(0) groups=1005(0)
  
  ..
  
  0@192.168.122.6's password:
  Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
  
  Last login: Thu Apr  8 16:17:06 2021 from 192.168.122.1
  $ loginctl
  No sessions.
  $ w
   16:20:09 up 4 min,  1 user,  load average: 0.03, 0.14, 0.08
  USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
  0pts/0192.168.122.116:170.00s  0.00s  0.00s w
  
  And pam-systemd shows the following message:
  
  Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for 
user 0 by (uid=0)
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd 
initializing
  Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get 
user record: Invalid argument
  
  2. With that same username, every successful authentication in gdm will
  loop back to gdm again instead of starting gnome, making the user unable
  to login.
  
  Making useradd fail (unless --badnames is set) when a fully numeric name
  is used will make the default OS behavior consistent.
  
  [Other info]
  
  - Upstream does not support fully numeric usernames
  - useradd has a --badnames parameter that would still allow the use of these 
type of names

** Description changed:

  [Impact]
  
   * If a fully numeric username is created, it will cause
     problems with systemd. One example is that the user with
     this type of name can log in, but loginctl will not create
     a session for them.
   * This can also cause users to be unable to log in to a gdm
     environment
  
  [Test Case]
  
   * `useradd 123` (this command should succeed)
   * `userdel 123` to clean up the user that was just added
   * Install `shadow` from -proposed
   * `useradd 123` should now fail
  
  [Regression Potential]
   * If there were a logic error in the fix, it is possible
     that valid usernames would now be disallowed.
   * Many test cases have been added to ensure this is not
     the case, and --badnames would still provide a work-around
-  * [racb] Users may have scripts that are currently using numeric usernames 
and this scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable behaviour such as 
systemd's behaviour described.
+  * [racb] Users may have scripts that are currently using numeric usernames 
and these scripts will break as a consequence of this deliberate change in 
stable Ubuntu releases. However, based on the discussion in the bug, we think 
this is preferable to leaving such users with unstable 

[Touch-packages] [Bug 1926062] Re: [hirsute/impish] Can't turn bluetooth on again after turning it off

2021-07-21 Thread Robie Basak
Hello Jatin, or anyone else affected,

Accepted gnome-settings-daemon into hirsute-proposed. The package will
build now and be available at
https://launchpad.net/ubuntu/+source/gnome-settings-
daemon/3.38.1-3ubuntu3.1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: gnome-settings-daemon (Ubuntu Hirsute)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-hirsute

** Changed in: gnome-settings-daemon (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1926062

Title:
  [hirsute/impish] Can't turn bluetooth on again after turning it off

Status in Bluez Utilities:
  Fix Released
Status in GNOME Bluetooth:
  Unknown
Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in bluez source package in Focal:
  Fix Released
Status in gnome-settings-daemon source package in Focal:
  Fix Committed
Status in bluez source package in Hirsute:
  Fix Released
Status in gnome-settings-daemon source package in Hirsute:
  Fix Committed
Status in bluez source package in Impish:
  Fix Released
Status in gnome-settings-daemon source package in Impish:
  Fix Released

Bug description:
  [Impact]

  On/off of Bluetooth in gnome-control-center will not work properly in kernels 
5.11 (approximately) onward. Devices are not refreshed in the list anymore.
   
  [Test Plan]

  1. Open gnome-control-center and select Bluetooth
  2. Turn off Bluetooth via UI
  3. Turn on Bluetooth via UI

  Expect: Device list appears, so Bluetooth really is on.

  [Where problems could occur]

  Since the fix involves the 'rfkill' logic it has the potential to
  affect any Bluetooth or Wifi on/off setting.

  [Other info]

  Upstream bug in gnome-bluetooth:
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

  Discussion in linux-bluetooth:
  https://marc.info/?t=16200475893=1=2

  [Original bug report]

  When ever i Turn on my system or restart bluetooth is open any it
  connects to any device. But when i turn off bluetooth and try to turn
  it on again. it neither turns on nor scans/connects to any device.
  This is happening since I updated my system to ubuntu 21.04 LTS

    Bluetooth: hci0: HCI reset during shutdown failed

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
  Uname: Linux 5.11.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Apr 25 15:09:23 2021
  InstallationDate: Installed on 2020-12-15 (130 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: LENOVO 80TR
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-16-generic 
root=UUID=7c507bd4-c66c-4233-a64e-804f6df5412b ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to hirsute on 2021-04-22 (2 days ago)
  dmi.bios.date: 07/31/2017
  dmi.bios.release: 1.29
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 3UCN29WW
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Nano 5B1
  dmi.board.vendor: LENOVO
  dmi.board.version: No DPK
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 110-15AST
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 

[Touch-packages] [Bug 1926062] Please test proposed package

2021-07-21 Thread Robie Basak
Hello Jatin, or anyone else affected,

Accepted gnome-settings-daemon into focal-proposed. The package will
build now and be available at
https://launchpad.net/ubuntu/+source/gnome-settings-
daemon/3.36.1-0ubuntu1.1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1926062

Title:
  [hirsute/impish] Can't turn bluetooth on again after turning it off

Status in Bluez Utilities:
  Fix Released
Status in GNOME Bluetooth:
  Unknown
Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Released
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in bluez source package in Focal:
  Fix Released
Status in gnome-settings-daemon source package in Focal:
  Fix Committed
Status in bluez source package in Hirsute:
  Fix Released
Status in gnome-settings-daemon source package in Hirsute:
  Fix Committed
Status in bluez source package in Impish:
  Fix Released
Status in gnome-settings-daemon source package in Impish:
  Fix Released

Bug description:
  [Impact]

  On/off of Bluetooth in gnome-control-center will not work properly in kernels 
5.11 (approximately) onward. Devices are not refreshed in the list anymore.
   
  [Test Plan]

  1. Open gnome-control-center and select Bluetooth
  2. Turn off Bluetooth via UI
  3. Turn on Bluetooth via UI

  Expect: Device list appears, so Bluetooth really is on.

  [Where problems could occur]

  Since the fix involves the 'rfkill' logic it has the potential to
  affect any Bluetooth or Wifi on/off setting.

  [Other info]

  Upstream bug in gnome-bluetooth:
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

  Discussion in linux-bluetooth:
  https://marc.info/?t=16200475893=1=2

  [Original bug report]

  When ever i Turn on my system or restart bluetooth is open any it
  connects to any device. But when i turn off bluetooth and try to turn
  it on again. it neither turns on nor scans/connects to any device.
  This is happening since I updated my system to ubuntu 21.04 LTS

    Bluetooth: hci0: HCI reset during shutdown failed

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
  Uname: Linux 5.11.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Apr 25 15:09:23 2021
  InstallationDate: Installed on 2020-12-15 (130 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: LENOVO 80TR
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-16-generic 
root=UUID=7c507bd4-c66c-4233-a64e-804f6df5412b ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to hirsute on 2021-04-22 (2 days ago)
  dmi.bios.date: 07/31/2017
  dmi.bios.release: 1.29
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 3UCN29WW
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Nano 5B1
  dmi.board.vendor: LENOVO
  dmi.board.version: No DPK
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 110-15AST
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvr3UCN29WW:bd07/31/2017:br1.29:efr1.29:svnLENOVO:pn80TR:pvrLenovoideapad110-15AST:rvnLENOVO:rnNano5B1:rvrNoDPK:cvnLENOVO:ct10:cvrLenovoideapad110-15AST:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80TR
  dmi.product.sku: LENOVO_MT_80TR_BU_idea_FM_Lenovo ideapad 110-15AST
  dmi.product.version: Lenovo ideapad 110-15AST
  dmi.sys.vendor: LENOVO
  hciconfig:
   hci0:Type: Primary  Bus: USB
    BD Address: 

[Touch-packages] [Bug 1916651] Re: asks about irc user home directory during upgrade

2021-07-21 Thread Robie Basak
Hello Joe, or anyone else affected,

Accepted base-passwd into hirsute-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/base-
passwd/3.5.49ubuntu1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: base-passwd (Ubuntu Hirsute)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-hirsute

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-passwd in Ubuntu.
https://bugs.launchpad.net/bugs/1916651

Title:
  asks about irc user home directory during upgrade

Status in base-passwd package in Ubuntu:
  Fix Released
Status in base-passwd source package in Hirsute:
  Fix Committed
Status in base-passwd package in Debian:
  Fix Released

Bug description:
  [Test Case]
  1) On an Ubuntu 20.10 system edit your /etc/apt/sources.list file to have 
hirsute instead of groovy (this is the easiest way to verify the fix because 
the release upgrade process disables -proposed)
  2) Run apt-get update
  3) Execute 'sudo apt-get install base-passwd'

  With the version of base-passwd in the release component you'll
  receive a prompt about moving the 'irc' user's home directory from
  '/var/run/ircd' to '/run/ircd'.

  With the version of base-passwd from -proposed you will not receive a
  prompt and will instead see the following dpkg message:

  "Changing home-directory of irc from /var/run/ircd to /run/ircd"

  [Where Problems Could Occur]
  In the event that there is a logical error when checking for the irc user and 
its old home directory being /var/run/ircd a debconf prompt may not be 
presented when it really should be.

  [Original Description]
  Upgrading from groovy to hirsuite, base-passwd asks if the `irc` user's home 
directory should be moved from `/var/run/ircd` to `/run/ircd`.  Having no IRC 
server installed makes this very confusing, but appears harmless 
(https://askubuntu.com/questions/876975/user-irc-inside-of-default-ubuntu-16-04-server).
  Possibly caused by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946884, 
but can this not prompt the user for a decision?

  ProblemType: BugDistroRelease: Ubuntu 21.04
  Package: base-passwd 3.5.49
  ProcVersionSignature: Ubuntu 5.8.0-44.50-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu59
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: GNOME
  Date: Tue Feb 23 12:02:59 2021
  InstallationDate: Installed on 2019-08-17 (556 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190305.1)
  RebootRequiredPkgs:
   libc6
   libc6
   libssl1.1
   libssl1.1SourcePackage: base-passwd
  UpgradeStatus: Upgraded to hirsute on 2021-02-23 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-passwd/+bug/1916651/+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 1934992] Re: rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

2021-07-09 Thread Robie Basak
Sorry, the use cases you describe are not supported by Ubuntu.

You're welcome to hack your system as you wish, but that doesn't mean
that we will necessarily make changes in Ubuntu to accommodate that. We
do try to be helpful, of course. And in this case I agree that it is a
bug that rsync doesn't depend on a higher version of libxxhash
automatically. That's something we should fix, but it is of low priority
but I don't expect such a fix to be backported to Groovy because, as
presented at the moment, this doesn't meet our threshold of disrupting
users to achieve such a change. See
https://wiki.ubuntu.com/StableReleaseUpdates for details of our policies
in this area.

In particular:

> - I make a hypothetical package that depends on libxxhash < 0.8
because I want the "broken/old" xxh128 support

Such a hypothetical package does not exist in the Ubuntu archive in
practice. Adding third party packages is not something that Ubuntu can
realistically support. The scenario you present is exactly why we don't
support third party packages in the general case: they break
distribution release upgrades.

> - libxxhash-dev,
> + libxxhash-dev (>= 0.8),

I don't think your patch will work as-is. You've changed the build
dependency versioning, not the binary package dependency versioning. I
suspect what needs adjusting is the symbols file in the xxhash source
(debian/libxxhash0.symbols). However this needs further investigation
and the low priority of this issue means that I'm not going to spend any
more time on this unless a more important and supported use case is
presented here.

> (Ok, in fact, I think it's ultimately a bug in soname-version/symbol
handling of libxxhash. But that's not where the problem manifests
itself.)

Right. We track bugs and their fixes by following the status of a fix
against the root cause. So I'm going to reassign the bug to that package
as it seems likely to me that this is where the problem lies.

> I'll leave it as is if you still feel it should be closed.

I agree that it's not correct that the binary dependency is wrong, so
this bug can remain open if somebody wants to volunteer a fix. However,
I suggest you find the fix and send it to wherever the problem
originates in our ecosystem (maybe Debian? Or perhaps xxhash upstream?).
Unless a supported use case is presented, I think it's unlikely that
we'll carry a patch for this in Ubuntu.

> But at least it has some visibility/presence on the internet so others
are helped if they also run into this issue.

Sure. People affected by this are welcome to coordinate in this bug.

I'm going to explicitly mark a Groovy task as Won't Fix to make it clear
that we don't expect any change will be made in Groovy to fix this. The
bug remains open to being fixed in a future Ubuntu release if a
volunteer takes the appropriate steps to get the issue resolved at its
actual origin.

** Package changed: rsync (Ubuntu) => xxhash (Ubuntu)

** Also affects: xxhash (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Changed in: xxhash (Ubuntu Groovy)
   Status: New => Won't Fix

** Changed in: xxhash (Ubuntu)
   Status: New => Triaged

** Changed in: xxhash (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1934992

Title:
  rsync 3.2.x in Groovy depends on broken libxxhash 0.7.x

Status in xxhash package in Ubuntu:
  Triaged
Status in xxhash source package in Groovy:
  Won't Fix

Bug description:
  **Problem**

$ rsync root@focal-system:/etc/.pwd.lock . 
ERROR: .pwd.lock failed verification -- update discarded.
rsync error: some files/attrs were not transferred (see previous errors)
  (code 23) at main.c(1816) [generator=3.2.3]

  
$ rsync root@focal-system:/etc/.pwd.lock . --debug=all
opening connection using: ssh -l root focal-system rsync --server --sender \
  -e.LsfxCIvu . /etc/.pwd.lock  (10 args)
(Client) Protocol versions: remote=31, negotiated=31
Client negotiated checksum: xxh128
...

  
  **Cause**

focal-system# dpkg -l | grep -E 'libxxhash|rsync'
ii  libxxhash0:amd64  0.7.3-1 amd64
ii  rsync 3.2.3-2ubuntu1  amd64

  
  **Why this affects only us and not more people?**

  On Ubuntu/Focal, there is no rsync 3.2.3, only 3.1.3-8. But because we
  need the lz4 compression support we've fetched a newer rsync (from
  Groovy).

  However: the rsync 3.2.3 depends on libxxhash0 0.7.1+, while in fact
  it needs 0.8+.

  
  **Details**

  On a Ubuntu/Focal system we have installed a rsync 3.2.3 package from 
Ubuntu/Groovy because we need the lz4 compression support.

  
  focal-system# apt-cache show rsync
  Package: rsync
  ...
  Version: 3.2.3-2ubuntu1
  Depends: lsb-base, libacl1 (>= 2.2.23), libc6 (>= 2.15),
liblz4-1 (>= 0.0~r130), libpopt0 (>= 1.14), libssl1.1 (>= 1.1.0),
libxxhash0 (>= 0.7.1), 

[Touch-packages] [Bug 1933516] Re: gzip: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted

2021-07-07 Thread Robie Basak
Thanks - I had missed the Debian bug link.

** Description changed:

  [impact]
  
  gzip/libgzip fails for systemd services using MemoryDenyWriteExecute=yes
  
  [test case]
  
  note this only fails on ppc64el
  
  create service file /etc/systemd/system/test-localegen.service with
  content:
  
  [Service]
  MemoryDenyWriteExecute=yes
  ExecStart=/usr/sbin/locale-gen
  
- 
  run systemctl daemon-reload, and start the service:
  
- ubuntu@test-ppc-b:~$ sudo systemctl daemon-reload 
- ubuntu@test-ppc-b:~$ sudo systemctl start test-localegen.service 
- ubuntu@test-ppc-b:~$ sudo systemctl status test-localegen.service 
+ ubuntu@test-ppc-b:~$ sudo systemctl daemon-reload
+ ubuntu@test-ppc-b:~$ sudo systemctl start test-localegen.service
+ ubuntu@test-ppc-b:~$ sudo systemctl status test-localegen.service
  ○ test-localegen.service
-  Loaded: loaded 
(8;;file://test-ppc-b/etc/systemd/system/test-localegen.service^G/etc/systemd/system/test-localegen.service8;;^G;
 static)
-  Active: inactive (dead)
+  Loaded: loaded 
(8;;file://test-ppc-b/etc/systemd/system/test-localegen.service^G/etc/systemd/system/test-localegen.service8;;^G;
 static)
+  Active: inactive (dead)
  
  Jun 24 16:44:18 test-ppc-b locale-gen[2737]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2738]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2739]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2740]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2741]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: failed to set locale!
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: [error] default character map 
file `ANSI_X3.4-1968' not found: No such file or directory
  Jun 24 16:44:18 test-ppc-b locale-gen[2489]:  done
  Jun 24 16:44:18 test-ppc-b locale-gen[2483]: Generation complete.
  Jun 24 16:44:18 test-ppc-b systemd[1]: test-localegen.service: Deactivated 
successfully.
  
- 
  [regression potential]
  
  as this sets NO_ASM any regression would likely involve changed
  performance or architecture-specific failures
+ 
+ [racb] As NO_ASM switches code implementations inside gzip, it's
+ possible that this regresses behaviour if a bug exists in the C
+ implementation but not in the assembly implementation. However in
+ mitigation the C implementation has been in use since Focal, and it
+ doesn't look like anything relevant to this change has been changed
+ since Bionic.
  
  [scope]
  
  this is needed only in b
  
  this was fixed in debian at version 1.9-2.1, so this is fixed already in
  f and later

** Changed in: gzip (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1933516

Title:
  gzip: error while loading shared libraries: cannot restore segment
  prot after reloc: Operation not permitted

Status in gzip package in Ubuntu:
  Fix Released
Status in gzip source package in Bionic:
  Fix Committed
Status in gzip package in Debian:
  Fix Released

Bug description:
  [impact]

  gzip/libgzip fails for systemd services using
  MemoryDenyWriteExecute=yes

  [test case]

  note this only fails on ppc64el

  create service file /etc/systemd/system/test-localegen.service with
  content:

  [Service]
  MemoryDenyWriteExecute=yes
  ExecStart=/usr/sbin/locale-gen

  run systemctl daemon-reload, and start the service:

  ubuntu@test-ppc-b:~$ sudo systemctl daemon-reload
  ubuntu@test-ppc-b:~$ sudo systemctl start test-localegen.service
  ubuntu@test-ppc-b:~$ sudo systemctl status test-localegen.service
  ○ test-localegen.service
   Loaded: loaded 
(8;;file://test-ppc-b/etc/systemd/system/test-localegen.service^G/etc/systemd/system/test-localegen.service8;;^G;
 static)
   Active: inactive (dead)

  Jun 24 16:44:18 test-ppc-b locale-gen[2737]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2738]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2739]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2740]: gzip: error while loading shared 
libraries: cannot restore segment prot 

[Touch-packages] [Bug 1933516] Please test proposed package

2021-07-07 Thread Robie Basak
Hello Dan, or anyone else affected,

Accepted gzip into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/gzip/1.6-5ubuntu1.1 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1933516

Title:
  gzip: error while loading shared libraries: cannot restore segment
  prot after reloc: Operation not permitted

Status in gzip package in Ubuntu:
  Fix Released
Status in gzip source package in Bionic:
  Fix Committed
Status in gzip package in Debian:
  Fix Released

Bug description:
  [impact]

  gzip/libgzip fails for systemd services using
  MemoryDenyWriteExecute=yes

  [test case]

  note this only fails on ppc64el

  create service file /etc/systemd/system/test-localegen.service with
  content:

  [Service]
  MemoryDenyWriteExecute=yes
  ExecStart=/usr/sbin/locale-gen

  run systemctl daemon-reload, and start the service:

  ubuntu@test-ppc-b:~$ sudo systemctl daemon-reload
  ubuntu@test-ppc-b:~$ sudo systemctl start test-localegen.service
  ubuntu@test-ppc-b:~$ sudo systemctl status test-localegen.service
  ○ test-localegen.service
   Loaded: loaded 
(8;;file://test-ppc-b/etc/systemd/system/test-localegen.service^G/etc/systemd/system/test-localegen.service8;;^G;
 static)
   Active: inactive (dead)

  Jun 24 16:44:18 test-ppc-b locale-gen[2737]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2738]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2739]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2740]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2741]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: failed to set locale!
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: [error] default character map 
file `ANSI_X3.4-1968' not found: No such file or directory
  Jun 24 16:44:18 test-ppc-b locale-gen[2489]:  done
  Jun 24 16:44:18 test-ppc-b locale-gen[2483]: Generation complete.
  Jun 24 16:44:18 test-ppc-b systemd[1]: test-localegen.service: Deactivated 
successfully.

  [regression potential]

  as this sets NO_ASM any regression would likely involve changed
  performance or architecture-specific failures

  [racb] As NO_ASM switches code implementations inside gzip, it's
  possible that this regresses behaviour if a bug exists in the C
  implementation but not in the assembly implementation. However in
  mitigation the C implementation has been in use since Focal, and it
  doesn't look like anything relevant to this change has been changed
  since Bionic.

  [scope]

  this is needed only in b

  this was fixed in debian at version 1.9-2.1, so this is fixed already
  in f and later

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1933516/+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 1925320] Please test proposed package

2021-07-07 Thread Robie Basak
Hello Timo, or anyone else affected,

Accepted xorg-server into focal-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/xorg-
server/2:1.20.11-1ubuntu1~20.04.2 in a few hours, and then in the
-proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1925320

Title:
  Backport packages for 20.04.3 HWE stack

Status in directx-headers package in Ubuntu:
  Invalid
Status in libdrm package in Ubuntu:
  Invalid
Status in llvm-toolchain-12 package in Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Invalid
Status in xorg-server package in Ubuntu:
  Invalid
Status in directx-headers source package in Focal:
  Fix Committed
Status in libdrm source package in Focal:
  Fix Committed
Status in llvm-toolchain-12 source package in Focal:
  Fix Released
Status in mesa source package in Focal:
  Fix Committed
Status in xorg-server source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  These are needed for 20.04.3 images.

  [Test case]

  Boot a daily image, see that it still has the necessary stack
  installed and working.

  [What could go wrong]

  directx-headers: a new package, nothing can go wrong

  libdrm: adds some new api, no changes to old stuff

  llvm-12: a new package, no regression potential on it's own

  mesa: a new major release, but we'll pull the final stable release of
  21.0.x series, so there shouldn't be any regressions left at that
  point

  xserver: a new point-release, 1.20.x series is in deep maintenance
  mode, so there should be little chance of breakage

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/1925320/+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 1933516] Re: gzip: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted

2021-06-30 Thread Robie Basak
> [impact]

> gzip/libgzip fails for systemd services using
MemoryDenyWriteExecute=yes

Please could you expand on this? Under what circumstances are users
going to be affected by this?

Specifically our SRU process requires: "An explanation of the bug on
users and justification for backporting the fix to the stable release".

I also don't understand what's going on here, so I'd also appreciate "In
addition, it is helpful, but not required, to include an explanation of
how the upload fixes this bug".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1933516

Title:
  gzip: error while loading shared libraries: cannot restore segment
  prot after reloc: Operation not permitted

Status in gzip package in Ubuntu:
  Fix Released
Status in gzip source package in Bionic:
  In Progress
Status in gzip package in Debian:
  Fix Released

Bug description:
  [impact]

  gzip/libgzip fails for systemd services using
  MemoryDenyWriteExecute=yes

  [test case]

  note this only fails on ppc64el

  create service file /etc/systemd/system/test-localegen.service with
  content:

  [Service]
  MemoryDenyWriteExecute=yes
  ExecStart=/usr/sbin/locale-gen

  
  run systemctl daemon-reload, and start the service:

  ubuntu@test-ppc-b:~$ sudo systemctl daemon-reload 
  ubuntu@test-ppc-b:~$ sudo systemctl start test-localegen.service 
  ubuntu@test-ppc-b:~$ sudo systemctl status test-localegen.service 
  ○ test-localegen.service
   Loaded: loaded 
(8;;file://test-ppc-b/etc/systemd/system/test-localegen.service^G/etc/systemd/system/test-localegen.service8;;^G;
 static)
   Active: inactive (dead)

  Jun 24 16:44:18 test-ppc-b locale-gen[2737]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2738]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2739]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2740]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2741]: gzip: error while loading shared 
libraries: cannot restore segment prot after reloc: Operation not permitted
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: failed to set locale!
  Jun 24 16:44:18 test-ppc-b locale-gen[2506]: [error] default character map 
file `ANSI_X3.4-1968' not found: No such file or directory
  Jun 24 16:44:18 test-ppc-b locale-gen[2489]:  done
  Jun 24 16:44:18 test-ppc-b locale-gen[2483]: Generation complete.
  Jun 24 16:44:18 test-ppc-b systemd[1]: test-localegen.service: Deactivated 
successfully.

  
  [regression potential]

  as this sets NO_ASM any regression would likely involve changed
  performance or architecture-specific failures

  [scope]

  this is needed only in b

  this was fixed in debian at version 1.9-2.1, so this is fixed already
  in f and later

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1933516/+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 1933221] Please test proposed package

2021-06-24 Thread Robie Basak
Hello Andy, or anyone else affected,

Accepted bluez into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/bluez/5.53-0ubuntu3.3
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1933221

Title:
  Blutooth on/off does not work properly from gnome-control-center

Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed
Status in bluez source package in Focal:
  Fix Committed
Status in bluez source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

   * On/off of Bluetooth in gnome-control-center will not work properly.

   * Devices are not refreshed in the list anymore.

   * The passed struct will depend on the length of the submitted read() and the
 kernel version.

  [Test Plan]

   * Open gnome-control-center and select Bluetooth
 
   * turn off Bluetooth via UI
 
   * turn on Bluetooth via UI

  [Where problems could occur]

   * If user install newer kernel such as 5.13, they may have this
  issue.

   * Tested on Intel AX201 and Intel 6235 with kernel version
  5.13.0-1003-oem.

   * Upstream bug in gnome-bluetooth
 https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

   * Discussion in linux-bluetooth
 https://marc.info/?t=16200475893=1=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1933221/+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 1933221] Re: Blutooth on/off does not work properly from gnome-control-center

2021-06-24 Thread Robie Basak
Hello Andy, or anyone else affected,

Accepted bluez into hirsute-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/bluez/5.56-0ubuntu4.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: bluez (Ubuntu Hirsute)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-hirsute

** Changed in: bluez (Ubuntu Focal)
   Status: New => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1933221

Title:
  Blutooth on/off does not work properly from gnome-control-center

Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed
Status in bluez source package in Focal:
  Fix Committed
Status in bluez source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

   * On/off of Bluetooth in gnome-control-center will not work properly.

   * Devices are not refreshed in the list anymore.

   * The passed struct will depend on the length of the submitted read() and the
 kernel version.

  [Test Plan]

   * Open gnome-control-center and select Bluetooth
 
   * turn off Bluetooth via UI
 
   * turn on Bluetooth via UI

  [Where problems could occur]

   * If user install newer kernel such as 5.13, they may have this
  issue.

   * Tested on Intel AX201 and Intel 6235 with kernel version
  5.13.0-1003-oem.

   * Upstream bug in gnome-bluetooth
 https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

   * Discussion in linux-bluetooth
 https://marc.info/?t=16200475893=1=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1933221/+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 1926062] Re: [hirsute/impish] Can't turn bluetooth on again after turning it off

2021-06-24 Thread Robie Basak
> Declaring "Fix Committed" when a fix exists in an upstream tributary
before anything has reached proposed is a procedure requested by seb128
and we now follow on the desktop team.

I'm not sure what you mean by "upstream tributary", but if the fix
exists in the main Ubuntu packaging branch used by the desktop team (ie.
Vcs-Git in debian/control points to it) then that makes sense, as it was
in this case. If you mean it's just fixed upstream somewhere, then that
doesn't make sense - Launchpad's bug tracker expects to have a separate
task to track upstream status if you want that.

However, from an SRU perspective, I would expect an upload to the
development release *before* an SRU is uploaded. Sometimes we make
concessions (eg. during a development release freeze), but I don't think
a sponsorship delay qualifies. The sponsor should be able to sponsor to
the development release first, so there's no reason not to do it.

I see it's there now, but please could you adjust your processes to make
sure that in the normal case, this happens? This would save me reviewing
the SRU twice.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1926062

Title:
  [hirsute/impish] Can't turn bluetooth on again after turning it off

Status in Bluez Utilities:
  Unknown
Status in GNOME Bluetooth:
  Unknown
Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in bluez source package in Focal:
  In Progress
Status in bluez source package in Hirsute:
  In Progress
Status in bluez source package in Impish:
  Fix Committed
Status in gnome-settings-daemon source package in Impish:
  Fix Released

Bug description:
  [Impact]

  On/off of Bluetooth in gnome-control-center will not work properly in kernels 
5.11 (approximately) onward. Devices are not refreshed in the list anymore.
   
  [Test Plan]

  1. Open gnome-control-center and select Bluetooth
  2. Turn off Bluetooth via UI
  3. Turn on Bluetooth via UI

  Expect: Device list appears, so Bluetooth really is on.

  [Where problems could occur]

  Since the fix involves the 'rfkill' logic it has the potential to
  affect any Bluetooth or Wifi on/off setting.

  [Other info]

  Upstream bug in gnome-bluetooth:
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

  Discussion in linux-bluetooth:
  https://marc.info/?t=16200475893=1=2

  [Original bug report]

  When ever i Turn on my system or restart bluetooth is open any it
  connects to any device. But when i turn off bluetooth and try to turn
  it on again. it neither turns on nor scans/connects to any device.
  This is happening since I updated my system to ubuntu 21.04 LTS

    Bluetooth: hci0: HCI reset during shutdown failed

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
  Uname: Linux 5.11.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Apr 25 15:09:23 2021
  InstallationDate: Installed on 2020-12-15 (130 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: LENOVO 80TR
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-16-generic 
root=UUID=7c507bd4-c66c-4233-a64e-804f6df5412b ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to hirsute on 2021-04-22 (2 days ago)
  dmi.bios.date: 07/31/2017
  dmi.bios.release: 1.29
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 3UCN29WW
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Nano 5B1
  dmi.board.vendor: LENOVO
  dmi.board.version: No DPK
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 110-15AST
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvr3UCN29WW:bd07/31/2017:br1.29:efr1.29:svnLENOVO:pn80TR:pvrLenovoideapad110-15AST:rvnLENOVO:rnNano5B1:rvrNoDPK:cvnLENOVO:ct10:cvrLenovoideapad110-15AST:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80TR
  dmi.product.sku: LENOVO_MT_80TR_BU_idea_FM_Lenovo ideapad 110-15AST
  dmi.product.version: Lenovo ideapad 110-15AST
  dmi.sys.vendor: LENOVO
  hciconfig:
   hci0:Type: Primary  Bus: USB
    BD Address: C8:3D:D4:84:E0:06  ACL MTU: 820:8  SCO MTU: 255:16
    DOWN
    RX bytes:744804 acl:76 sco:0 events:105989 errors:0
    TX bytes:51871528 acl:113157 sco:0 commands:192 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/bluez/+bug/1926062/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to 

[Touch-packages] [Bug 1933221] Re: Blutooth on/off does not work properly from gnome-control-center

2021-06-24 Thread Robie Basak
See bug 1926062 for previous SRU review.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1933221

Title:
  Blutooth on/off does not work properly from gnome-control-center

Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed

Bug description:
  [Impact]

   * On/off of Bluetooth in gnome-control-center will not work properly.

   * Devices are not refreshed in the list anymore.

   * The passed struct will depend on the length of the submitted read() and the
 kernel version.

  [Test Plan]

   * Open gnome-control-center and select Bluetooth
 
   * turn off Bluetooth via UI
 
   * turn on Bluetooth via UI

  [Where problems could occur]

   * If user install newer kernel such as 5.13, they may have this
  issue.

   * Tested on Intel AX201 and Intel 6235 with kernel version
  5.13.0-1003-oem.

   * Upstream bug in gnome-bluetooth
 https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

   * Discussion in linux-bluetooth
 https://marc.info/?t=16200475893=1=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1933221/+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 1926062] Re: [hirsute/impish] Can't turn bluetooth on again after turning it off

2021-06-23 Thread Robie Basak
Also, the current upload references bug 1933221 which is a dupe. I'm not
sure how SRU tooling will handle this. Unless you can confirm that it
will work, please could you reference the master bug in your upload
instead?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1926062

Title:
  [hirsute/impish] Can't turn bluetooth on again after turning it off

Status in GNOME Bluetooth:
  Unknown
Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in bluez source package in Focal:
  In Progress
Status in bluez source package in Hirsute:
  In Progress
Status in bluez source package in Impish:
  Fix Committed
Status in gnome-settings-daemon source package in Impish:
  Fix Released

Bug description:
  [Impact]

  On/off of Bluetooth in gnome-control-center will not work properly in kernels 
5.11 (approximately) onward. Devices are not refreshed in the list anymore.
   
  [Test Plan]

  1. Open gnome-control-center and select Bluetooth
  2. Turn off Bluetooth via UI
  3. Turn on Bluetooth via UI

  Expect: Device list appears, so Bluetooth really is on.

  [Where problems could occur]

  Since the fix involves the 'rfkill' logic it has the potential to
  affect any Bluetooth or Wifi on/off setting.

  [Other info]

  Upstream bug in gnome-bluetooth:
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

  Discussion in linux-bluetooth:
  https://marc.info/?t=16200475893=1=2

  [Original bug report]

  When ever i Turn on my system or restart bluetooth is open any it
  connects to any device. But when i turn off bluetooth and try to turn
  it on again. it neither turns on nor scans/connects to any device.
  This is happening since I updated my system to ubuntu 21.04 LTS

    Bluetooth: hci0: HCI reset during shutdown failed

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
  Uname: Linux 5.11.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Apr 25 15:09:23 2021
  InstallationDate: Installed on 2020-12-15 (130 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: LENOVO 80TR
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-16-generic 
root=UUID=7c507bd4-c66c-4233-a64e-804f6df5412b ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to hirsute on 2021-04-22 (2 days ago)
  dmi.bios.date: 07/31/2017
  dmi.bios.release: 1.29
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 3UCN29WW
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Nano 5B1
  dmi.board.vendor: LENOVO
  dmi.board.version: No DPK
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 110-15AST
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvr3UCN29WW:bd07/31/2017:br1.29:efr1.29:svnLENOVO:pn80TR:pvrLenovoideapad110-15AST:rvnLENOVO:rnNano5B1:rvrNoDPK:cvnLENOVO:ct10:cvrLenovoideapad110-15AST:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80TR
  dmi.product.sku: LENOVO_MT_80TR_BU_idea_FM_Lenovo ideapad 110-15AST
  dmi.product.version: Lenovo ideapad 110-15AST
  dmi.sys.vendor: LENOVO
  hciconfig:
   hci0:Type: Primary  Bus: USB
    BD Address: C8:3D:D4:84:E0:06  ACL MTU: 820:8  SCO MTU: 255:16
    DOWN
    RX bytes:744804 acl:76 sco:0 events:105989 errors:0
    TX bytes:51871528 acl:113157 sco:0 commands:192 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-bluetooth/+bug/1926062/+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 1926062] Re: [hirsute/impish] Can't turn bluetooth on again after turning it off

2021-06-23 Thread Robie Basak
The fix for this seems missing in Impish. What does "Fix Committed" mean
here? What are your plans to fix this in Impish?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/1926062

Title:
  [hirsute/impish] Can't turn bluetooth on again after turning it off

Status in GNOME Bluetooth:
  Unknown
Status in OEM Priority Project:
  New
Status in bluez package in Ubuntu:
  Fix Committed
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in bluez source package in Focal:
  In Progress
Status in bluez source package in Hirsute:
  In Progress
Status in bluez source package in Impish:
  Fix Committed
Status in gnome-settings-daemon source package in Impish:
  Fix Released

Bug description:
  [Impact]

  On/off of Bluetooth in gnome-control-center will not work properly in kernels 
5.11 (approximately) onward. Devices are not refreshed in the list anymore.
   
  [Test Plan]

  1. Open gnome-control-center and select Bluetooth
  2. Turn off Bluetooth via UI
  3. Turn on Bluetooth via UI

  Expect: Device list appears, so Bluetooth really is on.

  [Where problems could occur]

  Since the fix involves the 'rfkill' logic it has the potential to
  affect any Bluetooth or Wifi on/off setting.

  [Other info]

  Upstream bug in gnome-bluetooth:
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/38

  Discussion in linux-bluetooth:
  https://marc.info/?t=16200475893=1=2

  [Original bug report]

  When ever i Turn on my system or restart bluetooth is open any it
  connects to any device. But when i turn off bluetooth and try to turn
  it on again. it neither turns on nor scans/connects to any device.
  This is happening since I updated my system to ubuntu 21.04 LTS

    Bluetooth: hci0: HCI reset during shutdown failed

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: bluetooth (not installed)
  ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
  Uname: Linux 5.11.0-16-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Apr 25 15:09:23 2021
  InstallationDate: Installed on 2020-12-15 (130 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: LENOVO 80TR
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-16-generic 
root=UUID=7c507bd4-c66c-4233-a64e-804f6df5412b ro quiet splash vt.handoff=7
  SourcePackage: bluez
  UpgradeStatus: Upgraded to hirsute on 2021-04-22 (2 days ago)
  dmi.bios.date: 07/31/2017
  dmi.bios.release: 1.29
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 3UCN29WW
  dmi.board.asset.tag: No Asset Tag
  dmi.board.name: Nano 5B1
  dmi.board.vendor: LENOVO
  dmi.board.version: No DPK
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 110-15AST
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvr3UCN29WW:bd07/31/2017:br1.29:efr1.29:svnLENOVO:pn80TR:pvrLenovoideapad110-15AST:rvnLENOVO:rnNano5B1:rvrNoDPK:cvnLENOVO:ct10:cvrLenovoideapad110-15AST:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80TR
  dmi.product.sku: LENOVO_MT_80TR_BU_idea_FM_Lenovo ideapad 110-15AST
  dmi.product.version: Lenovo ideapad 110-15AST
  dmi.sys.vendor: LENOVO
  hciconfig:
   hci0:Type: Primary  Bus: USB
    BD Address: C8:3D:D4:84:E0:06  ACL MTU: 820:8  SCO MTU: 255:16
    DOWN
    RX bytes:744804 acl:76 sco:0 events:105989 errors:0
    TX bytes:51871528 acl:113157 sco:0 commands:192 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-bluetooth/+bug/1926062/+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 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected

2021-06-17 Thread Robie Basak
Hello Mike, or anyone else affected,

Accepted libvirt into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/libvirt/6.0.0-0ubuntu8.10 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: libvirt (Ubuntu Focal)
   Status: Triaged => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1890858

Title:
  AppArmor profile causes QEMU/KVM - Not Connected

Status in apparmor package in Ubuntu:
  Invalid
Status in libvirt package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  New
Status in libvirt source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * libvirt in Focal in some cases e.g. with non local users
 needs to resolve those users. When trying to do so it fails
 due to apparmor isolation and breaks badly.

   * In later and former releases this issue isn't triggered,
 but it is unknown which (potentially complex) set of changes
 did that. A simple apparmor rule would help to allow libvirt
 to better function in environments with non known user IDs.

  [Test Plan]

   * Following these steps in an unfixed release triggers the issue

  sudo apt update; sudo apt dist-upgrade -y
  sudo apt install -y sssd sssd-ldap slapd ldap-utils openssl expect 
lsb-release libvirt-clients libvirt-daemon-system ubuntu-dev-tools
  pull-lp-source sssd
  cd sssd-2.4.1
  echo "*;*;*;Al-2400;libvirt" | sudo tee -a /etc/security/group.conf
  head -n -5 debian/tests/ldap-user-group-ldap-auth > 
debian/tests/lp1890858-test
  chmod +x debian/tests/lp1890858-test
  sudo ./debian/tests/lp1890858-test
  sudo systemctl restart libvirtd
  # ensure it works in a normal login
  virsh list
  journalctl -u libvirtd
  # try the sssd login
  sudo login
  # use testuser1 / testuser1secret to log in
  virsh list

  If affected this will not work reporting an error like:
  $ virsh list
  error: failed to connect to the hypervisor
  error: End of file while reading data: Input/output error

  And in dmesg/journal an apparmor denial like:

  Jun 14 11:25:26 ldap.example.com audit[48330]: AVC apparmor="DENIED"
  operation="bind" profile="libvirtd" pid=48330 comm="rpc-worker"
  family="unix" sock_type="dgram" protocol=0 requested_mask="bind"
  denied_mask="bind" addr="@userdb-f283d575d74df972f9e10bd14d0befe3"

  
  [Where problems could occur]

   * Allowing a little bit more to a daemon that already is rather powerful 
 and open in regard to it's profile usually isn't changing behavior.
 If anything it would be considered a potential risk, but this rule 
 should be ok to be added and ubuntu-security confirmed this.

  [Other Info]
   
   * Comment 38 confirms that this should be ok - from the security Teams 
 POV. 
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/comments/38 



  
  ---

  On some focal 20.04 systems, users are seeing "QEMU/KVM - Not
  Connected" when they attempt to use virt-manager to manage virtual
  machines. AppArmor denials like the following are seen in the logs:

  sudo grep libvirt /var/log/syslog | grep -i apparmor | grep -i denied
  Jun 28 14:53:27 koromicha kernel: [  334.660844] audit: type=1400 
audit(1593345207.778:951): apparmor="DENIED" operation="bind" 
profile="libvirtd" pid=12254 comm="libvirtd" family="unix" sock_type="dgram" 
protocol=0 requested_mask="bind" denied_mask="bind" 
addr="@userdb-6228daaaf66b14dfd14d93ef46d962c3"
  Jun 28 14:54:19 koromicha kernel: [  386.034970] audit: type=1400 
audit(1593345259.145:952): apparmor="DENIED" operation="bind" 
profile="libvirtd" pid=14311 comm="libvirtd" family="unix" sock_type="dgram" 
protocol=0 requested_mask="bind" denied_mask="bind" 
addr="@userdb-c861507740da1fa0c3356ad3b78bffe9"
  Jun 28 15:02:30 

[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs

2021-05-07 Thread Robie Basak
I very much appreciate the security review by Seth here. When I first
started reading this bug I was going to insist on having a security
review, but then I saw you've already taken care to arrange that. Thank
you!

** Changed in: openssl (Ubuntu Groovy)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1926254

Title:
  x509 Certificate verification fails when
  basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Fix Committed
Status in openssl source package in Groovy:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  In openssl 1.1.1f, the below commit was merged:

  commit ba4356ae4002a04e28642da60c551877eea804f7
  Author: Bernd Edlinger 
  Date:   Sat Jan 4 15:54:53 2020 +0100
  Subject: Fix error handling in x509v3_cache_extensions and related functions
  Link: 
https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7

  This introduced a regression which caused certificate validation to
  fail when certificates violate RFC 5280 [1], namely, when a
  certificate has "basicConstraints=CA:FALSE,pathlen:0". This
  combination is commonly seen by self-signed leaf certificates with an
  intermediate CA before the root CA.

  Because of this, openssl 1.1.1f rejects these certificates and they
  cannot be used in the system certificate store, and ssl connections
  fail when you try to use them to connect to a ssl endpoint.

  The error you see when you try verify is:

  $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem 
user1_cert.pem
  error 20 at 0 depth lookup: unable to get local issuer certificate
  error user1_cert.pem: verification failed

  The exact same certificates work fine on Xenial, Bionic and Hirsute.

  [1] https://tools.ietf.org/html/rfc5280.html

  [Testcase]

  We will create our own root CA, intermediate CA and leaf server
  certificate.

  Create necessary directories:

  $ mkdir reproducer
  $ cd reproducer
  $ mkdir CA

  Write openssl configuration files to disk for each CA and cert:

  $ cat << EOF >> rootCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Root-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> subCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Sub-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE,pathlen:0
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> user.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test User

  [ usr_cert ]
  basicConstraints= critical,CA:FALSE,pathlen:0
  keyUsage= critical,digitalSignature,keyAgreement
  extendedKeyUsage= clientAuth,serverAuth
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  Then generate the necessary RSA keys and form certificates:

  $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt 
rsa_keygen_bits:2048
  $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes 
-x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt 
rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1

  $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt 
rsa_keygen_bits:2048
  $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem 
-sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1
  $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey 
rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt 
-CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt 
rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1
  $ c_rehash CA

  $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt 
rsa_keygen_bits:2048
  $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem 
-sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1
  $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey 
subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial 
-extfile user.cnf 

[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one

2021-05-07 Thread Robie Basak
Hello Dan, or anyone else affected,

Accepted openssl into hirsute-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/openssl/1.1.1j-
1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
hirsute to verification-done-hirsute. If it does not fix the bug for
you, please add a comment stating that, and change the tag to
verification-failed-hirsute. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: openssl (Ubuntu Hirsute)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-hirsute

** Changed in: openssl (Ubuntu Groovy)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1927161

Title:
  dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch'
  patches files multiple times; split the diff in multiple files or
  merge the hunks into a single one

Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Groovy:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Committed
Status in openssl source package in Impish:
  In Progress

Bug description:
  [impact]

  openssl doesn't build source properly because of a badly-constructed
  patch

  [test case]

  $ pull-lp-source openssl groovy
  ...
  $ cd openssl-1.1.1f/
  $ quilt pop -a
  ...
  $ dpkg-buildpackage -d -S
  dpkg-buildpackage: info: source package openssl
  dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3
  dpkg-buildpackage: info: source distribution groovy-security
  dpkg-buildpackage: info: source changed by Marc Deslauriers 

   dpkg-source --before-build .
  dpkg-source: warning: can't parse dependency perl:native
  dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' 
patches files multiple times; split the diff in multiple files or merge the 
hunks into a single one
  dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned 
exit status 25

  Test builds are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test

  [regression potential]

  any regression would likely cause a failed build or would affect the
  functionality that patch pr12272 was added for, which is adding
  support for Intel CET

  [scope]

  this is needed only for g and later

  this is caused by the bad patch 'pr12272.patch' which is only included
  in g/h/i, so this does not apply to f or earlier

  [other info]

  note that if the patches are applied, this bug is bypassed; i.e. if
  'quilt pop -a' is removed from the test case above, the bug doesn't
  reproduce. this is only a problem when the patches aren't already
  applied and dpkg-buildpackage needs to call dpkg-source to apply the
  patches.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1926254] Please test proposed package

2021-05-07 Thread Robie Basak
Hello Matthew, or anyone else affected,

Accepted openssl into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/openssl/1.1.1f-
1ubuntu2.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1926254

Title:
  x509 Certificate verification fails when
  basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Fix Committed
Status in openssl source package in Groovy:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  In openssl 1.1.1f, the below commit was merged:

  commit ba4356ae4002a04e28642da60c551877eea804f7
  Author: Bernd Edlinger 
  Date:   Sat Jan 4 15:54:53 2020 +0100
  Subject: Fix error handling in x509v3_cache_extensions and related functions
  Link: 
https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7

  This introduced a regression which caused certificate validation to
  fail when certificates violate RFC 5280 [1], namely, when a
  certificate has "basicConstraints=CA:FALSE,pathlen:0". This
  combination is commonly seen by self-signed leaf certificates with an
  intermediate CA before the root CA.

  Because of this, openssl 1.1.1f rejects these certificates and they
  cannot be used in the system certificate store, and ssl connections
  fail when you try to use them to connect to a ssl endpoint.

  The error you see when you try verify is:

  $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem 
user1_cert.pem
  error 20 at 0 depth lookup: unable to get local issuer certificate
  error user1_cert.pem: verification failed

  The exact same certificates work fine on Xenial, Bionic and Hirsute.

  [1] https://tools.ietf.org/html/rfc5280.html

  [Testcase]

  We will create our own root CA, intermediate CA and leaf server
  certificate.

  Create necessary directories:

  $ mkdir reproducer
  $ cd reproducer
  $ mkdir CA

  Write openssl configuration files to disk for each CA and cert:

  $ cat << EOF >> rootCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Root-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> subCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Sub-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE,pathlen:0
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> user.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test User

  [ usr_cert ]
  basicConstraints= critical,CA:FALSE,pathlen:0
  keyUsage= critical,digitalSignature,keyAgreement
  extendedKeyUsage= clientAuth,serverAuth
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  Then generate the necessary RSA keys and form certificates:

  $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt 
rsa_keygen_bits:2048
  $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes 
-x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt 
rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1

  $ 

[Touch-packages] [Bug 1927161] Please test proposed package

2021-05-07 Thread Robie Basak
Hello Dan, or anyone else affected,

Accepted openssl into groovy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/openssl/1.1.1f-
1ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
groovy to verification-done-groovy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-groovy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1927161

Title:
  dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch'
  patches files multiple times; split the diff in multiple files or
  merge the hunks into a single one

Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Groovy:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Committed
Status in openssl source package in Impish:
  In Progress

Bug description:
  [impact]

  openssl doesn't build source properly because of a badly-constructed
  patch

  [test case]

  $ pull-lp-source openssl groovy
  ...
  $ cd openssl-1.1.1f/
  $ quilt pop -a
  ...
  $ dpkg-buildpackage -d -S
  dpkg-buildpackage: info: source package openssl
  dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3
  dpkg-buildpackage: info: source distribution groovy-security
  dpkg-buildpackage: info: source changed by Marc Deslauriers 

   dpkg-source --before-build .
  dpkg-source: warning: can't parse dependency perl:native
  dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' 
patches files multiple times; split the diff in multiple files or merge the 
hunks into a single one
  dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned 
exit status 25

  Test builds are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test

  [regression potential]

  any regression would likely cause a failed build or would affect the
  functionality that patch pr12272 was added for, which is adding
  support for Intel CET

  [scope]

  this is needed only for g and later

  this is caused by the bad patch 'pr12272.patch' which is only included
  in g/h/i, so this does not apply to f or earlier

  [other info]

  note that if the patches are applied, this bug is bypassed; i.e. if
  'quilt pop -a' is removed from the test case above, the bug doesn't
  reproduce. this is only a problem when the patches aren't already
  applied and dpkg-buildpackage needs to call dpkg-source to apply the
  patches.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1926254] Please test proposed package

2021-05-07 Thread Robie Basak
Hello Matthew, or anyone else affected,

Accepted openssl into groovy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/openssl/1.1.1f-
1ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
groovy to verification-done-groovy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-groovy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: openssl (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1926254

Title:
  x509 Certificate verification fails when
  basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Fix Committed
Status in openssl source package in Groovy:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  In openssl 1.1.1f, the below commit was merged:

  commit ba4356ae4002a04e28642da60c551877eea804f7
  Author: Bernd Edlinger 
  Date:   Sat Jan 4 15:54:53 2020 +0100
  Subject: Fix error handling in x509v3_cache_extensions and related functions
  Link: 
https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7

  This introduced a regression which caused certificate validation to
  fail when certificates violate RFC 5280 [1], namely, when a
  certificate has "basicConstraints=CA:FALSE,pathlen:0". This
  combination is commonly seen by self-signed leaf certificates with an
  intermediate CA before the root CA.

  Because of this, openssl 1.1.1f rejects these certificates and they
  cannot be used in the system certificate store, and ssl connections
  fail when you try to use them to connect to a ssl endpoint.

  The error you see when you try verify is:

  $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem 
user1_cert.pem
  error 20 at 0 depth lookup: unable to get local issuer certificate
  error user1_cert.pem: verification failed

  The exact same certificates work fine on Xenial, Bionic and Hirsute.

  [1] https://tools.ietf.org/html/rfc5280.html

  [Testcase]

  We will create our own root CA, intermediate CA and leaf server
  certificate.

  Create necessary directories:

  $ mkdir reproducer
  $ cd reproducer
  $ mkdir CA

  Write openssl configuration files to disk for each CA and cert:

  $ cat << EOF >> rootCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Root-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> subCA.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test RSA PSS Sub-CA

  [ usr_cert ]
  basicConstraints= critical,CA:TRUE,pathlen:0
  keyUsage= critical,keyCertSign,cRLSign
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  $ cat << EOF >> user.cnf
  [ req ]
  prompt  = no
  distinguished_name  = req_distinguished_name
  x509_extensions = usr_cert

  [ req_distinguished_name ]
  C  = DE
  O  = Test Org
  CN = Test User

  [ usr_cert ]
  basicConstraints= critical,CA:FALSE,pathlen:0
  keyUsage= critical,digitalSignature,keyAgreement
  extendedKeyUsage= clientAuth,serverAuth
  subjectKeyIdentifier= hash
  authorityKeyIdentifier  = keyid:always
  EOF

  Then generate the necessary RSA keys and form certificates:

  $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt 
rsa_keygen_bits:2048
  $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes 

[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-14 Thread Robie Basak
Hello Vincent, or anyone else affected,

Accepted openldap into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/openldap/2.4.49+dfsg-
2ubuntu1.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: openldap (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1921562

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  

  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit.

  
  [Test Plan]
  ===

  When using openldap on 20.04, this bug causes failures in the SSSD
  LDAP backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  With the patched version, this should no longer be a problem.

  
  [Where Problems Could Occur]
  

  With this patch applied, there may be few edge cases in (and varying
  b/w) different versions of GnuTLS. And also some bits that are
  discussed in https://bugs.openldap.org/show_bug.cgi?id=8650.

  But that said, the patched version is already being run in production
  for over two weeks time (at the time of writing - 07/04/21). So I
  believe the SRU will clearly benefit from this and has lower risk of
  regression.

  
  [More Info]
  ===

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openldap/+bug/1921562/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)

2021-04-11 Thread Robie Basak
Looks like this conflicting file started shipping in an Ubuntu delta
1.4-0ubuntu1 in Quantal, and Debian never shipped it in
gir1.2-signon-1.0 - only in gir1.2-signon-2.0. So this is an Ubuntu-
specific problem.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu.
https://bugs.launchpad.net/bugs/1916250

Title:
  gir1.2-signon-2.0 needs to declare replace on older releases
  (Groovy2Hirsute)

Status in libsignon-glib package in Ubuntu:
  New

Bug description:
  gir1.2-signon-1.0 from groovy
  gir1.2-signon-2.0 from hirsute

  above two packages ship the same file /usr/lib/python3/dist-
  packages/gi/overrides/Signon.py without specifying how to resolve the
  conflict.

  Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', 
which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5
  Errors were encountered while processing:
   /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  Probably needs a conflicts/replaces dependency added to the newer
  hirsute package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1874824] Please test proposed package

2021-04-07 Thread Robie Basak
Hello Sven, or anyone else affected,

Accepted procps into groovy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/procps/2:3.3.16-5ubuntu2.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
groovy to verification-done-groovy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-groovy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: procps (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1874824

Title:
  pgrep reports error "cannot allocate" when run without stack limit

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Focal:
  Fix Committed
Status in procps source package in Groovy:
  Fix Committed
Status in procps source package in Hirsute:
  Fix Released
Status in procps package in Debian:
  New

Bug description:
  [Impact]

- Users who have ulimit set high would see either slow
  or failed pgrep and pkill commands
- Users who have ulimit set to unlimited would see
  failed pgrep and pkill commands
- This bug occurs because the behavior of sysconf(_SC_ARG_MAX)
  changed with a newer version of the kernel.

  [Test Case]

- set the ulimit to unlimited by running `ulimit -S -s unlimited`
- run `pgrep bash` to see that the "cannot allocate" error is
   printed and the command has failed.

  [Where Problems Could Occur]

- We have set upper and lower limits on the size of the malloc, but
  if further kernel versions break the call to sysconf in
  unexpected ways we could still see problems.

  [Original Description]

  If you have no stack limit (ulimit -S -s unlimited), any pgrep call
  will fail with an error:

  > pgrep vim
  pgrep: cannot allocate 4611686018427387903 bytes

  If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is
  very slow:

  > time pgrep vim
  2196
  real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444

  The relevant upstream bug report could be: 
https://gitlab.com/procps-ng/procps/-/issues/152
  Archlinux bug report: https://bugs.archlinux.org/task/66093

  procps:
    Installed: 2:3.3.16-1ubuntu2
    500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1874824] Please test proposed package

2021-04-07 Thread Robie Basak
Hello Sven, or anyone else affected,

Accepted procps into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/procps/2:3.3.16-1ubuntu2.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1874824

Title:
  pgrep reports error "cannot allocate" when run without stack limit

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Focal:
  Fix Committed
Status in procps source package in Groovy:
  Fix Committed
Status in procps source package in Hirsute:
  Fix Released
Status in procps package in Debian:
  New

Bug description:
  [Impact]

- Users who have ulimit set high would see either slow
  or failed pgrep and pkill commands
- Users who have ulimit set to unlimited would see
  failed pgrep and pkill commands
- This bug occurs because the behavior of sysconf(_SC_ARG_MAX)
  changed with a newer version of the kernel.

  [Test Case]

- set the ulimit to unlimited by running `ulimit -S -s unlimited`
- run `pgrep bash` to see that the "cannot allocate" error is
   printed and the command has failed.

  [Where Problems Could Occur]

- We have set upper and lower limits on the size of the malloc, but
  if further kernel versions break the call to sysconf in
  unexpected ways we could still see problems.

  [Original Description]

  If you have no stack limit (ulimit -S -s unlimited), any pgrep call
  will fail with an error:

  > pgrep vim
  pgrep: cannot allocate 4611686018427387903 bytes

  If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is
  very slow:

  > time pgrep vim
  2196
  real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444

  The relevant upstream bug report could be: 
https://gitlab.com/procps-ng/procps/-/issues/152
  Archlinux bug report: https://bugs.archlinux.org/task/66093

  procps:
    Installed: 2:3.3.16-1ubuntu2
    500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1874824] Re: pgrep reports error "cannot allocate" when run without stack limit

2021-04-07 Thread Robie Basak
Ah, sorry, my mistake. I didn't think that pgrep.c would be used for a
different command. Now I see that pkill is a symlink to pgrep in
/usr/bin.

** Changed in: procps (Ubuntu Groovy)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1874824

Title:
  pgrep reports error "cannot allocate" when run without stack limit

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Focal:
  Fix Committed
Status in procps source package in Groovy:
  Fix Committed
Status in procps source package in Hirsute:
  Fix Released
Status in procps package in Debian:
  New

Bug description:
  [Impact]

- Users who have ulimit set high would see either slow
  or failed pgrep and pkill commands
- Users who have ulimit set to unlimited would see
  failed pgrep and pkill commands
- This bug occurs because the behavior of sysconf(_SC_ARG_MAX)
  changed with a newer version of the kernel.

  [Test Case]

- set the ulimit to unlimited by running `ulimit -S -s unlimited`
- run `pgrep bash` to see that the "cannot allocate" error is
   printed and the command has failed.

  [Where Problems Could Occur]

- We have set upper and lower limits on the size of the malloc, but
  if further kernel versions break the call to sysconf in
  unexpected ways we could still see problems.

  [Original Description]

  If you have no stack limit (ulimit -S -s unlimited), any pgrep call
  will fail with an error:

  > pgrep vim
  pgrep: cannot allocate 4611686018427387903 bytes

  If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is
  very slow:

  > time pgrep vim
  2196
  real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444

  The relevant upstream bug report could be: 
https://gitlab.com/procps-ng/procps/-/issues/152
  Archlinux bug report: https://bugs.archlinux.org/task/66093

  procps:
    Installed: 2:3.3.16-1ubuntu2
    500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1908818] Re: pure packaging of libnss3

2021-04-07 Thread Robie Basak
Hello Sergey, or anyone else affected,

Accepted nss into groovy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nss/2:3.55-1ubuntu3.1
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
groovy to verification-done-groovy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-groovy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: nss (Ubuntu Groovy)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1908818

Title:
  pure packaging of libnss3

Status in nss package in Ubuntu:
  Fix Released
Status in nss source package in Groovy:
  Fix Committed
Status in nss source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

   * A packaging error in the current version has led library symlinks
 to be broken and in the wrong place.

   * Fix by applying the later change to Groovy as well

  [Test Plan]

   * install libnss3
   * check (path depends on the architecture) the lib links
 $ dpkg -L libnss3 | grep MULTIARCH
 # ^^ should be empty
 $ ll /usr/lib/x86_64-linux-gnu/libfreebl3.so
 # vv should look like that:

  lrwxrwxrwx 1 root root 17 Feb 16 15:18 
/usr/lib/x86_64-linux-gnu/libfreebl3.so -> nss/libfreebl3.so
  root@h:~# ll /usr/lib/x86_64-linux-gnu/libfreebl*
  lrwxrwxrwx 1 root root 18 Feb 16 15:18 
/usr/lib/x86_64-linux-gnu/libfreebl3.chk -> nss/libfreebl3.chk
  lrwxrwxrwx 1 root root 17 Feb 16 15:18 
/usr/lib/x86_64-linux-gnu/libfreebl3.so -> nss/libfreebl3.so
  lrwxrwxrwx 1 root root 22 Feb 16 15:18 
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.chk -> nss/libfreeblpriv3.chk
  lrwxrwxrwx 1 root root 21 Feb 16 15:18 
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.so -> nss/libfreeblpriv3.so

  [Where problems could occur]

   * I first was afraid, that no matter how bad the paths would
 have been we'd need to retain them for anyone using them
 already. But the existing links go into nowhere since they
 are relative therefore the regression risk should be minimal

  root@g:~# ll '/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so' 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.so' 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.chk' 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.chk'
  lrwxrwxrwx 1 root root 18 Sep 29  2020 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.chk' -> nss/libfreebl3.chk
  lrwxrwxrwx 1 root root 17 Sep 29  2020 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so' -> nss/libfreebl3.so
  lrwxrwxrwx 1 root root 22 Sep 29  2020 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.chk' -> nss/libfreeblpriv3.chk
  lrwxrwxrwx 1 root root 21 Sep 29  2020 
'/usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.so' -> nss/libfreeblpriv3.so

   * never the less, to be clear - if problems occur they would be in 
 loading these libraries. E.g. a user could have had this package
 and a self built nss on his system, after the change it might load the 
 packaged one.

  [Other Info]
   
   * n/a

  ---

  
  dpkg -L libnss3
  /.
  /usr
  /usr/lib
  /usr/lib/${DEB_HOST_MULTIARCH}
  /usr/lib/x86_64-linux-gnu
  /usr/lib/x86_64-linux-gnu/libnss3.so
  /usr/lib/x86_64-linux-gnu/libnssutil3.so
  /usr/lib/x86_64-linux-gnu/libsmime3.so
  /usr/lib/x86_64-linux-gnu/libssl3.so
  /usr/lib/x86_64-linux-gnu/nss
  /usr/lib/x86_64-linux-gnu/nss/libfreebl3.chk
  /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
  /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.chk
  /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
  /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
  /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.chk
  /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
  /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.chk
  /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so
  /usr/share
  /usr/share/doc
  /usr/share/doc/libnss3
  /usr/share/doc/libnss3/changelog.Debian.gz
  /usr/share/doc/libnss3/copyright
  /usr/share/lintian
  /usr/share/lintian/overrides
  

[Touch-packages] [Bug 1874824] Re: pgrep reports error "cannot allocate" when run without stack limit

2021-04-07 Thread Robie Basak
> The problem is the same for other popular tools like pkill from the
same package.

The SRU uploads fix pgrep, but not pkill. Isn't pkill also affected?
Rather than fixing that in a separate SRU causing users to have to
update twice, should we be fixing both at the same time? Or are you
intending to never fix pkill in an SRU? Are there any other commands
affected by the same issue?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1874824

Title:
  pgrep reports error "cannot allocate" when run without stack limit

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Focal:
  In Progress
Status in procps source package in Groovy:
  In Progress
Status in procps source package in Hirsute:
  Fix Released
Status in procps package in Debian:
  New

Bug description:
  [Impact]

- Users who have ulimit set high would see either slow
  or failed pgrep and pkill commands
- Users who have ulimit set to unlimited would see
  failed pgrep and pkill commands
- This bug occurs because the behavior of sysconf(_SC_ARG_MAX)
  changed with a newer version of the kernel.

  [Test Case]

- set the ulimit to unlimited by running `ulimit -S -s unlimited`
- run `pgrep bash` to see that the "cannot allocate" error is
   printed and the command has failed.

  [Where Problems Could Occur]

- We have set upper and lower limits on the size of the malloc, but
  if further kernel versions break the call to sysconf in
  unexpected ways we could still see problems.

  [Original Description]

  If you have no stack limit (ulimit -S -s unlimited), any pgrep call
  will fail with an error:

  > pgrep vim
  pgrep: cannot allocate 4611686018427387903 bytes

  If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is
  very slow:

  > time pgrep vim
  2196
  real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444

  The relevant upstream bug report could be: 
https://gitlab.com/procps-ng/procps/-/issues/152
  Archlinux bug report: https://bugs.archlinux.org/task/66093

  procps:
    Installed: 2:3.3.16-1ubuntu2
    500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1920837] Re: apport bugs from official raspi or riscv images are not identified

2021-04-06 Thread Robie Basak
> labelling them as Raspberry Pi would exacerbate the issue

Sorry, I should have acknowledged that Dave's proposal would avoid this
issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1920837

Title:
  apport bugs from official raspi or riscv images are not identified

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  In Progress
Status in apport source package in Groovy:
  In Progress

Bug description:
  It would be helpful if bugs reported from images for Raspberry Pi's or
  RISCV systems were tagged so that one could search for bugs from
  systems running those images e.g. 'raspi-image'.

  [Test Case]
  After installing a preinstalled image of Ubuntu for Raspberry Pi do the 
following:
  1) run 'ubuntu-bug apport'
  2) view the bug report and check the Tags field

  With the current version of apport you will not see the tag 'raspi-image'.
  With the version of apport in -proposed you will see the tag 'raspi-image'.

  [Where problems could occur]
  If the code being added is syntactically incorrect then we'd see a Traceback 
which would be bad as it could affect all bug / crash reports.

  [Other Info]
  Since there aren't any Groovy images for RISC-V there will be nothing to test 
there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1920837/+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 1920837] Re: apport bugs from official raspi or riscv images are not identified

2021-04-06 Thread Robie Basak
A couple of thoughts:

1)

In addition to future supported platforms, what about weird third party
hacked up things? Are we going to end up with reports from users who
have grabbed a custom image for some esoteric platform from someone who
is hacking something together for that platform by basing their work on
one of our official Raspberry Pi images? To be clear, they're welcome to
do that; we just don't want images mislabelled as Raspberry Pi causing
confusion in that case. Of course people can do that regardless of what
apport does, but labelling them as Raspberry Pi would exacerbate the
issue.

2)

+if 'ImageMediaBuild' in report:
+if report['Architecture'] in ('arm64', 'armhf'):
+add_tag(report, 'raspi-image')

Why not simply add tags arm64-image and armhf-image? Then you'll get the
same effect you want but without a potentially misleading tag. This may
be kicking the can down the road, but maybe that's exactly what we want
to do here?


This should presumably be settled in the development release before the SRU 
proceeds, so I'm deferring SRU review for now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1920837

Title:
  apport bugs from official raspi or riscv images are not identified

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  In Progress
Status in apport source package in Groovy:
  In Progress

Bug description:
  It would be helpful if bugs reported from images for Raspberry Pi's or
  RISCV systems were tagged so that one could search for bugs from
  systems running those images e.g. 'raspi-image'.

  [Test Case]
  After installing a preinstalled image of Ubuntu for Raspberry Pi do the 
following:
  1) run 'ubuntu-bug apport'
  2) view the bug report and check the Tags field

  With the current version of apport you will not see the tag 'raspi-image'.
  With the version of apport in -proposed you will see the tag 'raspi-image'.

  [Where problems could occur]
  If the code being added is syntactically incorrect then we'd see a Traceback 
which would be bad as it could affect all bug / crash reports.

  [Other Info]
  Since there aren't any Groovy images for RISC-V there will be nothing to test 
there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1920837/+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 1917677] Re: ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release

2021-03-10 Thread Robie Basak
See also: bug 1915547

> It is highly unlikely that the configuration file on one distro is
replaced with one that was shipped on a different one.

I think it's more likely than you say in cases that a configuration
shipped is primarily a set of boolean values and enumerations of a
limited set of strings, and the difference in distributions is mostly in
choices of those values. The extreme example would be a configuration
file that ships just one boolean setting. I think this unattended-
upgrades case is closer to that extreme example than it is to openssh's
sshd_config.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1917677

Title:
  ubuntu: ucf tracking of valid known md5sums   should be limited to
  only those md5sums that affect a given distro release

Status in unattended-upgrades package in Ubuntu:
  New
Status in unattended-upgrades source package in Bionic:
  New
Status in unattended-upgrades source package in Focal:
  New
Status in unattended-upgrades source package in Groovy:
  New
Status in unattended-upgrades source package in Hirsute:
  New

Bug description:
  Currently the project tracks all valid md5sums of permutations of
  50unattended-upgrades.conf in a single md5sum file that contains every
  md5sum of every historic version of all unique distros:

   50unattended-upgrades.Debian
   50unattended-upgrades.Devuan
   50unattended-upgrades.Raspbian
   50unattended-upgrades.Ubuntu

  Ultimately ucf for a given packaging release should only track the
  applicable md5sums which are expected to be seen on that particular
  distribution and release.

  For example:
 On Ubuntu Bionic: valid md5sums should be limited to the md5sum of the 
most recent Ubuntu Xenial 50unattended-upgrades.conf and the md5sums of 
previous Ubuntu Bionic releases to allow Xenial->Bionic and Bionic->Bionic 
upgrades without prompt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1917677/+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 1915547] Re: Users are prompted by ucf on upgrade from Trusty to Xenial

2021-03-05 Thread Robie Basak
Hello Lucas, or anyone else affected,

Accepted unattended-upgrades into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source
/unattended-upgrades/1.1ubuntu1.18.04.7~16.04.7 in a few hours, and then
in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
xenial to verification-done-xenial. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-xenial. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: Triaged => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1915547

Title:
  Users are prompted by ucf on upgrade from Trusty to Xenial

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  During an upgrade from trusty to xenial, users will be prompted to make a 
decision regarding the diff on unattended-upgrades. This is not a good user 
experience, specially because the user can make an uninformed decision of 
keeping the old config file, which will make unattended-upgrades to not work as 
we expect.

  [Test case]

  To reproduce the issue, you can:

  1. Launch a trusty vm
  2. Perform a do-release-upgrade and observe that you will be prompted with 
the 50unattended-upgrades change

  To verify that the error is fixed:

  1. Launch a trusty vm
  2. Import this ppa into the system:
 https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
  3. Configure do-release-upgrade to allow using third parties during upgrade
  4. Run a do-release-upgrade
  5. Verify the prompt is no longer there and that we end up with the 
 expected 50unattended-upgrades config file

  [Where problems could occur]

  The changes in this package should only surface during an upgrade
  operation.  With this change, we are now delivering a new file to the
  system and configuring postinst to use it. Because of that, we believe
  this is the only scenario that could be affected in case of a
  regression is discovered in the package.

  
  [Discussion]
  When upgrading from trusty to xenial, we are prompted about config changes on 
50unattended-upgrades with the following diff:

  --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 
19:21:39
  +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 
2020-02-17 18:03:38
  @@ -1,11 +1,13 @@
   // Automatically upgrade packages from these (origin:archive) pairs
   Unattended-Upgrade::Allowed-Origins {
  + "${distro_id}:${distro_codename}";
   "${distro_id}:${distro_codename}-security";
   // Extended Security Maintenance; doesn't necessarily exist for
   // every release and this system may not have it installed, but if
   // available, the policy for updates is such that unattended-upgrades
   // should also install from here by default.
  - "${distro_id}ESM:${distro_codename}";
  + "${distro_id}ESMApps:${distro_codename}-apps-security";
  + "${distro_id}ESM:${distro_codename}-infra-security";
   // "${distro_id}:${distro_codename}-updates";
   // "${distro_id}:${distro_codename}-proposed";
   // "${distro_id}:${distro_codename}-backports";

  The reason we are presented with this diff is that the xenial package
  does not contain a md5sum history file that informs ucf about all the
  supported configs for 50unattended-upgrades. To fix that upgrade
  problem, we are prosing the following changes on the xenial package of
  unattended-upgrades:

  - Add 50unattended-upgrades.md5sum file into the xenial package
  - Add md5sum of the current xenial 50unattende-upgrades file into the 
md5sum history file
  - Modify ucf command in postinst to be aware of the md5sum history file

  See the changelog entry below for a full list of changes and bugs.

  We have performed a manual test with a modified version of the xenial package:
  

[Touch-packages] [Bug 1915547] Re: Users are prompted by ucf on upgrade from Trusty to Xenial

2021-03-03 Thread Robie Basak
Imagine a package shipping config file with contents "foo: true; bar:
false". You might put the md5 of that in the ucf history, so that
packaging that later changes to "foo: true; bar: true" knows that if the
user has anything other than "foo: true; bar: false" then it is a
customisation that should be preserved.

However, if packaging has iterated between all four possibilities, then
list of all possible hashes defeats the purpose. Packaging will believe
that whatever the user changed, it isn't a customisation because it was
shipped previously by the packaging. Customisations will therefore get
lost, contrary to our intention.

Therefore, it follows that the list of hashes shipped should be
minimally what packaging did actually previously ship; anything more
unnecessarily increases the risk of a collision with a user
customisation. Since we don't support upgrade leaps beyond LTS-to-LTS,
historical hashes can therefore be dropped to keep this minimal.

For this SRU, I'd therefore expect to see being added only the hashes
involved in the specific issue being fixed - presumably only one -
rather than 117. Usually the above never comes up, but I think it's
relevant when there are 117, rather than the one or two entries that are
common.

Similarly, for Hirsute, I'd have expected only the hashes since Focal
and onwards to be included.

I did ask on IRC how to reproduce the hashes, and Balint pointed out
that an explanation exists in README.source. Sorry I didn't see this
before - the explanation is in Hirsute but not in this SRU upload. I
think this reference to that from this bug comment is sufficient for
reproducibility.

Perhaps I'm completely wrong here, in which case I'd appreciate a
correction. Otherwise, please adjust the upload to minimally fix the
specific issue here by only including the required hashes. I also
suggest rethinking the Hirsute upload.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1915547

Title:
  Users are prompted by ucf on upgrade from Trusty to Xenial

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Triaged

Bug description:
  [Impact]
  During an upgrade from trusty to xenial, users will be prompted to make a 
decision regarding the diff on unattended-upgrades. This is not a good user 
experience, specially because the user can make an uninformed decision of 
keeping the old config file, which will make unattended-upgrades to not work as 
we expect.

  [Test case]

  To reproduce the issue, you can:

  1. Launch a trusty vm
  2. Perform a do-release-upgrade and observe that you will be prompted with 
the 50unattended-upgrades change

  To verify that the error is fixed:

  1. Launch a trusty vm
  2. Import this ppa into the system:
 https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
  3. Configure do-release-upgrade to allow using third parties during upgrade
  4. Run a do-release-upgrade
  5. Verify the prompt is no longer there and that we end up with the 
 expected 50unattended-upgrades config file

  [Where problems could occur]

  The changes in this package should only surface during an upgrade
  operation.  With this change, we are now delivering a new file to the
  system and configuring postinst to use it. Because of that, we believe
  this is the only scenario that could be affected in case of a
  regression is discovered in the package.

  
  [Discussion]
  When upgrading from trusty to xenial, we are prompted about config changes on 
50unattended-upgrades with the following diff:

  --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 
19:21:39
  +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 
2020-02-17 18:03:38
  @@ -1,11 +1,13 @@
   // Automatically upgrade packages from these (origin:archive) pairs
   Unattended-Upgrade::Allowed-Origins {
  + "${distro_id}:${distro_codename}";
   "${distro_id}:${distro_codename}-security";
   // Extended Security Maintenance; doesn't necessarily exist for
   // every release and this system may not have it installed, but if
   // available, the policy for updates is such that unattended-upgrades
   // should also install from here by default.
  - "${distro_id}ESM:${distro_codename}";
  + "${distro_id}ESMApps:${distro_codename}-apps-security";
  + "${distro_id}ESM:${distro_codename}-infra-security";
   // "${distro_id}:${distro_codename}-updates";
   // "${distro_id}:${distro_codename}-proposed";
   // "${distro_id}:${distro_codename}-backports";

  The reason we are presented with this diff is that the xenial package
  does not contain a md5sum history file that informs ucf about all the
  supported configs for 50unattended-upgrades. To fix that upgrade
  problem, we are prosing the following changes on the xenial package of
  unattended-upgrades:

  - 

[Touch-packages] [Bug 1915547] Re: Users are prompted by ucf on upgrade from Trusty to Xenial

2021-03-03 Thread Robie Basak
** Summary changed:

-  sru unattended-upgrades (1.1ubuntu1.18.04.7~16.04.6  update to   
1.1ubuntu1.18.04.7~16.04.7 ) Xenial
+ Users are prompted by ucf on upgrade from Trusty to Xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1915547

Title:
  Users are prompted by ucf on upgrade from Trusty to Xenial

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Triaged

Bug description:
  [Impact]
  During an upgrade from trusty to xenial, users will be prompted to make a 
decision regarding the diff on unattended-upgrades. This is not a good user 
experience, specially because the user can make an uninformed decision of 
keeping the old config file, which will make unattended-upgrades to not work as 
we expect.

  [Test case]

  To reproduce the issue, you can:

  1. Launch a trusty vm
  2. Perform a do-release-upgrade and observe that you will be prompted with 
the 50unattended-upgrades change

  To verify that the error is fixed:

  1. Launch a trusty vm
  2. Import this ppa into the system:
 https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
  3. Configure do-release-upgrade to allow using third parties during upgrade
  4. Run a do-release-upgrade
  5. Verify the prompt is no longer there and that we end up with the 
 expected 50unattended-upgrades config file

  [Where problems could occur]

  The changes in this package should only surface during an upgrade
  operation.  With this change, we are now delivering a new file to the
  system and configuring postinst to use it. Because of that, we believe
  this is the only scenario that could be affected in case of a
  regression is discovered in the package.

  
  [Discussion]
  When upgrading from trusty to xenial, we are prompted about config changes on 
50unattended-upgrades with the following diff:

  --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 
19:21:39
  +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 
2020-02-17 18:03:38
  @@ -1,11 +1,13 @@
   // Automatically upgrade packages from these (origin:archive) pairs
   Unattended-Upgrade::Allowed-Origins {
  + "${distro_id}:${distro_codename}";
   "${distro_id}:${distro_codename}-security";
   // Extended Security Maintenance; doesn't necessarily exist for
   // every release and this system may not have it installed, but if
   // available, the policy for updates is such that unattended-upgrades
   // should also install from here by default.
  - "${distro_id}ESM:${distro_codename}";
  + "${distro_id}ESMApps:${distro_codename}-apps-security";
  + "${distro_id}ESM:${distro_codename}-infra-security";
   // "${distro_id}:${distro_codename}-updates";
   // "${distro_id}:${distro_codename}-proposed";
   // "${distro_id}:${distro_codename}-backports";

  The reason we are presented with this diff is that the xenial package
  does not contain a md5sum history file that informs ucf about all the
  supported configs for 50unattended-upgrades. To fix that upgrade
  problem, we are prosing the following changes on the xenial package of
  unattended-upgrades:

  - Add 50unattended-upgrades.md5sum file into the xenial package
  - Add md5sum of the current xenial 50unattende-upgrades file into the 
md5sum history file
  - Modify ucf command in postinst to be aware of the md5sum history file

  See the changelog entry below for a full list of changes and bugs.

  We have performed a manual test with a modified version of the xenial package:
  https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa

  Using that package, we were able to verify that the config change
  prompt no longer happens from trusty to xenial.

  Since we are modifying are features on unattended-upgrades, just
  adding a new file to package, we don't believe there is any regression
  potential

  
  == Changelog ==

    * data: add md5sum history file on the data folder
  - This file contains md5sum of several supported 50unattended-upgrades
    config files
    * data: add xenial md5sum of 50unattented-upgrades into md5sum file
    * debian/postint: make ucf command reference the md5sum history file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915547/+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 1874824] Re: pgrep reports error "cannot allocate" when run without stack limit

2021-03-01 Thread Robie Basak
Patch available at https://gitlab.com/procps-
ng/procps/-/commit/bb96fc42956c9ed926a1b958ab715f8b4a663dec

** Tags added: bitesize patch rls-hh-incoming

** Changed in: procps (Ubuntu)
   Status: Confirmed => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1874824

Title:
  pgrep reports error "cannot allocate" when run without stack limit

Status in procps package in Ubuntu:
  Triaged
Status in procps package in Debian:
  New

Bug description:
  If you have no stack limit (ulimit -S -s unlimited), any pgrep call
  will fail with an error:

  > pgrep vim
  pgrep: cannot allocate 4611686018427387903 bytes

  If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is
  very slow:

  > time pgrep vim
  2196
  real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444

  The relevant upstream bug report could be: 
https://gitlab.com/procps-ng/procps/-/issues/152
  Archlinux bug report: https://bugs.archlinux.org/task/66093

  procps:
Installed: 2:3.3.16-1ubuntu2
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1860826] Re: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory

2021-02-28 Thread Robie Basak
I'm adding a Focal task as requested in #ubuntu-bugs. However, please
don't take this as an endorsement for a Focal SRU. If it's just spurious
log entries, I'm not sure if an SRU would be appropriate or not.

** Also affects: pam (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1860826

Title:
  pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or
  directory

Status in pam package in Ubuntu:
  Confirmed
Status in pam source package in Focal:
  New
Status in pam source package in Groovy:
  Confirmed
Status in pam package in Debian:
  Fix Released

Bug description:
  Hello, after upgrading to focal I found the following in my journalctl
  output:

  Jan 24 23:07:00 millbarge sudo[32120]: pam_unix(sudo:auth): Couldn't open 
/etc/securetty: No such file or directory
  Jan 24 23:07:01 millbarge sudo[32120]: pam_unix(sudo:auth): Couldn't open 
/etc/securetty: No such file or directory

  
  The login package stopped packaging this file:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731656
  and now forcibly removes the file:
  https://paste.ubuntu.com/p/myh9cGWrHD/

  However, the pam package's pam_unix.so module has not yet been adapted to 
ignore this file:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674857#25

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libpam-modules 1.3.1-5ubuntu4
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  Date: Fri Jan 24 23:35:33 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: pam
  UpgradeStatus: Upgraded to focal on 2020-01-24 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1860826/+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 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child

2021-02-19 Thread Robie Basak
Hello Marco, or anyone else affected,

Accepted sssd into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu0.4
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: sssd (Ubuntu Focal)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1905790

Title:
  Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for
  p11_child

Status in ca-certificates package in Ubuntu:
  New
Status in sssd package in Ubuntu:
  Fix Released
Status in ca-certificates source package in Focal:
  New
Status in sssd source package in Focal:
  Fix Committed

Bug description:
  [ Impact ]

  SSSD supports in 20.04 two security backends: NSS and OpenSSL
  (speaking in past tense as upstream dropped NSS support completely).

  Those two backends are used for various generic crypto features (so
  they are interchangeable), but also for the management of the PKCS#11
  modules for smart cards.

  In this case, the main problem is that by using NSS it also relies on
  the presence of a "system NSS" database [1] that is something present
  in Fedora and RHEL, but not in ubuntu or generic Linux distributions.

  In order to make SSSD to find a smart card module, we would then need to 
create a such database that mentions a p11kit proxy that will eventually load 
the p11-kit module and then add the card CA certificate to the same DB (see 
more details in [2]).
  And even in such case... It will not work at login phase.

  This is making support for Smart-card based authentication in 20.04
  quite complicated, and hard to implement in professional environments
  (see bug #1865226).

  As per this, recompiling SSSD's p11_child to use OpenSSL (as it
  already happens starting from 20.10) would be enough to make the this
  tool (the one in charge for smartcard authentications and certificate
  matching) to be able to get the smartcard devices from p11-kit allowed
  modules and to check their certificate using CA certificates in the
  ubuntu system ca certificate files (or other configured file).

  One more mayor reason to do this, is also that if we fix 20.04 now to
  use the "proper" method, people who will configure smartcard access
  there via SSSD (not easily possible right now) won't be affected by
  future migrations.

  
  [ Proposed Implementations ]

  1) Use p11-kit and openssl for p11_child, by changing the build/test system 
(preferred)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child

  2) Build both versions and package things accordingly (hackish)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1

  3) Recompile SSSD completely to use libcrypto as backend

  The option 3) has been finally choosen, but we also require migration
  scripts on upgrade.

  
  [ Test case ]

  With a smartcard reader available (and with a card in its slot) as reported 
by:
   $ p11-kit list-modules

  launch:
   $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \
     --nssdb=/etc/ssl/certs/ca-certificates.crt

  The tool should find your card:

  (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module 
List:
  (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common 
name: [p11-kit-trust].
  (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll 
name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so].
  (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): 
Description [/etc/ssl/certs/ca-certificates.crt  
PKCS#11 Kit ] Manufacturer [PKCS#11 Kit 
] flags [1] removable [false] token present [true].
  (2020-11-26 21:34:22:020611): 

[Touch-packages] [Bug 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)

2021-02-19 Thread Robie Basak
Thank you for working on this!

Conflicts is a little too strong perhaps, and are best avoided to give
apt the most leeway to resolve things. Can you pick from
https://wiki.debian.org/PackageTransition please? Unversioned is also
unusual; I'd expect versioned relationships in this case I think.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu.
https://bugs.launchpad.net/bugs/1916250

Title:
  gir1.2-signon-2.0 needs to declare replace on older releases
  (Groovy2Hirsute)

Status in libsignon-glib package in Ubuntu:
  New

Bug description:
  gir1.2-signon-1.0 from groovy
  gir1.2-signon-2.0 from hirsute

  above two packages ship the same file /usr/lib/python3/dist-
  packages/gi/overrides/Signon.py without specifying how to resolve the
  conflict.

  Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', 
which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5
  Errors were encountered while processing:
   /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  Probably needs a conflicts/replaces dependency added to the newer
  hirsute package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child

2021-02-18 Thread Robie Basak
> +  certs = CERT_CreateSubjectCertList (NULL, handle,
>derSubject,

Doesn't this need a return value test? AFAICT,
CERT_CreateSubjectCertList might return NULL, and CERTLIST_HEAD (certs)
will unconditionally look up a member? There's a second instance of this
pattern in print_trusted_certificates().

However, since the postinst only calls nss-database-pem-exporter from
inside import_nss_ca_certs(), the "set -e" won't have any effect there,
so I think this is OK in practice. I'd normally ask for more explicit
error handling (or at least comments in the postinst) but since this
migration code will only exist in this SRU, I think it's OK to leave it
as-is.

> +if dpkg --compare-versions "$2" lt-nl 2.2.3-3ubuntu0.2; then

Doesn't this now need bumping to 0.4? The current version in focal-
updates is 2.2.3-3ubuntu0.3. Otherwise I think the upgrade path won't
activate for anyone already on 2.2.3-3ubuntu0.2 or 2.2.3-3ubuntu0.3?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1905790

Title:
  Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for
  p11_child

Status in ca-certificates package in Ubuntu:
  New
Status in sssd package in Ubuntu:
  Fix Released
Status in ca-certificates source package in Focal:
  New
Status in sssd source package in Focal:
  New

Bug description:
  [ Impact ]

  SSSD supports in 20.04 two security backends: NSS and OpenSSL
  (speaking in past tense as upstream dropped NSS support completely).

  Those two backends are used for various generic crypto features (so
  they are interchangeable), but also for the management of the PKCS#11
  modules for smart cards.

  In this case, the main problem is that by using NSS it also relies on
  the presence of a "system NSS" database [1] that is something present
  in Fedora and RHEL, but not in ubuntu or generic Linux distributions.

  In order to make SSSD to find a smart card module, we would then need to 
create a such database that mentions a p11kit proxy that will eventually load 
the p11-kit module and then add the card CA certificate to the same DB (see 
more details in [2]).
  And even in such case... It will not work at login phase.

  This is making support for Smart-card based authentication in 20.04
  quite complicated, and hard to implement in professional environments
  (see bug #1865226).

  As per this, recompiling SSSD's p11_child to use OpenSSL (as it
  already happens starting from 20.10) would be enough to make the this
  tool (the one in charge for smartcard authentications and certificate
  matching) to be able to get the smartcard devices from p11-kit allowed
  modules and to check their certificate using CA certificates in the
  ubuntu system ca certificate files (or other configured file).

  One more mayor reason to do this, is also that if we fix 20.04 now to
  use the "proper" method, people who will configure smartcard access
  there via SSSD (not easily possible right now) won't be affected by
  future migrations.

  
  [ Proposed Implementations ]

  1) Use p11-kit and openssl for p11_child, by changing the build/test system 
(preferred)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child

  2) Build both versions and package things accordingly (hackish)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1

  3) Recompile SSSD completely to use libcrypto as backend

  The option 3) has been finally choosen, but we also require migration
  scripts on upgrade.

  
  [ Test case ]

  With a smartcard reader available (and with a card in its slot) as reported 
by:
   $ p11-kit list-modules

  launch:
   $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \
     --nssdb=/etc/ssl/certs/ca-certificates.crt

  The tool should find your card:

  (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module 
List:
  (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common 
name: [p11-kit-trust].
  (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll 
name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so].
  (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): 
Description [/etc/ssl/certs/ca-certificates.crt  
PKCS#11 Kit ] Manufacturer [PKCS#11 Kit 
] flags [1] removable [false] token present [true].
  (2020-11-26 21:34:22:020611): [p11_child[100729]] [do_card] (0x4000): common 
name: [opensc-pkcs11].
  (2020-11-26 21:34:22:020646): [p11_child[100729]] [do_card] (0x4000): dll 
name: [/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so].
  (2020-11-26 21:34:22:025443): [p11_child[100729]] [do_card] (0x4000): 
Description [VMware Virtual USB CCID 00 00   
VMware  ] Manufacturer [VMware  
] flags [7] 

[Touch-packages] [Bug 1913179] Re: krb5 fails dep8 in Hirsute

2021-01-27 Thread Robie Basak
krb5 has now migrated with the fix to openldap.

** Changed in: krb5 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1913179

Title:
  krb5 fails dep8 in Hirsute

Status in krb5 package in Ubuntu:
  Fix Released

Bug description:
  I'm creating this bug to lead people looking at update_excuses to the
  MP that fixes this issue, since unfortunately there's no easier way of
  doing that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1913179/+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 1913187] Re: iproute2 segfaults when filtering sockets

2021-01-27 Thread Robie Basak
Hello Rafael, or anyone else affected,

Accepted iproute2 into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/iproute2/4.15.0-2ubuntu1.3 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: iproute2 (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1913187

Title:
  iproute2 segfaults when filtering sockets

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * The ss tool crashes when a query returns no results (seg fault)

  [Test Case]

   * $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 
127.0.0.1
  Segmentation fault

   * PPA with the fix:
  https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187

  [Where problems could occur]

   * The ss tool is impacted and it has its code changed for the fix.

   * The fix is a clean cherry-pick and straightforward (moving
  declaration after a NULL check).

  [Other Info]

  When in Ubuntu Bionic, if one calls:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  tcp  00   
127.0.0.1:58910 127.0.0.1:22   
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)

  it works. Just like when in Groovy:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  tcp   00  
127.0.0.1:58908 127.0.0.1:22   
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)

  but.. if there is nothing to show, in Bionic we get a segfault:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  Segmentation fault

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1677881] Re: Missing dep8 tests

2021-01-26 Thread Robie Basak
FWIW, this test correctly caught a regression, fixed in openldap 2.4.56
+dfsg-1ubuntu2. Good job :)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1677881

Title:
  Missing dep8 tests

Status in krb5 package in Ubuntu:
  Fix Released

Bug description:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

  As of March 29, 2017, this source package did not contain dep8 tests in
  the current development release of Ubuntu, named Zesty. This was
  determined by running `pull-lp-source krb5 zesty` and then
  checking for the existence of 'debian/tests/' and
  'debian/tests/control'.

  Test automation is essential to higher levels of quality and confidence
  in updates to packages. dep8 tests [1] specify how automatic testing can
  be integrated into packages and then run by package maintainers before
  new uploads.

  This defect is to report the absence of these tests and to report the
  opportunity as a potential item for development by both new and
  experienced contributors.

  [1] http://packaging.ubuntu.com/html/auto-pkg-test.html

   affects ubuntu/krb5
   status new
   importance wishlist
   tag needs-dep8

  - ---
  Joshua Powers
  Ubuntu Server
  Canonical Ltd

  -BEGIN PGP SIGNATURE-

  iQIcBAEBCAAGBQJY3YGVAAoJEIP8BxPaZgwlCIEP/36uotG3iLNIh5/fPc2FDzwV
  hqK5CLKbCLqlX7RmzkSzO303hJ051Q6uWIb1ZcnvZShO4h2mrQfyXXmWBXO3So/2
  imYe6Pg3j9v1aNYCxpvWKL6VIpN5beADCoWlAS9P89qSIdyEYTiaL6HFHzbA5hck
  7rtMhHnzw16mkT+ttZ39f4kqZ9jqqV1je0lPyCI3L+UicswkdeymHeZAZSkG13lW
  uSi5SVLFDpDeWq/23Ohj0tacLZbpBKG4vScRQ7+Me3ieGnC0gii8C1luXGPWpS9v
  CvW1JLPbuo3yHooBzJw6YAYI2TiWyNjtO2/9ESPxcmn+tPn7iXoeTBIstlQC2iY0
  fvoUrmxUjSJafgCyZE1NNy8gTlFLObpMP/qZPtw7YLKaD9t64+JZUK4vzSNr1tY5
  ltCXFf0mneUrUjTOS1Io+vigiBbMEIFuUjEXT3DxGEybf8rrl6fJdCD++1L0NTXR
  ImfhCBgSEYBrluRLHu1tGftin7wKgarl7uWLzZxGeJ/MiXkX0eWIgOVoXaQq6gnR
  HR7XF1x9x1VJYi2CGMrDDWSHWDHgXC5UOcBz/KLMSPMcyQakXyRrw1Hqplj3G3PM
  OkqR8uLWUYfTZvrVvnSj4jJPNRSiBOz95FFbfMZ43yxoE5F6QBhztwgcJC8/g+bn
  zu94s0Hiyv+yxmptMwgX
  =ibX0
  -END PGP SIGNATURE-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1677881/+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 1913187] Re: iproute2 segfaults when filtering sockets

2021-01-26 Thread Robie Basak
** Merge proposal linked:
   
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/iproute2/+git/iproute2/+merge/396921

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1913187

Title:
  iproute2 segfaults when filtering sockets

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Confirmed

Bug description:
  [Impact]

   * The ss tool crashes when a query returns no results (seg fault)

  [Test Case]

   * $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 
127.0.0.1
  Segmentation fault

   * PPA with the fix:
  https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187

  [Where problems could occur]

   * The ss tool is impacted and it has its code changed for the fix.

   * The fix is a clean cherry-pick and straightforward (moving
  declaration after a NULL check).

  [Other Info]

  When in Ubuntu Bionic, if one calls:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  tcp  00   
127.0.0.1:58910 127.0.0.1:22   
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)

  it works. Just like when in Groovy:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  tcp   00  
127.0.0.1:58908 127.0.0.1:22   
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)

  but.. if there is nothing to show, in Bionic we get a segfault:

  $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
  Segmentation fault

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913306] Re: slapd Apparmor profile allows /tmp widely

2021-01-26 Thread Robie Basak
Any advice/comment from the security team on this please?

** Description changed:

  Currently debian/apparmor-profile defines:
  
  /var/tmp/** rw,
  
  This is quite wide. Can we narrow it down? There are a couple of
  alternative opportunities here:
  
  1) Remove that line, and define instead more specific path rules, such
  as "/var/tmp/krb5_*.rcache2 rwk" that we recently added. A risk here is
  that it's difficult for us to determine and track the necessary paths,
  since some may be related to functionality that we don't have dep8 test
  coverage for.
  
  2) Retain that line, add a "k", move slapd to a native systemd service
  and use PrivateTmp=yes.
  
  A third opportunity, independent of the above, is to move the rules to
  an abstraction that any sasl+gssapi+krb5 -using service could include.
+ 
+ This discussion came up in
+ 
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853,
+ but we focused on fixing only the immediate issue there, leaving this
+ bug open for another time.

** Merge proposal linked:
   
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1913306

Title:
  slapd Apparmor profile allows /tmp widely

Status in openldap package in Ubuntu:
  Triaged

Bug description:
  Currently debian/apparmor-profile defines:

  /var/tmp/** rw,

  This is quite wide. Can we narrow it down? There are a couple of
  alternative opportunities here:

  1) Remove that line, and define instead more specific path rules, such
  as "/var/tmp/krb5_*.rcache2 rwk" that we recently added. A risk here
  is that it's difficult for us to determine and track the necessary
  paths, since some may be related to functionality that we don't have
  dep8 test coverage for.

  2) Retain that line, add a "k", move slapd to a native systemd service
  and use PrivateTmp=yes.

  A third opportunity, independent of the above, is to move the rules to
  an abstraction that any sasl+gssapi+krb5 -using service could include.

  This discussion came up in
  
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853,
  but we focused on fixing only the immediate issue there, leaving this
  bug open for another time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1913306/+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 1913306] [NEW] slapd Apparmor profile allows /tmp widely

2021-01-26 Thread Robie Basak
Public bug reported:

Currently debian/apparmor-profile defines:

/var/tmp/** rw,

This is quite wide. Can we narrow it down? There are a couple of
alternative opportunities here:

1) Remove that line, and define instead more specific path rules, such
as "/var/tmp/krb5_*.rcache2 rwk" that we recently added. A risk here is
that it's difficult for us to determine and track the necessary paths,
since some may be related to functionality that we don't have dep8 test
coverage for.

2) Retain that line, add a "k", move slapd to a native systemd service
and use PrivateTmp=yes.

A third opportunity, independent of the above, is to move the rules to
an abstraction that any sasl+gssapi+krb5 -using service could include.

This discussion came up in
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853,
but we focused on fixing only the immediate issue there, leaving this
bug open for another time.

** Affects: openldap (Ubuntu)
 Importance: Medium
 Status: Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1913306

Title:
  slapd Apparmor profile allows /tmp widely

Status in openldap package in Ubuntu:
  Triaged

Bug description:
  Currently debian/apparmor-profile defines:

  /var/tmp/** rw,

  This is quite wide. Can we narrow it down? There are a couple of
  alternative opportunities here:

  1) Remove that line, and define instead more specific path rules, such
  as "/var/tmp/krb5_*.rcache2 rwk" that we recently added. A risk here
  is that it's difficult for us to determine and track the necessary
  paths, since some may be related to functionality that we don't have
  dep8 test coverage for.

  2) Retain that line, add a "k", move slapd to a native systemd service
  and use PrivateTmp=yes.

  A third opportunity, independent of the above, is to move the rules to
  an abstraction that any sasl+gssapi+krb5 -using service could include.

  This discussion came up in
  
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853,
  but we focused on fixing only the immediate issue there, leaving this
  bug open for another time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1913306/+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 1913179] [NEW] krb5 fails dep8 in Hirsute

2021-01-25 Thread Robie Basak
Public bug reported:

I'm creating this bug to lead people looking at update_excuses to the MP
that fixes this issue, since unfortunately there's no easier way of
doing that.

** Affects: krb5 (Ubuntu)
 Importance: Undecided
 Status: Triaged


** Tags: update-excuse

** Merge proposal linked:
   
https://code.launchpad.net/~racb/ubuntu/+source/openldap/+git/openldap/+merge/396853

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1913179

Title:
  krb5 fails dep8 in Hirsute

Status in krb5 package in Ubuntu:
  Triaged

Bug description:
  I'm creating this bug to lead people looking at update_excuses to the
  MP that fixes this issue, since unfortunately there's no easier way of
  doing that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1913179/+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 1848330] Update Released

2021-01-25 Thread Robie Basak
The verification of the Stable Release Update for audit has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-23 Thread Robie Basak
I think it's important to distinguish:

 a) merely failing to reproduce the issue; versus

 b) confirming reproduction of the issue against the previous version of
the package (version 1:2.8.2-1ubuntu1 in this case), and then confirming
that the proposed version (version 1:2.8.2-1ubuntu1.1 in this case)
resolves the issue _in the same environment_.

The distinction is important because if the test method and environment
used is unable to reproduce against the previous version, then
confirming that it's not possible to reproduce the issue with the
proposed version is effectively no testing at all.

Please could you confirm if the testing was actually case b, and if so
detail what testing was performed?

Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-22 Thread Robie Basak
** Tags removed: verification-done-bionic
** Tags added: verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-21 Thread Robie Basak
I'd like to see some testing from someone actually affected please.
Otherwise we'd be releasing a change that risks regression to users not
affected, for a bug that we're not even sure if we've fixed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed 

[Touch-packages] [Bug 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions

2021-01-19 Thread Robie Basak
Is this really worth an SRU to Groovy? One could consider the change to
be fully implemented since Hirsute only, and Groovy will EOL before long
anyway. Otherwise there's a risk that we'll break users' existing
automation that is already live against Groovy.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1912122

Title:
  /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT
  restrictions

Status in rsyslog package in Ubuntu:
  In Progress
Status in rsyslog source package in Groovy:
  In Progress
Status in rsyslog source package in Hirsute:
  In Progress

Bug description:
  [Impact]

  In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the
  Ubuntu kernel starting with Groovy and onward, in an effort to
  restrict access to the kernel log buffer from unprivileged users.

  It seems we have overlooked /var/log/dmesg, as it is still mode 0644,
  while /var/log/kern.log, /var/log/syslog are all 0640:

  $ ll /var/log
  -rw-r--r--   1 root  adm 81768 Jan 18 09:09 dmesg
  -rw-r-   1 syslogadm 24538 Jan 18 13:05 
kern.log
  -rw-r-   1 syslogadm213911 Jan 18 13:22 syslog

  Change /var/log/dmesg to 0640 to close the information leak.

  [Testcase]

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  [0.00] kernel: Linux version 5.8.0-36-generic 
(buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld 
(GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 
11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18)
  [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---

  If you install the package in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test

  $ sudo systemctl daemon-reload
  $ sudo systemctl start dmesg.service

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  cat: /var/log/dmesg: Permission denied

  [Where problems could occur]

  Some users or log scraper programs might need to view the kernel log
  buffers, and in this case, their underlying service accounts should be
  added to the 'adm' group.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic

2021-01-13 Thread Robie Basak
I asked on IRC for confirmation that the regression fix has landed in
Hirsute.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1908167

Title:
  [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be
  selected automatically if there is no internal mic

Status in HWE Next:
  New
Status in OEM Priority Project:
  New
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Committed
Status in pulseaudio source package in Groovy:
  Fix Committed
Status in pulseaudio source package in Hirsute:
  Fix Released

Bug description:
  [Impact]
  On the Dell AIO machines, there is no internal mic, after plugging a
  headset, users expect the headset-mic or headphone-mic could be selected
  automatically. But with the current rule, the headset-mic/headphone-mic will 
not be selected automatically and even users manually select them, they will 
not show up in the gnome sound setting, and users could not record sound by 
headset-mic/headphone-mic.

  [Fix]
  backport a patch from pulseaudio mergerequest, the patch is going to be
  merged to pulseaudio 14.1. This patch could be backported to hirsute without 
any change, but need to be changed if backport it to groovy and focal.

  [Test]
  With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a 
headset to the problematic Dell AIO machine will not automatically select 
headset-mic/headphone-mic, and they also do not show up in Gnome sound 
settings, leading to failure to record any sound.

  With the new proposed package, on those Dell AIO, plug a headset, open
  the gnome sound setting, the headset-mic is selected automatically,
  use the headset-mic to record the sound, the sound could be recorded
  and the sound quality is good.

  [Where problems could occur]
  This patch could change the policy of audio device switching, it will not
  affect all audio devices, but only the devices which has AVAIL_UNKNOWN 
available status, that means it has possibility to introduce the regression on 
headphone-mic ,headset-mic, internal mic and internal speaker's switching since 
they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, 
the input device will not switch to internal mic automatically or after unplug 
the headphone, the output device will not switch to internal speaker 
automatically. But this possibility is very low, we have tested the patch on 
many Dell and Lenovo machines, all worked well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1908167/+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 1848330] Please test proposed package

2021-01-13 Thread Robie Basak
Hello Dr., or anyone else affected,

Accepted audit into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/audit/1:2.8.2-1ubuntu1.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-13 Thread Robie Basak
I verified that this is fixed in both Focal and Hirsute by examining the
source (so presumably Groovy too).

** Also affects: audit (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: audit (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: audit (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 

[Touch-packages] [Bug 1908814] Re: systemd : inconsistencies in man pages

2021-01-04 Thread Robie Basak
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

You didn't say which version of systemd whose manpages you are looking
at, or which Ubuntu release you're using. I looked at the current
development release of Ubuntu, and I don't see that we're changing the
manpages at all from upstream in this respect (other changes are made,
but that are not relevant here). Since your suggestion is an editorial
one rather than a material error, I suggest that you make your case to
systemd upstream directly to see if they are willing to change it. If
you want to do this, I suggest you file an issue (or better, a pull
request) against https://github.com/systemd/systemd/tree/master/man.

I don't think it makes sense for Ubuntu to your proposed change without
upstream, so I'm going to mark this bug as Won't Fix. However if
upstream make the change you suggest, a future release of Ubuntu will
pick it up.

** Changed in: openssh (Ubuntu)
   Importance: Undecided => Low

** Changed in: openssh (Ubuntu)
   Status: New => Won't Fix

** Package changed: openssh (Ubuntu) => systemd (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1908814

Title:
  systemd : inconsistencies in man pages

Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  From "man systemd-system.conf":

  When packages need to customize the configuration, they can install
  configuration snippets in /usr/lib/systemd/*.conf.d/ or
  /usr/local/lib/systemd/*.conf.d/. The main configuration file is read
  before any of the configuration directories, and has the lowest
  precedence; entries in a file in any configuration directory override
  entries in the single configuration file. Files in the *.conf.d/
  configuration subdirectories are sorted by their filename in
  lexicographic order, regardless of in which of the subdirectories they
  reside. When multiple files specify the same option, for options which
  accept just a single value, the entry in the file with the
  lexicographically latest name takes precedence. For options which
  accept a list of values, entries are collected as they occur in files
  sorted lexicographically.

  
  However from "man SYSTEMD":

  DIRECTORIES
 System unit directories
 The systemd system manager reads unit configuration from various 
directories. Packages that want to install unit files shall place them in the 
directory returned by pkg-config systemd
 --variable=systemdsystemunitdir. Other directories checked are 
/usr/local/lib/systemd/system and /lib/systemd/system. User configuration 
always takes precedence.  pkg-config systemd
 --variable=systemdsystemconfdir returns the path of the system 
configuration directory. Packages should alter the content of these directories 
only with the enable and disable commands of
 the systemctl(1) tool. Full list of directories is provided in 
systemd.unit(5).

 User unit directories
 Similar rules apply for the user unit directories. However, here 
the XDG Base Directory specification[6] is followed to find units. Applications 
should place their unit files in the
 directory returned by pkg-config systemd 
--variable=systemduserunitdir. Global configuration is done in the directory 
reported by pkg-config systemd --variable=systemduserconfdir. The
 enable and disable commands of the systemctl(1) tool can handle 
both global (i.e. for all users) and private (for one user) enabling/disabling 
of units. Full list of directories is provided
 in systemd.unit(5).


  Obviously, the 2nd one is more precise about directories for
  configuration files and therefore should be used in all cases. 1st
  paragraph of doc should link there

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908814/+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 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression

2020-12-09 Thread Robie Basak
Unsubscribing ~ubuntu-sponsors as I believe there is no longer anything
to sponsor.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1906627

Title:
  GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active
  Directory, causing recent adcli regression

Status in adcli package in Ubuntu:
  Fix Released
Status in cyrus-sasl2 package in Ubuntu:
  Fix Released
Status in adcli source package in Bionic:
  In Progress
Status in cyrus-sasl2 source package in Bionic:
  In Progress

Bug description:
  [Impact]

  A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a
  regression for some users when attempting to join a Active Directory
  realm. adcli introduced a default behaviour change, moving from GSS-
  API to GSS-SPNEGO as the default channel encryption algorithm.

  adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi-
  mit, a part of cyrus-sasl2. The implementation seems to have some
  compatibility issues with particular configurations of Active
  Directory on recent Windows Server systems.

  Particularly, adcli sends a ldap query to the domain controller, which
  responds with a tcp ack, but never returns a ldap response. The
  connection just hangs at this point and no more traffic is sent.

  You can see it on the packet trace below:

  https://paste.ubuntu.com/p/WRnnRMGBPm/

  On Focal, where the implementation of GSS-SPNEGO is working, we see a
  full exchange, and adcli works as expected:

  https://paste.ubuntu.com/p/8668pJrr2m/

  The fix is to not assume use of confidentiality and integrity modes,
  and instead use the flags negotiated by GSS-API during the initial
  handshake, as required by Microsoft's implementation.

  [Testcase]

  You will need to set up a Windows Server 2019 system, install and
  configure Active Directory and enable LDAP extensions and configure
  LDAPS and import the AD SSL certificate to the Ubuntu client. Create
  some users in Active Directory.

  On the Ubuntu client, set up /etc/hosts with the hostname of the
  Windows Server machine, if your system isn't configured for AD DNS.

  From there, install adcli 0.8.2-1 from -release.

  $ sudo apt install adcli

  Set up a packet trace with tcpdump:

  $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)'

  Next, join the AD realm using the normal GSS-API:

  # adcli join --verbose -U Administrator --domain WIN-
  SB6JAS7PH22.testing.local --domain-controller WIN-
  SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL

  You will be prompted for Administrator's passowrd.

  The output should look like the below:

  https://paste.ubuntu.com/p/NWHGQn746D/

  Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the 
regression.
  Repeat the above steps. Now you should see the connection hang.

  https://paste.ubuntu.com/p/WRnnRMGBPm/

  Finally, install the fixed cyrus-sasl2 package, which is available from the
  below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test

  $ sudo add-apt-repository ppa:mruffell/lp1906627-test
  $ sudo apt-get update
  $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db 
libsasl2-modules-gssapi-mit

  Repeat the steps. GSS-SPNEGO should be working as intended, and you
  should get output like below:

  https://paste.ubuntu.com/p/W5cJNGvCsx/

  [Where problems could occur]

  Since we are changing the implementation of GSS-SPNEGO, and cyrus-
  sasl2 is the library which provides it, we can potentially break any
  package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO.

  $ apt rdepends libsasl2-modules-gssapi-mit
  libsasl2-modules-gssapi-mit
  Reverse Depends:
   |Suggests: ldap-utils
Depends: adcli
Conflicts: libsasl2-modules-gssapi-heimdal
   |Suggests: libsasl2-modules
Conflicts: libsasl2-modules-gssapi-heimdal
   |Recommends: sssd-krb5-common
   |Suggests: slapd
   |Suggests: libsasl2-modules
   |Suggests: ldap-utils
   |Depends: msktutil
Conflicts: libsasl2-modules-gssapi-heimdal
   |Depends: libapache2-mod-webauthldap
Depends: freeipa-server
Depends: freeipa-client
Depends: adcli
Depends: 389-ds-base
   |Recommends: sssd-krb5-common
   |Suggests: slapd
   |Suggests: libsasl2-modules
   
  While this SRU makes cyrus-sasl2 work with Microsoft implementations of 
GSS-SPNEGO, which will be the more common usecase, it may change the behaviour  
when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 
assumes use of confidentiality and integrity modes. This shouldn't be a problem 
as the krb5 implementation signals its intentions by setting the correct flags 
during handshake, which these patches to cyrus-sasl2 should now parse correctly.

  [Other Info]

  The below two commits are needed. The first fixes the problem, the second 
fixes
  some unused parameter warnings.

  commit 

[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression

2020-12-09 Thread Robie Basak
Thank you for preparing this revert.

Since Bionic 0.8.2-1ubuntu1 was previously in bionic-security, I think
this revert needs to go into the security pocket, and therefore cannot
be built in the bionic-updates pocket and needs handling via the
security team PPA.

However I'm not sure, so to avoid confusion I'll leave this for Łukasz.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1906627

Title:
  GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active
  Directory, causing recent adcli regression

Status in adcli package in Ubuntu:
  Fix Released
Status in cyrus-sasl2 package in Ubuntu:
  Fix Released
Status in adcli source package in Bionic:
  In Progress
Status in cyrus-sasl2 source package in Bionic:
  In Progress

Bug description:
  [Impact]

  A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a
  regression for some users when attempting to join a Active Directory
  realm. adcli introduced a default behaviour change, moving from GSS-
  API to GSS-SPNEGO as the default channel encryption algorithm.

  adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi-
  mit, a part of cyrus-sasl2. The implementation seems to have some
  compatibility issues with particular configurations of Active
  Directory on recent Windows Server systems.

  Particularly, adcli sends a ldap query to the domain controller, which
  responds with a tcp ack, but never returns a ldap response. The
  connection just hangs at this point and no more traffic is sent.

  You can see it on the packet trace below:

  https://paste.ubuntu.com/p/WRnnRMGBPm/

  On Focal, where the implementation of GSS-SPNEGO is working, we see a
  full exchange, and adcli works as expected:

  https://paste.ubuntu.com/p/8668pJrr2m/

  The fix is to not assume use of confidentiality and integrity modes,
  and instead use the flags negotiated by GSS-API during the initial
  handshake, as required by Microsoft's implementation.

  [Testcase]

  You will need to set up a Windows Server 2019 system, install and
  configure Active Directory and enable LDAP extensions and configure
  LDAPS and import the AD SSL certificate to the Ubuntu client. Create
  some users in Active Directory.

  On the Ubuntu client, set up /etc/hosts with the hostname of the
  Windows Server machine, if your system isn't configured for AD DNS.

  From there, install adcli 0.8.2-1 from -release.

  $ sudo apt install adcli

  Set up a packet trace with tcpdump:

  $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)'

  Next, join the AD realm using the normal GSS-API:

  # adcli join --verbose -U Administrator --domain WIN-
  SB6JAS7PH22.testing.local --domain-controller WIN-
  SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL

  You will be prompted for Administrator's passowrd.

  The output should look like the below:

  https://paste.ubuntu.com/p/NWHGQn746D/

  Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the 
regression.
  Repeat the above steps. Now you should see the connection hang.

  https://paste.ubuntu.com/p/WRnnRMGBPm/

  Finally, install the fixed cyrus-sasl2 package, which is available from the
  below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test

  $ sudo add-apt-repository ppa:mruffell/lp1906627-test
  $ sudo apt-get update
  $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db 
libsasl2-modules-gssapi-mit

  Repeat the steps. GSS-SPNEGO should be working as intended, and you
  should get output like below:

  https://paste.ubuntu.com/p/W5cJNGvCsx/

  [Where problems could occur]

  Since we are changing the implementation of GSS-SPNEGO, and cyrus-
  sasl2 is the library which provides it, we can potentially break any
  package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO.

  $ apt rdepends libsasl2-modules-gssapi-mit
  libsasl2-modules-gssapi-mit
  Reverse Depends:
   |Suggests: ldap-utils
Depends: adcli
Conflicts: libsasl2-modules-gssapi-heimdal
   |Suggests: libsasl2-modules
Conflicts: libsasl2-modules-gssapi-heimdal
   |Recommends: sssd-krb5-common
   |Suggests: slapd
   |Suggests: libsasl2-modules
   |Suggests: ldap-utils
   |Depends: msktutil
Conflicts: libsasl2-modules-gssapi-heimdal
   |Depends: libapache2-mod-webauthldap
Depends: freeipa-server
Depends: freeipa-client
Depends: adcli
Depends: 389-ds-base
   |Recommends: sssd-krb5-common
   |Suggests: slapd
   |Suggests: libsasl2-modules
   
  While this SRU makes cyrus-sasl2 work with Microsoft implementations of 
GSS-SPNEGO, which will be the more common usecase, it may change the behaviour  
when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 
assumes use of confidentiality and integrity modes. This shouldn't be a problem 
as the krb5 implementation signals its intentions by setting the correct 

[Touch-packages] [Bug 1902109] Re: rsync uses lchmod and fails in Ubuntu >= 20.10

2020-10-29 Thread Robie Basak
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

This is interesting and I appreciate your investigation! I wonder though
if there's a third outcome here - that it's not a bug because the glibc
implementation of lchmod() requires /proc to be mounted, and if you
don't have /proc mounted then by that definition you have a broken
system and lchmod() is not expected to work, so rsync won't work, as a
design decision of upstream glibc.

I'm not claiming that this is the case, just that it's another case to
consider.

** Changed in: rsync (Ubuntu)
   Status: New => Triaged

** Summary changed:

- rsync uses lchmod and fails in Ubuntu >= 20.10
+ rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1902109

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109/+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 1899195] Re: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

2020-10-28 Thread Robie Basak
Hello errors.ubuntu.com, or anyone else affected,

Accepted apport into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.9-0ubuntu7.19 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1899195

Title:
  
/usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Fix Committed
Status in apport source package in Bionic:
  Fix Committed
Status in apport source package in Focal:
  Fix Committed

Bug description:
  Impact
  --
  apport is crashing for some users when a crash file is created about an 
executable which has been deleted.

  Test Case
  -
  While you won't get a Traceback (because there is a location for apport to 
print its usages message) with the following test case you will see apport 
usage printed:

   $ PYTHONPATH=/home/bdmurray/source-trees/apport/trunk data/apport '8219' 
'11' '0' '1' '8219' '!usr!bin!yes' '(deleted)'
  usage: apport [-h] [-p PID] [-s SIGNAL_NUMBER] [-c CORE_ULIMIT] [-d 
DUMP_MODE] [-P [GLOBAL_PID]]

  With the fixed version of apport you'll see no such usage message.

  Regression Potential
  
  Because new code is being added its possible that the python syntax could be 
bad which would result in another crash, so careful review the code.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu27.10, the problem page at 
https://errors.ubuntu.com/problem/290470c9cf5f278596966c386aac31e70a49988e 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.

  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 451, in 
  options = parse_arguments()
    File "/usr/share/apport/apport", line 396, in parse_arguments
  parser.print_usage()
    File "/usr/lib/python3.6/argparse.py", line 2370, in print_usage
  self._print_message(self.format_usage(), file)
    File "/usr/lib/python3.6/argparse.py", line 2381, in _print_message
  file.write(message)
  AttributeError: 'NoneType' object has no attribute 'write'

  After working on https://bugs.launchpad.net/apport/+bug/1732962, the error 
tracker started throwing the error above.
  it appears that print_usage is called and throwing an error because in this 
context (called with core_pattern) apport doesn't have an stdout or stderr. 
after looking at traces it seems the kernel is adding 'deleted' to the name of 
the process which cause argument parsing to fail.

  The fix below from bdmurray seems to fix it.
  https://paste.ubuntu.com/p/pVKNP9kWP4/

  There is report of this issue in Focal, Bionic and xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1899195/+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 1899195] Re: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

2020-10-28 Thread Robie Basak
Hello errors.ubuntu.com, or anyone else affected,

Accepted apport into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu27.11 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1899195

Title:
  
/usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Fix Committed
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Focal:
  Fix Committed

Bug description:
  Impact
  --
  apport is crashing for some users when a crash file is created about an 
executable which has been deleted.

  Test Case
  -
  While you won't get a Traceback (because there is a location for apport to 
print its usages message) with the following test case you will see apport 
usage printed:

   $ PYTHONPATH=/home/bdmurray/source-trees/apport/trunk data/apport '8219' 
'11' '0' '1' '8219' '!usr!bin!yes' '(deleted)'
  usage: apport [-h] [-p PID] [-s SIGNAL_NUMBER] [-c CORE_ULIMIT] [-d 
DUMP_MODE] [-P [GLOBAL_PID]]

  With the fixed version of apport you'll see no such usage message.

  Regression Potential
  
  Because new code is being added its possible that the python syntax could be 
bad which would result in another crash, so careful review the code.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu27.10, the problem page at 
https://errors.ubuntu.com/problem/290470c9cf5f278596966c386aac31e70a49988e 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.

  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 451, in 
  options = parse_arguments()
    File "/usr/share/apport/apport", line 396, in parse_arguments
  parser.print_usage()
    File "/usr/lib/python3.6/argparse.py", line 2370, in print_usage
  self._print_message(self.format_usage(), file)
    File "/usr/lib/python3.6/argparse.py", line 2381, in _print_message
  file.write(message)
  AttributeError: 'NoneType' object has no attribute 'write'

  After working on https://bugs.launchpad.net/apport/+bug/1732962, the error 
tracker started throwing the error above.
  it appears that print_usage is called and throwing an error because in this 
context (called with core_pattern) apport doesn't have an stdout or stderr. 
after looking at traces it seems the kernel is adding 'deleted' to the name of 
the process which cause argument parsing to fail.

  The fix below from bdmurray seems to fix it.
  https://paste.ubuntu.com/p/pVKNP9kWP4/

  There is report of this issue in Focal, Bionic and xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1899195/+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 1899195] Re: /usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

2020-10-28 Thread Robie Basak
Hello errors.ubuntu.com, or anyone else affected,

Accepted apport into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.1-0ubuntu2.26 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
xenial to verification-done-xenial. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-xenial. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1899195

Title:
  
/usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Fix Committed
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Focal:
  In Progress

Bug description:
  Impact
  --
  apport is crashing for some users when a crash file is created about an 
executable which has been deleted.

  Test Case
  -
  While you won't get a Traceback (because there is a location for apport to 
print its usages message) with the following test case you will see apport 
usage printed:

   $ PYTHONPATH=/home/bdmurray/source-trees/apport/trunk data/apport '8219' 
'11' '0' '1' '8219' '!usr!bin!yes' '(deleted)'
  usage: apport [-h] [-p PID] [-s SIGNAL_NUMBER] [-c CORE_ULIMIT] [-d 
DUMP_MODE] [-P [GLOBAL_PID]]

  With the fixed version of apport you'll see no such usage message.

  Regression Potential
  
  Because new code is being added its possible that the python syntax could be 
bad which would result in another crash, so careful review the code.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu27.10, the problem page at 
https://errors.ubuntu.com/problem/290470c9cf5f278596966c386aac31e70a49988e 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.

  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 451, in 
  options = parse_arguments()
    File "/usr/share/apport/apport", line 396, in parse_arguments
  parser.print_usage()
    File "/usr/lib/python3.6/argparse.py", line 2370, in print_usage
  self._print_message(self.format_usage(), file)
    File "/usr/lib/python3.6/argparse.py", line 2381, in _print_message
  file.write(message)
  AttributeError: 'NoneType' object has no attribute 'write'

  After working on https://bugs.launchpad.net/apport/+bug/1732962, the error 
tracker started throwing the error above.
  it appears that print_usage is called and throwing an error because in this 
context (called with core_pattern) apport doesn't have an stdout or stderr. 
after looking at traces it seems the kernel is adding 'deleted' to the name of 
the process which cause argument parsing to fail.

  The fix below from bdmurray seems to fix it.
  https://paste.ubuntu.com/p/pVKNP9kWP4/

  There is report of this issue in Focal, Bionic and xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1899195/+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 1899195] Proposed package upload rejected

2020-10-28 Thread Robie Basak
An upload of apport to bionic-proposed has been rejected from the upload
queue for the following reason: "Symlinks appear inadvertently
flattened; for example bin/apport-collect has changed from a symlink to
a flat file.".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1899195

Title:
  
/usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Focal:
  In Progress

Bug description:
  Impact
  --
  apport is crashing for some users when a crash file is created about an 
executable which has been deleted.

  Test Case
  -
  While you won't get a Traceback (because there is a location for apport to 
print its usages message) with the following test case you will see apport 
usage printed:

   $ PYTHONPATH=/home/bdmurray/source-trees/apport/trunk data/apport '8219' 
'11' '0' '1' '8219' '!usr!bin!yes' '(deleted)'
  usage: apport [-h] [-p PID] [-s SIGNAL_NUMBER] [-c CORE_ULIMIT] [-d 
DUMP_MODE] [-P [GLOBAL_PID]]

  With the fixed version of apport you'll see no such usage message.

  Regression Potential
  
  Because new code is being added its possible that the python syntax could be 
bad which would result in another crash, so careful review the code.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu27.10, the problem page at 
https://errors.ubuntu.com/problem/290470c9cf5f278596966c386aac31e70a49988e 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.

  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 451, in 
  options = parse_arguments()
    File "/usr/share/apport/apport", line 396, in parse_arguments
  parser.print_usage()
    File "/usr/lib/python3.6/argparse.py", line 2370, in print_usage
  self._print_message(self.format_usage(), file)
    File "/usr/lib/python3.6/argparse.py", line 2381, in _print_message
  file.write(message)
  AttributeError: 'NoneType' object has no attribute 'write'

  After working on https://bugs.launchpad.net/apport/+bug/1732962, the error 
tracker started throwing the error above.
  it appears that print_usage is called and throwing an error because in this 
context (called with core_pattern) apport doesn't have an stdout or stderr. 
after looking at traces it seems the kernel is adding 'deleted' to the name of 
the process which cause argument parsing to fail.

  The fix below from bdmurray seems to fix it.
  https://paste.ubuntu.com/p/pVKNP9kWP4/

  There is report of this issue in Focal, Bionic and xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1899195/+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 1899195] Proposed package upload rejected

2020-10-28 Thread Robie Basak
An upload of apport to focal-proposed has been rejected from the upload
queue for the following reason: "Symlinks appear inadvertently
flattened; for example bin/apport-collect has changed from a symlink to
a flat file.".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1899195

Title:
  
/usr/share/apport/apport:AttributeError:/usr/share/apport/apport@451:parse_arguments:print_usage:_print_message

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Focal:
  In Progress

Bug description:
  Impact
  --
  apport is crashing for some users when a crash file is created about an 
executable which has been deleted.

  Test Case
  -
  While you won't get a Traceback (because there is a location for apport to 
print its usages message) with the following test case you will see apport 
usage printed:

   $ PYTHONPATH=/home/bdmurray/source-trees/apport/trunk data/apport '8219' 
'11' '0' '1' '8219' '!usr!bin!yes' '(deleted)'
  usage: apport [-h] [-p PID] [-s SIGNAL_NUMBER] [-c CORE_ULIMIT] [-d 
DUMP_MODE] [-P [GLOBAL_PID]]

  With the fixed version of apport you'll see no such usage message.

  Regression Potential
  
  Because new code is being added its possible that the python syntax could be 
bad which would result in another crash, so careful review the code.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu27.10, the problem page at 
https://errors.ubuntu.com/problem/290470c9cf5f278596966c386aac31e70a49988e 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.

  Traceback (most recent call last):
    File "/usr/share/apport/apport", line 451, in 
  options = parse_arguments()
    File "/usr/share/apport/apport", line 396, in parse_arguments
  parser.print_usage()
    File "/usr/lib/python3.6/argparse.py", line 2370, in print_usage
  self._print_message(self.format_usage(), file)
    File "/usr/lib/python3.6/argparse.py", line 2381, in _print_message
  file.write(message)
  AttributeError: 'NoneType' object has no attribute 'write'

  After working on https://bugs.launchpad.net/apport/+bug/1732962, the error 
tracker started throwing the error above.
  it appears that print_usage is called and throwing an error because in this 
context (called with core_pattern) apport doesn't have an stdout or stderr. 
after looking at traces it seems the kernel is adding 'deleted' to the name of 
the process which cause argument parsing to fail.

  The fix below from bdmurray seems to fix it.
  https://paste.ubuntu.com/p/pVKNP9kWP4/

  There is report of this issue in Focal, Bionic and xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1899195/+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 1873678] Re: gnome-language-selector crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.Accounts.Error.Failed: 'C.UTF-8' is not a valid locale name

2020-10-14 Thread Robie Basak
Hello Robert, or anyone else affected,

Accepted accountsservice into focal-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/accountsservice/0.6.55-0ubuntu12~20.04.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: accountsservice (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to accountsservice in Ubuntu.
https://bugs.launchpad.net/bugs/1873678

Title:
  gnome-language-selector crashed with dbus.exceptions.DBusException in
  call_blocking(): org.freedesktop.Accounts.Error.Failed: 'C.UTF-8' is
  not a valid locale name

Status in accountsservice package in Ubuntu:
  Fix Released
Status in accountsservice source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  accountsservice includes a function for checking the validity of
  locales, and it incorrectly considers "C.UTF-8" to be invalid. It
  leads to incorrect behavior under certain conditions and also a crash
  if the function was triggered from language-selector-gnome.

  Even if this only makes a difference in special corner cases, it
  happens often enough to justify this SRU:

  https://errors.ubuntu.com/?release=Ubuntu%2020.04=language-
  selector=year

  (It's the top ranked crash type in the list.)

  The version in focal-proposed fixes the issue.

  [Test case]

  Make a fresh install of Ubuntu 20.04 (a VM works fine)

  Once logged in:

  * Install accountsservice, gir1.2-accountsservice-1.0 and
libaccountsservice0 from focal-proposed

  * Open /etc/default/locale for editing, replace its contents with
the single line:

LANG=C.UTF-8

and reboot.

  Open Language Support and change language (drag any language above
  the "English" item)

  Open ~/.pam_environment and find that e.g. LANG is now the locale
  representing the language you selected, while e.g. LC_TIME is set to
  "C.UTF-8".

  [Regression risk]

  This is a oneliner which white list "C.UTF-8" as a valid locale name.
  I can't think of a case where this would cause unexpected behavior.

  [Original description]

  USB live disk (20.04 beta)

  ProblemType: Crash
  DistroRelease: Ubuntu 20.04
  Package: language-selector-gnome 0.203
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu22
  Architecture: amd64
  CasperVersion: 1.442
  CurrentDesktop: MATE
  Date: Sun Apr 19 17:07:26 2020
  ExecutablePath: /usr/bin/gnome-language-selector
  InterpreterPath: /usr/bin/python3.8
  LiveMediaBuild: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/bin/gnome-language-selector
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu1
  PythonArgs: ['/usr/bin/gnome-language-selector']
  PythonDetails: N/A
  SourcePackage: language-selector
  Title: gnome-language-selector crashed with dbus.exceptions.DBusException in 
call_blocking(): org.freedesktop.Accounts.Error.Failed: 'C.UTF-8' is not a 
valid locale name
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1873678/+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 1895865] Re: /usr/share/apport/dump_acpi_tables.py:PermissionError:/usr/share/apport/dump_acpi_tables.py@59:dump_acpi_tables:dump_acpi_table

2020-10-07 Thread Robie Basak
Hello errors.ubuntu.com, or anyone else affected,

Accepted apport into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu27.10 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Focal)
   Status: Incomplete => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1895865

Title:
  
/usr/share/apport/dump_acpi_tables.py:PermissionError:/usr/share/apport/dump_acpi_tables.py@59:dump_acpi_tables:dump_acpi_table

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  Fix Committed
Status in apport source package in Groovy:
  Fix Released

Bug description:
  Impact
  --
  Users running /usr/share/apport/dump_acpi_tables.py will receive a Traceback 
unless it is called by root.

  Test Case
  -
  1) Run /usr/share/apport/dump_acpi_tables.py
  2) Observe the Traceback in comment #1

  Additionally, running 'ubuntu-bug' about a package which calls
  attach_hardware (which then calls dump_acpi_tables.py) will have a
  Traceback in acpidump.

  1) Run 'ubuntu-bug udev'
  2) Save the report
  3) View the report and see the Traceback from comment #1 in it

  With the version of the package from -proposed you will not receive a
  Traceback in either situation.

  Regression Potential
  
  If the python is bad we could have a different crash.

  Original Description
  
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu45, the problem page at 
https://errors.ubuntu.com/problem/ad705c1a5e4068bcae9d4261519bac8fac5cb57f 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1895865/+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 1895865] Re: /usr/share/apport/dump_acpi_tables.py:PermissionError:/usr/share/apport/dump_acpi_tables.py@59:dump_acpi_tables:dump_acpi_table

2020-10-07 Thread Robie Basak
This needs SRU information please.

I'm also puzzled by comment 2, which doesn't seem to describe the same
issue as the upload in Focal. Did some bug numbers get confused?

** Changed in: apport (Ubuntu Focal)
   Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1895865

Title:
  
/usr/share/apport/dump_acpi_tables.py:PermissionError:/usr/share/apport/dump_acpi_tables.py@59:dump_acpi_tables:dump_acpi_table

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Focal:
  Incomplete
Status in apport source package in Groovy:
  Fix Released

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu45, the problem page at 
https://errors.ubuntu.com/problem/ad705c1a5e4068bcae9d4261519bac8fac5cb57f 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1895865/+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 1896073] Re: SRU the current 2.3.6 stable update

2020-09-23 Thread Robie Basak
** Also affects: tracker (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tracker in Ubuntu.
https://bugs.launchpad.net/bugs/1896073

Title:
  SRU the current 2.3.6 stable update

Status in tracker package in Ubuntu:
  Fix Released
Status in tracker source package in Focal:
  New

Bug description:
  * Impact
  That's the current GNOME stable update, including some fixes and translation 
updates
  https://gitlab.gnome.org/GNOME/tracker/-/blob/tracker-2.3/NEWS

  * Test case

  The update is part of GNOME stable updates
  https://wiki.ubuntu.com/StableReleaseUpdates/GNOME

  Check that file search works correctly from the command line, shell
  and nautilus

  * Regression potential

  There is no specific change or feature to test in that update

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1896073/+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 1894606] Proposed package upload rejected

2020-09-23 Thread Robie Basak
An upload of pulseaudio to focal-proposed has been rejected from the
upload queue for the following reason: "Changes/bug references from 3.7
are missing from the changes file. The ideal way to resolve this would
be to squash 3.7 and 3.8 together and upload as 3.7.".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1894606

Title:
  [SRU] Add profile-set for HP Thunderbolt Dock

Status in HWE Next:
  New
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  In Progress
Status in pulseaudio source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  HP Thunderbolt Dock has a USB audio device provides headset connector 
functionality. The Dock can also attach an optional USB audio module. Since 
they are both USB audio device, the input/output names are the same and it 
confuses user.

  [Fix]
  Add PulseAudio profile-sets for each USB device with different monikers.

  The merge request is already approved by maintainer, will be merged after 
14.0 release:
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/353

  [Test]
  With profile-set applied, two different USB audio device on HP TBT Dock have 
distinctive names.

  [Regression Potential]
  Currently I can't think of any regression risk, as this SRU only adds new 
profile-sets and description translation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1894606/+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 1891632] Re: The network manager does not check the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit

2020-09-23 Thread Robie Basak
Incomplete pending a proper regression analysis.

** Changed in: network-manager (Ubuntu Focal)
   Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1891632

Title:
  The network manager does not check the
  NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE bit

Status in OEM Priority Project:
  New
Status in OEM Priority Project focal series:
  Invalid
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Focal:
  Incomplete

Bug description:
  [Impact]

   In some cases, the wow is not configured and the
  NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE is set (for to disable
  management of wake-on-LAN in NetworkManager).

   The network manager only checks the NM_SETTING_WIRELESS_WAKE_ON_WLAN_NONE 
bit.
   But, the NM_SETTING_WIRELESS_WAKE_ON_WLAN_IGNORE does not be check.
   So, the management of wake-on-LAN still is done by NetworkManager.

  [Test Case]

   On a machine with killer 500s Wi-Fi and install the Qualcomm's driver.
   Step 1. Enter suspend (s2idle)
   Setp 2. Resume from suspend

   After resume from suspend, the Wi-Fi functiall still is normal.

   You can download the kernel and linux-firmware that backport the Qucalcomm's 
dirver fro focal from below link:
   https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1879633

  [Regression Potential]

   * No potential regressions.

  [Other Info]
   
   * None

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1891632/+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 216847] Re: sshd will not start at boot if ListenAddress is set, because network interface is not yet up

2020-09-18 Thread Robie Basak
** Tags added: network-online-ordering

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/216847

Title:
  sshd will not start at boot if ListenAddress is set, because network
  interface is not yet up

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: openssh-server

  The sshd will not start at boot if the ListenAddress option in
  /etc/ssh/sshd_config is set to an IPv4 address other then 0.0.0.0 .

  I am using Ubuntu 7.10 and the version 1:4.6p1-5ubuntu0.2 of the 
openssh-server package.
  I would expect that sshd is started after boot but it will not and I found 
this in /var/log/auth.log:

  sshd[4527]: error: Bind to port 22 on 10.1.1.22 failed: Cannot assign 
requested address.
  sshd[4527]: fatal: Cannot bind any address.

  Once the System is started you can start/stop the sshd with the
  /etc/init.d/ssh script without any problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/216847/+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 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

2020-09-18 Thread Robie Basak
** Tags added: network-online-ordering

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1531184

Title:
  [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

Status in One Hundred Papercuts:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq source package in Xenial:
  Confirmed
Status in dnsmasq source package in Bionic:
  Confirmed
Status in dnsmasq package in Debian:
  New

Bug description:
  [Impact]
  dnsmasq will fail to respond on network devices that weren't up when its
  service started, thus not binding as expected.

  [Test Case]
  TBD

  [Regression Potential]
  The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.

  [Fix]
  Straightforward packaging fix to the service to make it delay startup
  until after the network is online.

  https://bugs.debian.org/cgi-
  bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-
  online.debdiff;msg=22

  [Discussion]

  [Original Report]
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.

  During boot, dnsmasq is started before br-vz0 is created and this
  causes dnsmasq to exit:

  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1689833] Re: OpenVPN server does not start properly on boot

2020-09-18 Thread Robie Basak
** Tags added: network-online-ordering

-- 
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/1689833

Title:
  OpenVPN server does not start properly on boot

Status in openvpn package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  OpenVPN intermittently fails to bind to local address during boot on
  Ubuntu Server 16.04.2 LTS. Sometimes it succeeds, sometimes it does
  not.

  /var/log/openvpn.log
  Wed May 10 15:42:02 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:02 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:02 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:02 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:02 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:02 2017 TCP/UDP: Socket bind failed on local address 
[AF_INET]192.168.4.254:1194: Cannot assign requested address
  Wed May 10 15:42:02 2017 Exiting due to fatal error

  In case it does not start, running 'sudo service openvpn start' fixes
  that problem.

  /var/log/openvpn.log
  Wed May 10 15:42:43 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:43 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:43 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:43 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:43 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:43 2017 ROUTE_GATEWAY 192.168.4.1/255.255.255.0 IFACE=ens4 
HWADDR=52:54:00:f0:26:0c
  Wed May 10 15:42:43 2017 TUN/TAP device tun0 opened
  Wed May 10 15:42:43 2017 TUN/TAP TX queue length set to 100
  Wed May 10 15:42:43 2017 do_ifconfig, tt->ipv6=0, 
tt->did_ifconfig_ipv6_setup=0
  Wed May 10 15:42:43 2017 /sbin/ip link set dev tun0 up mtu 1500
  Wed May 10 15:42:43 2017 /sbin/ip addr add dev tun0 local 172.16.1.1 peer 
172.16.1.2
  Wed May 10 15:42:43 2017 /sbin/ip route add 172.16.1.0/24 via 172.16.1.2
  Wed May 10 15:42:43 2017 GID set to nogroup
  Wed May 10 15:42:43 2017 UID set to nobody
  Wed May 10 15:42:43 2017 UDPv4 link local (bound): [AF_INET]192.168.4.254:1194
  Wed May 10 15:42:43 2017 UDPv4 link remote: [undef]
  Wed May 10 15:42:43 2017 MULTI: multi_init called, r=256 v=256
  Wed May 10 15:42:43 2017 IFCONFIG POOL: base=172.16.1.4 size=62, ipv6=0
  Wed May 10 15:42:43 2017 IFCONFIG POOL LIST
  Wed May 10 15:42:43 2017 Initialization Sequence Completed

  My guess is that systemd starts OpenVPN too early before the network
  is brought up sufficiently. Running 'sudo systemctl edit --full
  openvpn' and adding 'Wants=network-online.target' does not change that
  behaviour.

  user@server:~$ sudo systemd-analyze critical-chain
  graphical.target @2.160s
  └─multi-user.target @2.159s
    └─ntp.service @2.054s +104ms
  └─remote-fs.target @2.052s
    └─remote-fs-pre.target @2.052s
  └─open-iscsi.service @1.993s +57ms
    └─iscsid.service @1.942s +47ms
  └─network-online.target @1.941s
    └─network.target @1.929s
  └─networking.service @1.793s +134ms
    └─apparmor.service @1.140s +395ms
  └─local-fs.target @1.140s
    └─local-fs-pre.target @1.139s
  └─lvm2-monitor.service @602ms +536ms
    └─lvm2-lvmetad.service @773ms
  └─systemd-journald.socket @574ms
    └─-.slice @500ms

  The boot time is quite short. Clean install with the additional
  packages ntp and openssh-server. This happens both on bare metal and
  as a Virtual Machine (KVM) as well.

  /etc/openvpn/server.conf
  local 192.168.4.254
  port 1194
  proto udp
  dev tun
  ca ./easy-rsa/keys/ca.crt
  cert ./easy-rsa/keys/crt.crt
  key ./easy-rsa/keys/key.key
  dh ./easy-rsa/keys/dh2048.pem
  tls-auth ./easy-rsa/keys/ta.key 0
  server 172.16.1.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "route 192.168.0.0 255.255.255.0"
  push "route 192.168.4.0 255.255.255.0"
  keepalive 10 120
 

[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

2020-09-09 Thread Robie Basak
Hello Olivier, or anyone else affected,

Accepted squid3 into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/squid3/3.5.12-1ubuntu7.14 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
xenial to verification-done-xenial. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-xenial. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: squid3 (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1761096

Title:
  dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in squid package in Ubuntu:
  Fix Released
Status in squid3 package in Ubuntu:
  Invalid
Status in dnsmasq source package in Xenial:
  Invalid
Status in squid source package in Xenial:
  Invalid
Status in squid3 source package in Xenial:
  Fix Committed
Status in dnsmasq source package in Bionic:
  Invalid
Status in squid source package in Bionic:
  Invalid
Status in squid3 source package in Bionic:
  Incomplete

Bug description:
  [Impact]

  When using dnsmasq along with squid on Ubuntu Xenial, the user will
  experience a deadlock while performing on every second execution of
  the "systemctl start dnsmasq.service" command.  The deadlock will be
  caused by an attempt to invoke, by nss-lookup.target, a "systemctl
  reload squid.service", which will itself try to start the nss-
  lookup.target, which will be waiting on squid, therefore eventually
  leading to a timeout.

  The underlying cause of this deadlock is related to how systemd used
  to handle dependencies between multiple jobs being started in the same
  transaction.

  [Test Case]

  One can reproduce the issue on a Xenial container:

  $ lxc launch ubuntu-daily:xenial squid-bug1761096
  $ lxc shell squid-bug1761096
  # apt update
  # apt install squid dnsmasq -y

  It is quite possible that during "apt install" the bug will manifest,
  and dnsmasq will fail to start due to a timeout.  The user might see a
  message like:

  Job for dnsmasq.service failed because a timeout was exceeded. See
  "systemctl status dnsmasq.service" and "journalctl -xe" for details.

  If the bug doesn't manifest itself during installation, the following
  commands in sequence should trigger it:

  # systemctl restart dnsmasq.service
  # systemctl restart dnsmasq.service

  [Regression Potential]

  This change only touches the mechanism by which squid has its
  configuration reloaded in case of a DNS resolver change.  Because
  "systemctl reload --no-block" returns practically immediately, if
  squid's configuration file is invalid the user won't see any
  notifications.  However, this behaviour is already present currently,
  because "systemctl reload squid" invokes "/etc/init.d/squid reload";
  the user has to check "journalctl -u squid.service" if she wants to
  verify whether there were any failures during the reload.

  Other than that, and because systemctl will offload the service to the
  SysV script as usual (in the case of squid), I don't foresee any
  potential regressions.

  [Original Description]

  Setup to reproduce:

  Ubuntu Xenial amd64 net install iso from
  http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-
  amd64/current/images/netboot/mini.iso

  Install system with mostly defaults + LVM + OpenSSH server

  Note that this bug applies to both DHCP and static IP+DNS network
  configurations

  Once server rebooted and is available, log in and install dnsmasq + squid:
  apt-get update && apt-get install squid dnsmasq

  output of this can be found at https://pastebin.com/9Atuipju
  journalctl -xe output at https://pastebin.com/uLhfM4jN

  Furthermore at this point I can run alternating errors

  root@ubuntu-min:~# date ; service dnsmasq start ; date
  Wed Apr  4 09:18:07 CEST 2018
  Wed Apr  4 09:18:07 CEST 2018
  root@ubuntu-min:~# 

[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

2020-09-09 Thread Robie Basak
On Xenial the source package is squid3, not squid, so I'll add/adjust
tasks for that so the tracking works correctly.

On Bionic the code suggests that the same problem might exist, but it
appears that nobody has reproduced it there so there is no need for an
SRU to Bionic. However, if somebody is affected then we can look again.
I'll leave an Incomplete task for Bionic to try to highlight that. We
don't have any specific policy or pattern to track this kind of thing so
I'm being inventive with the bug status here.

Excerpts from #ubuntu-devel:

17:32  cpaelzer, sergiodj: in bug 1761096, did you ever find out
why Bionic are unaffected, or did you decide it wasn't worth
investigating further?

17:32  *is*

17:38  rbasak: we could not find exactly why Bionic is not
affected.  my hypothesis is that between Xenial and Bionic there was a
fix on systemd which addressed this issue, but I could not pinpoint
exactly what was done

17:39  arguably, the best scenario would be to backport this
fix to Xenial's systemd, but since we had already spent a non-trivial
amount of time investigating this (without finding anything concrete on
systemd's side), I opted for the second best thing to do, which is to
use --no-block to workaround this bug


** Also affects: squid3 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: squid (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: dnsmasq (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: squid3 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: squid3 (Ubuntu)
   Status: New => Invalid

** Changed in: squid3 (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: squid3 (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: squid3 (Ubuntu Xenial)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: squid (Ubuntu Xenial)
 Assignee: Sergio Durigan Junior (sergiodj) => (unassigned)

** Changed in: squid (Ubuntu Xenial)
   Importance: High => Undecided

** Changed in: squid (Ubuntu Xenial)
   Status: Confirmed => Invalid

** Changed in: squid (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: squid3 (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: dnsmasq (Ubuntu Bionic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1761096

Title:
  dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in squid package in Ubuntu:
  Fix Released
Status in squid3 package in Ubuntu:
  Invalid
Status in dnsmasq source package in Xenial:
  Invalid
Status in squid source package in Xenial:
  Invalid
Status in squid3 source package in Xenial:
  Fix Committed
Status in dnsmasq source package in Bionic:
  Invalid
Status in squid source package in Bionic:
  Invalid
Status in squid3 source package in Bionic:
  Incomplete

Bug description:
  [Impact]

  When using dnsmasq along with squid on Ubuntu Xenial, the user will
  experience a deadlock while performing on every second execution of
  the "systemctl start dnsmasq.service" command.  The deadlock will be
  caused by an attempt to invoke, by nss-lookup.target, a "systemctl
  reload squid.service", which will itself try to start the nss-
  lookup.target, which will be waiting on squid, therefore eventually
  leading to a timeout.

  The underlying cause of this deadlock is related to how systemd used
  to handle dependencies between multiple jobs being started in the same
  transaction.

  [Test Case]

  One can reproduce the issue on a Xenial container:

  $ lxc launch ubuntu-daily:xenial squid-bug1761096
  $ lxc shell squid-bug1761096
  # apt update
  # apt install squid dnsmasq -y

  It is quite possible that during "apt install" the bug will manifest,
  and dnsmasq will fail to start due to a timeout.  The user might see a
  message like:

  Job for dnsmasq.service failed because a timeout was exceeded. See
  "systemctl status dnsmasq.service" and "journalctl -xe" for details.

  If the bug doesn't manifest itself during installation, the following
  commands in sequence should trigger it:

  # systemctl restart dnsmasq.service
  # systemctl restart dnsmasq.service

  [Regression Potential]

  This change only touches the mechanism by which squid has its
  configuration reloaded in case of a DNS resolver change.  Because
  "systemctl reload --no-block" returns practically immediately, if
  squid's configuration file is invalid the user won't see any
  notifications.  However, this behaviour is already present currently,
  because "systemctl reload squid" invokes "/etc/init.d/squid reload";
  the user has to check "journalctl -u squid.service" if she wants to
  verify whether there were any failures during the reload.

  Other than that, and 

[Touch-packages] [Bug 1861451] Re: apport's cloud-init-specific handling tracebacks on minimal cloud images

2020-08-20 Thread Robie Basak
Hello Dan, or anyone else affected,

Accepted apport into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.9-0ubuntu7.17 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1861451

Title:
  apport's cloud-init-specific handling tracebacks on minimal cloud
  images

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Bionic:
  Fix Committed
Status in apport source package in Focal:
  Invalid

Bug description:
  Impact
  --
  It is not possible to run ubuntu-bug for some packages which gather 
information as root because pkexec does not work in non-graphical environments 
(LP: #1821415). This was worked around in Ubuntu 19.10 by not gathering any 
information that would require root access.

  Test Case
  -

  1) Install multipass.
  2) `multipass launch 
http://cloud-images.ubuntu.com/minimal/daily/bionic/current/bionic-minimal-cloudimg-amd64.img
 -n reproducer`
  3) `multipass shell reproducer`
  4) `ubuntu-bug cloud-init`

  Expected behaviour:

  Usual bug reporting flow (though, currently, I would really expect to
  see just the issue reported in bug 1861450).

  Actual behaviour:

  ERROR: hook /usr/share/apport/package-hooks/cloud-init.py crashed:
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
  symb['add_info'](report, ui)
    File "/usr/share/apport/package-hooks/cloud-init.py", line 6, in add_info
  return cloudinit_add_info(report, ui)
    File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 123, in 
add_info
  attach_cloud_init_logs(report, ui)
    File "/usr/lib/python3/dist-packages/cloudinit/apport.py", line 57, in 
attach_cloud_init_logs
  'cloud-init-output.log.txt': 'cat /var/log/cloud-init-output.log'})
    File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 444, in 
attach_root_command_outputs
  sp = subprocess.Popen(_root_command_prefix() + [wrapper_path, 
script_path])
    File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
  restore_signals, start_new_session)
    File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
  raise child_exception_type(errno_num, err_msg, err_filename)
  FileNotFoundError: [Errno 2] No such file or directory: 'pkexec': 'pkexec'

  (As alluded to above, this also demonstrates bug 1861450 after the
  traceback is emitted.)

  Regression Potential
  
  Little as we are just returning and empty list if pkexec is not available, 
however it is always possible that the code is misformated or that there is a 
logic error in it. A regression test would be to run the ubuntu-bug cloud-init 
on a system with pkexec installed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861451/+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 1872059] Re: missing hardware/runtime info when reporing linux-firmware bugs via apport

2020-08-20 Thread Robie Basak
Hello You-Sheng, or anyone else affected,

Accepted apport into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/apport/2.20.9-0ubuntu7.17 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: apport (Ubuntu Bionic)
   Status: New => Fix Committed

** Tags removed: verification-done
** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1872059

Title:
  missing hardware/runtime info when reporing linux-firmware bugs via
  apport

Status in OEM Priority Project:
  Confirmed
Status in apport package in Ubuntu:
  Fix Released
Status in linux-firmware package in Ubuntu:
  Invalid
Status in apport source package in Bionic:
  Fix Committed
Status in linux-firmware source package in Bionic:
  Invalid
Status in linux-firmware source package in Eoan:
  Invalid
Status in apport source package in Focal:
  Fix Released
Status in linux-firmware source package in Focal:
  Invalid

Bug description:
  Updated Description to match SRU requirements for bionic

  [Impact]
  linux-firmware doesn't install any package hooks for apport, so it will only 
carry some default items leaving hardware list, kernel messages unattached. 
Suggest symlink /usr/share/apport/package-hooks/source_linux-firmware.py to 
source_linux.py as other linux image debs do in bug 1847967.

  [Test Case]
  1) On an Ubuntu 18.04 LTS system run 'apport-cli linux-firmware'.
  2) Choose 'View report'
  3) Observe that 'ProcFB' is not collected

  With the version of apport from -proposed 'ProcFB' will be in the
  report.

  
  [Regression Potential]
  Very limited, as we are just adding a symlink from linux-firmware to the 
linux source package hook. this change has been available in Focal and Groovy 
without problem


  Original Description
  
  ProblemType: BugDistroRelease: Ubuntu 20.04
  Package: linux-firmware 1.187
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu26
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Apr 10 19:15:15 2020
  Dependencies:

  InstallationDate: Installed on 2019-09-28 (194 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190923)
  PackageArchitecture: allSourcePackage: linux-firmware
  UpgradeStatus: No upgrade log present (probably fresh install)
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu26
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Dependencies:

  DistroRelease: Ubuntu 20.04
  InstallationDate: Installed on 2019-09-28 (194 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190923)
  MachineType: Apple Inc. MacBookPro11,1
  NonfreeKernelModules: wl
  Package: linux-firmware
  PackageArchitecture: all
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.4.0-21-generic 
root=UUID=38c16714-8883-4c88-baae-df71ffa89972 ro rootflags=subvol=@ quiet 
splash acpi_enforce_resources=lax crashkernel=512M-:192M vt.handoff=7
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-21-generic N/A
   linux-backports-modules-5.4.0-21-generic  N/A
   linux-firmware1.187
  Tags:  focal
  Uname: Linux 5.4.0-21-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm audio cdrom dip docker lpadmin lxd microk8s plugdev 
sambashare sudo video
  _MarkForUpload: True
  dmi.bios.date: 06/13/2019
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: 156.0.0.0.0
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-189A3D4F975D5FFC
  dmi.board.vendor: Apple Inc.
  dmi.board.version: MacBookPro11,1
  

[Touch-packages] [Bug 1891548] Re: autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

2020-08-18 Thread Robie Basak
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

Since this affects an unusual end-user configuration, I'm setting
Importance to Low, and I don't expect anyone to work on this soon.
However if you can help definitively explain what needs adjusting to fix
this correctly, then that would be helpful and we can try to help get
that fix landed. Caveat: normally we'd expect an explanation and patch
to be sent to Debian first.

I'm deferring a decision on whether or not this requires a fix in
openldap until the above is clear.

** Changed in: autofs (Ubuntu)
   Importance: Undecided => Low

** Changed in: openldap (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1891548

Title:
  autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

Status in autofs package in Ubuntu:
  New
Status in openldap package in Ubuntu:
  New

Bug description:
  Ubuntu Release:
  # lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  Version of packages in use:
  # dpkg -l autofs autofs-ldap slapd | grep '^ii'
  ii  autofs 5.1.6-2ubuntu0.1   amd64kernel-based 
automounter for Linux
  ii  autofs-ldap5.1.6-2ubuntu0.1   amd64LDAP map support for 
autofs
  ii  slapd  2.4.49+dfsg-2ubuntu1.3 amd64OpenLDAP server (slapd)

  Expected:
  No errors from slaptest

  Actual Output:
  5f359370 /etc/ldap/schema/autofs.schema: line 14 attributetype: AttributeType 
inappropriate matching rule: "caseExactMatch"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1891548/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-08-12 Thread Robie Basak
Hello Ryan, or anyone else affected,

Accepted bcache-tools into bionic-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/bcache-
tools/1.0.8-2ubuntu0.18.04.1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: bcache-tools (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-bionic

-- 
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/1861941

Title:
  bcache by-uuid links disappear after mounting bcache0

Status in bcache-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in bcache-tools source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Won't Fix
Status in bcache-tools source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  SRU TEAM: The last 2 commits show a summary for the merges/changes
  I added some specific (to Bionic) notes in the template.
  Thanks!

  [Impact]

   * bcache-tools udev created symlinks might disappear when other udev
  events are processed for the same devices.

   * after mkfs.XXX in /dev/bcacheY you might face a condition where
  /dev/bcache/by-{uuid,label}/zzz symlinks are gone.

   * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache
  devices can be addressed by their UUIDs and not the ordering they were
  assembled (MAAS depends on this feature, for example).

   * it was also discussed in this bug that systemd-udev should *not*
  populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
  backing devices. this was turned into a discussion whether blkid
  should report those or not, and this discussion "died" after sometime.
  This last item is what the systemd update is all about: to disallow
  /dev/disk/by-XXX/ creation for bcache backing devices (a simple
  change that will reduce end users confusion).

  [Test Case]

   * The reproducer script is here:

     https://paste.ubuntu.com/p/37KGy2Smnp/

   * Bionic can't reproduce the issue with the 18.04 kernel, nor with
  the HWE kernel. Nevertheless, it is preferable that Bionic also do the
  same thing: to read bcache superblock and feed environment for
  /dev/bcache/by-{uuid,label} symlinks creation.

  [Regression Potential]

   * We are not depending on bcache device udev events any more when
  creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
  depending on a wrapper script that heads bcache device superblock. If
  there is a bug in this wrapper the symlinks wouldn't work.

   * Previously we were thinking in asking the kernel team to remove the
  bcache udev event delta script they've done for previous case (LP:
  #1729145). It creates the udev events that were being read and filling
  the symlinks. We decided not to remove those (just from Groovy and on)
  so we don't need to worry on Breaks/Conflicts in between the kernel
  package and bcache-tools (and udev)).

   * Long story short: kernel will continue to emit bcache udev events
  as it did previously but now those events won't be used by anything -
  after installing this SRU - because udev wrapper script is doing this
  job (and doing it properly)

  [Other Info]

  - Original Description:

  1.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04
  root@ubuntu:~# apt-cache policy linux-image-virtual
  linux-image-virtual:
    Installed: 5.4.0.12.15
    Candidate: 5.4.0.12.15
    Version table:
   *** 5.4.0.12.15 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  root@ubuntu:~# apt-cache policy 

[Touch-packages] [Bug 304393] Re: rpcbind grabs ports used by other daemons such as cupsd

2020-08-12 Thread Robie Basak
The Ubuntu Xenial SRU looks fine in principle but is currently blocked
until the previous SRU is released. I've not reviewed this in detail
yet.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/304393

Title:
  rpcbind grabs ports used by other daemons such as cupsd

Status in cups package in Ubuntu:
  Invalid
Status in rpcbind package in Ubuntu:
  Fix Released
Status in rpcbind source package in Xenial:
  In Progress
Status in rpcbind source package in Bionic:
  Fix Committed
Status in rpcbind package in Debian:
  Fix Released
Status in Fedora:
  Confirmed

Bug description:
  [impact]

  rpcbind binds to a 'random' reserved port at startup, which can
  conflict with the reserved port number for other applications that
  actually 'own' the reserved port number. One example is cups, which
  uses the reserved port 631.

  This prevents the actual 'owner' of the reserved port from starting,
  since it can't bind to its reserved port.

  Additionally, this can raise alarms from security monitoring software
  that does not expect programs to be listening on random reserved
  ports.

  [test case]

  start rpcbind and check which ports it is listening on, e.g.:

  $ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc
  udp0  0 0.0.0.0:614 0.0.0.0:* 
  4678/rpcbind

  each time rpcbind is restarted, it will be listening to a different
  'random' port.

  [regression potential]

  this adds a way to disable rpcbind from listening to the 'random'
  port. any regression would likely prevent rpcbind from starting, or
  may cause problems with the interaction between rpcinfo and rpcbind,
  as rpcinfo may use the random reserved port in some cases, as detailed
  in the Debian bug.

  [scope]

  This is needed only for Bionic and earlier.

  In Focal and later, and in Debian, rpcbind defaults to not opening the
  random reserved port.  The admin can use the -r parameter to cause
  rpcbind to restore the old behavior of opening the random reserved
  port.

  [other info]

  Note that the -r parameter is a Debian addition, and the upstream
  rpcbind has disabled the random port functionality at build time;
  there is no runtime parameter to allow the admin to choose the
  behavior.

  Also, as discussed in the Debian bug, disabling this rpcbind 'feature'
  is known to cause problems for the rpcinfo program, which is why
  Debian introduced the -r parameter. So, when this -r parameter is
  backported to Bionic and earlier, we must retain the default behavior
  for those releases, which is for rpcbind to open the random reserved
  port.

  Thus, the patch for this will first backport the upstream patch that adds 
functionality to be able to disable the 'remote calls' function, and also 
backports the debian patch to change that from a compile-time to run-time 
option. Then, another patch is added, which changes the default back to the 
behavior of x/b, which is for remote calls to be enabled by default,
  and also adds a check for the existence of an environment variable 
"RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change 
the default to disabled.

  This allows 1) retaining the existing default behavior of rpcbind in x
  and b, while also 2) providing a mechanism to change that default for
  anyone who does *not* want remote calls to be enabled, and 3) allowing
  the mechanism to change the default to remain in place after an
  upgrade to Focal. Using the environment variable allows anyone to
  disable the remote calls in x and/or b, and then upgrade to Focal
  without breaking rpcbind or needing to remove the env var. After the
  upgrade to Focal, the environment variable (defined in
  /etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored
  without any change needed to the rpcbind package in Focal or later.

  [original description]

  Binary package hint: cups

  cups 1.3.9-2ubuntu4
  From /var/log/cups/error_log:
  cups: unable to bind socket for address 127.0.0.1:631 - Address already in 
use.

  Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd
  when started.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+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 1876018] Re: 40-vm-hotadd.rules attempts to set non-existent sysfs parameters

2020-07-15 Thread Robie Basak
Hello Jose, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.2 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
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/1876018

Title:
  40-vm-hotadd.rules attempts to set non-existent sysfs parameters

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  40-vm-hotadd.rules unconditionally tries onlining memory, which
  results in logged error messages if the memory is already online

  [test case]

  since this rules file restricts operation to only hyper-v or xen
  guests, boot a hyper-v or xen vm guest, and check for logged error
  msgs like:

  Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
  /usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
  ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
  argument

  alternately, to test on a vm guest other than hyper-v or xen,
  comment/remove the 'GOTO="vm_hotadd_end"' line from the rules file and
  reboot.

  [regression potential]

  as this adds a check before attempting to online memory for hyper-v
  and xen vm guests, any regression would likely involve failure to
  correctly online all memory on those guest platforms.

  [scope]

  this rule has been around for a long time, so is needed for x/b/f/g.

  [original description]

  In focal, udev's 40-vm-hotadd.rules (from debian/extra/rules-ubuntu)
  tries to write to invalid (as of 5.4.0-1010-azure) sysfs nodes
  resulting in warnings such as:

  Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
  /usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
  ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
  argument

  Perhaps 40-vm-hotadd.rules needs to be updated for 5.4 semantics,
  removed, or something else. This behavior is present on systems
  upgraded from 18.04 (via d-r-u) as well as new focal systems, upon
  first reboot of the VM.

  udev: 245.4-4ubuntu3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876018/+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 1838329] Re: Cryptswap periodically fails to mount at boot due to missing a udev notification

2020-07-15 Thread Robie Basak
Hello Michael, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.2 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
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/1838329

Title:
  Cryptswap periodically fails to mount at boot due to missing a udev
  notification

Status in systemd:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  New

Bug description:
  [impact]

  systems using cryptsetup-based encrypted swap may hang during boot due
  to udevd missing the notification that swap has been setup on the
  newly created swap device.

  [test case]

  see original description, and reproduction is intermittent based on
  timing

  [regression potential]

  any regression would likely occur during, or after, boot when creating
  an encrypted swap device and/or while waiting to activate the new swap
  device. Regressions may cause failure to correctly enable swap and/or
  hung boot waiting for the swap device.

  [scope]

  this was (potentially) fixed upstream with PR 15836, which is not yet
  included in any upstream release, so this is needed in all releases,
  including groovy.

  also note while the upstream bug is closed, and code review seems to
  indicate this *should* fix this specific issue, there are some
  comments in the upstream bug indicating it may not completely solve
  the problem, although there is no further debug of the new reports.

  [original description]

  On some systems, cryptsetup-based encrypted swap partitions cause
  systemd to get stuck at boot. This is a timing-sensitive Heisenbug, so
  the rate of occurrence varies from one system to another. Some
  hardware will not experience the issue at all, others will only
  occasionally experience the issue, and then there are the unlucky who
  are unable to boot at all, no matter how many times they restart.

  The workaround is for the cryptsetup-generator to generate cryptswap
  service entries that call `udevadm trigger` after `mkswap`. This will
  ensure that the udev event is triggered, so that systemd is notified
  that the encrypt swap partition is ready to activate. This patch has
  already been submitted upstream to systemd, but it was not accepted
  because it is a workaround for the side effect of systemd not seeing
  the udev event upon creating the swap partition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1838329/+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 1875708] Re: Truncated messages in journald since systemd v244

2020-07-15 Thread Robie Basak
Hello Laurent, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.2 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
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/1875708

Title:
  Truncated messages in journald since systemd v244

Status in libvirt package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in libvirt source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Fix Committed
Status in libvirt source package in Groovy:
  Invalid
Status in systemd source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * since 09d0b46a "journal: refresh cached credentials of stdout streams"
 in ~244 output may be trincated.

   * Upstream has a fix in https://github.com/systemd/systemd/pull/15685

   * Backporting the fix will avoid truncation of log output to journald

  [Test Case]

   * This could happen in any case, but is more likely when a program that 
 has output going to journald is spawning short-lived sub-programs often.
 Therefore the test emphasizes on that:

 - Use a test service like /etc/systemd/system/test.service:
  [Unit]
  Description=Test Truncate
  After=network.target

  [Service]
  ExecStart=/usr/lib/test.sh long-test-for-start
  ExecStop=/usr/lib/test.sh long-test-for-stop
  Type=oneshot
  RemainAfterExit=yes
  StandardOutput=journal+console
  TimeoutStopSec=0

  [Install]
  WantedBy=multi-user.target

 - And a test script like /usr/lib/test.sh:
  #!/bin/sh
  gettext "This will"
  echo
  gettext "usually fail"
  echo
  gettext "and be truncated"
  echo 

  Start/Stopping that service without the fix will look like:
  Apr 30 18:56:40 f systemd[1]: Stopping Test Truncate...
  Apr 30 18:56:40 f test.sh[1165]: T
  Apr 30 18:56:40 f test.sh[1167]: T
  Apr 30 18:56:40 f test.sh[1167]: sually fai
  Apr 30 18:56:40 f test.sh[1165]: s
  Apr 30 18:56:40 f test.sh[1168]: s
  Apr 30 18:56:40 f test.sh[1168]: nd be truncate
  Apr 30 18:56:40 f test.sh[1165]: n
  Apr 30 18:56:40 f systemd[1]: test.service: Succeeded.
  Apr 30 18:56:40 f systemd[1]: Stopped Test Truncate.

  
  [Regression Potential] 

   * The patches are rather small, but there might be a slightly increased 
 memory consumption of journald for output buffers. 
   * Issues (if any and I couldn't find any so far) should be only to 
 journald output handling. Systemd is huge, this at least narrows
 down the potential places of a regression a lot.

  [Other Info]
   
   * n/a

  --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

  Originally reported against libvirt which happens to be one of the
  example-triggers

  Hi,

  when I shut down my machine I see messages from /usr/lib/libvirt
  /libvirt-guests.sh but there are 2 anomalies:

   - 3 libvirt-guests.sh processes are run
   - messages are truncated

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libvirt-daemon 6.0.0-0ubuntu8
  Uname: Linux 5.6.7-050607-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Tue Apr 28 19:42:56 2020
  SourcePackage: libvirt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 

  1   2   3   4   5   6   7   8   9   10   >