[Touch-packages] [Bug 1966886] Re: ssh-copy-id and Dropbear Server

2022-05-18 Thread Sergio Durigan Junior
Thanks for the further clarification.

We don't carry delta for openssh in Ubuntu, and since this is a low
priority bug it should really be reported against the Debian openssh
package.  Could you please file a bug there and post its link here?

Thanks.

** Tags removed: server-todo

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

Title:
  ssh-copy-id and Dropbear Server

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  on Dropbear SSH Servers ssh-copy-id installs the key in
  /etc/dropbear/authorized_keys

  only the openwrt dropbear server uses that path
  
https://github.com/openwrt/openwrt/blob/2211ee0037764e1c6b1576fe7a0975722cd4acdc/package/network/services/dropbear/patches/100-pubkey_path.patch

  the upstream dropbear server uses the normal path
  ~/.ssh/authorized_keys

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1966886/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-05-11 Thread Sergio Durigan Junior
FWIW, I've also retriggered the tests marked as OLD_NEUTRAL.  It should
take a while until everything runs.

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Fix Committed
Status in openssh source package in Focal:
  Fix Committed
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When using "ssh-keygen -R" to remove a host from "known_hosts" the
  command changes permissions on the file.  This can cause problems
  particularly when used on the global "known_hosts" file
  (/etc/ssh/ssh_known_hosts), because then only root can read it.
  Programs running non-interactively as non-root users suddenly fail to
  SSH and it's not immediately obvious why.

  [Test Plan]

  The problem happens on Bionic and Focal.

  $ lxc launch ubuntu-daily:focal openssh-bug1966591
  $ lxc shell openssh-bug1966591
  # ssh-keyscan github.com > test_known_hosts
  # chmod 644 test_known_hosts
  # ssh-keygen -R github.com -f test_known_hosts
  # stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  ...

  [Where problems could occur]

  The upstream patch is very simple and it is unlikely that it will
  cause any regressions.  An indirect problem that could occur is that
  users might expect to see a more strict set of permissions on a
  "known_hosts" file after using "ssh-keygen -R", but arguably this is
  not defined behaviour and should not be relied upon.  Of course, there
  is always a (very) small risk of introducing problems when rebuilding
  packages using newer versions of its dependencies (especially on
  Bionic, because it's older).

  [Original Description]

  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
    Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1966591/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-05-11 Thread Sergio Durigan Junior
The Impish failure passed with a retrigger, as expected.

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Fix Committed
Status in openssh source package in Focal:
  Fix Committed
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When using "ssh-keygen -R" to remove a host from "known_hosts" the
  command changes permissions on the file.  This can cause problems
  particularly when used on the global "known_hosts" file
  (/etc/ssh/ssh_known_hosts), because then only root can read it.
  Programs running non-interactively as non-root users suddenly fail to
  SSH and it's not immediately obvious why.

  [Test Plan]

  The problem happens on Bionic and Focal.

  $ lxc launch ubuntu-daily:focal openssh-bug1966591
  $ lxc shell openssh-bug1966591
  # ssh-keyscan github.com > test_known_hosts
  # chmod 644 test_known_hosts
  # ssh-keygen -R github.com -f test_known_hosts
  # stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  ...

  [Where problems could occur]

  The upstream patch is very simple and it is unlikely that it will
  cause any regressions.  An indirect problem that could occur is that
  users might expect to see a more strict set of permissions on a
  "known_hosts" file after using "ssh-keygen -R", but arguably this is
  not defined behaviour and should not be relied upon.  Of course, there
  is always a (very) small risk of introducing problems when rebuilding
  packages using newer versions of its dependencies (especially on
  Bionic, because it's older).

  [Original Description]

  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
    Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1966591/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-05-11 Thread Sergio Durigan Junior
Sorry about that.

There are not failures on Focal, but there were a bunch of old passes,
so I've retriggered them.

I'm investigating what's happening with the Impish one.

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Fix Committed
Status in openssh source package in Focal:
  Fix Committed
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When using "ssh-keygen -R" to remove a host from "known_hosts" the
  command changes permissions on the file.  This can cause problems
  particularly when used on the global "known_hosts" file
  (/etc/ssh/ssh_known_hosts), because then only root can read it.
  Programs running non-interactively as non-root users suddenly fail to
  SSH and it's not immediately obvious why.

  [Test Plan]

  The problem happens on Bionic and Focal.

  $ lxc launch ubuntu-daily:focal openssh-bug1966591
  $ lxc shell openssh-bug1966591
  # ssh-keyscan github.com > test_known_hosts
  # chmod 644 test_known_hosts
  # ssh-keygen -R github.com -f test_known_hosts
  # stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  ...

  [Where problems could occur]

  The upstream patch is very simple and it is unlikely that it will
  cause any regressions.  An indirect problem that could occur is that
  users might expect to see a more strict set of permissions on a
  "known_hosts" file after using "ssh-keygen -R", but arguably this is
  not defined behaviour and should not be relied upon.  Of course, there
  is always a (very) small risk of introducing problems when rebuilding
  packages using newer versions of its dependencies (especially on
  Bionic, because it's older).

  [Original Description]

  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
    Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1966591/+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 1971888] Re: Can not ssh to github.com or gitlab.com when upgrading to 22.04

2022-05-11 Thread Sergio Durigan Junior
Good catch, Seth :-).

Apparently this topic has been discussed in the past in bug #1822370 and
https://lists.debian.org/debian-devel/2019/04/msg00010.html.  Those
discussions resulted in the decision to revert the IPQoS default values
from openssh, which is something we're still doing.  The default value
for Debian/Ubuntu packages is "lowdelay", which, from what you said
above, seems to be what's causing the problem for you.

This can be caused by how your router is handling QoS packets, for
example.  Either way, could you test this using a Debian testing
container/VM and check if you can reproduce the issue there?  If yes,
then I would suggest opening a bug against the Debian openssh package,
which is the best way to implement/discuss this decision IMHO.  If you
do so, please link the Debian bug here so that we can also keep track of
its progress.

Thanks.

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

Title:
  Can not ssh to github.com or gitlab.com when upgrading to 22.04

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Dear all,

  After the upgrading to Ubuntu 22.04 I can not use git over ssh.

  The best way to reproduce the error is:

  ```
  acs@lsp-022:~$ ssh -vT g...@github.com
  OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to github.com [140.82.121.4] port 22.
  debug1: connect to address 140.82.121.4 port 22: Connection timed out
  ```

  Before the upgrading I can connect correctly with:

  ```
  ssh -vT g...@github.com
  OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 23: Applying options for *
  debug1: Connecting to github.com [140.82.121.4] port 22.
  debug1: Connection established
  ```

  The same issue is happening with gitlab.com.

  Probably it is related with the OpenSSL version.

  Cheers!

  -- Alvaro

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: ssh 1:8.9p1-3
  ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
  Uname: Linux 5.15.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: GNOME
  Date: Thu May  5 23:00:33 2022
  InstallationDate: Installed on 2021-03-08 (423 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  SourcePackage: openssh
  UpgradeStatus: Upgraded to jammy on 2022-05-05 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1971888/+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 1971305] Re: Merge openldap from Debian unstable for kinetic

2022-05-04 Thread Sergio Durigan Junior
** Changed in: openldap (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  Merge openldap from Debian unstable for kinetic

Status in openldap package in Ubuntu:
  New

Bug description:
  Upstream: tbd
  Debian:   2.5.11+dfsg-1
  Ubuntu:   2.5.11+dfsg-1~exp1ubuntu3


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  openldap (2.5.11+dfsg-1) unstable; urgency=medium

* Upload to unstable.

   -- Ryan Tandy   Fri, 11 Mar 2022 19:38:02 -0800

  openldap (2.5.11+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Add openssl to Build-Depends to enable more checks in test067-tls.
* Update slapd-contrib's custom-library-search-path override to work with
  current Lintian.

   -- Ryan Tandy   Sun, 23 Jan 2022 17:16:05 -0800

  openldap (2.5.8+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Update slapd-contrib's custom-library-search-path override to work with
  Lintian 2.108.0.

   -- Ryan Tandy   Wed, 13 Oct 2021 18:42:55 -0700

  openldap (2.5.7+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
* Don't run autoreconf in contrib/ldapc++. We don't build it, and it is not
  yet compatible with autoconf 2.71. (Closes: #993032)
* Stop disabling automake in debian/rules now that upstream removed the
  AM_INIT_AUTOMAKE invocation.
* Drop custom config.{guess,sub} handling. dh_update_autotools_config does
  the right thing for us.
* Update Standards-Version to 4.6.0; no changes required.
* debian/not-installed: Add the ldapvc.1 man page.

   -- Ryan Tandy   Mon, 30 Aug 2021 18:54:25 -0700

  openldap (2.5.6+dfsg-1~exp1) experimental; urgency=medium

[ Ryan Tandy ]
* New upstream release.
* Export the cn=config database to LDIF format before upgrading from 2.4.
* slapd.README.Debian:
  - Remove text about the dropped evolution-ntlm patch.
  - Add guidance for recovering from upgrade failures.
* Remove the debconf warning and README text about the unsafe ACL configured
  by default in versions before jessie.
* Remove upgrade code for adding the pwdMaxRecordedFailure attribute to the
  ppolicy schema. It's obsolete since the schema has been internalized.

    [ Sergio Durigan Junior ]
* Implement the 'escape hatch' mechanism.
  - d/po/*.po: Update PO files given the new template note.
  - d/po/templates.pot: Update file.
  - d/slapd.templates: Add note warning user about a postinst failure,
its possible cause and what to do.
  - d/slapd.postinst: Make certain upgrade functions return failure
instead of exiting, which allows the postinst script to gracefully
fail when applicable.  Also, when the general configuration upgrade
fails, display a critical warning to the user.  Implement
ignore_init_failure function.
  - d/slapd.prerm: Implement ignore_init_failure function.
  - d/slapd.scripts-common: Make certain functions return failure
instead of exiting.
  - d/rules: Use dh_installinit's --error-handler to instruct it on how
to handle possible errors with the init script.
  - d/slapd.NEWS: Add excerpt mentioning that the postinst script might
error out if it can't migrate the existing (old) database backend.

   -- Ryan Tandy   Mon, 16 Aug 2021 18:32:29 -0700

  openldap (2.5.5+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
  - Drop patches applied upstream: ITS#9544, ITS#9548.
* Mark slapd-contrib as breaking the old version of slapd to reduce the
  chance of upgrade failure due to slapd-contrib being unpacked first.

   -- Ryan Tandy   Fri, 11 Jun 2021 11:43:15 -0700

  openldap (2.5.4+dfsg-1~exp1) experimental; urgency=medium

* New upstream release.
  - Changing olcAuthzRegexp dynamically is supported. (Closes: #761407)
  - Support for LANMAN password hashes has been removed. (Closes: #988033)
  - Added pkg-config files for liblber and libldap. (Closes: #670824)
  - libldap_r has been merged into libldap. The Debian package will continue
to install a libldap_r.so symlink for backwards compatibility with
applications that still link with -lldap_r.
  - The Berkeley DB backends, slapd-bdb(5) and slapd-hdb(5), have been
removed.
  - The shell backend, slapd-shell(5), has been removed.
  - New backend: slapd-asyncmeta(5).
  - New core overlays: slapd-homedir(5), slapd-otp(5), and
slapd-remoteauth(5).
  - The ppolicy schema has been merged into the slapo-ppolicy(5) module.
  - The arg

[Touch-packages] [Bug 1971319] Re: Merge rsync from Debian unstable for kinetic

2022-05-04 Thread Sergio Durigan Junior
** Changed in: rsync (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  Merge rsync from Debian unstable for kinetic

Status in rsync package in Ubuntu:
  New

Bug description:
  Upstream: tbd
  Debian:   3.2.4-1
  Ubuntu:   3.2.3-8ubuntu3


  Debian does new releases regularly, so it's likely there will be newer
  versions available before FF that we can pick up if this merge is done
  later in the cycle.

  
  ### New Debian Changes ###

  rsync (3.2.4-1) unstable; urgency=medium

[ Samuel Henrique ]
* New upstream version 3.2.4
  - Work around a glibc bug where lchmod() breaks in a chroot w/o /proc
mounted (closes: #995046).
  - rsync.1: remove prepended backticks which broke --stop-after and
--stop-at formatting (closes: #1007990).
* Ship new python-based rrsync with --with-rrsync:
  - rrsync was previouysly written in bash.
  - A manpage is now shipped for rrsync.
  - python3 and python3-cmarkgfm are new B-Ds since they're needed
to generate the manpage.
* d/control:
  - Add version requirement for some libxxhash-dev and libzstd-dev as
per upstream docs.
  - Add python3-braceexpand to Suggests as it can be used by rrsync.
* d/rsync.install: cull_options has been renamed to cull-options.
* d/patches:
  - Refresh the following patches:
~ disable_reconfigure_req.diff;
~ perl_shebang.patch;
~ skip_devices_test.patch;
  - Drop the following patches, applied upstream now:
~ CVE-2020-14387.patch;
~ copy-devices.diff;
~ fix_delay_updates.patch;
~ fix_ftcbfs_configure.patch;
~ fix_mkpath.patch;
~ fix_rsync-ssl_RSYNC_SSL_CERT_feature.patch;
~ fix_sparse_inplace.patch;
~ manpage_upstream_fixes.patch;
~ update_rrsync_options.patch;
~ workaround_glibc_lchmod_regression.patch;

    [ Sergio Durigan Junior ]
* d/rules: Disable ASM optimizations when building.
  This is not needed because the only ASM-optimized implementation
  available is the MD5 hash, which is actually a no-op because we link
  against OpenSSL and rsync ends up using that library's implementation
  of the hash.  Even then, the final binary ends up with the
  ASM-optimized version included, which makes it become
  CET-incompatible.
  Thanks to Dimitri John Ledkov 

   -- Samuel Henrique   Mon, 18 Apr 2022 14:44:44
  +0100

  rsync (3.2.3-8) unstable; urgency=medium

* debian/patches:
  - manpage_upstream_fixes.patch: Import multiple upstream patches to fix
manpage.
  - copy-devices.diff: Add missing manpage changes to patch
  - CVE-2020-14387.patch: Add Forwarded DEP3 field to point to upstream 
patch
  - fix_delay_updates.patch: Refresh patch
  - fix_mkpath.patch: New upstream patch to fix an edge case on --mkpath
  - fix_rsync-ssl_RSYNC_SSL_CERT_feature.patch: New upstream patch
  - fix_sparse_inplace.patch: New upstream patch to fix --sparse + --inplace
options
  - update_rrsync_options.patch: New upstream patch to update rrsync options

   -- Samuel Henrique   Sat, 25 Sep 2021 17:38:16
  +0100

  rsync (3.2.3-7) unstable; urgency=medium

* Bump Standards-Version to 4.6.0
* d/p/workaround_glibc_lchmod_regression.patch: New patch from upstream
  (closes: #994543)
* debian/rsync.NEWS: Fix typo in last entry

   -- Samuel Henrique   Sat, 18 Sep 2021 00:25:13
  +0100

  rsync (3.2.3-6) unstable; urgency=medium

* d/t/upstream-tests: Suppress stderr warnings from the build
  process

   -- Samuel Henrique   Sun, 12 Sep 2021 18:22:57
  +0100

  rsync (3.2.3-5) unstable; urgency=medium

[ 刘建强 ]
* Set the rsync.service not to start automatically after installation,
  the rsyncd.conf configuration file needs to be configured by the user
  before the service can start

[ Samuel Henrique ]
* Re-add upstream patch for --copy-devices, the --write-devices option is
  not fully equivalent (closes: #992215)
* d/rsync.docs: Add NEWS.md file (previously named NEWS) (closes: #993697)
* d/p/fix_delay_updates.patch: New patch from upstream (closes: #992231)

   -- Samuel Henrique   Sun, 12 Sep 2021 17:25:37
  +0100

  rsync (3.2.3-4) unstable; urgency=medium

[ Helmut Grohne ]
* d/p/fix_ftcbfs_configure.patch: New patch to fix FTCBFS (closes: #971285)

[ Samuel Henrique ]
* Bump Standards-Version to 4.5.1


  ### Old Ubuntu Delta ###

  rsync (3.2.3-8ubuntu3) jammy; urgency=high

* No change rebuild for ppc64el baseline bump.

   -- Julian Andres Klode   Fri, 25 Mar 2022
  10:51:06 +0100

  rsync (3.2.3-8ubuntu2) jammy; urgency=medium

* No-change rebuild against openssl3

   -- Simon Chopin   Wed,

[Touch-packages] [Bug 1970979] Re: compiler flags leaking through krb5-config --libs

2022-05-02 Thread Sergio Durigan Junior
I'm marking this bug as Triaged and subscribing ubuntu-server to it just
to follow our triaging procedure.

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

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

Title:
  compiler flags leaking through krb5-config --libs

Status in krb5 package in Ubuntu:
  Triaged

Bug description:
  krb5-config --libs is leaking some compiler specific flags that we
  define in Ubuntu:

  $ krb5-config --libs 
  -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions -flto=auto 
-ffat-lto-objects -flto=auto -Wl,-z,relro -lkrb5 -lk5crypto -lcom_err

  That ones that concern me more specifically are:
  - -Wl,-Bsymbolic-functions
  - -lto related ones

  I'm unsure if -Wl,-z,relro should be there either.

  It looks like LDFLAGS got mixed with LIBS. pkg-config's output is
  different and only contains the libraries and library path:

  $ pkg-config --libs krb5
  -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lkrb5 -lk5crypto -lcom_err

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-04-13 Thread Sergio Durigan Junior
Verification for Focal:

First, verifying that the bug manifests with the current package:

# apt policy openssh-client
openssh-client:
  Installed: 1:8.2p1-4ubuntu0.4
  Candidate: 1:8.2p1-4ubuntu0.4
  Version table:
 *** 1:8.2p1-4ubuntu0.4 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
100 /var/lib/dpkg/status
 1:8.2p1-4ubuntu0.2 500
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
 1:8.2p1-4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
# ssh-keygen -R github.com -f test_known_hosts
# Host github.com found: line 1
# Host github.com found: line 2
# Host github.com found: line 3
test_known_hosts updated.
Original contents retained as test_known_hosts.old
# stat test_known_hosts | grep ^Access
Access: (0600/-rw---)  Uid: (0/root)   Gid: (0/root)
Access: 2022-04-13 21:54:40.698183232 +

Now, enabling -proposed and verifying that the new package fixes the
bug:

# apt policy openssh-client
openssh-client:
  Installed: 1:8.2p1-4ubuntu0.5
  Candidate: 1:8.2p1-4ubuntu0.5
  Version table:
 *** 1:8.2p1-4ubuntu0.5 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 1:8.2p1-4ubuntu0.4 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
 1:8.2p1-4ubuntu0.2 500
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
 1:8.2p1-4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
# ssh-keygen -R github.com -f test_known_hosts
# Host github.com found: line 1
# Host github.com found: line 2
# Host github.com found: line 3
test_known_hosts updated.
Original contents retained as test_known_hosts.old
# stat test_known_hosts | grep ^Access
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2022-04-13 21:57:25.676987718 +


The bug has been fixed.

** Tags removed: server-todo verification-needed verification-needed-focal
** Tags added: verification-done-focal

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Fix Committed
Status in openssh source package in Focal:
  Fix Committed
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When using "ssh-keygen -R" to remove a host from "known_hosts" the
  command changes permissions on the file.  This can cause problems
  particularly when used on the global "known_hosts" file
  (/etc/ssh/ssh_known_hosts), because then only root can read it.
  Programs running non-interactively as non-root users suddenly fail to
  SSH and it's not immediately obvious why.

  [Test Plan]

  The problem happens on Bionic and Focal.

  $ lxc launch ubuntu-daily:focal openssh-bug1966591
  $ lxc shell openssh-bug1966591
  # ssh-keyscan github.com > test_known_hosts
  # chmod 644 test_known_hosts
  # ssh-keygen -R github.com -f test_known_hosts
  # stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  ...

  [Where problems could occur]

  The upstream patch is very simple and it is unlikely that it will
  cause any regressions.  An indirect problem that could occur is that
  users might expect to see a more strict set of permissions on a
  "known_hosts" file after using "ssh-keygen -R", but arguably this is
  not defined behaviour and should not be relied upon.  Of course, there
  is always a (very) small risk of introducing problems when rebuilding
  packages using newer versions of its dependencies (especially on
  Bionic, because it's older).

  [Original Description]

  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
    Installed: 1:7.6p1-4ubuntu0.6

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


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

[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2022-04-13 Thread Sergio Durigan Junior
I still haven't been able to sit down and work on this issue.  My
comment #31 still applies, though.

I think I have deleted the PPA by mistake.  I can recreate it and
reupload the package, but I'm not making any promises to maintain the
PPA nor to backport security fixes; it's just a workaround.  Let me know
if you'd like that.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Bionic:
  Triaged

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1874257] Re: SSH fails with connection timed out - in VPN and hangs here "expecting SSH2_MSG_KEX_ECDH_REPLY" + Ubuntu 16.04.6 LTS

2022-04-13 Thread Sergio Durigan Junior
Ubuntu Xenial has reached end of standard support, so I marked its task
as Won't Fix.

** Changed in: openconnect (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

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

Title:
  SSH fails with connection timed out - in VPN and hangs here "expecting
  SSH2_MSG_KEX_ECDH_REPLY" + Ubuntu 16.04.6 LTS

Status in linux package in Ubuntu:
  Invalid
Status in openconnect package in Ubuntu:
  Fix Released
Status in openssh package in Ubuntu:
  Invalid
Status in openconnect source package in Xenial:
  Won't Fix

Bug description:
  Hello Team,

  SSH timeout issue, once connect to VPN.

  Environment

  ==
  Dell XPS 9570 
  Ubuntu 16.04.6 Xenial Xerus)
  kernel - 4.15.0-55-generic

  $dpkg -l | grep -i openssh
  ii  openssh-client 1:7.2p2-4ubuntu2.8  --> 
  ii  openssh-server 1:7.2p2-4ubuntu2.8  
  ii  openssh-sftp-server  1:7.2p2-4ubuntu2.8

  
  VPN tunnel info 
  
  vpn0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:IP  P-t-P:xx  Mask:255.255.252.0
inet6 addr: fe80::b8e2:bea4:2e62:fe08/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1406  Metric:1
RX packets:962 errors:0 dropped:0 overruns:0 frame:0
TX packets:1029 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:87839 (87.8 KB)  TX bytes:238740 (238.7 KB)

  Issue
  
  Unable to connect to any host via ssh or sftp after VPN connection 

  Tried 
  =

  Reinstalled the openssh-client package and still no luck. May I know
  why the default cipher is not taking/hanging? Please let me know .
  There were no recent changes.

  
  Workaround
  ===
  Able to connect to ssh / sftp $ssh -c aes128-ctr   user@IP

  
  Below is the debug ssh client logs ===
  ==

  $ssh -vvv  user@ip
  OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug2: resolving "IP" port 22
  debug2: ssh_connect_direct: needpriv 0
  debug1: Connecting to IP [IP] port 22.
  debug1: Connection established.
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_rsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_rsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_dsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_dsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ecdsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ed25519 type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
  debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 
Ubuntu-4ubuntu0.3
  debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x0400
  debug2: fd 3 setting O_NONBLOCK
  debug1: Authenticating to IP:22 as 'user'
  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-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
  debug2: host key algorithms: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 

[Touch-packages] [Bug 1764044] Re: ssh-add asks about passphrases for keys already unlocked in the keychain

2022-04-01 Thread Sergio Durigan Junior
A bit more info because this bug came up again for me.

It was mentioned that this was working OK in Trusty, so I assume that
openssh 6.6 was being used there, and that when the upgrade to openssh
7.x happened this issue started happening.  I agree that the tool itself
could be more helpful in its output, but this deprecation has been
documented in the release notes:

https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/#OpenSSH_7.2p2

I looked at upstream's bugzilla and could not find any bugs requesting a
more verbose output from the tool.  I still believe this bug should be
dealt with by upstream, and we can follow their lead.  Keeping as Low
priority (and I consider that the priority will only get lower, given
that people will forcefully start migrating away from DSA).

BTW, I confirmed that this issue still applies to Jammy.

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

** Changed in: openssh (Ubuntu)
   Importance: Low => Wishlist

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

Title:
  ssh-add asks about passphrases for keys already unlocked in the
  keychain

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  In the below example, on the second invocation of ssh-add I should not
  be prompted to enter the passphrase again after I successfully entered
  it on the first instance.  This used to work fine in trusty i386
  setup.

  $ keychain && ssh-add

   * keychain 2.8.2 ~ http://www.funtoo.org
   * Starting ssh-agent...

  Enter passphrase for /home/rolf/.ssh/id_rsa:
  Identity added: /home/rolf/.ssh/id_rsa (/home/rolf/.ssh/id_rsa)
  Enter passphrase for /home/rolf/.ssh/id_dsa:
  Identity added: /home/rolf/.ssh/id_dsa (/home/rolf/.ssh/id_dsa)

  $ keychain && ssh-add

   * keychain 2.8.2 ~ http://www.funtoo.org
   * Found existing ssh-agent: 25744

  Enter passphrase for /home/rolf/.ssh/id_rsa:
  Identity added: /home/rolf/.ssh/id_rsa (/home/rolf/.ssh/id_rsa)
  Enter passphrase for /home/rolf/.ssh/id_dsa:
  Identity added: /home/rolf/.ssh/id_dsa (/home/rolf/.ssh/id_dsa)

  gnome-keyring is running:
  $ ps -ax|grep key
   2067 ?SLl0:05 /usr/bin/gnome-keyring-daemon --start --components 
ssh
   2078 ?Ssl0:01 
/usr/lib/x86_64-linux-gnu/indicator-keyboard/indicator-keyboard-service 
--use-gtk
   6987 ?S  0:00 /usr/bin/ssh-agent -D -a 
/run/user/1000/keyring/.ssh
  17832 pts/2S+ 0:00 grep --color=auto key

  ssh-agent is running:
  $ ps aux | grep ssh-agent
  leggewie  1928  0.0  0.0  15548   340 ?Ss   02:38   0:00 
/usr/bin/ssh-agent /usr/bin/im-launch env LD_PRELOAD=libgtk3-nocsd.so.0 
/usr/lib/gnome-session/run-systemd-session unity-session.target
  leggewie  6987  0.0  0.0  11304  1484 ?S02:50   0:00 
/usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh
  leggewie  9952  0.0  0.0  11304   320 ?Ss   04:11   0:00 ssh-agent 
bash
  leggewie 17850  0.0  0.0  14492  1160 pts/2S+   06:06   0:00 grep 
--color=auto ssh-agent

  $ env|grep SSH
  SSH_AUTH_SOCK=/tmp/ssh-W6fuGBztRRds/agent.6992
  SSH_AGENT_PID=9952
  SSH_AGENT_LAUNCHER=gnome-keyring

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1764044/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-03-31 Thread Sergio Durigan Junior
** Description changed:

+ [Impact]
+ 
+ When using "ssh-keygen -R" to remove a host from "known_hosts" the
+ command changes permissions on the file.  This can cause problems
+ particularly when used on the global "known_hosts" file
+ (/etc/ssh/ssh_known_hosts), because then only root can read it. Programs
+ running non-interactively as non-root users suddenly fail to SSH and
+ it's not immediately obvious why.
+ 
+ [Test Plan]
+ 
+ The problem happens on Bionic and Focal.
+ 
+ $ lxc launch ubuntu-daily:focal openssh-bug1966591
+ $ lxc shell openssh-bug1966591
+ # ssh-keyscan github.com > test_known_hosts
+ # chmod 644 test_known_hosts
+ # ssh-keygen -R github.com -f test_known_hosts
+ # stat test_known_hosts
+ ...
+ Access: (0600/-rw---) ...
+ ...
+ 
+ [Where problems could occur]
+ 
+ The upstream patch is very simple and it is unlikely that it will cause
+ any regressions.  An indirect problem that could occur is that users
+ might expect to see a more strict set of permissions on a "known_hosts"
+ file after using "ssh-keygen -R", but arguably this is not defined
+ behaviour and should not be relied upon.  Of course, there is always a
+ (very) small risk of introducing problems when rebuilding packages using
+ newer versions of its dependencies (especially on Bionic, because it's
+ older).
+ 
+ [Original Description]
+ 
  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used on
  the global known hosts file (/etc/ssh/ssh_known_hosts), because then
  only root can read it. Programs running non-interactively as non-root
  users suddenly fail to SSH and it's not immediately obvious why.
  
  To reproduce:
  
  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  
  Expected behavior: file permissions remain unchanged (mode 0741 in this
  example).
  
  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04
  
  $ apt-cache policy openssh-client
  openssh-client:
-   Installed: 1:7.6p1-4ubuntu0.6
+   Installed: 1:7.6p1-4ubuntu0.6

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  In Progress
Status in openssh source package in Focal:
  In Progress
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  [Impact]

  When using "ssh-keygen -R" to remove a host from "known_hosts" the
  command changes permissions on the file.  This can cause problems
  particularly when used on the global "known_hosts" file
  (/etc/ssh/ssh_known_hosts), because then only root can read it.
  Programs running non-interactively as non-root users suddenly fail to
  SSH and it's not immediately obvious why.

  [Test Plan]

  The problem happens on Bionic and Focal.

  $ lxc launch ubuntu-daily:focal openssh-bug1966591
  $ lxc shell openssh-bug1966591
  # ssh-keyscan github.com > test_known_hosts
  # chmod 644 test_known_hosts
  # ssh-keygen -R github.com -f test_known_hosts
  # stat test_known_hosts
  ...
  Access: (0600/-rw---) ...
  ...

  [Where problems could occur]

  The upstream patch is very simple and it is unlikely that it will
  cause any regressions.  An indirect problem that could occur is that
  users might expect to see a more strict set of permissions on a
  "known_hosts" file after using "ssh-keygen -R", but arguably this is
  not defined behaviour and should not be relied upon.  Of course, there
  is always a (very) small risk of introducing problems when rebuilding
  packages using newer versions of its dependencies (especially on
  Bionic, because it's older).

  [Original Description]

  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
    Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:

[Touch-packages] [Bug 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-03-30 Thread Sergio Durigan Junior
Thanks for the bug report Evgeny and for the initial investigation,
Lena.

The following commit "fixes" the issue:

commit f2d84f1b3fa68d77c99238d4c645d0266fae2a74
Author: d...@openbsd.org 
AuthorDate: Wed May 13 09:55:57 2020 +
Commit: Damien Miller 
CommitDate: Wed May 27 10:09:19 2020 +1000

I say "fixes" because it doesn't do exactly what Evgeny is asking in the
bug description; that is, it doesn't make ssh-keygen preserve *all* of
the permission bits.  Instead, with the commit above applied we see that
ssh-keygen in Focal/Bionic start behaving exactly like what we see in
Impish/Jammy, and the group/all *read* permissions are preserved, but
not the (e.g.) execute permission.  We can see that on the output that
Lena pasted.

Either way, preserving the "read" permission bits for group/all and
dropping everything else is done on purpose, as can be seen on this
excerpt (from ssh-keygen.c:do_known_hosts):

...
fchmod(fd, sb.st_mode & 0644);
...


I have already backported & tested the patch on Bionic, and it works.  I will 
start filing MPs tomorrow.

** Changed in: openssh (Ubuntu Bionic)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: openssh (Ubuntu Focal)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: openssh (Ubuntu Bionic)
   Status: Confirmed => Triaged

** Changed in: openssh (Ubuntu Bionic)
   Status: Triaged => In Progress

** Changed in: openssh (Ubuntu Focal)
   Status: Confirmed => In Progress

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  In Progress
Status in openssh source package in Focal:
  In Progress
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1966591/+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 1966591] Re: ssh-keygen -R changes known_hosts file permissions (mode)

2022-03-30 Thread Sergio Durigan Junior
** Bug watch added: OpenSSH Portable Bugzilla #3146
   https://bugzilla.mindrot.org/show_bug.cgi?id=3146

** Also affects: openssh via
   https://bugzilla.mindrot.org/show_bug.cgi?id=3146
   Importance: Unknown
   Status: Unknown

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

Title:
  ssh-keygen -R changes known_hosts file permissions (mode)

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Confirmed
Status in openssh source package in Focal:
  Confirmed
Status in openssh source package in Impish:
  Fix Released
Status in openssh source package in Jammy:
  Fix Released

Bug description:
  When I use ssh-keygen -R to remove a host from known_hosts it changes
  permissions on the file. This causes problems particularly when used
  on the global known hosts file (/etc/ssh/ssh_known_hosts), because
  then only root can read it. Programs running non-interactively as non-
  root users suddenly fail to SSH and it's not immediately obvious why.

  To reproduce:

  $ ssh-keyscan github.com >test_known_hosts
  $ chmod 741 test_known_hosts
  $ ssh-keygen -R github.com -f test_known_hosts
  $ stat test_known_hosts
  ...
  Access: (0600/-rw---) ...

  Expected behavior: file permissions remain unchanged (mode 0741 in
  this example).

  $ lsb_release -rd
  Description:  Ubuntu 18.04.6 LTS
  Release:  18.04

  $ apt-cache policy openssh-client
  openssh-client:
Installed: 1:7.6p1-4ubuntu0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1966591/+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 1966886] Re: ssh-copy-id and Dropbear Server

2022-03-30 Thread Sergio Durigan Junior
Thank you for taking the time to file a bug report.

I don't know if I fully understand the issue here.  I installed dropbear
inside a container, started it, and then ran ssh-copy-id on the host in
order to copy my public key to the dropbear server.  It got copied
successfully and I was able to login via SSH without issues later.

Could you please provide reproduction steps here?  Also, from your
description, it doesn't seem like this is an openssh bug.  But first we
need to verify whether this is really an issue or not.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

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

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

Title:
  ssh-copy-id and Dropbear Server

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  on Dropbear SSH Servers ssh-copy-id installs the key in
  /etc/dropbear/authorized_keys

  only the openwrt dropbear server uses that path
  
https://github.com/openwrt/openwrt/blob/2211ee0037764e1c6b1576fe7a0975722cd4acdc/package/network/services/dropbear/patches/100-pubkey_path.patch

  the upstream dropbear server uses the normal path
  ~/.ssh/authorized_keys

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1966886/+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 1964642] Re: Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4 but can connect to Ubuntu 20.4

2022-03-14 Thread Sergio Durigan Junior
Thanks for reporting this bug.

As Seth said, it seems unlikely that this is ssh's fault.  I don't have
an easy way to use virtualbox/packer here, so I'm wondering if you could
either provide more info (as Seth also requested) or an out-of-the-box
way to reproduce what you're seeing (i.e., without involving third-party
applications).

Thanks.

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

Title:
  Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4
  but can connect to Ubuntu 20.4

Status in openssh package in Ubuntu:
  New

Bug description:
  Two years ago I was able to create a Virtualbox Ubuntu 20.04 guest in a 
Windows 10 host with Packer 1.5.6, using an unattended installation.
  The Packer command was:
    "boot_command": [
  " ",
  "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/",
  ""
    ],
  The user-data file was:
  #cloud-config
  autoinstall:
    version: 1
    identity:
  realname: mclibre
  hostname: ubuntu
  password: 
'$6$mclibre$YiuRPSZM3ZXVe4UyIqv1dvy9rUjf5/LsGCkDyaex.WN45wzVTuRmW5QLuctuicGAFZIO2M3QR8NLdtQYatKTn1'
  username: mclibre
    locale: es_ES.UTF-8
    keyboard:
  layout: es
    network:
  network:
    version: 2
    ethernets:
  ens33: {dhcp4: true, dhcp-identifier: mac}
    ssh:
  install-server: true
    late-commands:
  - sed -i 's/^#*\(send dhcp-client-identifier\).*$/\1 = hardware;/' 
/target/etc/dhcp/dhclient.conf
  - 'sed -i "s/dhcp4: true/&\n  dhcp-identifier: mac/" 
/target/etc/netplan/00-installer-config.yaml'
  Now, I have tried to create a Virtualbox Ubuntu 20.04.4/.3/.2/.1 guest using 
packer 1.5.6 but Packer can't create the image because once the installation is 
done, after rebooting the SSH server does not answer (the packer log error 
says: SSH handshake err: Timeout during SSH handshake).
  I have tried with the last version of Packer, Packer 1.8.0, and the result is 
the same. I can create a Ubuntu Server 20.4 image but not a Ubuntu Server 
20.4.1, .2, .3 or .4 image.
  I can provide as much aditional information as you want.
  Thanking you in advance,
  Bartolome Sintes

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1964642/+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 1962389] Re: Sync upower 0.99.16-2 (main) from Debian unstable (main)

2022-02-27 Thread Sergio Durigan Junior
This bug was fixed in the package upower - 0.99.16-2
Sponsored for Rik Mills (rikmills)

---
upower (0.99.16-2) unstable; urgency=medium

  * Cherry-pick FD handling fixes from upstream (Closes: #1006368)

 -- Michael Biebl   Sat, 26 Feb 2022 10:43:19 +0100

** Changed in: upower (Ubuntu)
   Status: New => Fix Released

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

Title:
  Sync upower 0.99.16-2 (main) from Debian unstable (main)

Status in upower package in Ubuntu:
  Fix Released

Bug description:
  Please sync upower 0.99.16-2 (main) from Debian unstable (main)

  Changelog entries since current jammy version 0.99.16-1:

  upower (0.99.16-2) unstable; urgency=medium

* Cherry-pick FD handling fixes from upstream (Closes: #1006368)

   -- Michael Biebl   Sat, 26 Feb 2022 10:43:19 +0100

  As per https://gitlab.freedesktop.org/upower/upower/-/issues/174

  this should fix KDE not registering and acting on laptop lid closure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1962389/+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 1651451] Re: NSS Shared System Database non-functional

2022-02-16 Thread Sergio Durigan Junior
Thank you for this bug report.

It seems that it affects only Xenial installations, is that correct?
Would you be able to confirm whether this still applies for
Bionic/Focal/Jammy?

Thanks.

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

Title:
  NSS Shared System Database non-functional

Status in nss package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 16.04 appears to ship with libnsssysinit.so configured in
  /etc/pki/nssdb as it should be, but the library isn't *present*. So
  when applications such as Evolution attempt to open it, they fail:

  (evolution:20974): camel-WARNING **: Failed to initialize NSS SQL
  database in sql:/etc/pki/nssdb: NSS error -8126

  For background, see https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
  and https://wiki.mozilla.org/NSS_Shared_DB

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1651451/+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

2022-02-10 Thread Sergio Durigan Junior
Xenial has reached end of standard support.

** Changed in: dnsmasq (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
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:
  Won't Fix
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 1817955] Re: Getting new "DN is out of the realm subtree" error on adding principal

2022-02-10 Thread Sergio Durigan Junior
Trusty has reached its end of standard support.

** Changed in: krb5 (Ubuntu Trusty)
   Status: Triaged => Won't Fix

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

Title:
  Getting new "DN is out of the realm subtree" error on adding principal

Status in krb5 package in Ubuntu:
  Fix Released
Status in krb5 source package in Trusty:
  Won't Fix

Bug description:
  Recently applied security update to 14.04.5 LTS kerberos
  (1.12+dfsg-2ubuntu5.4), and started getting errors when adding new
  principals to LDAP.

  Obfuscated example:

  kadmin.local -q "ank -x
  dn=\"uid=testuser,ou=People,dc=example,dc=com\" -pw \"dummypass\"
  testuser"

  now gives:
  Authenticating as principal root/ad...@test.example.com with password.
  NOTICE: no policy specified for testu...@test.example.com; assigning "default"
  add_principal: DN is out of the realm subtree while creating 
"testu...@test.example.com".

  
  This worked up through 1.12+dfsg-2ubuntu5.3, and I think it now fails due to 
changes in src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c in response to 
CVE-2018-5729 or CVE-2018-5730.

  I'm going to attempt a downgrade to 1.12+dfsg-2ubuntu5.3 to check.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817955/+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 1878945] Re: crash slapd after update

2022-02-09 Thread Sergio Durigan Junior
Sorry about the delay in replying to this bug.

>From the bug description, it seems to me that this issue happened while
using Ubuntu Xenial (16.04); is that correct?  I know it has been a
while, but can you still reproduce the issue?  If yes, are you able to
describe the steps necessary to trigger this failure?

Ubuntu Xenial has reached the end of standard support, but I would like
to determine whether this is still affecting you and if you are able to
reproduce this using a newer version of Ubuntu (Bionic or Focal).

I'm marking this bug as Incomplete for now; please move it back to New
once you have replied to this comment and provided more details.

Thanks.

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

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

Title:
  crash slapd after update

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  hi,
  after update slapd to version 2.4.42+dfsg-2ubuntu3.8 I get not working ldap 
auth service;

  perform: slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d/ and
  get:

  5ebeb45f hdb_db_open: database "dc=myBase": 
db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
  5ebeb45f backend_startup_one (type=hdb, suffix="dc=myBase"): bi_db_open 
failed! (2)
  slap_startup failed (test would succeed using the -u switch)

  journalctl -xe

  -- Unit slapd.service has finished starting up.
  --
  -- The start-up result is done.
  May 15 18:25:33 srv sshd[3917]: Connection closed by IP port PORT1 [preauth]
  May 15 18:26:32 srv sshd[3919]: Connection closed by IP port PORT2 [preauth]
  May 15 18:27:21 srv systemd[1]: Starting Daily apt download activities...
  -- Subject: Unit apt-daily.service has begun start-up
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit apt-daily.service has begun starting up.
  May 15 18:27:23 srv systemd[1]: Started Daily apt download activities.
  -- Subject: Unit apt-daily.service has finished start-up
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit apt-daily.service has finished starting up.
  --
  -- The start-up result is done.
  May 15 18:27:32 srv sshd[3987]: Connection closed by IP port PORT3 [preauth]
  May 15 18:28:04 srv systemd[1]: Stopping LSB: OpenLDAP standalone server 
(Lightweight Directory Access Protocol)...
  -- Subject: Unit slapd.service has begun shutting down
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit slapd.service has begun shutting down.
  May 15 18:28:04 srv slapd[4020]:  * Stopping OpenLDAP slapd
  May 15 18:28:14 srv slapd[4020]:...fail!
  May 15 18:28:14 svr systemd[1]: slapd.service: Control process exited, 
code=exited status=1
  May 15 18:28:14 srv systemd[1]: Stopped LSB: OpenLDAP standalone server 
(Lightweight Directory Access Protocol).
  -- Subject: Unit slapd.service has finished shutting down
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit slapd.service has finished shutting down.
  May 15 18:28:14 srv systemd[1]: slapd.service: Unit entered failed state.
  May 15 18:28:14 srv systemd[1]: slapd.service: Failed with result 'exit-code'.
  May 15 18:28:14 srv systemd[1]: Starting LSB: OpenLDAP standalone server 
(Lightweight Directory Access Protocol)...
  -- Subject: Unit slapd.service has begun start-up
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit slapd.service has begun starting up.
  May 15 18:28:15 srv slapd[4029]:  * Starting OpenLDAP slapd
  May 15 18:28:15 srv slapd[4029]:...done.
  May 15 18:28:15 srv systemd[1]: Started LSB: OpenLDAP standalone server 
(Lightweight Directory Access Protocol).
  -- Subject: Unit slapd.service has finished start-up
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit slapd.service has finished starting up.
  --
  -- The start-up result is done.

  OS: Ubuntu 16.04.6 LTS

  help, please!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1878945/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

2022-02-08 Thread Sergio Durigan Junior
Dimitri,

I don't know if this will suffice.  With glibc's decision to remove
libpthread, I believe we will need to explicitly copy libpthread.so, at
least temporarily until everything else doesn't explicitly link against
it.

Taking the stub binary your MP is generating as an example (running on
Jammy):

# gcc -Wl,--no-as-needed -shared -pthread -l:libgcc_s.so.1 -o bla
# ldd bla 
linux-vdso.so.1 (0x7ffdba94d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f581d651000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f581d429000)
/lib64/ld-linux-x86-64.so.2 (0x7f581d678000)

We see that it's not linked against pthread.

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

Title:
  Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools source package in Jammy:
  Confirmed

Bug description:
  [Bug description]

  On a jammy installation, which was upgraded from focal, after a full-
  upgrade and a reboot,

  I enter the LUKS password to decrypt the disk. Then I get the
  following error:

  libgcc_s.so.1 must be installed for pthread_exit to work

  After the error is shown, the system asks for the password again
  (which never works, always throwing the same error).

  [Root cause]

  I was able to decrypt the disk with the same password by booting from
  a live usb. Which allowed further investigation.

  The error shown in the LUKS password prompt menu comes from
  https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, 
which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing.

  From
  
https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260,
  we noticed that libgcc_s.so.1 is only copied if

  1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or
  2) copy_exec is called for a binary linked to libpthread

  The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup,
  which is linked to libargon2.so.1, which is linked to libpthread.so.0.
  This covers case (2) above. As a consequence, libgcc_s.so.1 is copied
  to the initrd image and the error reported here is not seen.

  However, since glibc 2.34, libpthread is shipped within glibc, and the
  binaries are no longer linked to libpthread.so.0. As a consequence, an
  argon2 package built with glibc 2.32 will no longer be linked to
  libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the
  initrd image. Triggering the reported error.

  This can be verified in these two argon2 builds, from the same
  sources, but with different glibc versions:

  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610
  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217

  Still lvm2 is a seeded package, which Recommends thin-provisioning-
  tools. thin-provisioning-tools ships a initramfs hook that calls
  copy_exec for /usr/sbin/pdata_tools, which is directly linked to
  libgcc_s.so.1. This covers the case (1) above and should suffice to
  ensure the boot process works properly.

  Since thin-provisioning-tools is just a recommends for lvm2, it could
  be removed from the system (and indeed, for some reason, was not
  present in my focal=>jammy installation). In this case, a new kernel
  installation should trigger the reported error.

  [Reproducer]

  - Install jammy with a LUKS encrypted disk
  - remove thin-provisioning-tools
  - perform a full-upgrade (make sure the kernel was upgraded or run 
update-initramfs manually)
  - reboot and verify you can no longer get past the decrypt password prompt 
screen

  [Workaround]

  A workaround for anyone affected would be to install thin-
  provisioning-tools and run update-initramfs.

  [Impact]

  Users upgrading from focal to jammy will eventually be locked out of
  their systems in case they are using LUKS encryption.

  [Additional information]

  While this issue is similar to
  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551,
  This is a different bug, with a different root cause.

  Thanks to sergiodj for the pairing session on the root cause analysis.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

2022-02-02 Thread Sergio Durigan Junior
Yes, that's my take as well.  I was going to proposed a patch to do just
that but I decided to see if there was another way to just selectively
copy lib{gcc_s,pthread}.  I don't think it's worth the hassle, though.

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

Title:
  Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools source package in Jammy:
  Confirmed

Bug description:
  [Bug description]

  On a jammy installation, which was upgraded from focal, after a full-
  upgrade and a reboot,

  I enter the LUKS password to decrypt the disk. Then I get the
  following error:

  libgcc_s.so.1 must be installed for pthread_exit to work

  After the error is shown, the system asks for the password again
  (which never works, always throwing the same error).

  [Root cause]

  I was able to decrypt the disk with the same password by booting from
  a live usb. Which allowed further investigation.

  The error shown in the LUKS password prompt menu comes from
  https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, 
which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing.

  From
  
https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260,
  we noticed that libgcc_s.so.1 is only copied if

  1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or
  2) copy_exec is called for a binary linked to libpthread

  The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup,
  which is linked to libargon2.so.1, which is linked to libpthread.so.0.
  This covers case (2) above. As a consequence, libgcc_s.so.1 is copied
  to the initrd image and the error reported here is not seen.

  However, since glibc 2.34, libpthread is shipped within glibc, and the
  binaries are no longer linked to libpthread.so.0. As a consequence, an
  argon2 package built with glibc 2.32 will no longer be linked to
  libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the
  initrd image. Triggering the reported error.

  This can be verified in these two argon2 builds, from the same
  sources, but with different glibc versions:

  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610
  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217

  Still lvm2 is a seeded package, which Recommends thin-provisioning-
  tools. thin-provisioning-tools ships a initramfs hook that calls
  copy_exec for /usr/sbin/pdata_tools, which is directly linked to
  libgcc_s.so.1. This covers the case (1) above and should suffice to
  ensure the boot process works properly.

  Since thin-provisioning-tools is just a recommends for lvm2, it could
  be removed from the system (and indeed, for some reason, was not
  present in my focal=>jammy installation). In this case, a new kernel
  installation should trigger the reported error.

  [Reproducer]

  - Install jammy with a LUKS encrypted disk
  - remove thin-provisioning-tools
  - perform a full-upgrade (make sure the kernel was upgraded or run 
update-initramfs manually)
  - reboot and verify you can no longer get past the decrypt password prompt 
screen

  [Workaround]

  A workaround for anyone affected would be to install thin-
  provisioning-tools and run update-initramfs.

  [Impact]

  Users upgrading from focal to jammy will eventually be locked out of
  their systems in case they are using LUKS encryption.

  [Additional information]

  While this issue is similar to
  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551,
  This is a different bug, with a different root cause.

  Thanks to sergiodj for the pairing session on the root cause analysis.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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


Re: [Touch-packages] [Bug 1959101] Re: sync/merge krb5

2022-02-02 Thread Sergio Durigan Junior
On Wednesday, February 02 2022, Andreas Hasenack wrote:

> Sync requested, I'll wait for the package to migrate before closing the
> bug.

You can also invoke "syncpackage" using the "--bug" option, FWIW.

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

Title:
  sync/merge krb5

Status in krb5 package in Ubuntu:
  In Progress

Bug description:
  We went ahead of debian because of openssl3:
  krb5 (1.19.2-0ubuntu1) jammy; urgency=medium

[ Sam Hartman ]
* New Upstream version
* Depend on tex-gyre, Closes: #997407

[Simon Chopin]
* d/p/0012-Fix-softpkcs11-build-issues-with-openssl-3.0.patch:
  Cherry-picked from upstream master to fix OpenSSL3 build.
  Closes: #995152, LP: #1945795

   -- Simon Chopin   Tue, 30 Nov 2021
  10:54:17 +0100

  Debian unstable still has 1.18.3-7, but experimental got 1.19.2-1:
  krb5 (1.19.2-1) experimental; urgency=medium

* New Upstream version
* Include patch to work with OpenSSL 3.0, Closes: #995152
* Depend on tex-gyre, Closes: #997407
  
   -- Sam Hartman   Wed, 27 Oct 2021 14:04:42 -0600

  Since we are already at 1.19.2, we might as well merge/sync with
  experimental.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1959101/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2022-01-26 Thread Sergio Durigan Junior
rol: suggest ufw.
    + d/rules: install ufw profile.
    + d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.
  - d/rules: better regexp to match the Maintainer tag in d/control,
    needed in the Ubuntu case because of XSBC-Original-Maintainer
    (Closes #960448, LP #1875697)

   -- Sergio Durigan Junior   Tue, 17 Aug
  2021 14:06:00 -0400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946883/+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 1943280] Re: OpenLDAP's ufw profile is redundant and can be removed

2022-01-25 Thread Sergio Durigan Junior
As it turns out, the situation is a bit more complex.  Although ufw does
provide the ufw-directoryserver profile, for some reason we don't
install ufw profiles on Ubuntu:

https://git.launchpad.net/ufw/tree/debian/rules?h=ubuntu/master#n90

I'm not sure why that is the case, and git-blame isn't very helpful to
clarify the question.  I will try to ask around and see if I can
understand the rationale behind this decision.

** Changed in: openldap (Ubuntu)
   Importance: Medium => Wishlist

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

Title:
  OpenLDAP's ufw profile is redundant and can be removed

Status in openldap package in Ubuntu:
  Triaged

Bug description:
  The openldap package currently carries its own ufw profile as a delta
  against its Debian counterpart.

  Ryan (Debian openldap maintainer) noticed that the ufw package already
  installs a profile that covers OpenLDAP as well as other related
  services:

  https://git.launchpad.net/ufw/tree/profiles/ufw-directoryserver

  I'm filing this bug to serve as a reminder to make sure that we remove
  this unnecessary delta from the openldap package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1943280/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

2022-01-25 Thread Sergio Durigan Junior
** Changed in: initramfs-tools (Ubuntu)
   Status: Fix Released => Confirmed

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

Title:
  Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  [Bug description]

  On a jammy installation, which was upgraded from focal, after a full-
  upgrade and a reboot,

  I enter the LUKS password to decrypt the disk. Then I get the
  following error:

  libgcc_s.so.1 must be installed for pthread_exit to work

  After the error is shown, the system asks for the password again
  (which never works, always throwing the same error).

  [Root cause]

  I was able to decrypt the disk with the same password by booting from
  a live usb. Which allowed further investigation.

  The error shown in the LUKS password prompt menu comes from
  https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, 
which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing.

  From
  
https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260,
  we noticed that libgcc_s.so.1 is only copied if

  1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or
  2) copy_exec is called for a binary linked to libpthread

  The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup,
  which is linked to libargon2.so.1, which is linked to libpthread.so.0.
  This covers case (2) above. As a consequence, libgcc_s.so.1 is copied
  to the initrd image and the error reported here is not seen.

  However, since glibc 2.34, libpthread is shipped within glibc, and the
  binaries are no longer linked to libpthread.so.0. As a consequence, an
  argon2 package built with glibc 2.32 will no longer be linked to
  libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the
  initrd image. Triggering the reported error.

  This can be verified in these two argon2 builds, from the same
  sources, but with different glibc versions:

  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610
  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217

  Still lvm2 is a seeded package, which Recommends thin-provisioning-
  tools. thin-provisioning-tools ships a initramfs hook that calls
  copy_exec for /usr/sbin/pdata_tools, which is directly linked to
  libgcc_s.so.1. This covers the case (1) above and should suffice to
  ensure the boot process works properly.

  Since thin-provisioning-tools is just a recommends for lvm2, it could
  be removed from the system (and indeed, for some reason, was not
  present in my focal=>jammy installation). In this case, a new kernel
  installation should trigger the reported error.

  [Reproducer]

  - Install jammy with a LUKS encrypted disk
  - remove thin-provisioning-tools
  - perform a full-upgrade (make sure the kernel was upgraded or run 
update-initramfs manually)
  - reboot and verify you can no longer get past the decrypt password prompt 
screen

  [Workaround]

  A workaround for anyone affected would be to install thin-
  provisioning-tools and run update-initramfs.

  [Impact]

  Users upgrading from focal to jammy will eventually be locked out of
  their systems in case they are using LUKS encryption.

  [Additional information]

  While this issue is similar to
  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551,
  This is a different bug, with a different root cause.

  Thanks to sergiodj for the pairing session on the root cause analysis.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

2022-01-25 Thread Sergio Durigan Junior
** Tags added: rls-jj-incoming

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

Title:
  Boot error: libgcc_s.so.1 must be installed for pthread_exit to work

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  [Bug description]

  On a jammy installation, which was upgraded from focal, after a full-
  upgrade and a reboot,

  I enter the LUKS password to decrypt the disk. Then I get the
  following error:

  libgcc_s.so.1 must be installed for pthread_exit to work

  After the error is shown, the system asks for the password again
  (which never works, always throwing the same error).

  [Root cause]

  I was able to decrypt the disk with the same password by booting from
  a live usb. Which allowed further investigation.

  The error shown in the LUKS password prompt menu comes from
  https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, 
which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing.

  From
  
https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260,
  we noticed that libgcc_s.so.1 is only copied if

  1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or
  2) copy_exec is called for a binary linked to libpthread

  The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup,
  which is linked to libargon2.so.1, which is linked to libpthread.so.0.
  This covers case (2) above. As a consequence, libgcc_s.so.1 is copied
  to the initrd image and the error reported here is not seen.

  However, since glibc 2.34, libpthread is shipped within glibc, and the
  binaries are no longer linked to libpthread.so.0. As a consequence, an
  argon2 package built with glibc 2.32 will no longer be linked to
  libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the
  initrd image. Triggering the reported error.

  This can be verified in these two argon2 builds, from the same
  sources, but with different glibc versions:

  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610
  
https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217

  Still lvm2 is a seeded package, which Recommends thin-provisioning-
  tools. thin-provisioning-tools ships a initramfs hook that calls
  copy_exec for /usr/sbin/pdata_tools, which is directly linked to
  libgcc_s.so.1. This covers the case (1) above and should suffice to
  ensure the boot process works properly.

  Since thin-provisioning-tools is just a recommends for lvm2, it could
  be removed from the system (and indeed, for some reason, was not
  present in my focal=>jammy installation). In this case, a new kernel
  installation should trigger the reported error.

  [Reproducer]

  - Install jammy with a LUKS encrypted disk
  - remove thin-provisioning-tools
  - perform a full-upgrade (make sure the kernel was upgraded or run 
update-initramfs manually)
  - reboot and verify you can no longer get past the decrypt password prompt 
screen

  [Workaround]

  A workaround for anyone affected would be to install thin-
  provisioning-tools and run update-initramfs.

  [Impact]

  Users upgrading from focal to jammy will eventually be locked out of
  their systems in case they are using LUKS encryption.

  [Additional information]

  While this issue is similar to
  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757,
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551,
  This is a different bug, with a different root cause.

  Thanks to sergiodj for the pairing session on the root cause analysis.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1955347] Re: rsync works bad with encfs now

2022-01-24 Thread Sergio Durigan Junior
Hello Claude,

It should be straightforward to downgrade the package on Focal, because
the previous version is still in the -release pocket.  You can simply:

# apt install rsync=3.1.3-8

and it should do the trick.

While at it, would it be possible for you to provide a step-by-step
reproducer for this bug?  It would be easier for us if we had this.

Thanks in advance.

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

Title:
  rsync works bad with encfs now

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  Hello,
  I think rsync works bad with encfs now.

  When root uses it, rsync cannot read a directory encrypted with encfs
  by a user. More precisely, it cannot read the mounted directory, the
  virtual one where the user can read the datas.

  Until now there was only a warning like this
  "rsync: readlink_stat("/home/claude/Documents_chiffres") failed:
  Permission denied (13)"
  and the software went on working (only ignoring the content of the mounted 
directory and of course without saving this content)

  But recently there is this more:
  "IO error encountered -- skipping file deletion"
  and because of this "skipping file deletion", the software can't work 
normally. The destination gets bigger more and more because the deleted files 
in the source are not deleted in the destination.

  Thanks for reading me.
  rsync 3.1.3-8ubuntu0.1
  Description:Ubuntu 20.04.3 LTS
  Release:20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1955347/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2022-01-20 Thread Sergio Durigan Junior
-maintainer-name: Extract maintainer address dynamically
  from debian/control. (Closes: #960448)
    * Fix Torsten's email address in a historic debian/changelog entry to
  resolve a Lintian error (bogus-mail-host-in-debian-changelog).

  ### Old Ubuntu Delta ###

  openldap (2.5.6+dfsg-1~exp1ubuntu1) impish; urgency=medium

    * Merge with Debian unstable. Remaining changes:
  - Enable AppArmor support:
    + d/apparmor-profile: add AppArmor profile
    + d/rules: use dh_apparmor
    + d/control: Build-Depends on dh-apparmor
    + d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
    + d/control: suggest ufw.
    + d/rules: install ufw profile.
    + d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.
  - d/rules: better regexp to match the Maintainer tag in d/control,
    needed in the Ubuntu case because of XSBC-Original-Maintainer
    (Closes #960448, LP #1875697)

   -- Sergio Durigan Junior   Tue, 17 Aug
  2021 14:06:00 -0400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946883/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2022-01-19 Thread Sergio Durigan Junior
ium

    * Merge with Debian unstable. Remaining changes:
  - Enable AppArmor support:
    + d/apparmor-profile: add AppArmor profile
    + d/rules: use dh_apparmor
    + d/control: Build-Depends on dh-apparmor
    + d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
    + d/control: suggest ufw.
    + d/rules: install ufw profile.
    + d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.
  - d/rules: better regexp to match the Maintainer tag in d/control,
    needed in the Ubuntu case because of XSBC-Original-Maintainer
    (Closes #960448, LP #1875697)

   -- Sergio Durigan Junior   Tue, 17 Aug
  2021 14:06:00 -0400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946883/+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 1064201] Re: package heimdal-kcm 1.6~git20120311.dfsg.1-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

2021-12-09 Thread Sergio Durigan Junior
The Debian bug mentioned in comment #3 has been fixed in Debian and
found its way into Ubuntu a long time ago.  Marking as Fix Released.

** Changed in: heimdal (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  package heimdal-kcm 1.6~git20120311.dfsg.1-2 failed to
  install/upgrade: subprocess installed post-installation script
  returned error exit status 1

Status in heimdal package in Ubuntu:
  Fix Released

Bug description:
  Crashing starts after I have upgraded to Ubuntu 12.04.1 LTS

  ProblemType: Package
  DistroRelease: Ubuntu 12.04
  Package: heimdal-kcm 1.6~git20120311.dfsg.1-2
  ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
  Uname: Linux 3.2.0-30-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.0.1-0ubuntu13
  Architecture: amd64
  Date: Tue Oct  9 05:50:55 2012
  DuplicateSignature:
   Setting up heimdal-kcm (1.6~git20120311.dfsg.1-2) ...
   Starting Heimdal KCM: invoke-rc.d: initscript heimdal-kcm, action "start" 
failed.
   dpkg: error processing heimdal-kcm (--configure):
subprocess installed post-installation script returned error exit status 1
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
  SourcePackage: heimdal
  Title: package heimdal-kcm 1.6~git20120311.dfsg.1-2 failed to 
install/upgrade: subprocess installed post-installation script returned error 
exit status 1
  UpgradeStatus: Upgraded to precise on 2012-09-19 (19 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1064201/+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 1953201] Re: pam_env doesn't accept /etc/environment files that don't end with newline anymore (PAM 1.4.x behaviour change/regression)

2021-12-03 Thread Sergio Durigan Junior
FWIW, the problem happens because of this new check on
modules/pam_env/pam_env.c:

https://github.com/linux-pam/linux-
pam/blob/master/modules/pam_env/pam_env.c#L317-L320

if (p[strlen(p)-1] != '\n' && !feof(f)) {
D(("_assemble_line: line too long"));
return -1;
}

This has been fixed upstream by:

https://github.com/linux-pam/linux-
pam/commit/12824dd648b0668968231044ed805d1f3b212d7e

** Bug watch added: github.com/linux-pam/linux-pam/issues #263
   https://github.com/linux-pam/linux-pam/issues/263

** Also affects: pam via
   https://github.com/linux-pam/linux-pam/issues/263
   Importance: Unknown
   Status: Unknown

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

Title:
  pam_env doesn't accept /etc/environment files that don't end with
  newline anymore (PAM 1.4.x behaviour change/regression)

Status in PAM:
  Unknown
Status in pam package in Ubuntu:
  Confirmed

Bug description:
  Since PAM 1.4.x, pam_env's behaviour has silently changed and now it
  fails to parse/doesn't accept /etc/environment files that don't end
  with a newline.

  It's easy to reproduce:

  $ lxc launch ubuntu-daily:jammy pam-env-test --vm
  $ lxc shell pam-env-test
  # # Note that pam-1.4.x is currently in jammy-proposed as I write this bug.
  # cat > /etc/environment
  # printf 'no_proxy=gnu.org' >> /etc/environment
  # su -
  # curl gnu.org
  curl: (5) Could not resolve proxy: invalid.address

  
  The right output should have been similar to:

  # curl gnu.org
  
  
  301 Moved Permanently
  
  Moved Permanently
  The document has moved http://www.gnu.org/;>here.
  
  Apache/2.4.29 Server at gnu.org Port 80
  

  
  This bug has impacted autopkgtest.u.c; see the following MP:

  
https://code.launchpad.net/~sergiodj/autopkgtest/+git/development/+merge/412771

To manage notifications about this bug go to:
https://bugs.launchpad.net/pam/+bug/1953201/+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 1953201] [NEW] pam_env doesn't accept /etc/environment files that don't end with newline anymore (PAM 1.4.x behaviour change/regression)

2021-12-03 Thread Sergio Durigan Junior
Public bug reported:

Since PAM 1.4.x, pam_env's behaviour has silently changed and now it
fails to parse/doesn't accept /etc/environment files that don't end with
a newline.

It's easy to reproduce:

$ lxc launch ubuntu-daily:jammy pam-env-test --vm
$ lxc shell pam-env-test
# # Note that pam-1.4.x is currently in jammy-proposed as I write this bug.
# cat > /etc/environment
# printf 'no_proxy=gnu.org' >> /etc/environment
# su -
# curl gnu.org
curl: (5) Could not resolve proxy: invalid.address


The right output should have been similar to:

# curl gnu.org


301 Moved Permanently

Moved Permanently
The document has moved http://www.gnu.org/;>here.

Apache/2.4.29 Server at gnu.org Port 80



This bug has impacted autopkgtest.u.c; see the following MP:

https://code.launchpad.net/~sergiodj/autopkgtest/+git/development/+merge/412771

** Affects: pam (Ubuntu)
 Importance: High
 Status: Confirmed

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

Title:
  pam_env doesn't accept /etc/environment files that don't end with
  newline anymore (PAM 1.4.x behaviour change/regression)

Status in pam package in Ubuntu:
  Confirmed

Bug description:
  Since PAM 1.4.x, pam_env's behaviour has silently changed and now it
  fails to parse/doesn't accept /etc/environment files that don't end
  with a newline.

  It's easy to reproduce:

  $ lxc launch ubuntu-daily:jammy pam-env-test --vm
  $ lxc shell pam-env-test
  # # Note that pam-1.4.x is currently in jammy-proposed as I write this bug.
  # cat > /etc/environment
  # printf 'no_proxy=gnu.org' >> /etc/environment
  # su -
  # curl gnu.org
  curl: (5) Could not resolve proxy: invalid.address

  
  The right output should have been similar to:

  # curl gnu.org
  
  
  301 Moved Permanently
  
  Moved Permanently
  The document has moved http://www.gnu.org/;>here.
  
  Apache/2.4.29 Server at gnu.org Port 80
  

  
  This bug has impacted autopkgtest.u.c; see the following MP:

  
https://code.launchpad.net/~sergiodj/autopkgtest/+git/development/+merge/412771

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1953201/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-11-24 Thread Sergio Durigan Junior
** Tags removed: server-todo

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  Fix Released
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  Fix Released
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1912950] Re: rsync halts with Permission denied (13) with a sticky dir and only recent kernels

2021-11-19 Thread Sergio Durigan Junior
Thanks for the report and sorry for the delay in replying.

I did a quick test here and tried to reproduce the bug using a Jammy VM.
Here's what I did:

# mkdir tmp1 tmp2
# for i in $(seq 20); do > tmp1/${i}; done
# chmod -R +t tmp1
# rsync -avz tmp1/ tmp2/

Everything seemed to work fine.  It's important to say that I'm not
using ZFS here, but from your description I got the impression that you
aren't either; am I correct in assuming this?

Could you please provide a reproducer for this bug?  Also, it would be
nice if you could confirm whether this still happens on Impish/Jammy.

Thanks.

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

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

Title:
  rsync halts with Permission denied (13) with a sticky dir and only
  recent kernels

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  Looks like rsync should be adapted to a new policy of the Linux
  kernel. I found a report in the ZFS Github that looks a lot like my
  problem : https://github.com/openzfs/zfs/issues/10742 But on that
  page, the suggested solution using /proc/sys/fs/protected_regular
  doesn't seem to be ideal and instead rsync should be able to figure it
  out by itself so that users aren't encouraged to keep that security
  measure turned off (perhaps my idea is bad, but pros and cons have to
  be figured out).

  I'm regularly backing up a remote folder on a machine that has a
  different user list and that folder has sticky bit set, while being
  root on both sides. I had no error using Ubuntu 18.04 : it started
  failing just after upgrading to 20.04. If I try to rsync individual
  files of that folder, I get error 13 in most cases, but if I chmod -t
  on that folder, I can rsync them, but if I try rsyncing the folder
  again (by recursion), rsync does chmod +t on it before rsyncing
  individual files in the folder, and then it fails again. And of
  course, to work around the problem, rsync would probably have to catch
  error 13 and retry after doing chmod -t temporarily on the folder,
  then schedule a chmod +t after this folder is finished syncing, or at
  cleanup time (Ctrl+c or SIGTERM).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1912950/+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 1950856] Re: package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade: »installiertes openssh-server-Skript des Paketes post-installation«-Unterprozess gab den Fehlerw

2021-11-15 Thread Sergio Durigan Junior
Thank you for taking the time to file a bug report.

While looking at the log files that have been attached to the bug, more
specifically to the DpkgTerminalLog.txt file, the following excert has
caught my attention:

Nov 13 06:51:37 HP-UP17 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 13 06:51:37 HP-UP17 sshd[19069]: /etc/ssh/sshd_config line 68: Directive 
'ChallengeResponseAuthentication' is not allowed within a Match block

Did you perhaps modify your /etc/ssh/sshd_config file and add a "Match"
block containing a "ChallengeResponseAuthentication" directive inside
it?  If that is the case, then this is not supported by sshd and will
prevent its initialization.  If you haven't done that, please let us
know and we will proceed with the investigation, probably by asking you
to provide more information about your setup.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'.

However, if you believe that this is really a bug in Ubuntu, then we would
be grateful if you would provide a more complete description of the problem
with steps to reproduce, explain why you believe this is a bug in Ubuntu
rather than a problem specific to your system, and then change the bug
status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

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

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

Title:
  package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade:
  »installiertes openssh-server-Skript des Paketes post-
  installation«-Unterprozess gab den Fehlerwert 1 zurück

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  no more

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.3
  ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
  Uname: Linux 5.4.0-90-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  AptOrdering:
   libpq5:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sat Nov 13 06:51:37 2021
  ErrorMessage: »installiertes openssh-server-Skript des Paketes 
post-installation«-Unterprozess gab den Fehlerwert 1 zurück
  InstallationDate: Installed on 2021-02-05 (280 days ago)
  InstallationMedia: Ubuntu 18.04.5 LTS "Bionic Beaver" - Release amd64 
(20200806.1)
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.6
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: /etc/ssh/sshd_config line 68: Directive 'ChallengeResponseAuthentication' 
is not allowed within a Match block
  SourcePackage: openssh
  Title: package openssh-server 1:8.2p1-4ubuntu0.3 failed to install/upgrade: 
»installiertes openssh-server-Skript des Paketes 
post-installation«-Unterprozess gab den Fehlerwert 1 zurück
  UpgradeStatus: Upgraded to focal on 2021-04-04 (222 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1950856/+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 1949535] Re: X-forwarding no longer works

2021-11-10 Thread Sergio Durigan Junior
Closing the bug as Invalid as per the reporter's request.

** Changed in: openssh (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  X-forwarding no longer works

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  I operate a Linux based Internet hosting service that includes Linux
  shell servers of various flavors.  I control these from home using
  Ubuntu 21.10 presently.  Until recently, X-forwarding has worked from
  all but ancient Redhat 6.2 servers.  I recently upgraded my debian
  shell server to Bullet, and after the upgrade ssh -X debian.eskimo.com
  from my workstation nanook.eskimo.com ceased to function.  It simply
  says "Cannot open DISPLAY".  At the time, all the others continued to
  work.  Today, when I went to do upgrades, now ssh -X is forwarding
  across the board to all flavors of Linux.  I did an ssh -V, nothing
  obvious wrong in the connection.

  debug1: Authentications that can continue: publickey,password
  debug1: Next authentication method: publickey
  debug1: Offering public key: /home/nanook/.ssh/id_rsa RSA 
SHA256:a5bReJXl7L91eGOuCYugHsY2rn2a0WTDXEBTC93YdmA agent
  debug1: Server accepts key: /home/nanook/.ssh/id_rsa RSA 
SHA256:a5bReJXl7L91eGOuCYugHsY2rn2a0WTDXEBTC93YdmA agent
  debug1: Authentication succeeded (publickey).
  Authenticated to igloo.eskimo.com ([204.122.16.128]:22).
  debug1: channel 0: new [client-session]
  debug1: Requesting no-more-sessi...@openssh.com
  debug1: Entering interactive session.
  debug1: pledge: network
  debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
  debug1: Remote: /home/nanook/.ssh/authorized_keys:1: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: Remote: /home/nanook/.ssh/authorized_keys:1: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: Sending environment.
  debug1: Sending env LANG = en_US.UTF-8
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 2 clearing O_NONBLOCK
  Connection to igloo.eskimo.com closed.
  Transferred: sent 3748, received 3820 bytes, in 6.4 seconds
  Bytes per second: sent 589.4, received 600.8

  I don't see anything obviously wrong here but still it does not work, I get:
  xclock
  Error: Can't open display:

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: ssh (not installed)
  Uname: Linux 5.13.19 x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: MATE
  Date: Tue Nov  2 17:31:14 2021
  SourcePackage: openssh
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1949535/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2021-11-09 Thread Sergio Durigan Junior
set-maintainer-name: Extract maintainer address dynamically
  from debian/control. (Closes: #960448)
    * Fix Torsten's email address in a historic debian/changelog entry to
  resolve a Lintian error (bogus-mail-host-in-debian-changelog).

  ### Old Ubuntu Delta ###

  openldap (2.5.6+dfsg-1~exp1ubuntu1) impish; urgency=medium

    * Merge with Debian unstable. Remaining changes:
  - Enable AppArmor support:
    + d/apparmor-profile: add AppArmor profile
    + d/rules: use dh_apparmor
    + d/control: Build-Depends on dh-apparmor
    + d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
    + d/control: suggest ufw.
    + d/rules: install ufw profile.
    + d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.
  - d/rules: better regexp to match the Maintainer tag in d/control,
    needed in the Ubuntu case because of XSBC-Original-Maintainer
    (Closes #960448, LP #1875697)

   -- Sergio Durigan Junior   Tue, 17 Aug
  2021 14:06:00 -0400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946883/+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

2021-11-03 Thread Sergio Durigan Junior
It seems like I can't add another Debian bug reference to this bug, but
I found this one to be a very interesting read:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982950

In a nutshell, although the "After=network-online.target" change can be
considered to be a workaround here, I find it quite unlikely that the
Debian maintainer (and therefore Ubuntu) will accept a patch proposing
to use this statement in openssh's systemd service file.  You can find a
rationale by Colin in the bug I mentioned above.

In a way, I think this bug is similar to
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141, and we
still don't seem to have a good "silver bullet" for these cases...

** Bug watch added: Debian Bug tracker #982950
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982950

-- 
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
Status in openssh package in Debian:
  New
Status in openssh package in Fedora:
  Unknown

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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-10-14 Thread Sergio Durigan Junior
MR for the Debian postfix package also submitted:

https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/13

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

** Changed in: postfix (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  Triaged
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  Triaged
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-10-13 Thread Sergio Durigan Junior
I've also submitted a Merge Request against the Debian clamav package:

https://salsa.debian.org/clamav-team/clamav/-/merge_requests/4

Hopefully it will be accepted & merged into Ubuntu soon. If not, I will
submit an MP to add this change as a delta to our package.

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  Triaged
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-10-13 Thread Sergio Durigan Junior
FWIW, I submitted a Merge Request against the Debian nss-pam-ldapd here:

https://salsa.debian.org/debian/nss-pam-ldapd/-/merge_requests/2

Hopefully it will be accepted & merged into Ubuntu soon.  If not, I will
submit an MP to add this change as a delta to our package.

** Changed in: nss-pam-ldapd (Ubuntu)
   Status: New => Triaged

** Changed in: nss-pam-ldapd (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  Triaged
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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

[Touch-packages] [Bug 1636205] Re: NumberFormatter has incorrect currency symbols for certain locales

2021-10-13 Thread Sergio Durigan Junior
Xenial has entered ESM (Extended Support) recently.  As such, I am
closing its task as Won't Fix.

** Changed in: icu (Ubuntu Xenial)
   Status: Triaged => Won't Fix

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

Title:
  NumberFormatter  has incorrect currency symbols for certain locales

Status in icu package in Ubuntu:
  Fix Released
Status in php7.0 package in Ubuntu:
  Fix Released
Status in icu source package in Xenial:
  Won't Fix
Status in php7.0 source package in Xenial:
  Invalid
Status in icu source package in Yakkety:
  Fix Released
Status in php7.0 source package in Yakkety:
  Fix Released

Bug description:
  Intl seems to be missing certain currency symbols in certain locales
  on ubuntu 16.04.

  I noticed while doing some unit tests.
  Under hu_HU locale, the expected result was 5 000 Ft
  The actual result turned out to be 5 000 HUF.
  It seems to be specific to this build, as this passes without problems on the 
CI server, and also worked fine on other distributions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1636205/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2021-10-13 Thread Sergio Durigan Junior
 support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppArmor
  - Enable ufw support:
+ d/control: suggest ufw.
+ d/rules: install ufw profile.
+ d/slapd.ufw.profile: add ufw profile.
  - d/{rules,slapd.py}: Add apport hook.
  - d/rules: better regexp to match the Maintainer tag in d/control,
needed in the Ubuntu case because of XSBC-Original-Maintainer
(Closes #960448, LP #1875697)

   -- Sergio Durigan Junior   Tue, 17 Aug
  2021 14:06:00 -0400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946883/+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 1946883] Re: Merge openldap from Debian unstable for 22.04

2021-10-13 Thread Sergio Durigan Junior
** Changed in: openldap (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  Merge openldap from Debian unstable for 22.04

Status in openldap package in Ubuntu:
  New

Bug description:
  Scheduled-For: 22.12
  Upstream: tbd
  Debian:   2.4.59+dfsg-12.5.7+dfsg-1~exp1
  Ubuntu:   2.5.6+dfsg-1~exp1ubuntu1


  Debian new has 2.5.7+dfsg-1~exp1

  
  ### New Debian Changes ###

  openldap (2.4.59+dfsg-1) unstable; urgency=medium

* New upstream release.
* Fix FTBFS with autoconf 2.71 (Closes: #993032):
  - Backport upstream changes to support Autoconf 2.69 instead of simply
disabling automake in debian/rules. Fixes FTBFS due to autoreconf
thinking files required by Automake are missing, even though Automake is
not actually used.
  - Stop running autoreconf in contrib/ldapc++ since we don't build it.
  - Drop custom config.{guess,sub} handling. dh_update_autotools_config does
the right thing for us.
* Update Standards-Version to 4.6.0; no changes required.
* Add a superficial autopkgtest for smbk5pwd.
* Stop disabling test060-mt-hot on ppc64el. The underlying kernel bug
  (#866122) is fixed in all relevant suites by now.

   -- Ryan Tandy   Fri, 27 Aug 2021 09:42:31 -0700

  openldap (2.4.57+dfsg-3) unstable; urgency=medium

* Link smbk5pwd with -lkrb5. (Closes: #988565)

   -- Ryan Tandy   Sat, 15 May 2021 16:03:34 -0700

  openldap (2.4.57+dfsg-2) unstable; urgency=medium

* Fix slapd assertion failure in Certificate List Exact Assertion validation
  (ITS#9454) (CVE-2021-27212)

   -- Ryan Tandy   Sun, 14 Feb 2021 09:26:41 -0800

  openldap (2.4.57+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed slapd crashes in Certificate Exact Assertion processing
(ITS#9404, ITS#9424) (CVE-2020-36221)
  - Fixed slapd assertion failures in saslAuthzTo validation
(ITS#9406, ITS#9407) (CVE-2020-36222)
  - Fixed slapd crash in Values Return Filter control handling
(ITS#9408) (CVE-2020-36223)
  - Fixed slapd crashes in saslAuthzTo processing
(ITS#9409, ITS#9412, ITS#9413)
(CVE-2020-36224, CVE-2020-36225, CVE-2020-36226)
  - Fixed slapd assertion failure in X.509 DN parsing
(ITS#9423) (CVE-2020-36230)
  - Fixed slapd crash in X.509 DN parsing (ITS#9425) (CVE-2020-36229)
  - Fixed slapd crash in Certificate List Exact Assertion processing
(ITS#9427) (CVE-2020-36228)
  - Fixed slapd infinite loop with Cancel operation
(ITS#9428) (CVE-2020-36227)

   -- Ryan Tandy   Sat, 23 Jan 2021 08:57:07 -0800

  openldap (2.4.56+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed slapd abort due to assertion failure in Certificate List syntax
validation (ITS#9383) (CVE-2020-25709)
  - Fixed slapd abort due to assertion failure in CSN normalization with
invalid input (ITS#9384) (CVE-2020-25710)

   -- Ryan Tandy   Wed, 11 Nov 2020 09:13:56 -0800

  openldap (2.4.55+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Fixed slapd normalization handling with modrdn
(ITS#9370) (CVE-2020-25692)

   -- Ryan Tandy   Tue, 27 Oct 2020 21:07:29 -0700

  openldap (2.4.54+dfsg-1) unstable; urgency=medium

* New upstream release.
* Change upstream Homepage and get-orig-source URLs to HTTPS.
* Create debian/gbp.conf.

   -- Ryan Tandy   Sun, 18 Oct 2020 16:03:46 +

  openldap (2.4.53+dfsg-1) unstable; urgency=medium

* New upstream release.

   -- Ryan Tandy   Mon, 07 Sep 2020 09:47:28 -0700

  openldap (2.4.51+dfsg-1) unstable; urgency=medium

* New upstream release.
  - Add ldap_parse_password_expiring_control to libldap-2.4-2.symbols.
* Merge some changes from Ubuntu:
  - slapd.default, slapd.README.Debian: update to refer to slapd.d instead
of slapd.conf.
  - debian/slapd.scripts-common: dump_databases: make slapcat_opts a local
variable.
* Drop paragraph about patch gnutls-altname-nulterminated (#465197) from
  slapd.README.Debian. The patch referred to was dropped in 2.4.7-6.
* debian/patches/set-maintainer-name: Extract maintainer address dynamically
  from debian/control. (Closes: #960448)
* Fix Torsten's email address in a historic debian/changelog entry to
  resolve a Lintian error (bogus-mail-host-in-debian-changelog).


  ### Old Ubuntu Delta ###

  openldap (2.5.6+dfsg-1~exp1ubuntu1) impish; urgency=medium

* Merge with Debian unstable. Remaining changes:
  - Enable AppArmor support:
+ d/apparmor-profile: add AppArmor profile
+ d/rules: use dh_apparmor
+ d/control: Build-Depends on dh-apparmor
+ d/slapd.README.Debian: add note about AppAr

[Touch-packages] [Bug 1946293] Re: Update slapd to include db directory in debconf

2021-10-08 Thread Sergio Durigan Junior
Hello Matt,

Thank you for your bug report/feature request.  We are finishing the
next Ubuntu release as I write this comment, and therefore it is not
possible to address this on Impish.

Moreover, I believe that this request would be more suitable for the
Debian package.  I don't think we should be carrying a delta just for
it, and I consider that the Debian OpenLDAP users could also benefit
from such feature.

Could you please file a bug against the OpenLDAP Debian package and
request this feature there?  Once you do that, please link the Debian
bug to this one so that we can easily track it.

Thank you!

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

** Changed in: openldap (Ubuntu)
   Importance: Undecided => Wishlist

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

Title:
  Update slapd to include db directory in debconf

Status in openldap package in Ubuntu:
  Triaged

Bug description:
  Add the olcDbDirectory value as a debconf setting, so the directory
  may be relocated. This is especially helpful when building a container
  to run slapd with multiple ldap databases using one or more volumes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946293/+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 1945713] Re: Flaky test brotli/basic on focal amd64?

2021-10-06 Thread Sergio Durigan Junior
I spent some time trying to get to the bottom of the issue, but
unfortunately I was not able to make much progress here.

As expected, the very first thing to do here is to reproduce the bug
locally.  I tried many things:

- I built the package locally and ran autopkgtest against it.  Passed.

- I built the package inside a Focal LXD container and then ran
autopkgtest there.  Passed.

- Still inside the Focal LXD container, I tried to invoke the failing
test manually.  Passed.

- I know that Ubuntu's autopkgtest infra uses a Bionic host to run the
tests.  I created a Bionic VM, and inside it I git cloned the
development version of autopkgtest.  Then, I invoked autopkgtest against
the Focal source package for libsoup2.4, using a Focal LXD container as
the testbed.  Passed.

I ran out of ideas on what to try locally, and given that Bryce was able
to add a hint for the failure and unblock apache2, I am giving up (at
least for now).  The way I see it, a person interested in continuing
debugging this could:

- Add debugging statements to the libsoup2.4 code, upload the modified
package to a PPA, and run autopkgtests using the Ubuntu infra.  This
should be able to provide more useful information regarding the array
manipulation that's happening in the test.

- If the above doesn't work, one could try to add debugging statements
to the libglib code that's responsible for array manipulations.


Lastly, it's important to mention that this may very well be something 
unrelated to libsoup2.4/glib.  It can even be a hardware issue, who knows...

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

Title:
  Flaky test brotli/basic on focal amd64?

Status in libsoup2.4 package in Ubuntu:
  New

Bug description:
  The brotli/basic test case periodically fails.  It appears that a few
  retriggers can result in a pass:

  https://autopkgtest.ubuntu.com/packages/libs/libsoup2.4/focal/amd64

  The failures look like this in autopkgtest logs:

  ERROR:../tests/brotli-decompressor-test.c:59:test_brotli:
  assertion failed ((char*)out_bytes->data == contents): ("***\nU" ==
  "***\n")

  I've replaced most of the text with '***' to highlight the difference
  is a 'U' character appended.

  The test case is essentially doing a decompression of 'brotli-
  data/compressed.br' and comparing that it matches 'brotli-
  data/uncompressed.txt'.  I've done this manually using the brotli cli,
  and the files do indeed have the same content.  I've also built the
  package and run the test case locally in a focal lxc container on
  amd64:

  $ cd 
libsoup2.4-gu/debian/libsoup2.4-tests/usr/libexec/installed-tests/libsoup-2.4
  $ while : ; do ./brotli-decompressor-test | grep 'brotli/basic';  sleep 
0.1; done

  I left that to run several hundred cycles but no failures reported at
  all.

  There are a bunch of instances of this failure, here's a few for
  reference:

  
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/libs/libsoup2.4/20210602_152107_d1d56@/log.gz
  
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/libs/libsoup2.4/20210531_201241_8b1be@/log.gz
  
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/libs/libsoup2.4/20200508_211619_2aec8@/log.gz

  That last link is the earliest instance I've been able to find.

  You'll notice in the second two links they also have a failure "not ok
  2 /ssl/tls-interaction", but the first link shows only the brotli
  failure.

  Interestingly, I've not found instances of this failure against other
  architectures than amd64, nor have I seen it on releases other than
  focal.  No dice from googling for bug reports or other reports of test
  failures with libsoup2.4 + brotli.

  The test's code is doing this, basically:

  SoupBrotliDecompressor *dec = soup_brotli_decompressor_new ();
  do {
  result = g_converter_convert (G_CONVERTER (dec), in_buf, 
length, out_buf, sizeof out_buf, 0,
_read, _written, 
);
  g_byte_array_append (out_bytes, out_buf, bytes_written);
in_buf += bytes_read;
  length -= bytes_read;

  } while (result == G_CONVERTER_CONVERTED);

  soup_brotli_decompressor's code is here:

  https://gitlab.gnome.org/GNOME/libsoup/-/blob/master/libsoup/content-
  decoder/soup-brotli-decompressor.c

  But I'm not spotting anything that would obviously cause a 'U' to be
  randomly appended sometimes.  And why 'U'?  UINT? Unknown? User error?

  There are some interesting bug reports in GNOME about brotli in
  libsoup's bug tracker (e.g. #106, #146, #119, and #193), but none that
  match this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsoup2.4/+bug/1945713/+subscriptions


-- 
Mailing list: 

[Touch-packages] [Bug 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-10-06 Thread Sergio Durigan Junior
This bug doesn't apply to Impish.

** Changed in: gssproxy (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  Invalid
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  Fix Released
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  Fix Released
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
  [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
  lt (core dumped)

  [ Where problems could occur ]

  * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
  * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 
package is not very complex.

  [ Original Description ]

  I have apache configured to perform a kerberized NFS4 mount using
  rpc.gssd and gssproxy.

  If I request a web page that requires NFS4 access, then gssproxy
  crashes, reporting a segfault in libselinux.so.1 and the web request
  generates a 403 error.

  gssproxy[6267]: segfault at 0 ip 7f2f5bb1951a sp 7ffe861da150
  error 4 in libselinux.so.1[7f2f5bb0d000+25000]

  If I run gssproxy at debug level = 3, and then load a web page, I can
  see the uid/principal request for www-data come in from rpc.gssd:

  # gssproxy -d --debug-level=3 -i -C /etc/gssproxy

  [2018/08/22 17:51:40]: Debug Enabled (level: 3)
  [2018/08/22 17:52:06]: Client [2018/08/22 17:52:06]: (/usr/sbin/rpc.gssd) 
[2018/08/22 17:52:06]:  connected (fd = 10)[2018/08/22 17:52:06]:  (pid = 4548) 
(uid = 33) (gid = 33)Segmentation fault (core dumped)

  Since gssproxy is required to initiate kerberos principals for any
  local application services - Ubuntu 18.04 does not currently support
  running application services with NFS4 kerberos dependencies.  This
  has a fairly significant impact on anyone attempting to implement
  kerberos on Ubuntu 18.04

  Ubuntu 18.04.1 LTS
  gssproxy 0.8.0-1
  libselinux1:amd64 2.7-2build2
  libgssrpc4:amd64 1.16-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gssproxy/+bug/1788459/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2021-10-06 Thread Sergio Durigan Junior
** Changed in: clamav (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-10-04 Thread Sergio Durigan Junior
Performing the verification for Hirsute.

First, install the problematic package and reproduce the error:

# apt policy gssproxy
gssproxy:
  Installed: 0.8.2-2
  Candidate: 0.8.2-2
  Version table:
 *** 0.8.2-2 500
500 http://archive.ubuntu.com/ubuntu hirsute/universe amd64 Packages
100 /var/lib/dpkg/status
# /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
[2021/10/04 18:34:27]: Debug Enabled (level: 3)
[2021/10/04 18:34:27]: Keytab /etc/krb5.keytab has no content (-1765328203)
[2021/10/04 18:34:27]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
[2021/10/04 18:34:27]: Client [2021/10/04 18:34:27]: (/usr/sbin/gssproxy) 
[2021/10/04 18:34:27]:  connected (fd = 12)[2021/10/04 18:34:27]:  (pid = 1676) 
(uid = 0) (gid = 0)Segmentation fault (core dumped)


Now, install the version from -proposed and verify that it works correctly:

# apt install gssproxy
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be upgraded:
  gssproxy
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 88.0 kB of archives.
After this operation, 13.3 kB disk space will be freed.
Get:1 http://archive.ubuntu.com/ubuntu hirsute-proposed/universe amd64 gssproxy 
amd64 0.8.2-2ubuntu0.21.04.1 [88.0 kB]
Fetched 88.0 kB in 0s (236 kB/s)
(Reading database ... 15225 files and directories currently installed.)
Preparing to unpack .../gssproxy_0.8.2-2ubuntu0.21.04.1_amd64.deb ...
Unpacking gssproxy (0.8.2-2ubuntu0.21.04.1) over (0.8.2-2) ...
Setting up gssproxy (0.8.2-2ubuntu0.21.04.1) ...
# apt policy gssproxy
gssproxy:
  Installed: 0.8.2-2ubuntu0.21.04.1
  Candidate: 0.8.2-2ubuntu0.21.04.1
  Version table:
 *** 0.8.2-2ubuntu0.21.04.1 500
500 http://archive.ubuntu.com/ubuntu hirsute-proposed/universe amd64 
Packages
100 /var/lib/dpkg/status
 0.8.2-2 500
500 http://archive.ubuntu.com/ubuntu hirsute/universe amd64 Packages
# /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
[2021/10/04 18:35:20]: Debug Enabled (level: 3)
[2021/10/04 18:35:20]: Keytab /etc/krb5.keytab has no content (-1765328203)
[2021/10/04 18:35:20]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
[2021/10/04 18:35:20]: Client [2021/10/04 18:35:20]: (/usr/sbin/gssproxy) 
[2021/10/04 18:35:20]:  connected (fd = 12)[2021/10/04 18:35:20]:  (pid = 2029) 
(uid = 0) (gid = 0)[2021/10/04 18:35:20]: 
^C[2021/10/04 18:35:24]: Exiting after receiving a signal


Therefore, the new package indeed fixes the problem.

** Tags removed: verification-needed verification-needed-focal 
verification-needed-hirsute
** Tags added: verification-done-focal verification-done-hirsute

** Tags removed: removal-candidate

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  Fix Committed
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  Fix Committed
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
  [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
  lt (core dumped)

  [ Where problems could occur ]

  * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
  * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 

[Touch-packages] [Bug 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-10-04 Thread Sergio Durigan Junior
Performing the verification for Focal.

First, install the problematic package and reproduce the error:

# apt policy gssproxy
gssproxy:
  Installed: 0.8.2-2
  Candidate: 0.8.2-2
  Version table:
 *** 0.8.2-2 500
500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
100 /var/lib/dpkg/status
# /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
[2021/10/04 18:30:15]: Debug Enabled (level: 3)
[2021/10/04 18:30:15]: Keytab /etc/krb5.keytab has no content (-1765328203)
[2021/10/04 18:30:15]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
[2021/10/04 18:30:15]: Client [2021/10/04 18:30:15]: (/usr/sbin/gssproxy) 
[2021/10/04 18:30:15]:  connected (fd = 12)[2021/10/04 18:30:15]:  (pid = 1877) 
(uid = 0) (gid = 0)Segmentation fault (core dumped)


Now, install the version from -proposed and verify that it works correctly:

# apt install gssproxy
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  gssproxy
1 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 88.4 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 gssproxy 
amd64 0.8.2-2ubuntu0.20.04.1 [88.4 kB]
Fetched 88.4 kB in 0s (224 kB/s)
(Reading database ... 15068 files and directories currently installed.)
Preparing to unpack .../gssproxy_0.8.2-2ubuntu0.20.04.1_amd64.deb ...
Unpacking gssproxy (0.8.2-2ubuntu0.20.04.1) over (0.8.2-2) ...
Setting up gssproxy (0.8.2-2ubuntu0.20.04.1) ...
# apt policy gssproxy
gssproxy:
  Installed: 0.8.2-2ubuntu0.20.04.1
  Candidate: 0.8.2-2ubuntu0.20.04.1
  Version table:
 *** 0.8.2-2ubuntu0.20.04.1 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 
Packages
100 /var/lib/dpkg/status
 0.8.2-2 500
500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
# /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
[2021/10/04 18:31:59]: Debug Enabled (level: 3)
[2021/10/04 18:31:59]: Keytab /etc/krb5.keytab has no content (-1765328203)
[2021/10/04 18:31:59]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
[2021/10/04 18:31:59]: Client [2021/10/04 18:31:59]: (/usr/sbin/gssproxy) 
[2021/10/04 18:31:59]:  connected (fd = 12)[2021/10/04 18:31:59]:  (pid = 2244) 
(uid = 0) (gid = 0)[2021/10/04 18:31:59]: 
^C[2021/10/04 18:32:10]: Exiting after receiving a signal


Therefore, the new package indeed fixes the problem.

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  Fix Committed
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  Fix Committed
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
  [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
  lt (core dumped)

  [ Where problems could occur ]

  * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
  * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 
package is not very complex.

  [ Original Description ]

  I have apache configured to perform a kerberized NFS4 mount using
  rpc.gssd and gssproxy.

  If I request a web page that requires 

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-09-22 Thread Sergio Durigan Junior
I took the liberty to clean up this bug and mark things as Invalid/Fix
Released as needed.  Hopefully I got everything right, but feel free to
reopen/re-classify a task if there's something wrong.

Thanks.

** Changed in: libseccomp (Ubuntu Hirsute)
   Status: Fix Committed => Fix Released

** Changed in: libseccomp (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: ubuntu-z-systems
   Status: New => Invalid

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  Invalid
Status in docker.io package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Released
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Released
Status in runc source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Released
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  Invalid
Status in libseccomp source package in Focal:
  Fix Released
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  Won't Fix
Status in libseccomp source package in Groovy:
  Won't Fix
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  Invalid
Status in libseccomp source package in Hirsute:
  Fix Released
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ sudo tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt  

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-09-22 Thread Sergio Durigan Junior
** Changed in: docker.io (Ubuntu Bionic)
   Status: New => Fix Released

** Changed in: docker.io (Ubuntu Focal)
   Status: New => Fix Released

** Changed in: docker.io (Ubuntu Hirsute)
   Status: New => Fix Released

** Changed in: docker.io (Ubuntu Bionic)
   Status: Fix Released => Invalid

** Changed in: docker.io (Ubuntu Xenial)
   Status: Won't Fix => Invalid

** Changed in: docker.io (Ubuntu Focal)
   Status: Fix Released => Invalid

** Changed in: docker.io (Ubuntu Hirsute)
   Status: Fix Released => Invalid

** Changed in: libseccomp (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: libseccomp (Ubuntu Bionic)
   Status: New => Fix Released

** Changed in: libseccomp (Ubuntu Focal)
   Status: New => Fix Released

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Released
Status in runc source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Released
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  Invalid
Status in libseccomp source package in Focal:
  Fix Released
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  Won't Fix
Status in libseccomp source package in Groovy:
  Won't Fix
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  Invalid
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ sudo tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-09-22 Thread Sergio Durigan Junior
** Changed in: docker.io (Ubuntu Xenial)
   Status: New => Won't Fix

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Released
Status in runc source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  Invalid
Status in libseccomp source package in Bionic:
  Fix Released
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  Invalid
Status in libseccomp source package in Focal:
  Fix Released
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  Won't Fix
Status in libseccomp source package in Groovy:
  Won't Fix
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  Invalid
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ sudo tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 

Re: [Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-09-21 Thread Sergio Durigan Junior
On Tuesday, September 21 2021, Matt Thalman wrote:

> Client:
>  Version:   20.10.7
>  API version:   1.41
>  Go version:go1.16.4
>  Git commit:f0df35096d5f5e6b559b42c7fde6c65a2909f7c5
>  Built: Sat Sep 11 15:09:09 2021
>  OS/Arch:   linux/arm64
>  Context:   default
>  Experimental:  true
>
> Server: Docker Engine - Community
>  Engine:
>   Version:  20.10.8
>   API version:  1.41 (minimum version 1.12)
>   Go version:   go1.16.6
>   Git commit:   75249d8
>   Built:Fri Jul 30 19:53:13 2021
>   OS/Arch:  linux/arm64
>   Experimental: false
>  containerd:
>   Version:  1.4.9
>   GitCommit:e25210fe30a0a703442421b0f60afac609f950a3
>  runc:
>   Version:  1.0.1
>   GitCommit:v1.0.1-0-g4144b63
>  docker-init:
>   Version:  0.19.0
>   GitCommit:de40ad0

I don't have time to try to reproduce right now, but as mwhudson said it
doesn't look like you're using the Ubuntu docker.io package.  The first
thing that caught my attention is the Go version used to build the
package: we use Go 1.13, whereas you used Go 1.16.  The other suspicious
thing is the GitCommit field, which should contain our tags (for example
"20.10.7-0ubuntu1~20.04.1" on Focal).

Are you using Ubuntu on the host?  Perhaps your comment was made because
you're experiencing this error with the Ubuntu docker image, but bear in
mind that this bug is about the docker.io/runc/containerd packages that
run on the Ubuntu host.

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  Won't Fix
Status in libseccomp source package in Groovy:
  Won't Fix
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ sudo tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || 

[Touch-packages] [Bug 1943280] [NEW] OpenLDAP's ufw profile is redundant and can be removed

2021-09-10 Thread Sergio Durigan Junior
Public bug reported:

The openldap package currently carries its own ufw profile as a delta
against its Debian counterpart.

Ryan (Debian openldap maintainer) noticed that the ufw package already
installs a profile that covers OpenLDAP as well as other related
services:

https://git.launchpad.net/ufw/tree/profiles/ufw-directoryserver

I'm filing this bug to serve as a reminder to make sure that we remove
this unnecessary delta from the openldap package.

** 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/1943280

Title:
  OpenLDAP's ufw profile is redundant and can be removed

Status in openldap package in Ubuntu:
  Triaged

Bug description:
  The openldap package currently carries its own ufw profile as a delta
  against its Debian counterpart.

  Ryan (Debian openldap maintainer) noticed that the ufw package already
  installs a profile that covers OpenLDAP as well as other related
  services:

  https://git.launchpad.net/ufw/tree/profiles/ufw-directoryserver

  I'm filing this bug to serve as a reminder to make sure that we remove
  this unnecessary delta from the openldap package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1943280/+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


Re: [Touch-packages] [Bug 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-13 Thread Sergio Durigan Junior
On Friday, August 13 2021, Graham Inggs wrote:

> libvpx was added to the '# packages not in main:' section.
>
> Please only use lto-disabled-list for packages not in main. Packages in
> main should either be fixed or worked around in the package itself.

Sorry about that.  doko had pinged me about this mistake as well.  I
have removed libvpx from lto-disabled-list and uploaded the package
again.  I will fix the issue on libvpx.

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  Fix Released

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
Thanks for the review, Lucas.

Uploaded:

$ dput lto-disabled-list_15_source.changes
Trying to upload package to ubuntu
Checking signature on .changes
gpg: /home/sergio/work/lto-disabled-list/lto-disabled-list_15_source.changes: 
Valid signature from 106DA1C8C3CBBF14
Checking signature on .dsc
gpg: /home/sergio/work/lto-disabled-list/lto-disabled-list_15.dsc: Valid 
signature from 106DA1C8C3CBBF14
Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading lto-disabled-list_15.dsc: done.
  Uploading lto-disabled-list_15.tar.xz: done.  
  Uploading lto-disabled-list_15_source.buildinfo: done.
  Uploading lto-disabled-list_15_source.changes: done.
Successfully uploaded packages.

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
Actually, I *can* reproduce the bug using git HEAD.  As it turns out I
was using an incomplete set of build flags that didn't trigger the
problem.  So yeah, the problem is still present in git HEAD.

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
Good point, Oibaf.  I've just tested git HEAD and verified that the bug
seems to have been fixed there, indeed.  I commented on the bug report.
Thanks.

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
I have filed an upstream bug report:

https://bugs.chromium.org/p/webm/issues/detail?id=1736

Unfortunately it seems like a Google account is needed in order to
view/comment on it.

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
This patch adds libvpx to the lto-disabled-list package, thus working
around the problem and disabling LTO for libvpx.

** Patch added: "fix-ftbfs-libvpx-lto.patch"
   
https://bugs.launchpad.net/ubuntu/+source/lto-disabled-list/+bug/1939640/+attachment/5517532/+files/fix-ftbfs-libvpx-lto.patch

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] Re: libvpx FTBFS with LTO enabled

2021-08-12 Thread Sergio Durigan Junior
** Changed in: lto-disabled-list (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
  collect2: error: ld returned 1 exit status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1939640/+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 1939640] [NEW] libvpx FTBFS with LTO enabled

2021-08-11 Thread Sergio Durigan Junior
Public bug reported:

libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

https://people.canonical.com/~doko/ftbfs-report/test-
rebuild-20210805-impish-impish.html#ubuntu-server

https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
amd64.libvpx_1.9.0-1_BUILDING.txt.gz

g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference to `gtest_all.cc.5c9bdf8f'
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158a5): undefined 
reference to `gtest_all.cc.5c9bdf8f'
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b2): undefined 
reference to `gtest_all.cc.5c9bdf8f'
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158b7): undefined 
reference to `gtest_all.cc.5c9bdf8f'
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x158dd): undefined 
reference to `gtest_all.cc.5c9bdf8f'
/usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x15903): more 
undefined references to `gtest_all.cc.5c9bdf8f' follow
collect2: error: ld returned 1 exit status

** Affects: libvpx (Ubuntu)
 Importance: Undecided
 Assignee: Sergio Durigan Junior (sergiodj)
 Status: Confirmed

** Affects: lto-disabled-list (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: ftbfs lto

** Also affects: lto-disabled-list (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  libvpx FTBFS with LTO enabled

Status in libvpx package in Ubuntu:
  Confirmed
Status in lto-disabled-list package in Ubuntu:
  New

Bug description:
  libvpx FTBFS with LTO enabled on GCC 11, as can be seen here:

  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#ubuntu-server

  https://launchpadlibrarian.net/552670245/buildlog_ubuntu-impish-
  amd64.libvpx_1.9.0-1_BUILDING.txt.gz

  g++ -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wl,-z,now -m64 -o 
test_libvpx ivfenc.c.o md5_utils.c.o test/active_map_refresh_test.cc.o 
test/active_map_test.cc.o test/alt_ref_aq_segment_test.cc.o 
test/altref_test.cc.o test/aq_segment_test.cc.o test/bench.cc.o 
test/borders_test.cc.o test/byte_alignment_test.cc.o test/config_test.cc.o 
test/cpu_speed_test.cc.o test/cq_test.cc.o test/decode_api_test.cc.o 
test/decode_corrupted.cc.o test/decode_svc_test.cc.o 
test/decode_test_driver.cc.o test/encode_api_test.cc.o 
test/encode_test_driver.cc.o test/error_resilience_test.cc.o 
test/external_frame_buffer_test.cc.o test/frame_size_tests.cc.o 
test/invalid_file_test.cc.o test/keyframe_test.cc.o test/level_test.cc.o 
test/realtime_test.cc.o test/resize_test.cc.o test/svc_datarate_test.cc.o 
test/svc_end_to_end_test.cc.o test/svc_test.cc.o test/test_libvpx.cc.o 
test/test_vector_test.cc.o test/test_vectors.cc.o test/timestamp_test.cc.o 
test/user_priv_test.cc.o test/vp8_datarate_test.cc.o 
test/vp9_datarate_test.cc.o test/vp9_end_to_end_test.cc.o 
test/vp9_ethread_test.cc.o test/vp9_lossless_test.cc.o 
test/vp9_motion_vector_test.cc.o test/vp9_skip_loopfilter_test.cc.o 
test/y4m_test.cc.o third_party/libwebm/mkvparser/mkvparser.cc.o 
third_party/libwebm/mkvparser/mkvreader.cc.o webmdec.cc.o y4menc.c.o 
y4minput.c.o -L. -lvpx -lgtest -lpthread -lm -lpthread
  ln -sf  libvpx.so.6.3.0 vpx-vp8-vp9-x86_64-linux-v1.9.0/lib/libvpx.so.6
  /usr/bin/ld: /tmp/ccsyaUhJ.ltrans0.ltrans.o:(.debug_info+0x1586f): undefined 
reference

[Touch-packages] [Bug 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange

2021-07-30 Thread Sergio Durigan Junior
So, I give this a try and attempted to reproduce the issue.

I set up a VM acting as the KDC, and configured sshd in it with the
following options:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes

I then configured an LXD container to act as the krb5 client.  I created
a user "john" both in the KDC and in the client, then was able to verify
that kinit was working fine.  With that out of the way, I tried to
connect via ssh to the KDC:

$ ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex -o
GSSAPIKeyExchange=yes krb5.test.lan

The connection worked.  I did the RH bug and tried to check if there was
anything else I could do, but apparently the bug should have manifested
with what I did.  I also tried to start sshd by hand using the options
you mentioned (plus "-o UsePam=yes"), to no avail.  So I'm a bit lost
here, and would also appreciate more info.

Thanks.

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

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

Title:
  monitor_read: unpermitted request 48 on server while attempting GSSAPI
  key exchange

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I'm using openssh 1:8.2p1-4ubuntu0.2 on Ubuntu 20.04.2 LTS (client and
  server) with the option "GSSAPIKeyExchange=yes", and this causes the
  connection to fail. The server has GSSAPI (Kerberos authentication)
  enabled, but is is only used for non-root users (root uses SSH keys).

  Client command:

  ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex
  root@server -v -p  -o GSSAPIKeyExchange=yes

  Client log:

  OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
  debug1: Reading configuration data /home/user/.ssh/config
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to compute-test [130.75.80.46] port .
  debug1: Connection established.
  debug1: identity file /home/rother/.ssh/id_rsa type 0
  debug1: identity file /home/rother/.ssh/id_rsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_dsa type -1
  debug1: identity file /home/rother/.ssh/id_dsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/rother/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519 type -1
  debug1: identity file /home/rother/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/rother/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/rother/.ssh/id_xmss type -1
  debug1: identity file /home/rother/.ssh/id_xmss-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 
Ubuntu-4ubuntu0.2
  debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x0400
  debug1: Authenticating to server: as 'root'
  debug1: Offering GSSAPI proposal: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: Doing group exchange
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Received GSSAPI_COMPLETE
  debug1: Calling gss_init_sec_context
  debug1: Delegating credentials
  debug1: Rekey has happened - updating saved versions
  debug1: rekey out after 134217728 blocks
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug1: SSH2_MSG_NEWKEYS received
  debug1: rekey in after 134217728 blocks
  debug1: Will attempt key: /home/rother/.ssh/id_rsa RSA 
SHA256:n/EY/cGjgd/r+7JpuqODxIotHHLsYptGXYx9GlKCWSM agent
  debug1: Will attempt key: /home/rother/.ssh/root_id_rsa RSA 
SHA256:yCLAID9FMILharHmDpCB8wW8eiA+iHa4oQKLODbbzKw agent
  debug1: Will attempt key: /home/user/.ssh/id_dsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
  debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519 
  debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
  debug1: Will attempt key: /home/user/.ssh/id_xmss 
  debug1: SSH2_MSG_EXT_INFO received
  debug1: 

[Touch-packages] [Bug 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-06-30 Thread Sergio Durigan Junior
I removed the krb5 component because the bug is not in it.

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  In Progress
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  In Progress
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
  [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
  lt (core dumped)

  [ Where problems could occur ]

  * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
  * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 
package is not very complex.

  [ Original Description ]

  I have apache configured to perform a kerberized NFS4 mount using
  rpc.gssd and gssproxy.

  If I request a web page that requires NFS4 access, then gssproxy
  crashes, reporting a segfault in libselinux.so.1 and the web request
  generates a 403 error.

  gssproxy[6267]: segfault at 0 ip 7f2f5bb1951a sp 7ffe861da150
  error 4 in libselinux.so.1[7f2f5bb0d000+25000]

  If I run gssproxy at debug level = 3, and then load a web page, I can
  see the uid/principal request for www-data come in from rpc.gssd:

  # gssproxy -d --debug-level=3 -i -C /etc/gssproxy

  [2018/08/22 17:51:40]: Debug Enabled (level: 3)
  [2018/08/22 17:52:06]: Client [2018/08/22 17:52:06]: (/usr/sbin/rpc.gssd) 
[2018/08/22 17:52:06]:  connected (fd = 10)[2018/08/22 17:52:06]:  (pid = 4548) 
(uid = 33) (gid = 33)Segmentation fault (core dumped)

  Since gssproxy is required to initiate kerberos principals for any
  local application services - Ubuntu 18.04 does not currently support
  running application services with NFS4 kerberos dependencies.  This
  has a fairly significant impact on anyone attempting to implement
  kerberos on Ubuntu 18.04

  Ubuntu 18.04.1 LTS
  gssproxy 0.8.0-1
  libselinux1:amd64 2.7-2build2
  libgssrpc4:amd64 1.16-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gssproxy/+bug/1788459/+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 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-06-30 Thread Sergio Durigan Junior
The upstream bug is here: https://pagure.io/gssproxy/issue/256

The patch is here:
https://github.com/gssapi/gssproxy/commit/3b77666d463105fc485c0f269feaf0ed1061a769

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  In Progress
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  In Progress
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
  [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
  lt (core dumped)

  [ Where problems could occur ]

  * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
  * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 
package is not very complex.

  [ Original Description ]

  I have apache configured to perform a kerberized NFS4 mount using
  rpc.gssd and gssproxy.

  If I request a web page that requires NFS4 access, then gssproxy
  crashes, reporting a segfault in libselinux.so.1 and the web request
  generates a 403 error.

  gssproxy[6267]: segfault at 0 ip 7f2f5bb1951a sp 7ffe861da150
  error 4 in libselinux.so.1[7f2f5bb0d000+25000]

  If I run gssproxy at debug level = 3, and then load a web page, I can
  see the uid/principal request for www-data come in from rpc.gssd:

  # gssproxy -d --debug-level=3 -i -C /etc/gssproxy

  [2018/08/22 17:51:40]: Debug Enabled (level: 3)
  [2018/08/22 17:52:06]: Client [2018/08/22 17:52:06]: (/usr/sbin/rpc.gssd) 
[2018/08/22 17:52:06]:  connected (fd = 10)[2018/08/22 17:52:06]:  (pid = 4548) 
(uid = 33) (gid = 33)Segmentation fault (core dumped)

  Since gssproxy is required to initiate kerberos principals for any
  local application services - Ubuntu 18.04 does not currently support
  running application services with NFS4 kerberos dependencies.  This
  has a fairly significant impact on anyone attempting to implement
  kerberos on Ubuntu 18.04

  Ubuntu 18.04.1 LTS
  gssproxy 0.8.0-1
  libselinux1:amd64 2.7-2build2
  libgssrpc4:amd64 1.16-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gssproxy/+bug/1788459/+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 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-06-30 Thread Sergio Durigan Junior
I am taking care of this one.

It is important to mention that this could arguably be considered to be
a bug on libselinux, given that it shouldn't dereference pointers
without checking first (especially pointers that were passed to the
library by its clients).  However, in this case it makes sense to fix
this in gssproxy as well.

** Description changed:

+ [ Impact ]
  
- I have apache configured to perform a kerberized NFS4 mount using rpc.gssd 
and gssproxy.   
+ gssproxy users on Focal and Hiruste who configure the package to handle
+ NFS mountpoints using Kerberos authentication will experience a
+ segmentation fault when invoking the service either through systemd or
+ by hand.
+ 
+ [ Test Case]
+ 
+ Inside a Focal LXD container:
+ 
+ $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
+ $ lxc shell gssproxy-bug1788459-focal
+ # apt update
+ # apt install -y gssproxy nfs-kernel-server
+ # cat > /etc/gssproxy/gssproxy.conf << __EOF__
+ [gssproxy]
+ debug = true
+ debug_level = 3
+ __EOF__
+ # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
+ [service/nfs-server]
+ mechs = krb5
+ socket = /run/gssproxy.sock
+ cred_store = keytab:/etc/krb5.keytab
+ trusted = yes
+ kernel_nfsd = yes
+ euid = 0
+ __EOF__
+ # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
+ [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
+ [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
+ [2021/06/30 14:34:14]: Service: nfs-server, Enckey: [ephemeral], Enctype: 18
+ [2021/06/30 14:34:14]: Client [2021/06/30 14:34:14]: (/usr/sbin/gssproxy) 
[2021/06/30 14:34:14]:  connected (fd = 12)[2021/06/30 14:34:14]:  (pid = 3428) 
(uid = 0) (gid = 0)Segmentation fau
+ lt (core dumped)
+ 
+ [ Where problems could occur ]
+ 
+ * The backported patch is simple and it is very unlikely that it will 
introduce a regression.
+ * As usual, it is always risky to rebuild a package that hasn't been touched 
for more than 1 year, albeit in this case the risk is very low because the 
package is not very complex.
+ 
+ [ Original Description ]
+ 
+ I have apache configured to perform a kerberized NFS4 mount using
+ rpc.gssd and gssproxy.
  
  If I request a web page that requires NFS4 access, then gssproxy
  crashes, reporting a segfault in libselinux.so.1 and the web request
  generates a 403 error.
  
  gssproxy[6267]: segfault at 0 ip 7f2f5bb1951a sp 7ffe861da150
  error 4 in libselinux.so.1[7f2f5bb0d000+25000]
  
  If I run gssproxy at debug level = 3, and then load a web page, I can
  see the uid/principal request for www-data come in from rpc.gssd:
  
  # gssproxy -d --debug-level=3 -i -C /etc/gssproxy
  
  [2018/08/22 17:51:40]: Debug Enabled (level: 3)
  [2018/08/22 17:52:06]: Client [2018/08/22 17:52:06]: (/usr/sbin/rpc.gssd) 
[2018/08/22 17:52:06]:  connected (fd = 10)[2018/08/22 17:52:06]:  (pid = 4548) 
(uid = 33) (gid = 33)Segmentation fault (core dumped)
  
  Since gssproxy is required to initiate kerberos principals for any local
  application services - Ubuntu 18.04 does not currently support running
  application services with NFS4 kerberos dependencies.  This has a fairly
  significant impact on anyone attempting to implement kerberos on Ubuntu
  18.04
  
- 
  Ubuntu 18.04.1 LTS
  gssproxy 0.8.0-1
  libselinux1:amd64 2.7-2build2
  libgssrpc4:amd64 1.16-2build1

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  In Progress
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  In Progress
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  [ Impact ]

  gssproxy users on Focal and Hiruste who configure the package to
  handle NFS mountpoints using Kerberos authentication will experience a
  segmentation fault when invoking the service either through systemd or
  by hand.

  [ Test Case]

  Inside a Focal LXD container:

  $ lxc launch images:ubuntu/focal gssproxy-bug1788459-focal
  $ lxc shell gssproxy-bug1788459-focal
  # apt update
  # apt install -y gssproxy nfs-kernel-server
  # cat > /etc/gssproxy/gssproxy.conf << __EOF__
  [gssproxy]
  debug = true
  debug_level = 3
  __EOF__
  # cat >> /etc/gssproxy/25-nfs-server.conf << __EOF__
  [service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0
  __EOF__
  # /usr/sbin/gssproxy --interactive --debug --debug-level=3 
--socket=/run/gssproxy.sock
  [2021/06/30 14:34:14]: Debug Enabled (level: 3) 
  [2021/06/30 14:34:14]: Keytab /etc/krb5.keytab has no content (-1765328203)
  [2021/06/30 

[Touch-packages] [Bug 1788459] Re: gssproxy crashes in libselinux.so.1 on Ubuntu 18.04 when called by rpc.gssd

2021-06-30 Thread Sergio Durigan Junior
** Changed in: gssproxy (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: gssproxy (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: gssproxy (Ubuntu)
   Importance: Undecided => Medium

** Also affects: krb5 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: libselinux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gssproxy (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: krb5 (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: libselinux (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: gssproxy (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Changed in: krb5 (Ubuntu)
   Status: Confirmed => Invalid

** No longer affects: krb5 (Ubuntu)

** No longer affects: krb5 (Ubuntu Focal)

** No longer affects: krb5 (Ubuntu Hirsute)

** Changed in: libselinux (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: libselinux (Ubuntu Focal)
   Status: New => Invalid

** Changed in: libselinux (Ubuntu Hirsute)
   Status: New => Invalid

** Changed in: gssproxy (Ubuntu Focal)
   Status: New => In Progress

** Changed in: gssproxy (Ubuntu Hirsute)
   Status: New => In Progress

** Changed in: gssproxy (Ubuntu Focal)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

** Changed in: gssproxy (Ubuntu Hirsute)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  gssproxy  crashes in libselinux.so.1 on Ubuntu 18.04 when called by
  rpc.gssd

Status in gssproxy package in Ubuntu:
  In Progress
Status in libselinux package in Ubuntu:
  Invalid
Status in gssproxy source package in Focal:
  In Progress
Status in libselinux source package in Focal:
  Invalid
Status in gssproxy source package in Hirsute:
  In Progress
Status in libselinux source package in Hirsute:
  Invalid

Bug description:
  
  I have apache configured to perform a kerberized NFS4 mount using rpc.gssd 
and gssproxy.   

  If I request a web page that requires NFS4 access, then gssproxy
  crashes, reporting a segfault in libselinux.so.1 and the web request
  generates a 403 error.

  gssproxy[6267]: segfault at 0 ip 7f2f5bb1951a sp 7ffe861da150
  error 4 in libselinux.so.1[7f2f5bb0d000+25000]

  If I run gssproxy at debug level = 3, and then load a web page, I can
  see the uid/principal request for www-data come in from rpc.gssd:

  # gssproxy -d --debug-level=3 -i -C /etc/gssproxy

  [2018/08/22 17:51:40]: Debug Enabled (level: 3)
  [2018/08/22 17:52:06]: Client [2018/08/22 17:52:06]: (/usr/sbin/rpc.gssd) 
[2018/08/22 17:52:06]:  connected (fd = 10)[2018/08/22 17:52:06]:  (pid = 4548) 
(uid = 33) (gid = 33)Segmentation fault (core dumped)

  Since gssproxy is required to initiate kerberos principals for any
  local application services - Ubuntu 18.04 does not currently support
  running application services with NFS4 kerberos dependencies.  This
  has a fairly significant impact on anyone attempting to implement
  kerberos on Ubuntu 18.04

  
  Ubuntu 18.04.1 LTS
  gssproxy 0.8.0-1
  libselinux1:amd64 2.7-2build2
  libgssrpc4:amd64 1.16-2build1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gssproxy/+bug/1788459/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-06-23 Thread Sergio Durigan Junior
Hi lincvz,

Unfortunately I don't plan to maintain the packages on the PPA; it would
be too cumbersome to keep monitoring security updates and rebuilding the
package every time.  My intention with the PPA was to facilitate the
diagnostic of the bug, and also to provide a hotfix for you.

I will try to talk to the SRU team again and see if we can reach some
sort of consensus on how to deal with this bug, but unfortunately I
cannot make promises here.  Sorry about that.

** Changed in: openldap (Ubuntu Bionic)
   Importance: High => Medium

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Bionic:
  Triaged

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1932980] Re: window title in mate terminal not change after I logout from ssh

2021-06-23 Thread Sergio Durigan Junior
Thank you for the bug report.

It seems to me that this is a MATE-specific configuration, and not
something related to openssh.  When you ssh into a host, ssh takes
control of the terminal and the PS1 variable becomes something else,
which is reflected on the window title.  When you log out of the ssh
connection, PS1 doesn't get overwritten again because the control is now
back to your shell.

Maybe there are ways to force the window title to be "refreshed" when
you disconnect, but I don't know offhand, sorry.

I'm setting the bug as Invalid for openssh.

** Changed in: openssh (Ubuntu)
   Status: New => Invalid

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

Title:
  window title in mate terminal not change after I logout from ssh

Status in Ubuntu MATE:
  New
Status in mate-terminal package in Ubuntu:
  New
Status in openssh package in Ubuntu:
  Invalid

Bug description:
  I use Ubuntu Mate 20.04. I always update my system. When, I open mate
  terminal and login into my server via ssh, the window title is change
  to my server @. But, its not change after I
  logout. In this report I attach a proof. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1932980/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-06-21 Thread Sergio Durigan Junior
Hello lincvz,

Sorry about the delay.  I have been busy with other stuff and did not
have time to follow up on this bug.  Here is the lay of the land right
now:

1) Unfortunately, it is unlikely that we will be able to get the SRU
team to accept an upload that reintroduces an issue.  This means that
removing the patch that causes the infinite loop is something that we
would rather not do, because another problem will reappear.

2) The ideal course of action here would be to investigate whether it
would be possible to backport the patch at
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503
and make it fully work.  This is probably a non-trivial task, as Ryan
himself said.

I am still looking into a possible solution for this, but I cannot
guarantee anything for now, I'm sorry (I'm very busy with other stuff,
including updating OpenLDAP in Impish to 2.5!)

Given that I have provided a PPA with a package that fixes the issue for
you, I would say that for now you are better off using it.

Last, but not least: if you feel like giving it a try and trying to
backport
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503
to the openldap version that's in Bionic, that would be awesome.  We can
review whatever you have and guide you through the SRU process.

Thank you.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Bionic:
  Triaged

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-06-01 Thread Sergio Durigan Junior
Hi lincvz,

We are still trying to determine the best approach here.  This is on my
TODO list, and hopefully I can put something together by the end of this
week.

Thank you for your patience.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Bionic:
  Triaged

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-05-19 Thread Sergio Durigan Junior
OK, here it is:

https://launchpad.net/~sergiodj/+archive/ubuntu/openldap-bug1926265

lincvz, could you please give this a try and check if this package fixes
the issue?  Thank you!

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Confirmed

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-05-19 Thread Sergio Durigan Junior
Thanks for the further investigation, Stephane and Ryan.  Much
appreciated!

It would be interesting to know if lincvz could test an openldap built
with Ryan's patch, to check if he can still reproduce the bug with it.
I am going to prepare a PPA with Ryan's patch and let you know ASAP.

Ryan, IIUC the patch you're proposing fixes the issue experienced by
Stephane, but we're not entirely sure that it's the same issue being
reported in this bug.  Am I right?

If that's correct, and if we verify that lincvz can still reproduce the
bug even with the fix proposed by Ryan, then the best way forward would
be for Stephane to open a new bug so that I can act on it.

Thanks.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Confirmed

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-05-03 Thread Sergio Durigan Junior
Thanks for following up.

It is hard to say what might be happening and whether switching to MDB
will help or not.  I'm still puzzled that you're seeing this hang on a
relatively new version of OpenLDAP.  The fact that it didn't happen on
Trusty may be helpful when diagnosing the issue, but I can't say for
sure.

I will wait until you are able to provide a backtrace or more
information.  I will see about talking to other OpenLDAP experts here
and see if this bug rings any bells for them.

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1916485] Re: test -x fails inside shell scripts in containers

2021-05-03 Thread Sergio Durigan Junior
Hello!  The kernel team has applied the fix to their pre-release branch.
They have a 5-week release cycle, so we should be seeing a new Bionic
Linux kernel with the fix in the following 3-4 weeks.  Thanks.

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  New
Status in libseccomp source package in Groovy:
  New
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 

[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall

2021-04-29 Thread Sergio Durigan Junior
Thank you for taking the time to file a bug report.

This one looks like a rabbit hole :-(.  I've also found many (very) old
reports of similar problems, but they all appear to have been fixed a
while ago (before Bionic was released).  I even found a possible patch
(from 2005) to fix the issue, and was able to determine that Bionic's
openldap already carries an improved version of the patch
(unsurprisingly).  I've also found an old Launchpad bug (#15270) and the
related Debian bug (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=255276) that reports the same problem as you, and
is marked having been fixed in Debian (also back in 2005).

I am a bit surprised that you're experiencing this problem on Bionic.  I
understand that it is hard to provide steps for reproducing this
problem, but I would like to ask you to provide as much information as
you can, please.  For example:

- Your full openldap configuration (please remove any confidential bits,
of course).

- Any log messages from slapd or related services.

- If you can, please install the debug symbols for openldap/slapd and
run "gdb -p $PROCESS_PID" (where "$PROCESS_PID" is slapd's PID), then
run a "bt" command and attach the output to this bug.

- More information about what is going on in the system when the problem
happens.  For example, I've read that this might happen when the system
load is high; do you notice that as well?

Meanwhile, I will mark this bug as Incomplete.  Feel free to revert its
status back to New once you provide more info.  Thanks!

** Bug watch added: Debian Bug tracker #255276
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255276

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

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

Title:
  slapd enter in infinite loop on sched_yield syscall

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  On a production server, sometimes slapd become unbresponsive, some threads 
loops in sched_yield syscall and consumme all CPU.
  To recover, slapd needs to restart.
  No related information is reported in log file.
  All same issues in OpenLDAP upstream project are old and fixed.
  So maybe this issue affects only Ubuntu package.
  It occurs randomly, so I have no steps to reproduce.

  
  OS : Bionic

  Openldap version:

  libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
 
  libldap-common 2.4.45+dfsg-1ubuntu1.10
 
  slapd  2.4.45+dfsg-1ubuntu1.10
 

  Modules loaded:

  olcModuleLoad: {0}back_bdb
  olcModuleLoad: {1}syncprov
  olcModuleLoad: {2}back_monitor
  olcModuleLoad: {3}memberof.la
  olcModuleLoad: {4}refint.la
  olcModuleLoad: {5}rwm
  olcModuleload: {6}back_ldap

  
  Backend is BDB. slapd run in (single) master - (multi) slave mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+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 1916485] Re: test -x fails inside shell scripts in containers

2021-04-23 Thread Sergio Durigan Junior
Dan, let me know if you need help driving the Linux kernel SRU forward.
Thanks!

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  New
Status in libseccomp source package in Groovy:
  New
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of
  them is required 

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-04-21 Thread Sergio Durigan Junior
Thanks for the investigation, Dan.  I tested the Linux package from your
PPA on a s390x machine and can confirm that it does solve the issue.

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

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  New
Status in libseccomp source package in Groovy:
  New
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-04-19 Thread Sergio Durigan Junior
Before I change the status of this bug, I would like to report my
findings here.

I am testing things on a Bionic s390x machine with everything up-to-
date:

# apt policy systemd
systemd:
  Installed: 237-3ubuntu10.46
...
# apt policy containerd
containerd:
  Installed: 1.4.4-0ubuntu1~18.04.2
...
# apt policy docker.io
docker.io:
  Installed: 20.10.2-0ubuntu1~18.04.2
...
# apt policy runc
runc:
  Installed: 1.0.0~rc93-0ubuntu1~18.04.1
...

Following the reproduction steps listed in the Description section still
fail for me:

# systemd-nspawn 
Spawning container h on /root/h.
Press ^] three times within 1s to kill container.
# bash -c 'test -x /usr/bin/gpg || echo Fail'
Fail

When I'm in a hirsute Docker container, it also fails:

$ docker run -it --rm ubuntu:hirsute
root@78506947b11f:/# bash -c 'test -x /usr/bin/gpg || echo Fail'
Fail

This is impacting the build of the 21.04 OCI images on s390x (amd64,
arm64 and ppc64el succeed).

I'm still not sure what's causing this, nor why this is happening only
on s390x.  I will post more details when I have them.

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

Title:
  test -x fails inside shell scripts in containers

Status in docker.io package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  New
Status in libseccomp source package in Groovy:
  New
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug 

[Touch-packages] [Bug 1917887] Re: Network Manager OpenVPN nested connections fail to setup routes correctly

2021-03-10 Thread Sergio Durigan Junior
Unfortunately I don't know.  I would recommend commenting on the bug in
order to let upstream know that more people are affected by this
problem.  You can try posting your reproduction instructions there, and
provide more information if upstream needs it.

I am marking this bug as Triaged, although I have not reproduced it
myself.

** Changed in: network-manager (Ubuntu)
   Status: Incomplete => Triaged

** Changed in: openvpn (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  Network Manager OpenVPN nested connections fail to setup routes
  correctly

Status in OpenVPN:
  Unknown
Status in network-manager package in Ubuntu:
  Triaged
Status in openvpn package in Ubuntu:
  Invalid

Bug description:
  Setup:
  Host lan: 192.168.0.238/24
  Host Default gw: 192.168.0.1

  ip route:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 

  
  Primary OpenVPN (check "Use this connection only for resources on its 
network"):
  server ip: public a.b.c.d
  OpenVPN Tunnel: 192.168.1.0/24
  routes pushed: 192.168.100.0/24

  First VPN works OK:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  
  Secondary OpenVPN  (check "Use this connection only for resources on its 
network"):
  server ip: private 192.168.100.10 
  OpenVPN Tunnel: 192.168.20.0/24
  routes pushed: 192.168.200.0/24

  Second VPN Connect OK, routing table is wrong:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 
  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100 <- this is 
wrong, the openVPN#2 Gateway is not on the local lan

  Correct routing table using "sudo /usr/sbin/openvpn
  /path/to/config.openvpn" (same a Network Manager)

  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  It seems that Network Manager add a wrong additional route not added
  by the openvpn bin:

  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openvpn 2.4.7-1ubuntu2
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar  5 12:44:39 2021
  InstallationDate: Installed on 2021-02-19 (13 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=it_IT.UTF-8
   SHELL=/bin/bash
  SourcePackage: openvpn
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/openvpn/+bug/1917887/+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 1917887] Re: Network Manager OpenVPN nested connections fail to setup routes correctly

2021-03-10 Thread Sergio Durigan Junior
Thank you for your reply, Riccardo.

I found the following upstream bug report that looks similar to yours:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/204

Can you confirm that this is the same issue?

Your setup seems a bit complex to configure locally, and given that you
said you were able to reproduce this problem on more than one version of
CentOS, I am inclined to believe that, if this is indeed an issue, it
came from upstream.

** Bug watch added: 
gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues #204
   https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/204

** Also affects: openvpn via
   https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/204
   Importance: Unknown
   Status: Unknown

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

Title:
  Network Manager OpenVPN nested connections fail to setup routes
  correctly

Status in OpenVPN:
  Unknown
Status in network-manager package in Ubuntu:
  Incomplete
Status in openvpn package in Ubuntu:
  Incomplete

Bug description:
  Setup:
  Host lan: 192.168.0.238/24
  Host Default gw: 192.168.0.1

  ip route:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 

  
  Primary OpenVPN (check "Use this connection only for resources on its 
network"):
  server ip: public a.b.c.d
  OpenVPN Tunnel: 192.168.1.0/24
  routes pushed: 192.168.100.0/24

  First VPN works OK:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  
  Secondary OpenVPN  (check "Use this connection only for resources on its 
network"):
  server ip: private 192.168.100.10 
  OpenVPN Tunnel: 192.168.20.0/24
  routes pushed: 192.168.200.0/24

  Second VPN Connect OK, routing table is wrong:
  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 
  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100 <- this is 
wrong, the openVPN#2 Gateway is not on the local lan

  Correct routing table using "sudo /usr/sbin/openvpn
  /path/to/config.openvpn" (same a Network Manager)

  default via 192.168.0.1 dev eno1 proto dhcp metric 100 
  192.168.200.0/24 via 192.168.20.1 dev tun1 
  192.168.20.0/24 dev tun1 proto kernel scope link src 192.168.20.59 
  169.254.0.0/16 dev eno1 scope link metric 1000 
  192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.238 metric 100 
  192.168.0.1 dev eno1 proto static scope link metric 100 
  192.168.100.0/24 via 192.168.10.1 dev tun0 proto static metric 50 
  a.b.c.d via 192.168.0.1 dev eno1 proto static metric 100 

  It seems that Network Manager add a wrong additional route not added
  by the openvpn bin:

  192.168.100.10 via 192.168.0.1 dev eno1 proto static metric 100

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openvpn 2.4.7-1ubuntu2
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-44-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar  5 12:44:39 2021
  InstallationDate: Installed on 2021-02-19 (13 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=it_IT.UTF-8
   SHELL=/bin/bash
  SourcePackage: openvpn
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/openvpn/+bug/1917887/+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 Sergio Durigan Junior
OK, new package (with the same version) uploaded now, which addresses
the comments made by Robie.  Let me know what you think.  Thanks!

-- 
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] removable [true] token present [true].
  (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found 
[MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of 
module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so].

  Then:
   1) If you previously configured SSSD match rules and/or CA certificates:
  - You should still get your certificate public key printed as output
  - Configured login with smartcard should continue working

   2) If SSSD was not configured to do smartcard authentication:
  - p11_child may fail if the card certificate was not previously added to
    the trusted DB, but this is outside of this test case.
  - What it matters is that the card is found.

  [ Regression potential ]

  While the change may involve quite 

Re: [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 Sergio Durigan Junior
On Thursday, February 18 2021, Robie Basak wrote:

>> +  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().

Agreed.  I can expand the code to make it check for NULL.

> 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?

Yes, this one slipped past my radar.  There were two more uploads since
Marco posted his first MP, and although he did rebase it against the
latest sssd on Focal, we forgot about this check.

How should I proceed here?  Should I just upload the new package with
the same version, since it wasn't accepted yet?

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink

2021-02-03 Thread Sergio Durigan Junior
Ah, good to know!  No problem at all, Brian!  Cheers :-)

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

Title:
  gdb doesn't search in debug-file-directory for .gnu_debugaltlink

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  New
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  As far as I can tell gdb version 8.2.90 isn't searching the debug-
  file-directory, which I set, for the '.gnu_debugaltlink' which is in
  the debug symbols. Here's the error I'm seeing:

  Type "apropos word" to search for commands related to "word".
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
  could not find '.gnu_debugaltlink' file for 
/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
  (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)

  Here's part of an strace of what's going on behind the scenes:

  lstat("/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
 {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 
  openat(AT_FDCWD, 
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

  This is the only time "/usr/lib/debug" is searched, generally
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox/usr/lib/debug/" is used. I'll attach the full strace though.

  For completeness here's the gdb command I'm using:

  Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
  /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
  --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
  prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
  --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
  -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
  dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox//usr/bin/gnome-calculator"' --ex 'core-file
  /tmp/apport_core_1b6dn6np'

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink

2021-02-03 Thread Sergio Durigan Junior
Ah, I see that is has indeed been backport by Debian, and is already in
hirsute: debian/patches/2bf3b79d05bf85e41cbdcb020bd1cc424f59dd9a.diff is
the patch.  @Brian, would you like me to backport the patch to another
release?

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

Title:
  gdb doesn't search in debug-file-directory for .gnu_debugaltlink

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  New
Status in gdb package in Ubuntu:
  Confirmed

Bug description:
  As far as I can tell gdb version 8.2.90 isn't searching the debug-
  file-directory, which I set, for the '.gnu_debugaltlink' which is in
  the debug symbols. Here's the error I'm seeing:

  Type "apropos word" to search for commands related to "word".
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
  could not find '.gnu_debugaltlink' file for 
/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
  (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)

  Here's part of an strace of what's going on behind the scenes:

  lstat("/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
 {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 
  openat(AT_FDCWD, 
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

  This is the only time "/usr/lib/debug" is searched, generally
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox/usr/lib/debug/" is used. I'll attach the full strace though.

  For completeness here's the gdb command I'm using:

  Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
  /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
  --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
  prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
  --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
  -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
  dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox//usr/bin/gnome-calculator"' --ex 'core-file
  /tmp/apport_core_1b6dn6np'

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink

2021-02-03 Thread Sergio Durigan Junior
@Brian, Ops, sorry.  I forgot about this bug, and then I kind of assumed
that it had already been backported on Debian.  This is just for
hirsute, right?  I can backport it now, give me just a second.

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

Title:
  gdb doesn't search in debug-file-directory for .gnu_debugaltlink

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  New
Status in gdb package in Ubuntu:
  Confirmed

Bug description:
  As far as I can tell gdb version 8.2.90 isn't searching the debug-
  file-directory, which I set, for the '.gnu_debugaltlink' which is in
  the debug symbols. Here's the error I'm seeing:

  Type "apropos word" to search for commands related to "word".
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
  could not find '.gnu_debugaltlink' file for 
/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
  (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)

  Here's part of an strace of what's going on behind the scenes:

  lstat("/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
 {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 
  openat(AT_FDCWD, 
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

  This is the only time "/usr/lib/debug" is searched, generally
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox/usr/lib/debug/" is used. I'll attach the full strace though.

  For completeness here's the gdb command I'm using:

  Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
  /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
  --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
  prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
  --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
  -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
  dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox//usr/bin/gnome-calculator"' --ex 'core-file
  /tmp/apport_core_1b6dn6np'

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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 1913810] Re: restart doesn't test for syntax errors

2021-02-01 Thread Sergio Durigan Junior
** Changed in: openssh (Ubuntu)
   Status: New => Confirmed

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

Title:
  restart doesn't test for syntax errors

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  Tested openssh on bionic and groovy, same issue.

  The switch to systemd lost the ability to do a sanity check on the
  config file (via sshd -t) before attempting to restart sshd. This was
  originally bug #624361 in the SySV days, fixed in the initscript back
  then.

  The sysv script still does it, but it's not used anymore:
   restart)
  check_privsep_dir
  check_config
  log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd" || true

  
  And:
  check_config() {
  if [ ! -e /etc/ssh/sshd_not_to_be_run ]; then
  /usr/sbin/sshd $SSHD_OPTS -t || exit 1
  fi
  }

  
  The systemd service file has only ExecStartPre, which doesn't let it start if 
there is an error, but will happily stop it:
  [Unit]
  Description=OpenBSD Secure Shell server
  After=network.target auditd.service
  ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

  [Service]
  EnvironmentFile=-/etc/default/ssh
  ExecStartPre=/usr/sbin/sshd -t
  ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
  ExecReload=/usr/sbin/sshd -t
  ExecReload=/bin/kill -HUP $MAINPID
  ...

  Example:
  # sshd -t 
  
  # systemctl restart sshd  
  
  # telnet localhost 22 
  
  Trying 127.0.0.1...   
  
  Connected to localhost.   
  
  Escape character is '^]'. 
  
  SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3   
  
  ^]
  
  telnet> quit  
  
  Connection closed.
  

  
  # echo "syntax error" >> /etc/ssh/sshd_config 
  
  # sshd -t 
  
  /etc/ssh/sshd_config: line 123: Bad configuration option: syntax  
  
  /etc/ssh/sshd_config: terminating, 1 bad configuration options
  

  
  # systemctl restart sshd  
  
  Job for ssh.service failed because the control process exited with error 
code.  
  See "systemctl status ssh.service" and "journalctl -xe" for details.  
  

  
  # telnet localhost 22 
  
  Trying 127.0.0.1...   
  
  telnet: Unable to connect to remote host: Connection refused  
  
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1913810/+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-01-12 Thread Sergio Durigan Junior
** Changed in: sssd (Ubuntu Focal)
 Assignee: Sergio Durigan Junior (sergiodj) => Marco Trevisan (Treviño) 
(3v1n0)

-- 
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] removable [true] token present [true].
  (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found 
[MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of 
module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so].

  Then:
   1) If you previously configured SSSD match rules and/or CA certificates:
  - You should still get your certificate public key printed as output
  - Configured login with smartcard should continue working

   2) If SSSD was not configured to do smartcard authentication:
  - p11_child may fail if the card certificate was not previously added to
    the trusted DB, but this is outside of this test case.
  - What it matters is that the card is found.

  [ Regression potential ]

  While the change may involve qui

[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink

2020-12-01 Thread Sergio Durigan Junior
FWIW, the fix has just been pushed upstream:

https://sourceware.org/git/?p=binutils-
gdb.git;a=commit;h=2bf3b79d05bf85e41cbdcb020bd1cc424f59dd9a

If no one else beats me to it, I can try to backport it this weekend.

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

Title:
  gdb doesn't search in debug-file-directory for .gnu_debugaltlink

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  New
Status in gdb package in Ubuntu:
  Confirmed

Bug description:
  As far as I can tell gdb version 8.2.90 isn't searching the debug-
  file-directory, which I set, for the '.gnu_debugaltlink' which is in
  the debug symbols. Here's the error I'm seeing:

  Type "apropos word" to search for commands related to "word".
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
  Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
  could not find '.gnu_debugaltlink' file for 
/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
  (No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)

  Here's part of an strace of what's going on behind the scenes:

  lstat("/srv/vms/apport-sandbox-dir/Ubuntu 
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
 {st_mode=S_IFREG|0644, st_size=839744, ...}) = 0 
  openat(AT_FDCWD, 
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

  This is the only time "/usr/lib/debug" is searched, generally
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox/usr/lib/debug/" is used. I'll attach the full strace though.

  For completeness here's the gdb command I'm using:

  Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
  /report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
  --ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
  prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
  --ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
  19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
  /apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
  -linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
  dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
  "/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
  sandbox//usr/bin/gnome-calculator"' --ex 'core-file
  /tmp/apport_core_1b6dn6np'

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1818918/+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 1906333] [NEW] Missing dep8 tests

2020-11-30 Thread Sergio Durigan Junior
Public bug reported:

rsyslog is missing dep8 tests, which would be really good to have given
the importance of this package and the amount of delta we're currently
carrying.

** Affects: rsyslog (Ubuntu)
 Importance: Wishlist
 Status: New


** Tags: needs-dep8

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

Title:
  Missing dep8 tests

Status in rsyslog package in Ubuntu:
  New

Bug description:
  rsyslog is missing dep8 tests, which would be really good to have
  given the importance of this package and the amount of delta we're
  currently carrying.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1906333/+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 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)

2020-11-27 Thread Sergio Durigan Junior
** Changed in: util-linux (Ubuntu)
   Status: New => Fix Committed

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

Title:
  utils-linux 2.36.1 breaks user mounts (cifs)

Status in Util-Linux-ng:
  Fix Released
Status in util-linux package in Ubuntu:
  Fix Committed
Status in util-linux package in Debian:
  Unknown

Bug description:
  I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while
  running the autopkgtests for the package I noticed that two tests are
  failing.  These tests attempt to invoke mount.cifs in order to mount a
  user mount point.  I investigated and found this on dmesg:

  [   53.586709] CIFS: Attempting to mount //localhost/myshare1760
  [   53.586735] CIFS: Unknown mount option "symfollow"

  After some more investigation, I noticed that there are both a Debian
  and an upstream bug reported about this failure, and that upstream has
  fixed it in util-linux 2.36.2.

  I would be nice to have this version in hirsute so that cifs user
  mounts can work again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)

2020-11-26 Thread Sergio Durigan Junior
** Changed in: util-linux (Ubuntu)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  utils-linux 2.36.1 breaks user mounts (cifs)

Status in Util-Linux-ng:
  Fix Released
Status in util-linux package in Ubuntu:
  New
Status in util-linux package in Debian:
  Unknown

Bug description:
  I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while
  running the autopkgtests for the package I noticed that two tests are
  failing.  These tests attempt to invoke mount.cifs in order to mount a
  user mount point.  I investigated and found this on dmesg:

  [   53.586709] CIFS: Attempting to mount //localhost/myshare1760
  [   53.586735] CIFS: Unknown mount option "symfollow"

  After some more investigation, I noticed that there are both a Debian
  and an upstream bug reported about this failure, and that upstream has
  fixed it in util-linux 2.36.2.

  I would be nice to have this version in hirsute so that cifs user
  mounts can work again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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

2020-11-26 Thread Sergio Durigan Junior
Thanks for the comment, Marcin.  Yes, you're right, the correct file to
edit was ssh@.service indeed.  That was a thinko on my part.

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

Title:
  socket-activated sshd breaks on concurrent connections

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  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: sk-ecdsa-sha2-nistp...@openssh.com
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: languages ctos:
  debug2: languages stoc:
  debug2: first_kex_follows 0
  debug2: reserved 0
  debug2: peer server 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,diffie-hellman-group14-sha1
  debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: 

[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections

2020-11-26 Thread Sergio Durigan Junior
Thanks for the report.

I was able to reproduce this bug.  Basically:

$ systemctl start ssh.socket
$ ssh-keyscan localhost

Interesting enough, I wasn't able to solve the problem by setting
RuntimeDirectoryPreserve=yes.  I edited sshd.service and added the
directive there, but I still see the fatal errors on /var/log/auth.log.
Maybe I'm missing something, but I don't have the time right now to dive
deep into this.

Marcin, as Seth said above, the right way to edit a systemd unit file is
to invoke "systemctl edit", which will make sure that the new .service
file is installed in a way that won't get ovewritten when you upgrade
your package/system.  You might want to use the "--full" option when
invoking the command, which will already pre-fill the new file with the
contents of the original .service.

I'm marking this bug as Triaged and setting the priority to Medium.
Hopefully someone will be able to work on it soon.

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

Title:
  socket-activated sshd breaks on concurrent connections

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  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: sk-ecdsa-sha2-nistp...@openssh.com
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: languages ctos:
  debug2: languages stoc:
  debug2: first_kex_follows 0
  debug2: reserved 0
  debug2: peer server 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,diffie-hellman-group14-sha1
  debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
  debug2: ciphers ctos: 

[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections

2020-11-26 Thread Sergio Durigan Junior
** Changed in: openssh (Ubuntu)
   Status: New => Triaged

** Changed in: openssh (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  socket-activated sshd breaks on concurrent connections

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  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: sk-ecdsa-sha2-nistp...@openssh.com
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: languages ctos:
  debug2: languages stoc:
  debug2: first_kex_follows 0
  debug2: reserved 0
  debug2: peer server 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,diffie-hellman-group14-sha1
  debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
  debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
  debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  debug2: compression ctos: none,z...@openssh.com
  debug2: compression stoc: none,z...@openssh.com
  debug2: languages 

[Touch-packages] [Bug 1905510] Re: utils-linux 2.36.1 breaks user mounts (cifs)

2020-11-24 Thread Sergio Durigan Junior
Set priority to High because it will block samba from migrating, which
will in turn block Python 3.9 from migrating.

** Changed in: util-linux (Ubuntu)
   Importance: Undecided => High

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

Title:
  utils-linux 2.36.1 breaks user mounts (cifs)

Status in Util-Linux-ng:
  Unknown
Status in util-linux package in Ubuntu:
  New
Status in util-linux package in Debian:
  Unknown

Bug description:
  I'm working on merging samba from Debian (2:4.13.2+dfsg-1), and while
  running the autopkgtests for the package I noticed that two tests are
  failing.  These tests attempt to invoke mount.cifs in order to mount a
  user mount point.  I investigated and found this on dmesg:

  [   53.586709] CIFS: Attempting to mount //localhost/myshare1760
  [   53.586735] CIFS: Unknown mount option "symfollow"

  After some more investigation, I noticed that there are both a Debian
  and an upstream bug reported about this failure, and that upstream has
  fixed it in util-linux 2.36.2.

  I would be nice to have this version in hirsute so that cifs user
  mounts can work again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/util-linux-ng/+bug/1905510/+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


  1   2   >