[Touch-packages] [Bug 2052618] Re: Missing sftp-server argument -m force_file_perms

[Paride Legovini]

This is a duplicate of LP: #1922130, marking it as such.

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

Title:
  Missing sftp-server argument -m force_file_perms

Status in openssh package in Ubuntu:
  New

Bug description:
  In Centos, RHEL, ... openssh-server package with sftp-server has an option
  -m force_file_perms
  Sets explicit file permissions to be applied to newly-created files instead 
of the default or client requested mode. Numeric values include: 777, 755, 750, 
666, 644, 640, etc. Using both -m and -u switches makes the umask (-u) 
effective only for newly created directories and explicit mode (-m) for newly 
created files.

  This option is missing in Ubuntu 22.04.3 LTS 
  Code patch from Fedora:
  
https://src.fedoraproject.org/rpms/openssh/raw/f34/f/openssh-6.7p1-sftp-force-permission.patch

  SFTP put command is sending source filemask to the remote server as is.
  For shared folders there is a risk sender will generate a file, which another 
user can not read.
  That's why there is force_file_perms to force filemask on shared sftp 
accounts no matters what filemask had source file on client side.

  This feature is welcome to migrate from RHEL to Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh-server 1:8.9p1-3ubuntu0.6
  Uname: Linux 5.15.0-200.131.27.1.el9uek.x86_64 x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Wed Feb  7 10:22:50 2024
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
  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/2052618/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong

[Paride Legovini]

Hello and thanks for this bug report. The analysis looks sensible to me,
but I'm not really familiar with gss. To better understand the situation
I have a couple of questions:

- Does this mean that gss is unusable in Jammy at the moment? AFAICT
this is the only bug report about it, so I would be surprised.

- Are you able to test openssh from newer Ubuntu releases, ideally
including Noble (the next LTS, currently in development)? The gss patch
has been updated since Jammy, the last time on:

Last-Updated: 2023-12-18

Thanks!

** Changed in: openssh (Ubuntu)
   Status: Confirmed => 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/2053146

Title:
  openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
  slightly wrong

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  The Authmethod struct now have 4 entries but the initialization of the
  method_gsskeyex in the debian/patches/gssapi.patch only have 3
  entries.

  The struct was changed in upstream commit 
dbb339f015c33d63484261d140c84ad875a9e548 as
  ===
  @@ -104,7 +104,8 @@ struct Authctxt {
   
   struct Authmethod {
  char*name;
  -   int (*userauth)(struct ssh *);
  +   char*synonym;
  +   int (*userauth)(struct ssh *, const char *);
  int *enabled;
   };

  ===

  The incorrect code does
  ===
  +Authmethod method_gsskeyex = {
  +   "gssapi-keyex",
  +   userauth_gsskeyex,
  +   &options.gss_authentication
  +};
  ===
  but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex

  
  This is now (change from Focal) causing gssapi-keyex to be disabled.

  
  ===
  lsb_release -rd
  Description:  Ubuntu 22.04.3 LTS
  Release:  22.04

  ===
  apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
   *** 1:8.9p1-3ubuntu0.6 500
  500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-updates/main amd64 Packages
  500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-security/main amd64 Packages
  100 /var/lib/dpkg/status
   1:8.9p1-3 500
  500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main 
amd64 Packages

  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2019026] Re: systemd /tmp cleaning is suboptimal

[Paride Legovini]

FWIW I agree with Nick's preference (clean at boot && clean files older
than 30d). Maybe we could make that 40d, as 30d is likely to be a time
interval at which a lot of periodic things happen (e.g. an off-site
backup). A retention period >30d is less likely be synchronized with it
in an unlucky way.

Mounts with relatime (the default) update the atime unconditionally if
the previous atime is >1day old, so no issues with that.

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

Title:
  systemd /tmp cleaning is suboptimal

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Historically on Debian and Ubuntu, before systemd, the default
  handling of /tmp was to periodically, and at boot, remove all
  files/directories older than 30 days; and leave other contents alone.

  With the move to systemd, the "default" (really, hard-coded in
  /usr/lib/tmpfiles.d/tmp.conf) is to not clean /tmp periodically, but
  at boot to remove all contents.

  This is suboptimal for two reasons.

  By cleaning /tmp *only* at boot, if a system makes heavy use of /tmp
  and has lots of inodes under it, possibly due to failures of some
  process to clean up after itself, at boot the system will be
  unavailable for an unnecessarily long time while these files are
  removed.

  By cleaning *all* files under /tmp, this makes a reboot an Event where
  in-progress files may be unnecessarily lost.

  While the FHS does not *guarantee* that files under /tmp will persist
  across boot (because /tmp may be a tmpfs), it also does not *require*
  that /tmp be cleared on boot.

 Although data stored in /tmp may be deleted in a site-specific
 manner, it is recommended that files and directories located in
 /tmp be deleted whenever the system is booted.

 FHS added this recommendation on the basis of historical
 precedent and common practice, but did not make it a
 requirement because system administration is not within the
 scope of this standard.

  I therefore believe the correct value for /usr/lib/tmpfiles.d/tmp.conf
  to restore past behavior is 'd /tmp 1777 root root 30d'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2019026/+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 2019026] Re: systemd /tmp cleaning is suboptimal

[Paride Legovini]

AIUI he suggests keeping the boot time cleanup, and that it could be
nice to have the 30d behavior back. In any case that's what I'd prefer.
I know we're speaking of file age; certainly not of blindly deleting
everything every month or so :-)

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

Title:
  systemd /tmp cleaning is suboptimal

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Historically on Debian and Ubuntu, before systemd, the default
  handling of /tmp was to periodically, and at boot, remove all
  files/directories older than 30 days; and leave other contents alone.

  With the move to systemd, the "default" (really, hard-coded in
  /usr/lib/tmpfiles.d/tmp.conf) is to not clean /tmp periodically, but
  at boot to remove all contents.

  This is suboptimal for two reasons.

  By cleaning /tmp *only* at boot, if a system makes heavy use of /tmp
  and has lots of inodes under it, possibly due to failures of some
  process to clean up after itself, at boot the system will be
  unavailable for an unnecessarily long time while these files are
  removed.

  By cleaning *all* files under /tmp, this makes a reboot an Event where
  in-progress files may be unnecessarily lost.

  While the FHS does not *guarantee* that files under /tmp will persist
  across boot (because /tmp may be a tmpfs), it also does not *require*
  that /tmp be cleared on boot.

 Although data stored in /tmp may be deleted in a site-specific
 manner, it is recommended that files and directories located in
 /tmp be deleted whenever the system is booted.

 FHS added this recommendation on the basis of historical
 precedent and common practice, but did not make it a
 requirement because system administration is not within the
 scope of this standard.

  I therefore believe the correct value for /usr/lib/tmpfiles.d/tmp.conf
  to restore past behavior is 'd /tmp 1777 root root 30d'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2019026/+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 2019026] Re: systemd /tmp cleaning is suboptimal

[Paride Legovini]

Looks like the experiment worked: having

  e /tmp 1777 root root 30d

deleted a test directory which has mtime and atime >30d old (done via:
touch -d '29 days ago', and then left to age over the weekend).

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

Title:
  systemd /tmp cleaning is suboptimal

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Historically on Debian and Ubuntu, before systemd, the default
  handling of /tmp was to periodically, and at boot, remove all
  files/directories older than 30 days; and leave other contents alone.

  With the move to systemd, the "default" (really, hard-coded in
  /usr/lib/tmpfiles.d/tmp.conf) is to not clean /tmp periodically, but
  at boot to remove all contents.

  This is suboptimal for two reasons.

  By cleaning /tmp *only* at boot, if a system makes heavy use of /tmp
  and has lots of inodes under it, possibly due to failures of some
  process to clean up after itself, at boot the system will be
  unavailable for an unnecessarily long time while these files are
  removed.

  By cleaning *all* files under /tmp, this makes a reboot an Event where
  in-progress files may be unnecessarily lost.

  While the FHS does not *guarantee* that files under /tmp will persist
  across boot (because /tmp may be a tmpfs), it also does not *require*
  that /tmp be cleared on boot.

 Although data stored in /tmp may be deleted in a site-specific
 manner, it is recommended that files and directories located in
 /tmp be deleted whenever the system is booted.

 FHS added this recommendation on the basis of historical
 precedent and common practice, but did not make it a
 requirement because system administration is not within the
 scope of this standard.

  I therefore believe the correct value for /usr/lib/tmpfiles.d/tmp.conf
  to restore past behavior is 'd /tmp 1777 root root 30d'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2019026/+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 2052482] Re: Bad packet length 2424479189 Connection corrupted

[Paride Legovini]

Thanks for the additional information. By reading the pages Sergio
linked to I found one user writing:

  Downgrading openssh-server to version 8.0p1-19.el8_8 will
  revert the update and SSH will work again, although this
  probably not advisable.

That's definitely not advisable, but I think it's worth checking that
the older version actually works. This will help figuring out where the
problem is.

Then from https://linux.oracle.com/errata/ELSA-2024-12164.html I see
that newer openssh versions are available. Those are quite recent
(2024-02-14). Could you please test those and report your findings?

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

Title:
  Bad packet length 2424479189 Connection corrupted

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ssh-clent:
  uname -a :5.15.0-48-generic #54-Ubuntu
  ```
  Ubuntu 22.04.3 LTS
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
  ```

  ssh-server:
  ```
  OracleLinux 8.9
  OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
  ```

  ```
  userxxx@userxxx-H3C-X7-030s-0274:~$ ssh 192.168.xxx.xxx -vvv
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, 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 *
  debug2: resolve_canonicalize: hostname 192.168.xxx.xxx is address
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 
'/home/userxxx/.ssh/known_hosts'
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
'/home/userxxx/.ssh/known_hosts2'
  debug3: ssh_connect_direct: entering
  debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
  debug3: set_sock_tos: set socket 3 IP_TOS 0x10
  debug1: Connection established.
  debug1: identity file /home/userxxx/.ssh/id_rsa type 0
  debug1: identity file /home/userxxx/.ssh/id_rsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa type 2
  debug1: identity file /home/userxxx/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519 type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
  debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x0400
  debug2: fd 3 setting O_NONBLOCK
  debug1: Authenticating to 192.168.xxx.xxx:22 as 'userxxx'
  debug3: record_hostkey: found key type ED25519 in file 
/home/userxxx/.ssh/known_hosts:20
  debug3: load_hostkeys_file: loaded 1 keys from 192.168.xxx.xxx
  debug1: load_hostkeys: fopen /home/userxxx/.ssh/known_hosts2: No such file or 
directory
  debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or 
directory
  debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or 
directory
  debug3: order_hostkeyalgs: have matching best-preference key type 
ssh-ed25519-cert-...@openssh.com, using HostkeyAlgorithms verbatim
  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,sntrup761x25519-sha...@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-...@openssh.com
  debug2: host key algorithms: 
ssh-ed25519-cert-...@openssh.com,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,sk-ssh-ed25519-cert-...@openssh.com,sk-ecdsa-sha2-nistp256-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,rsa-sha2-512,rsa-sha2-256
  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

[Touch-packages] [Bug 2054823] Re: Sync klibc 2.0.13-4 (main) from Debian unstable (main)

[Paride Legovini]

** Changed in: klibc (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  Sync klibc 2.0.13-4 (main) from Debian unstable (main)

Status in klibc package in Ubuntu:
  New

Bug description:
  Please sync klibc 2.0.13-4 (main) from Debian unstable (main)

  Explanation of the Ubuntu delta and why it can be dropped:
[ Klaus Frank ]
* d/i/h/klibc-utils: Fix compatibility issue with busybox and improve 
verbose debug output.
  (Closes: #1055694) (LP: #2046336)

  This patch provided one way to fix the `cp -n` incompatibility. The changelog
  below mentions another change with the same purpose. I've also checked the 
code,
  and that new version from Debian correctly doesn't use `cp -n`, which means
  it will be safe to use with any version of coreutils, older or newer than the
  change of semantic in `cp -n`.

  
  Changelog entries since current noble version 2.0.13-2ubuntu1:

  klibc (2.0.13-4) unstable; urgency=medium

[ Sven Joachim ]
* debian/initramfs-tools/hooks/klibc-utils: Avoid the use of "cp -n"
  (Closes: #1055694).

[ Salvatore Bonaccorso ]
* debian/control: Add myself to Uploaders

   -- Salvatore Bonaccorso   Wed, 21 Feb 2024
  13:08:58 +0100

  klibc (2.0.13-3) experimental; urgency=medium

* Install klibc shared library in /usr/lib

   -- Ben Hutchings   Sat, 25 Nov 2023 00:49:35 +

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/2054823/+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 2054823] Re: Sync klibc 2.0.13-4 (main) from Debian unstable (main)

[Paride Legovini]

klibc (2.0.13-4) unstable; urgency=medium

  [ Sven Joachim ]
  * debian/initramfs-tools/hooks/klibc-utils: Avoid the use of "cp -n"
(Closes: #1055694).

  [ Salvatore Bonaccorso ]
  * debian/control: Add myself to Uploaders

Date: 2024-02-21 22:32:43.744541+00:00
Signed-By: Paride Legovini 
https://launchpad.net/ubuntu/+source/klibc/2.0.13-4

==

 OK: klibc_2.0.13-4.dsc
 -> Component: main Section: libs
 OK: klibc_2.0.13.orig.tar.xz
 OK: klibc_2.0.13-4.debian.tar.xz

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

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

Title:
  Sync klibc 2.0.13-4 (main) from Debian unstable (main)

Status in klibc package in Ubuntu:
  Fix Released

Bug description:
  Please sync klibc 2.0.13-4 (main) from Debian unstable (main)

  Explanation of the Ubuntu delta and why it can be dropped:
[ Klaus Frank ]
* d/i/h/klibc-utils: Fix compatibility issue with busybox and improve 
verbose debug output.
  (Closes: #1055694) (LP: #2046336)

  This patch provided one way to fix the `cp -n` incompatibility. The changelog
  below mentions another change with the same purpose. I've also checked the 
code,
  and that new version from Debian correctly doesn't use `cp -n`, which means
  it will be safe to use with any version of coreutils, older or newer than the
  change of semantic in `cp -n`.

  
  Changelog entries since current noble version 2.0.13-2ubuntu1:

  klibc (2.0.13-4) unstable; urgency=medium

[ Sven Joachim ]
* debian/initramfs-tools/hooks/klibc-utils: Avoid the use of "cp -n"
  (Closes: #1055694).

[ Salvatore Bonaccorso ]
* debian/control: Add myself to Uploaders

   -- Salvatore Bonaccorso   Wed, 21 Feb 2024
  13:08:58 +0100

  klibc (2.0.13-3) experimental; urgency=medium

* Install klibc shared library in /usr/lib

   -- Ben Hutchings   Sat, 25 Nov 2023 00:49:35 +

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/2054823/+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 2054716] Re: package polkitd 124-1 failed to install/upgrade: installed polkitd package post-installation script subprocess returned error exit status 1

[Paride Legovini]

** Changed in: policykit-1 (Ubuntu)
   Importance: Undecided => High

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

Title:
  package polkitd 124-1 failed to install/upgrade: installed polkitd
  package post-installation script subprocess returned error exit status
  1

Status in policykit-1 package in Ubuntu:
  Confirmed

Bug description:
  I was working on recreating bug 2054319 and did so by modifying my
  /etc/apt/sources.list file from jammy to noble and installing polkit
  and all its dependencies.

  bdmurray@clean-jammy-amd64:~$ sudo apt-get install gir1.2-polkit-1.0 
libpolkit-agent-1-0:amd64 libpolkit-gobject-1-0:amd64 pkexec policykit-1 polkitd
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
linux-headers-6.2.0-26-generic linux-headers-6.2.0-36-generic 
linux-headers-6.5.0-14-generic
linux-hwe-6.2-headers-6.2.0-26 linux-hwe-6.2-headers-6.2.0-36 
linux-hwe-6.5-headers-6.5.0-14 linux-image-6.2.0-26-generic
linux-image-6.2.0-36-generic linux-image-6.5.0-14-generic 
linux-modules-6.2.0-26-generic linux-modules-6.2.0-36-generic
linux-modules-6.5.0-14-generic linux-modules-extra-6.2.0-26-generic 
linux-modules-extra-6.2.0-36-generic
linux-modules-extra-6.5.0-14-generic
  Use 'sudo apt autoremove' to remove them.
  The following additional packages will be installed:
libc-bin libc-dev-bin libc-devtools libc6 libc6-dbg libc6-dev libduktape207 
libgcrypt20 libglib2.0-0 libglib2.0-bin
libnss-systemd libpam-systemd libsystemd-shared libsystemd0 libudev1 
libzstd1 locales systemd systemd-dev systemd-oomd
systemd-resolved systemd-sysv systemd-timesyncd udev
  Suggested packages:
glibc-doc rng-tools low-memory-monitor polkitd-pkla systemd-container 
systemd-homed systemd-userdbd systemd-boot
libqrencode4 libtss2-rc0
  Recommended packages:
libnss-nis libnss-nisplus
  The following NEW packages will be installed:
libduktape207 libsystemd-shared systemd-dev systemd-resolved
  The following packages will be upgraded:
gir1.2-polkit-1.0 libc-bin libc-dev-bin libc-devtools libc6 libc6-dbg 
libc6-dev libgcrypt20 libglib2.0-0 libglib2.0-bin
libnss-systemd libpam-systemd libpolkit-agent-1-0 libpolkit-gobject-1-0 
libsystemd0 libudev1 libzstd1 locales pkexec
policykit-1 polkitd systemd systemd-oomd systemd-sysv systemd-timesyncd udev
  26 upgraded, 4 newly installed, 0 to remove and 1407 not upgraded.
  Need to get 34.9 MB of archives.

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: polkitd 124-1
  ProcVersionSignature: Ubuntu 6.5.0-18.18~22.04.1-generic 6.5.8
  Uname: Linux 6.5.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckMismatches: ./boot/grub/grub.cfg
  CasperMD5CheckResult: fail
  Date: Thu Feb 22 08:46:48 2024
  ErrorMessage: installed polkitd package post-installation script subprocess 
returned error exit status 1
  InstallationDate: Installed on 2023-11-02 (112 days ago)
  InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 
(20230807.2)
  Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.2
   apt  2.4.11
  SourcePackage: policykit-1
  Title: package polkitd 124-1 failed to install/upgrade: installed polkitd 
package post-installation script subprocess returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/2054716/+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 2054683] Re: Please merge lvm2 2.03.16-3 from Debian unstable.

[Paride Legovini]

** Changed in: lvm2 (Ubuntu)
   Status: New => In Progress

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

Title:
  Please merge lvm2 2.03.16-3 from Debian unstable.

Status in lvm2 package in Ubuntu:
  In Progress

Bug description:
  Please merge lvm2 2.03.16-3 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054683/+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 2054620] Re: libdm returns wrong error code when dm-verity key cannot be found

[Paride Legovini]

I just sponsored lvm2 2.03.16-3ubuntu1 which should fix the FTBFS.

On including libdm-propagate-ioctl-errors-back-to-caller.patch: I am not
sure this bug is important enough to grant that. The patch may apply
cleanly to 2.03.16, but still it comes from 2.03.23, which is not a
trivial change in the upstream codebase.

I can see that better error messages on ENOKEY will result in an overall
better UX, however most commits in an upstream devel repo will somehow
improve something, still we try to rely on releases as cut by upstream
when possible, for the many reasons I certainly don't have to tell you
about. :-)

However: I may have missed the point here, and maybe the current UX is
both (1) terrible, or at least quite bad (2) affecting many users, and
not only users with an niche disk encryption configuration. If you think
this is the case, can you please update the bug and elaborate a bit more
on it?

Thanks!

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

Title:
  libdm returns wrong error code when dm-verity key cannot be found

Status in lvm2 package in Ubuntu:
  Confirmed
Status in lvm2 source package in Noble:
  Confirmed

Bug description:
  When libcryptsetup tries to activate a signed dm-verity volume, and
  the key is not in the kernel keyring, libdevicemapper does not return
  the appropriate ENOKEY, so the failure cannot be distinguished from
  other generic issues.

  This is fixed in the lvm2 version 2.03.23 upstream release.

  Please consider backporting this patch for Noble.

  Upstream PR: https://gitlab.com/lvmteam/lvm2/-/merge_requests/3
  Upstream commit: 25ef7a7b1a876f491bd361369423d7309358f6c1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054620/+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 2054683] Re: Please merge lvm2 2.03.16-3 from Debian unstable.

[Paride Legovini]

Uploaded and accepted:

==

 OK: lvm2_2.03.16.orig.tar.xz
 OK: lvm2_2.03.16-3ubuntu1.debian.tar.xz
 OK: lvm2_2.03.16-3ubuntu1.dsc
 -> Component: main Section: admin

** Changed in: lvm2 (Ubuntu)
 Assignee: (unassigned) => Dave Jones (waveform)

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

Title:
  Please merge lvm2 2.03.16-3 from Debian unstable.

Status in lvm2 package in Ubuntu:
  In Progress

Bug description:
  Please merge lvm2 2.03.16-3 from Debian unstable.

  Updated changelog and diff against Debian unstable to be attached
  below.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/2054683/+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 2054916] Re: CVE-2022-44640 affects the version of heimdal on ubuntu 22.04 - could it be updated?

[Paride Legovini]

** Also affects: heimdal (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: heimdal (Ubuntu Jammy)
   Importance: Undecided
   Status: New

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

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

** Changed in: heimdal (Ubuntu)
   Status: Triaged => 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/2054916

Title:
  CVE-2022-44640 affects the version of heimdal on ubuntu 22.04 - could
  it be updated?

Status in heimdal package in Ubuntu:
  Fix Released
Status in heimdal source package in Focal:
  Fix Released
Status in heimdal source package in Jammy:
  Triaged

Bug description:
  I am running ubuntu 22.04. The version of heimdal installed (7.7.0) is
  vunerable to CVE-2022-44640, which is categorised as critical by some
  (crowdstrike falcon at least). Is is possible to upgrade it to some
  non-vulnerable version?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/2054916/+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 2054908] Re: gpg-wks-server pulls in postfix

[Paride Legovini]

** Changed in: auto-package-testing
 Assignee: (unassigned) => Paride Legovini (paride)

** Changed in: auto-package-testing
   Status: New => Fix Released

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

Title:
  gpg-wks-server pulls in postfix

Status in Auto Package Testing:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Won't Fix
Status in munin package in Ubuntu:
  Invalid
Status in ubuntu-release-upgrader package in Ubuntu:
  Confirmed

Bug description:
  Example 1
  
  I did a sudo apt dist-upgrade today on my developer machine running Ubuntu 
Desktop 24.04 LTS and it surprisingly pulled in postfix.

  I did not built this into a full reproducible test case because I
  found another test case…

  Example 2
  
  munin's autopkgtests are now failing because postfix is now unexpectedly 
being installed.

  https://autopkgtest.ubuntu.com/packages/munin/noble/amd64

  Other Info
  
  gnupg2's changelog indicates that there was an attempt to avoid this 
misbehavior by having gnupg only Suggest gpg-wks-server. In fact, there is 
**nothing** in Ubuntu 24.04 LTS that Depends or Recommends gpg-wks-server.

  I added a munin bug task as a pointer in case anyone wonder's about
  the autopkgtest regression but I don't believe munin needs any
  changes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/2054908/+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 2052482] Re: Bad packet length 2424479189 Connection corrupted

[Paride Legovini]

I am not sure I fully understand the latest comment. Does it mean that
8.0p1-19.0.1 just works? What about 8.0p1-19.0.1.2, mentioned in [1]?

[1] https://linux.oracle.com/errata/ELSA-2024-12164.html

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

Title:
  Bad packet length 2424479189 Connection corrupted

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ssh-clent:
  uname -a :5.15.0-48-generic #54-Ubuntu
  ```
  Ubuntu 22.04.3 LTS
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
  ```

  ssh-server:
  ```
  OracleLinux 8.9
  OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
  ```

  ```
  userxxx@userxxx-H3C-X7-030s-0274:~$ ssh 192.168.xxx.xxx -vvv
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, 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 *
  debug2: resolve_canonicalize: hostname 192.168.xxx.xxx is address
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 
'/home/userxxx/.ssh/known_hosts'
  debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
'/home/userxxx/.ssh/known_hosts2'
  debug3: ssh_connect_direct: entering
  debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
  debug3: set_sock_tos: set socket 3 IP_TOS 0x10
  debug1: Connection established.
  debug1: identity file /home/userxxx/.ssh/id_rsa type 0
  debug1: identity file /home/userxxx/.ssh/id_rsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa type 2
  debug1: identity file /home/userxxx/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519 type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/userxxx/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss type -1
  debug1: identity file /home/userxxx/.ssh/id_xmss-cert type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa type -1
  debug1: identity file /home/userxxx/.ssh/id_dsa-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
  debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
  debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x0400
  debug2: fd 3 setting O_NONBLOCK
  debug1: Authenticating to 192.168.xxx.xxx:22 as 'userxxx'
  debug3: record_hostkey: found key type ED25519 in file 
/home/userxxx/.ssh/known_hosts:20
  debug3: load_hostkeys_file: loaded 1 keys from 192.168.xxx.xxx
  debug1: load_hostkeys: fopen /home/userxxx/.ssh/known_hosts2: No such file or 
directory
  debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or 
directory
  debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or 
directory
  debug3: order_hostkeyalgs: have matching best-preference key type 
ssh-ed25519-cert-...@openssh.com, using HostkeyAlgorithms verbatim
  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,sntrup761x25519-sha...@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-...@openssh.com
  debug2: host key algorithms: 
ssh-ed25519-cert-...@openssh.com,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,sk-ssh-ed25519-cert-...@openssh.com,sk-ecdsa-sha2-nistp256-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,rsa-sha2-512,rsa-sha2-256
  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.co

[Touch-packages] [Bug 1197754] Re: print lxc-start-ephemeral container name in a machine-readable way

[Paride Legovini]

With 0b4c5056925e7358374874c8bf4767290157e903 (in autopkgtest 5.33) lxc-
start-ephemeral is not called anymore.

** Changed in: autopkgtest (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

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

Title:
  print lxc-start-ephemeral container name in  a machine-readable way

Status in autopkgtest package in Ubuntu:
  Fix Committed
Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  A script cannot call lxc-start-ephemeral and get a named container in
  a reliable, race-free way.

  Having the caller specify a name directly is racy, since the name
  could have been taken in between checking that it doesn't exist
  already and calling lxc-start-ephemeral.

  Allowing lxc-start-ephemeral allows it to take care of the mkdir (and
  retries) to generate an LXC container name in a race free manner, but
  this needs -d to return the name in a machine-readable way, so that we
  can create ephemeral LXC containers from scripts.

  Please add a machine-readable mechanism to "lxc-start-ephemeral -d"
  and then we can modify adt-virt-lxc to use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1197754/+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 2060150] Re: openssh sets PAM_RHOST to UNKNOWN causing slow logins

[Paride Legovini]

** Tags added: 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/2060150

Title:
  openssh sets PAM_RHOST to UNKNOWN causing slow logins

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  When using sshd's -i option with stdio that is not a AF_INET/AF_INET6
  socket, auth_get_canonical_hostname() returns "UNKNOWN" which is then
  set as the value of PAM_RHOST, causing pam to try to do a reverse DNS
  query of "UNKNOWN", which times out multiple times, causing a
  substantial slowdown when logging in.

  upstream PR: https://github.com/openssh/openssh-portable/pull/388
  upstream email: 
https://lists.mindrot.org/pipermail/openssh-unix-dev/2024-April/041289.html
  Fedora backport: https://src.fedoraproject.org/rpms/openssh/pull-request/71
  Debian backport: https://salsa.debian.org/ssh-team/openssh/-/merge_requests/25

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2060150/+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 1991592] Re: openssh-server should ship a systemd generator to generate ssh socket port configuration from sshd_config

[Paride Legovini]

I believe this is fixed in:

openssh (1:9.6p1-3ubuntu3) noble; urgency=medium

  * Add sshd-socket-generator to generate ssh.socket drop-in configuration
  [...]

>From README.Debian:

The provided ssh.socket unit file sets ListenStream=22. A systemd generator,
sshd-socket-generator, parses the sshd configuration and, if non-default
ListenAddress(s) or Port(s) are configured, generates corresponding
ListenStream= lines in a drop-in configration file for ssh.socket. 

So marking this as Fix Released.

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

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

Title:
  openssh-server should ship a systemd generator to generate ssh socket
  port configuration from sshd_config

Status in openssh package in Ubuntu:
  Fix Released

Bug description:
  A criticism of the existing sshd socket activation implementation is
  that Port/ListenAddress options are migrated on a one-time basis at
  package upgrade time, and afterwards users get the surprising behavior
  that Port/ListenAddress settings added to sshd_config are ignored.

  A systemd generator could be used to change the ssh socket unit
  configuration on boot, and on each change of /etc/ssh/sshd_config.
  Sample implementation from Dimitri:

  ssh.socket:
  [Unit]
  Wants=sshd-config.path

  #
  # Note the below defaults are cleared and overriden by
  #/lib/systemd/system-generators/sshd-generator
  # based on the sshd config from the sshd -T output
  #
  ListenStream=[::]:22
  ListenStream=0.0.0.0:22

  diff --git a/systemd/sshd-config.path b/systemd/sshd-config.path
  new file mode 100644
  index 0..cfa9674a3
  --- /dev/null
  +++ b/systemd/sshd-config.path
  @@ -0,0 +1,4 @@
  +[Unit]
  +ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
  +[Path]
  +PathChanged=/etc/ssh/sshd_config
  diff --git a/systemd/sshd-config.service b/systemd/sshd-config.service
  new file mode 100644
  index 0..b009ea52c
  --- /dev/null
  +++ b/systemd/sshd-config.service
  @@ -0,0 +1,5 @@
  +[Unit]
  +Description=Regenerate ssh.socket.d/ssh-listen.conf drop-in
  +
  +[Service]
  +ExecStart=/bin/systemctl daemon-reload
  diff --git a/systemd/sshd-generator b/systemd/sshd-generator
  new file mode 100755
  index 0..72c6aac04
  --- /dev/null
  +++ b/systemd/sshd-generator
  @@ -0,0 +1,10 @@
  +#!/bin/sh
  +set -eu
  +mkdir -p /run/sshd
  +sshd -t
  +mkdir -p $1/ssh.socket.d
  +target="$1/ssh.socket.d/ssh-listen.conf"
  +echo '[Socket]' > $target
  +echo 'ListenStream=' >> $target
  +sshd -T | sed -n 's/^listenaddress /ListenStream=/p' >> $target
  +rmdir --ignore-fail-on-non-empty /run/sshd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1991592/+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 2059796] Re: Other Software > Remove button doesn't work

[Paride Legovini]

Hello Nathan,

the diff LGTM, I just have two questions:

1. The bug description has a "test case", but that's more of a
reproducer than of a test case, right? The "expected result" is not
explicitly stated. In particular, looking at this step:

 - After Authentication, nothing happens.

what should happen instead? And, on:

  The repo line still shows.
  The repo is still in /etc/apt/sources.list.d/

the expected behavior is that the repo is gone, right?

Can you please make this more explicit and state that you actually
verified the fix that way?

Thanks!

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

Title:
  Other Software > Remove button doesn't work

Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  Test Case
  -
  - Add a PPA with apt-add-repository, not with software-properties (we want a 
deb822 format for the test).
  - Open the Software & Updates tab
  - Switch to the Other Software tab
  - Select the PPA line and click Remove
  - After Authentication, nothing happens.

  No error is emitted to the command line. The repo line still shows.
  The repo is still in /etc/apt/sources.list.d/

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.44
  ProcVersionSignature: Ubuntu 6.8.0-20.20-generic 6.8.1
  Uname: Linux 6.8.0-20-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 29 12:06:07 2024
  InstallationDate: Installed on 2022-04-06 (723 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Daily amd64 (20220405)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to noble on 2023-12-09 (111 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2059796/+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 2059796] Re: Other Software > Remove button doesn't work

[Paride Legovini]

** Changed in: software-properties (Ubuntu)
 Assignee: (unassigned) => Nathan Teodosio (nteodosio)

** Changed in: software-properties (Ubuntu)
   Status: Triaged => In Progress

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

Title:
  Other Software > Remove button doesn't work

Status in software-properties package in Ubuntu:
  In Progress

Bug description:
  Test Case
  -
  - Add a PPA with apt-add-repository, not with software-properties (we want a 
deb822 format for the test).
  - Open the Software & Updates tab
  - Switch to the Other Software tab
  - Select the PPA line and click Remove
  - After Authentication, nothing happens.

  No error is emitted to the command line. The repo line still shows.
  The repo is still in /etc/apt/sources.list.d/

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.44
  ProcVersionSignature: Ubuntu 6.8.0-20.20-generic 6.8.1
  Uname: Linux 6.8.0-20-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 29 12:06:07 2024
  InstallationDate: Installed on 2022-04-06 (723 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Daily amd64 (20220405)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to noble on 2023-12-09 (111 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2059796/+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 2059796] Re: Other Software > Remove button doesn't work

[Paride Legovini]

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading software-properties_0.99.47.dsc: done.
  Uploading software-properties_0.99.47.tar.xz: done.
  Uploading software-properties_0.99.47_source.buildinfo: done.  
  Uploading software-properties_0.99.47_source.changes: done.
Successfully uploaded packages.


** Changed in: software-properties (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  Other Software > Remove button doesn't work

Status in software-properties package in Ubuntu:
  Fix Committed

Bug description:
  Test Case
  -
  - Add a PPA with apt-add-repository, not with software-properties (we want a 
deb822 format for the test).
  - Open the Software & Updates tab
  - Switch to the Other Software tab
  - Select the PPA line and click Remove
  - After Authentication, nothing happens.

  No error is emitted to the command line. The repo line still shows.
  The repo is still in /etc/apt/sources.list.d/

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: software-properties-gtk 0.99.44
  ProcVersionSignature: Ubuntu 6.8.0-20.20-generic 6.8.1
  Uname: Linux 6.8.0-20-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Mar 29 12:06:07 2024
  InstallationDate: Installed on 2022-04-06 (723 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Daily amd64 (20220405)
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: software-properties
  UpgradeStatus: Upgraded to noble on 2023-12-09 (111 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2059796/+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 2049529] Re: Extra ZFS-related log line with `useradd -m -R /path`

[Paride Legovini]

This also affects src:adduser, which has this delta:

+if ($action eq "adduser") {
+# Mute the command
+system('sh' => ( '-c' => '"$@" >/dev/null 2>&1', '--', 
'/usr/sbin/zsysctl', 'userdata', 'create', $new_name, $home_dir,));
+}

causing it to fail in minimal environments where /dev is non populated.

In practice we are hitting this with autopkgtest-virt-unshare(1), which
tries to create a user in the chroot, but fails because of that.

** Also affects: adduser (Ubuntu)
   Importance: Undecided
   Status: New

** Summary changed:

- Extra ZFS-related log line with `useradd -m -R /path`
+ Ubuntu delta causes `can't open /dev/null: No such file or directory` errors 
in minimal environments (chroot/unshare)

** Changed in: adduser (Ubuntu Noble)
   Status: New => Confirmed

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

Title:
  Ubuntu delta causes `can't open /dev/null: No such file or directory`
  errors in minimal environments (chroot/unshare)

Status in adduser package in Ubuntu:
  Confirmed
Status in shadow package in Ubuntu:
  Confirmed
Status in adduser source package in Noble:
  Confirmed
Status in shadow source package in Noble:
  Confirmed

Bug description:
  Hi,

  I was digging into fixing `autopkgtest`'s `unshare` testsuite, and the
  rabbit hole led me here.

  Here is a very quick reproducer, first:

  Start a fresh Ubuntu VM. Here is a quick path, but other ways should do fine:
  ```
  $ cd /tmp
  $ autopkgtest-buildvm-ubuntu-cloud -a amd64 -r noble
  $ kvm -m 1G -snapshot -hda autopkgtest-noble-amd64.img
  ```

  Now in the VM:
  ```
  $ sudo apt install -y mmdebstrap
  $ mmdebstrap noble /tmp/rootfs
  [...]
  $ sudo useradd --create-home --root /tmp/rootfs user1
  can't open /dev/null: No such file or directory
  ```

  The line `can't open /dev/null: No such file or directory` is printed
  on `stderr`, and that's unexpected by the part of the code I was
  debugging in the first place.

  Digging a bit led me to that line that does the printing:
  
https://git.launchpad.net/ubuntu/+source/shadow/tree/debian/patches/1015_add_zsys_support.patch#n69

  There seem to me that there are multiple issues with that patch:
  * Why try to call `zsysctl` in every case without first checking that it 
would be relevant: ZFS is not even installed on the VM we just created, less 
alone it has any ZFS volume/pool/whatever.
  * Obviously, when creating a user in a `chroot`, `/dev/null` won't exist 
unless mapped, and `useradd` is perfectly aware of that, because it even does 
the `chroot` call itself! But why even try to mess with ZFS in the `chroot` 
case in the first place?

  From what history @brian-murray told me, this patch was part of some
  ZFS experimentation in the past. Maybe that experimentation is now
  finished, and that patch could be dropped? At the very least it needs
  improvements, imho.

  EDIT: Just for context on why this issue appears only now: I was
  trying to fix the `unshare` testsuite in `autopkgtest`, which is
  pretty recent (2022) (https://salsa.debian.org/ci-
  team/autopkgtest/-/commit/d1671f94f68bce9a0c6793310a9f8b79b4e919a5)
  even upstream on Debian, and has never worked yet on Ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/2049529/+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 1923845] Re: Please compress packages with zstd by default

[Paride Legovini]

aptly is Fix Release in Kinetic in:

aptly (1.4.0+ds1-7) unstable; urgency=medium

  * Team upload.
  * Add support for zstd compression (Closes: #1010465)


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

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

Title:
  Please compress packages with zstd by default

Status in appstream-glib package in Ubuntu:
  New
Status in apt package in Ubuntu:
  Fix Released
Status in aptly package in Ubuntu:
  Fix Released
Status in boinc package in Ubuntu:
  New
Status in busybox package in Ubuntu:
  New
Status in cdebootstrap package in Ubuntu:
  New
Status in cdist package in Ubuntu:
  New
Status in debdelta package in Ubuntu:
  New
Status in debian-el package in Ubuntu:
  New
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debsig-verify package in Ubuntu:
  New
Status in debsigs package in Ubuntu:
  New
Status in diffoscope package in Ubuntu:
  Fix Released
Status in dpkg package in Ubuntu:
  Fix Released
Status in dpkg-sig package in Ubuntu:
  New
Status in file package in Ubuntu:
  New
Status in hello package in Ubuntu:
  Fix Released
Status in libsolv package in Ubuntu:
  New
Status in lintian package in Ubuntu:
  Fix Released
Status in lutris package in Ubuntu:
  Invalid
Status in obs-build package in Ubuntu:
  New
Status in osc package in Ubuntu:
  New
Status in python-debian package in Ubuntu:
  Fix Released
Status in radare2 package in Ubuntu:
  New
Status in reprepro package in Ubuntu:
  Fix Released
Status in vim-scripts package in Ubuntu:
  New
Status in zeroinstall-injector package in Ubuntu:
  New
Status in reprepro source package in Focal:
  Fix Released
Status in reprepro source package in Groovy:
  Fix Released
Status in reprepro source package in Hirsute:
  Fix Released
Status in debian-el package in Debian:
  New

Bug description:
  https://people.canonical.com/~rbalint/zstd-debs/ contains a .deb built
  on Hirsute having both data and control members of the .deb being
  compressed with zstd. It can be handy for testing various tools.

  [dpkg]
  Decompression support in dpkg landed first in Bionic and is being SRUd to 
Xenial in LP: #1764220 enable Launchpad's Xenial systems to process the 
zstd-compressed binary packages.
  From dpkg's perspective the upgrade path is cleared.

  The original plan was compressing only the internal data.tar .deb
  member, but dpkg uses uniform compression by default since dpkg 1.19.0
  thus I'm collecting all the changes to support control.tar.zst, too,
  in this bug.

  Reviewed packages from:
  https://codesearch.debian.net/search?q=data.tar.xz&literal=1&perpkg=1
  https://codesearch.debian.net/search?q=control.tar.xz&literal=1&perpkg=1

  appstream-glib  - needs fix: libappstream-builder/asb-package-deb.c
  aptly   - needs fix: deb/deb.go
  boinc   - needs fix: debian/fetch_example_applications.sh
  busybox - needs fix: archival/dpkg_deb.c archival/dpkg.c
  cdebootstrap- needs fix: src/package.c
  cdist   - may need fix, can use dpkg-deb: 
cdist/preos/debootstrap/files/devuan-debootstrap/functions
  debdelta- needs fix: debdelta debpatch.sh
  debian-el   - needs fix: deb-view.el
  debian-handbook - needs fix, maybe later, for Debian
  debootstrap - needs fix, 
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/54
  debsigs - needs fix, debsigs
  debsig-verify   - needs fix, src/debsig-verify.c
  diffoscope  - needs fix, diffoscope/comparators/deb.py
  dpkg- needs fix, change default
  dpkg-sig- needs fix, dpkg-sig
  dpmb- needs fix, maybe later, for Debian
  elfutils- may need fix, uses dpkg-deb if it is available, does not 
handle .gz either
  file- needs fix, magic/Magdir/archive
  libsolv - needs fix, ext/repo_deb.c
  lintian - needs fix malformed-deb-archive
  lutris  - needs fix, lutris/util/extract.py
  obs-build   - needs fix Build/Deb.pm
  osc - needs fix osc/util/debquery.py control.tar.zst only
  python-apt  - needs fix 
apt_inst.DebFile("glibc-doc-reference_2.33-0ubuntu2~zstd1_all.deb").control.extractall()
  radare2 - needs fix
  reprepro- needs fix, debfile.c
  vim-scripts - needs fix debPlugin/autoload/deb.vim
  winetricks  - needs fix when Debian switches src/winetricks
  zeroinstall-injector - needs fix src/zeroinstall/archive.ml

  acr - skip, does not _have to_ be fixed, just creates packages, 
see dist/deb_hand.mak
  alien   - skip, uses dpkg-deb to extract .deb
  ansible - not affected, just test data in dbdata.tar.xz
  anthy   - not affected, just changelog entry
  apt - seems fixed already
  ceph- not affected in Ubuntu's version
  circlator   - not affected, just test data

[Touch-packages] [Bug 1978816] Re: sshd: ClientAliveCountMax=0 not honoured as expected

[Paride Legovini]

Hello James and thanks for your bug report. The "Make
ClientAliveCountMax=0 have sensible semantics" change you refer to is
actually an upstream change, see the OpenSSH bugfixes here:

  https://www.openssh.com/releasenotes.html

the upstream bug being:

  https://bugzilla.mindrot.org/show_bug.cgi?id=2627

which has a comment similar to yours here.

Even if the new behavior may be sometimes inconvenient I don't think
we're going to make Ubuntu deviate from what upstream does (for reasons
you clearly understand). As an Ubuntu bug I think this is Invalid, but
I'm marking it as Incomplete for now. Please comment back if there's
anything I missed or misunderstood, or mark this report as Invalid if
you agree with my findings. Thanks!

** Bug watch added: OpenSSH Portable Bugzilla #2627
   https://bugzilla.mindrot.org/show_bug.cgi?id=2627

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

Title:
  sshd: ClientAliveCountMax=0 not honoured as expected

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  $ apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.2p1-4ubuntu0.4
Candidate: 1:8.2p1-4ubuntu0.4

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.4 LTS
  Release:20.04
  Codename:   focal

  After upgrading from 'bionic' the openssh ClientAlive* parameters are
  not functioning as expected in sshd:

  /etc/ssh/sshd_config:ClientAliveInterval 900
  /etc/ssh/sshd_config:ClientAliveCountMax 0

  The expected behaviour is that after 900s with no traffic in the
  session the server terminates the connection.  There appears to be a
  custom patch in the package which changes this:

  - sshd(8): Make ClientAliveCountMax=0 have sensible semantics: it will
now disable connection killing entirely rather than the current
behaviour of instantly killing the connection after the first liveness
test regardless of success.

  It is unclear why this is a beneficial change in the default behaviour
  of sshd.  If the user doesn't want the session disconnected then they
  should set ClientAliveInterval=0.  It also defeats our requirement to
  have idle ssh sessions terminated when nothing has been done for 15
  minutes.

  It is tempting to mark this as a security issue due to unexpected
  change in behaviour and the fact it would leave idle sessions open
  whereas a vanilla ssh package would close them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1978816/+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 1974483] Re: autoinstall ssh:install-server:false is misleading in 22.04

[Paride Legovini]

Confirmed still happening on the Jammy 20220719 daily.

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

Title:
  autoinstall ssh:install-server:false is misleading in 22.04

Status in subiquity:
  Triaged
Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Jammy:
  New

Bug description:
  With 22.04, openssh-server is baked into the image curtin copies to
  the target.  The ssh:install-server key no longer controls whether
  openssh-server gets installed.  It should be easy enough to have the
  bit of code that installs openssh-server when the key is true also
  remove it when the key is false.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1974483/+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 1979879] Re: Apparmor profile in 22.04 jammy - fails to start when printing enabled

[Paride Legovini]

I see your point, and I find the one about "fixing it the Kinetic way"
especially convincing, it may save us headaches in the future, and may
help with backports. My concern is that other packages or scripts users
wrote and tested on Jammy systems refer to the "wrong" path
(/usr/lib/x86_64-linux-gnu/...). If we want to fix samba I think this is
the commit to cherry-pick

https://salsa.debian.org/samba-
team/samba/-/commit/3e8438ca59263aee8a2599b47a0dccf2d395e1f4

Note that speaking of binaries the commit message says

  Some of them are callable from other packages, and some
  others are specified in config files.

and that's what I'm a bit worried about. OTOH there may be packages in
Ubuntu that got merged from Debian and that already refer to the "right"
(libexec/...) path. So I think that to make fixing samba definitely
safer/better than fixing apparmor we should

 - Check which binaries are affected by the path change
 - Check how they're meant to be user facing
 - Check if and how other packages are calling them.
   https://codesearch.debian.net/ may help here.

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

Title:
  Apparmor profile in 22.04 jammy - fails to start when printing enabled

Status in apparmor package in Ubuntu:
  Invalid
Status in samba package in Ubuntu:
  Fix Released
Status in apparmor source package in Jammy:
  Triaged
Status in samba source package in Jammy:
  Triaged

Bug description:
  See bug here:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1191532

  Fix was backported, but the path to samba-bgqd is wrong on 22.04.

  Currently apparmor profile has it like this:
  /usr/lib*/samba/samba-bgqd

  When in fact 22.04 has it on /usr/lib/x86_64-linux-gnu/samba/samba-
  bgqd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1979879/+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 1988290] Re: NO_PROXY doesn't work for IPv6 literals

[Paride Legovini]

Fixed upstream and in >= Focal by:

https://github.com/curl/curl/commit/b7f90470be9b75f57167abbcd63aadb2e3b33958

** Description changed:

+ [Partial copypaste from the linked upstream bug.]
+ 
  Setting
  
-   NO_PROXY=localhost,127.0.0.1,::1
+   NO_PROXY=localhost,127.0.0.1,::1
  
  enables connections to http://localhost and http://127.0.0.1 and does
  not work for http://[::1] at all. Apparently the problem is caused by an
  assumption [1] that a hostname cannot contain a colon.
  
  [1]
  
https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577

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

Title:
  NO_PROXY doesn't work for IPv6 literals

Status in Curl:
  Unknown
Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Bionic:
  Triaged

Bug description:
  [Partial copypaste from the linked upstream bug.]

  Setting

    NO_PROXY=localhost,127.0.0.1,::1

  enables connections to http://localhost and http://127.0.0.1 and does
  not work for http://[::1] at all. Apparently the problem is caused by
  an assumption [1] that a hostname cannot contain a colon.

  [1]
  
https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577

To manage notifications about this bug go to:
https://bugs.launchpad.net/curl/+bug/1988290/+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 1988290] [NEW] NO_PROXY doesn't work for IPv6 literals

[Paride Legovini]

Public bug reported:

[Partial copypaste from the linked upstream bug.]

Setting

  NO_PROXY=localhost,127.0.0.1,::1

enables connections to http://localhost and http://127.0.0.1 and does
not work for http://[::1] at all. Apparently the problem is caused by an
assumption [1] that a hostname cannot contain a colon.

[1]
https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577

** Affects: curl
 Importance: Unknown
 Status: Unknown

** Affects: curl (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: curl (Ubuntu Bionic)
 Importance: Undecided
 Status: Triaged

** Also affects: curl (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

** Bug watch added: github.com/curl/curl/issues #2353
   https://github.com/curl/curl/issues/2353

** Also affects: curl via
   https://github.com/curl/curl/issues/2353
   Importance: Unknown
   Status: Unknown

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

Title:
  NO_PROXY doesn't work for IPv6 literals

Status in Curl:
  Unknown
Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Bionic:
  Triaged

Bug description:
  [Partial copypaste from the linked upstream bug.]

  Setting

    NO_PROXY=localhost,127.0.0.1,::1

  enables connections to http://localhost and http://127.0.0.1 and does
  not work for http://[::1] at all. Apparently the problem is caused by
  an assumption [1] that a hostname cannot contain a colon.

  [1]
  
https://github.com/curl/curl/blob/7e35eb77292fe6464889ddc8329c6a64136f969d/lib/url.c#L2577

To manage notifications about this bug go to:
https://bugs.launchpad.net/curl/+bug/1988290/+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 1971932] Re: error in rsync protocol data stream

[Paride Legovini]

Looks like there' also an openSUSE bug about this issue:

https://bugzilla.opensuse.org/show_bug.cgi?id=1175854

As I understand it the culprit is the old rsync (3.1.3). Upstream
suggests recompiling it with -with-included-zlib=yes, which I doubt
we're going to do, especially in stable releases. The openSUSE bug has
an attached patch for rsync 3.1.3:

https://bugzilla.opensuse.org/attachment.cgi?id=853856&action=diff

If confirmed working we could SRU this fix to Focal (rsync 3.1.3) and
maybe Bionic (rsync 3.1.2), but first we need one of the affected users
to verify that the patch works, as as we're unable to reproduce the bug
at the moment.

** Bug watch added: bugzilla.opensuse.org/ #1175854
   https://bugzilla.opensuse.org/show_bug.cgi?id=1175854

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

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

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


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

[Touch-packages] [Bug 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds

[Paride Legovini]

ppa-purge 0.2.8+bzr63-0ubuntu2 is currently in mantic-proposed,
sponsored by halves. Unsubscribing ubuntu-sponsors.

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

Title:
  [mantic] ppa-purge no longer purges what add-apt-repository adds

Status in ppa-purge package in Ubuntu:
  Fix Released
Status in software-properties package in Ubuntu:
  Confirmed
Status in ppa-purge source package in Mantic:
  Fix Committed
Status in software-properties source package in Mantic:
  Confirmed
Status in ppa-purge source package in Noble:
  Fix Released
Status in software-properties source package in Noble:
  Confirmed

Bug description:
  Thank you @jbicha for the original bug report!

  [ Impact ]

  Currently ppa-purge fails to purge packages on distribution using the deb822 
source format. Currently mantic and noble make use of this format and are 
affected by this issue.
  When running ppa-purge to remove a custom PPA, ppa-purge fails to disable the 
custom PPA since it cannot disable deb822 sources and leads to apt still 
querying the ppa when running:

  $ apt update

  In older versions of ubuntu, PPAs used the ".list" format which could be 
disabled by simply commenting out the "deb" line with a "#". This was the 
method that ppa-purge used to disable PPAs.
  This new patch allows ppa-purge to detect and disable deb822 source files by 
adding an "Enabled: no" field in each component section of the deb822 file. It 
also removes any line that starts with "Enabled:"
  to make sure the resulting file is clean.

  [ Test Plan ]

  The changes were tested on both mantic and noble in a lxc container using the 
oibaf mesa PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) 
as the test PPA.
  The following steps were recorded in a noble lxc container.

   - First make sure that mesa-utils is installed in your environment:
  $ sudo apt update && sudo apt install mesa-utils

   - Add the oibaf PPA to your system using the following command:
  $ sudo add-apt-repository ppa:oibaf/graphics-drivers

   - Make sure that the mesa-utils packages were upgraded after adding the PPA:
  $ sudo apt update && sudo apt upgrade
  $ dpkg - l | grep mesa

   - output should be similar to the following:

  ii  libegl-mesa0:amd64  24.1~git2402280600.41722c~oibaf~n 
  amd64free implementation of the EGL API -- Mesa vendor library
  ii  libgl1-mesa-dri:amd64   24.1~git2402280600.41722c~oibaf~n 
  amd64free implementation of the OpenGL API -- DRI modules
  ii  libglapi-mesa:amd64 24.1~git2402280600.41722c~oibaf~n 
  amd64free implementation of the GL API -- shared library
  ii  libglx-mesa0:amd64  24.1~git2402280600.41722c~oibaf~n 
  amd64free implementation of the OpenGL API -- GLX vendor library
  ii  mesa-utils  9.0.0-2   
  amd64Miscellaneous Mesa utilities -- symlinks
  ii  mesa-utils-bin:amd649.0.0-2   
  amd64Miscellaneous Mesa utilities -- native applications
  ii  mesa-vulkan-drivers:amd64   24.1~git2402280600.41722c~oibaf~n 
  amd64Mesa Vulkan graphics drivers


   - Install and run ppa-purge:
  $ sudo apt install ppa-purge
  $ sudo ppa-purge ppa:oibaf/graphics-drivers

   - ppa-purge will report at the end that none of the oibaf packages
  need to be downgraded/removed:

  
  libglapi-mesa is already the newest version 
(24.1~git2402280600.41722c~oibaf~n).
  libglapi-mesa set to manually installed.
  libglx-mesa0 is already the newest version 
(24.1~git2402280600.41722c~oibaf~n).
  libglx-mesa0 set to manually installed.
  mesa-vulkan-drivers is already the newest version 
(24.1~git2402280600.41722c~oibaf~n).
  mesa-vulkan-drivers set to manually installed.
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-amdgpu1'
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [all]) for 'libdrm-common'
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-intel1'
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-nouveau2'
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-radeon1'
  Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open 
Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm2'
  Selected version '24.1~git2402280600.41722c~oibaf~n

[Touch-packages] [Bug 2049529] Re: Ubuntu delta causes `can't open /dev/null: No such file or directory` errors in minimal environments (chroot/unshare)

[Paride Legovini]

Hopefully worked around in autopkgtest by:

https://salsa.debian.org/ci-
team/autopkgtest/-/commit/2344e8197ed29ed1d94c33270207252574bb743c

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

Title:
  Ubuntu delta causes `can't open /dev/null: No such file or directory`
  errors in minimal environments (chroot/unshare)

Status in adduser package in Ubuntu:
  Confirmed
Status in shadow package in Ubuntu:
  Confirmed
Status in adduser source package in Noble:
  Confirmed
Status in shadow source package in Noble:
  Confirmed

Bug description:
  Hi,

  I was digging into fixing `autopkgtest`'s `unshare` testsuite, and the
  rabbit hole led me here.

  Here is a very quick reproducer, first:

  Start a fresh Ubuntu VM. Here is a quick path, but other ways should do fine:
  ```
  $ cd /tmp
  $ autopkgtest-buildvm-ubuntu-cloud -a amd64 -r noble
  $ kvm -m 1G -snapshot -hda autopkgtest-noble-amd64.img
  ```

  Now in the VM:
  ```
  $ sudo apt install -y mmdebstrap
  $ mmdebstrap noble /tmp/rootfs
  [...]
  $ sudo useradd --create-home --root /tmp/rootfs user1
  can't open /dev/null: No such file or directory
  ```

  The line `can't open /dev/null: No such file or directory` is printed
  on `stderr`, and that's unexpected by the part of the code I was
  debugging in the first place.

  Digging a bit led me to that line that does the printing:
  
https://git.launchpad.net/ubuntu/+source/shadow/tree/debian/patches/1015_add_zsys_support.patch#n69

  There seem to me that there are multiple issues with that patch:
  * Why try to call `zsysctl` in every case without first checking that it 
would be relevant: ZFS is not even installed on the VM we just created, less 
alone it has any ZFS volume/pool/whatever.
  * Obviously, when creating a user in a `chroot`, `/dev/null` won't exist 
unless mapped, and `useradd` is perfectly aware of that, because it even does 
the `chroot` call itself! But why even try to mess with ZFS in the `chroot` 
case in the first place?

  From what history @brian-murray told me, this patch was part of some
  ZFS experimentation in the past. Maybe that experimentation is now
  finished, and that patch could be dropped? At the very least it needs
  improvements, imho.

  EDIT: Just for context on why this issue appears only now: I was
  trying to fix the `unshare` testsuite in `autopkgtest`, which is
  pretty recent (2022) (https://salsa.debian.org/ci-
  team/autopkgtest/-/commit/d1671f94f68bce9a0c6793310a9f8b79b4e919a5)
  even upstream on Debian, and has never worked yet on Ubuntu.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/2049529/+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 2078555] Re: Upgrading from 22.04 to 24.04.01 breaks dnsmasq

[Paride Legovini]

I reproduced this issue by:

1. Starting a Jammy LXD container
2. Stop+disable systemd-resolved, install dnsmasq
3. Verify that dnsmasq is healthy
4. Upgraded to Noble
5. systemd-resolved is running again, dnsmasq is broken

I started looking into this bug because it has a dnsmasq task (so it's
part of the Ubuntu Server triage package set), but I believe the fix
belongs to systemd.

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

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

Title:
  Upgrading from 22.04 to 24.04.01 breaks dnsmasq

Status in Ubuntu:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Incomplete

Bug description:
  Was running Ubuntu 22.04 as home gateway/firewall with dnsmasq as
  dns/dhcp server. Previous upgrade from Ubuntu 20.04 to 22.04 had
  worked without issue.

  After the upgrade to 24.04.01, systemd-resovled was automatically
  enabled. The result was that after a reboot, dnsmasq failed to start,
  as systemd-resolved had already bound to the necessary port. This in
  turn meant that my entire home network lost connectivity as it was
  dependant on dnsmasq running to provide both correct dns and dhcp
  functionality.

  Ideally, during the upgrade process, a check should be made for if
  another dns/dhcp service is already enabled, and if so, not enable
  systemd-resolved.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/2078555/+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 1971932] Re: error in rsync protocol data stream

[Paride Legovini]

That's consistent with the comments above as the USB->SSD transfer
doesn't use the rsync protocol.

What we need to move this forward is a verification that applying [1] to
the version of rsync in Bionic (3.1.2) or Focal (3.1.3) fixes the issue.

If any of you affected users is available for testing an experimental
package we can prepare one and publish it to a PPA. Once the fix is
verified we can start the actual SRU process, which will require more
feedback (verification) from affected users.

[1] https://bugzilla.opensuse.org/attachment.cgi?id=853856&action=diff

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

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1971932/+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 2003845] Re: updating NSS on 18.04

[Paride Legovini]

Hello Vijay and thanks for this bug report. The ca-certificates package
is periodically upgraded in stable releases. The package changelog [1]
will tell you which CAs are added/removed with the past updates.

If you still believe you spotted an issue with missing certificate
please specify:

1. Which version of the package you are using;
2. Which CA is missing.

On the other hand if you agree the package actually ships all you need
please mark this bug report as Invalid. Thanks!

[1] /usr/share/doc/ca-certificates/changelog.gz

** Package changed: nss (Ubuntu) => ca-certificates (Ubuntu)

** Changed in: ca-certificates (Ubuntu)
   Status: New => Incomplete

** Summary changed:

- updating NSS on 18.04
+ updating CA certificates on 18.04

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

Title:
  updating CA certificates on 18.04

Status in ca-certificates package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 18.04 uses older version of NSS (version 3.35) by which the
  latest root certificates distributed by NSS are not trusted in Ubuntu
  18.04. Hence, please update it to latest version of NSS. For example,
  Mozilla Firefox uses version 3.86 of NSS in Ubuntu 18.04. This issue
  is impacting a set of users using their TLS certificates from latest
  root CAs, where website connections are failing due to untrusted
  certificate authorities.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/2003845/+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 2004101] Re: package libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting c

[Paride Legovini]

Hello Atharva and thanks for this bug report.

Since there isn't enough information in your report to differentiate
between a problem specific to your system and a bug in Ubuntu, I'm
marking this bug as Incomplete.

If you believe that this is really a bug, please provide some extra
context on what led to the problem, and ideally a set of steps to
reproduce it locally.

** Changed in: cyrus-sasl2 (Ubuntu)
   Status: New => Incomplete

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

Title:
  package libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in cyrus-sasl2 package in Ubuntu:
  Incomplete

Bug description:
  IDK

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1
  ProcVersionSignature: Ubuntu 5.15.0-58.64-generic 5.15.74
  Uname: Linux 5.15.0-58-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sun Jan 29 14:41:30 2023
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2022-04-09 (294 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  Python3Details: /usr/bin/python3.10, Python 3.10.6, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.1
   apt  2.4.8
  SourcePackage: cyrus-sasl2
  Title: package libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 failed to 
install/upgrade: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  UpgradeStatus: Upgraded to jammy on 2022-09-29 (121 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/2004101/+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 2007837] Re: 22.04: Backport request from 3.2.4 for fix of 3.2.3 regression

[Paride Legovini]

Thanks. According to the package versions the bug is not present in >=
Kinetic, so setting the devel release task as Fix Released.

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

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

** Tags added: server-todo

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

Title:
  22.04: Backport request from 3.2.4 for fix of 3.2.3 regression

Status in rsync package in Ubuntu:
  Fix Released
Status in rsync source package in Jammy:
  Triaged
Status in rsync package in Debian:
  Unknown

Bug description:
  rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling,
  leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04)
  to surface [1].

  It practically makes using BackupPC 3 impossible with clients using
  rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04
  can't be used to back up machines with 22.04 is rather surprising and
  has bitten other users [2].

  It's unclear whether the bug will be fixed in 18.04's and 20.04's
  libfile-rsyncp-perl package (for status, see [3]).

  Because of this, the rsync maintainer has included a patch in 3.2.4
  that fixes this regression [4] (even though not strictly an rsync
  bug). As a result, rsync 3.2.3 is the only affected version, which
  happens to be the one packaged in 22.04.

  This report is to request backporting that fix [4] to Ubuntu 22.04, so
  that things don't silently break in scenarios where the backup server
  is left at 20.04, and some backup clients happen to upgrade to 22.04.

  I'm not sure what the criteria for security releases are, but as the
  issue causes backup denial of service and has easy mitigation, I think
  it would make sense to put it through the security channel.

  [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
  [2]: 
https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html
  [3]: 
https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
  [4]: 
https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+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 2002918] Re: ERROR: rejecting excluded file-list name

[Paride Legovini]

** Bug watch added: github.com/WayneD/rsync/issues #375
   https://github.com/WayneD/rsync/issues/375

** Also affects: rsync via
   https://github.com/WayneD/rsync/issues/375
   Importance: Unknown
   Status: Unknown

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

Title:
  ERROR: rejecting excluded file-list name

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  Problems related to --exclude and --filter=protect options are raising
  error while execution of rsync.

  The following error is launched: 
  ERROR: rejecting excluded file-list name:
  rsync error: protocol incompatibility (code 2) at flist.c(994) 
[receiver=3.2.5]
  rsync: [sender] write error: Broken pipe (32)

  It was already reported in: https://github.com/WayneD/rsync/issues/375
  There is also a patch released.

  ---

  lsb_release -rd
  Description:Ubuntu 22.10
  Release:22.10

  apt-cache policy rsync
  rsync:
    Instalado: 3.2.5-1
    Candidato: 3.2.5-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/rsync/+bug/2002918/+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 2002918] Re: ERROR: rejecting excluded file-list name

[Paride Legovini]

Hello, I didn't go into the specifics of the bug, but according to LP:
#2007837 the security team (Cc: mdeslaur) is going to release rsync
3.2.7 to jammy and kinetic as a security update, so this bug should get
fixed too.

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

Title:
  ERROR: rejecting excluded file-list name

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  Problems related to --exclude and --filter=protect options are raising
  error while execution of rsync.

  The following error is launched: 
  ERROR: rejecting excluded file-list name:
  rsync error: protocol incompatibility (code 2) at flist.c(994) 
[receiver=3.2.5]
  rsync: [sender] write error: Broken pipe (32)

  It was already reported in: https://github.com/WayneD/rsync/issues/375
  There is also a patch released.

  ---

  lsb_release -rd
  Description:Ubuntu 22.10
  Release:22.10

  apt-cache policy rsync
  rsync:
    Instalado: 3.2.5-1
    Candidato: 3.2.5-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/rsync/+bug/2002918/+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 2038561] Re: Requesting Ubuntu package manager to release openssh updates to focal and jammy

[Paride Legovini]

Hello, while [1] by itself is a straightforward patch, I don't think we
can acknowledge this to be a bug in in Ubuntu, given that you are trying
to use an Ubuntu packaged software using a manually compiled version of
a library it depends on. This is not a supported use case, so the
prerequisites for a SRU [2] are missing.

OpenSSL 3.0 has upstream support until 2026-09-07 [3], and even after
that the Ubuntu package will get security coverage from the Ubuntu
security team. Unless you have specific needs, I suggest sticking with
the Ubuntu packaged version of OpenSSL.

[1] 
https://github.com/openssh/openssh-portable/commit/b7afd8a4ecaca8afd3179b55e9db79c0ff210237
[2] https://wiki.ubuntu.com/StableReleaseUpdates
[3] https://www.openssl.org/policies/releasestrat.html

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

Title:
  Requesting Ubuntu package manager to release openssh updates to focal
  and jammy

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  We're are unable to test OpenSSL 3.1 versions on Ubuntu 22.04 and
  20.04 machines because the machine gets bricked and loses SSH after
  installation of OpenSSL 3.1.2.

  This is because SSHD gets restarted when OpenSSL 3.1 gets installed.
  But it fails to come up and we lose SSH access to the box.

  Debug logging on SSHD shows the below error when it tries to start : 
  OpenSSL version mismatch. Built against 3020, you have 30100020

  After researching in online forums, it appears that this is an OpenSSH bug 
and it's been fixed in version 9.4p1 and 9.5p1 via this fix : 
  
https://github.com/openssh/openssh-portable/commit/b7afd8a4ecaca8afd3179b55e9db79c0ff210237

  However, it appears that only 8.9p1 version of openssh-client and
  openssh-server are available in Ubuntu packages.

  Requesting you to please release openssh versions 9.4p1 or 9.5p1 on
  Jammy and Focal which will help us move past this bug and start
  testing OpenSSL 3.1 for our use cases.

  
  Additional information about our environment:
  $ lsb_release -rd
  Description:  Ubuntu 22.04.3 LTS
  Release:  22.04

  $ apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.9p1-3ubuntu0.4
Candidate: 1:8.9p1-3ubuntu0.4
Version table:
   *** 1:8.9p1-3ubuntu0.4 500
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy-updates/main 
amd64 Packages
  100 /var/lib/dpkg/status
   1:8.9p1-3ubuntu0.3 500
  500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 
Packages
   1:8.9p1-3 500
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 
Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2038561/+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 2038561] Re: Requesting Ubuntu package manager to release openssh updates to focal and jammy

[Paride Legovini]

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

Title:
  Requesting Ubuntu package manager to release openssh updates to focal
  and jammy

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  We're are unable to test OpenSSL 3.1 versions on Ubuntu 22.04 and
  20.04 machines because the machine gets bricked and loses SSH after
  installation of OpenSSL 3.1.2.

  This is because SSHD gets restarted when OpenSSL 3.1 gets installed.
  But it fails to come up and we lose SSH access to the box.

  Debug logging on SSHD shows the below error when it tries to start : 
  OpenSSL version mismatch. Built against 3020, you have 30100020

  After researching in online forums, it appears that this is an OpenSSH bug 
and it's been fixed in version 9.4p1 and 9.5p1 via this fix : 
  
https://github.com/openssh/openssh-portable/commit/b7afd8a4ecaca8afd3179b55e9db79c0ff210237

  However, it appears that only 8.9p1 version of openssh-client and
  openssh-server are available in Ubuntu packages.

  Requesting you to please release openssh versions 9.4p1 or 9.5p1 on
  Jammy and Focal which will help us move past this bug and start
  testing OpenSSL 3.1 for our use cases.

  
  Additional information about our environment:
  $ lsb_release -rd
  Description:  Ubuntu 22.04.3 LTS
  Release:  22.04

  $ apt-cache policy openssh-server
  openssh-server:
Installed: 1:8.9p1-3ubuntu0.4
Candidate: 1:8.9p1-3ubuntu0.4
Version table:
   *** 1:8.9p1-3ubuntu0.4 500
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy-updates/main 
amd64 Packages
  100 /var/lib/dpkg/status
   1:8.9p1-3ubuntu0.3 500
  500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 
Packages
   1:8.9p1-3 500
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 
Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2038561/+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 1097467] Re: bash does not fulfill --rcfile option properly

[Paride Legovini]

Thanks for digging into this issue and updating the relevant Debian bug,
refreshing the debdiff. This LGTM, tested locally, the manpage renders
fine. I am going to sponsor this.

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

Title:
  bash does not fulfill --rcfile option properly

Status in Gnu Bash:
  New
Status in bash package in Ubuntu:
  Confirmed

Bug description:
  I am starting a bash shell using

  $ bash --noprofile --rcfile my-custom-bash-rc-file

  Due to the --rcflag, the newly started bash should *not* execute
  commands from /etc/bash.bashrc. That is at least how I interpret `man
  bash`:

    --rcfile file
    Execute commands from file instead of the system wide 
initialization file /etc/bash.bashrc and the standard personal initial‐
    ization file ~/.bashrc if the shell is interactive (see 
INVOCATION below).

  However, it seems that the commands in /etc/bash.bashrc are in fact
  executed.

  To see/reproduce/diagnose this, on Ubuntu I believe one can just
  invoke bash like this (as the regular user):

  $ touch testrc
  $ env -i bash --noprofile --rcfile testrc

  The expected result would be that nothing special is printed on the
  terminal. However, there is an error message, which is printed from
  /etc/bash.bashrc. The "env -i" causes $HOME to not be set in the
  invoked shell, which in turn triggers the error. The error message is:

  > To run a command as administrator (user "root"), use "sudo ".
  > See "man sudo_root" for details.

  Another way to see this -- without the "env -i" -- is to add  a
  command to /etc/bash.bashrc, such as

  echo HELLO THERE

  To trigger the bug(?), one can then just do

  $ touch testrc
  $ bash --noprofile --rcfile testrc

  The expected result would be that nothing special is shown in the
  terminal. However, it turns out that the string

  HELLO THERE

  is printed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnubash/+bug/1097467/+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 1097467] Re: bash does not fulfill --rcfile option properly

[Paride Legovini]

Actually, it would be nice if the new patch had some dep-3 headers (see
[1], `quilt --dep3` and maybe dep3changelog). In particular I think we
miss bug references an a description of the patch. Do you think you
could add the relevant ones? Thanks!

[1] https://dep-team.pages.debian.net/deps/dep3/

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

Title:
  bash does not fulfill --rcfile option properly

Status in Gnu Bash:
  New
Status in bash package in Ubuntu:
  Confirmed

Bug description:
  I am starting a bash shell using

  $ bash --noprofile --rcfile my-custom-bash-rc-file

  Due to the --rcflag, the newly started bash should *not* execute
  commands from /etc/bash.bashrc. That is at least how I interpret `man
  bash`:

    --rcfile file
    Execute commands from file instead of the system wide 
initialization file /etc/bash.bashrc and the standard personal initial‐
    ization file ~/.bashrc if the shell is interactive (see 
INVOCATION below).

  However, it seems that the commands in /etc/bash.bashrc are in fact
  executed.

  To see/reproduce/diagnose this, on Ubuntu I believe one can just
  invoke bash like this (as the regular user):

  $ touch testrc
  $ env -i bash --noprofile --rcfile testrc

  The expected result would be that nothing special is printed on the
  terminal. However, there is an error message, which is printed from
  /etc/bash.bashrc. The "env -i" causes $HOME to not be set in the
  invoked shell, which in turn triggers the error. The error message is:

  > To run a command as administrator (user "root"), use "sudo ".
  > See "man sudo_root" for details.

  Another way to see this -- without the "env -i" -- is to add  a
  command to /etc/bash.bashrc, such as

  echo HELLO THERE

  To trigger the bug(?), one can then just do

  $ touch testrc
  $ bash --noprofile --rcfile testrc

  The expected result would be that nothing special is shown in the
  terminal. However, it turns out that the string

  HELLO THERE

  is printed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnubash/+bug/1097467/+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 1984107] Re: Printer SSL certificates are added but never removed, resulting in "no suitable destination host found by cups-browsed"

[Paride Legovini]

Hello Valentijn and thanks for this bug report, it really helped me
figure out an otherwise obscure printing issue.

However I don't agree with the suggested solution: the security model of
cups for ipps is TOFU (trust on first use): the certificate is accepted
the first time and then expected to be the same in the future. This is
why the printer certificate is saved to file in the first place. (This
approach is similar to what SSH uses: the first time you connect to a
host the pubkey is saved in authorized_keys; if at some point the key
changes ssh will refuse to connect and require manual deletion of the
old key from authorized_keys.)

I think this is a UI issue: from the cups web interface or cups logs it
was not clear at all that the issue was with ipps certificate
validation. Cups (or maybe the ipps backend? I'm not that familiar with
cups internals) should log a proper error message instead.

** Changed in: cups (Ubuntu)
   Status: New => Confirmed

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

Title:
  Printer SSL certificates are added but never removed, resulting in "no
  suitable destination host found by cups-browsed"

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  If a printer preferrably prints through ipps, Cups will store the
  printers (self signed) certificate in /etc/cups/ssl/

  However, if this certificate becomes outdated or invalid, or if it
  changes, it will *not be removed* and Cups only complains that the
  "backend returned status 4", "No suitable destination host found by
  cups-browsed". Even removing the printer manually will not remove the
  old certificate, rendering the printer invalid for life: when te
  printer re-appears, the old, invalid certificate is still there,
  resulting in the printer still not working.

  Steps to reproduce:
  - use a printer that prefers ipps, let's call it printer_bob
  - let this printer appear in your printer list
  - make a test print
  - Now remove the printer and check that the certificate will survive:
  lpadmin -x printer_bob; ls -al /etc/cups/ssl/*bob*crt

  What happens:
  - certificate is still there

  What should happen:
  - a removed printer should not have a certificate left

  Now in this example, it's rather harmless because the certificate is
  probably still valid. But a printer update, rename or otherwise will
  render it invalid and printing will become impossible.

  You could simulate a name change for printers:
  mv /etc/cups/ssl/printer-carol.local.crt /etc/cups/ssl/printer-bob.local.crt

  Or simply mess up the certificate:
  sed -i '2s/./a/g' /etc/cups/ssl/printer-bob.local.crt

  After this, you will *not* be able to print to printer-bob, because
  bob has the wrong certificate (obviously). Removing printer-bob does
  not help. You will need to manually remove the certificate in order to
  make bob print again. /var/log/cups/error.log will only say that "no
  suitable destination host found", which is not true: there *is* a
  destination but the SSL certificate does not match and Cups will only
  try the first printing method, ipps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1984107/+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 1984107] Re: Printer SSL certificates are added but never removed, resulting in "no suitable destination host found by cups-browsed"

[Paride Legovini]

Hello Valentijn and thanks for this bug report, it really helped me
figure out an otherwise obscure printing issue.

However I don't agree with the suggested solution: the security model of
cups for ipps is TOFU (trust on first use): the certificate is accepted
the first time and then expected to be the same in the future. This is
why the printer certificate is saved to file in the first place. (This
approach is similar to what SSH uses: the first time you connect to a
host the pubkey is saved in authorized_keys; if at some point the key
changes ssh will refuse to connect and require manual deletion of the
old key from authorized_keys.)

I think this is a UI issue: from the cups web interface or cups logs it
was not clear at all that the issue was with ipps certificate
validation. Cups (or maybe the ipps backend? I'm not that familiar with
cups internals) should log a proper error message instead.

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

Title:
  Printer SSL certificates are added but never removed, resulting in "no
  suitable destination host found by cups-browsed"

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  If a printer preferrably prints through ipps, Cups will store the
  printers (self signed) certificate in /etc/cups/ssl/

  However, if this certificate becomes outdated or invalid, or if it
  changes, it will *not be removed* and Cups only complains that the
  "backend returned status 4", "No suitable destination host found by
  cups-browsed". Even removing the printer manually will not remove the
  old certificate, rendering the printer invalid for life: when te
  printer re-appears, the old, invalid certificate is still there,
  resulting in the printer still not working.

  Steps to reproduce:
  - use a printer that prefers ipps, let's call it printer_bob
  - let this printer appear in your printer list
  - make a test print
  - Now remove the printer and check that the certificate will survive:
  lpadmin -x printer_bob; ls -al /etc/cups/ssl/*bob*crt

  What happens:
  - certificate is still there

  What should happen:
  - a removed printer should not have a certificate left

  Now in this example, it's rather harmless because the certificate is
  probably still valid. But a printer update, rename or otherwise will
  render it invalid and printing will become impossible.

  You could simulate a name change for printers:
  mv /etc/cups/ssl/printer-carol.local.crt /etc/cups/ssl/printer-bob.local.crt

  Or simply mess up the certificate:
  sed -i '2s/./a/g' /etc/cups/ssl/printer-bob.local.crt

  After this, you will *not* be able to print to printer-bob, because
  bob has the wrong certificate (obviously). Removing printer-bob does
  not help. You will need to manually remove the certificate in order to
  make bob print again. /var/log/cups/error.log will only say that "no
  suitable destination host found", which is not true: there *is* a
  destination but the SSL certificate does not match and Cups will only
  try the first printing method, ipps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1984107/+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 406397] Re: init: job stuck with expect fork/daemon when parent reaps child

[Paride Legovini]

** Changed in: pld-linux
   Status: New => Incomplete

** Changed in: irqbalance (Ubuntu)
   Status: New => Invalid

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

Title:
  init: job stuck with expect fork/daemon when parent reaps child

Status in upstart :
  Triaged
Status in irqbalance package in Ubuntu:
  Invalid
Status in upstart package in Ubuntu:
  Invalid
Status in upstart package in Debian:
  Fix Released
Status in PLD Linux:
  Incomplete

Bug description:
  Hi

  Wrong use of the expect fork stanza can create job with status
job stop/killled, process nnn
  without any process nnn running on the system.

  As an example the following avahi.conf should have used
  "expect daemon", but will instead create a stuck job.

  stop on stopping dbus-system
  respawn
  expect fork
  exec avahi-daemon -D

  /Emil Renner Berthing

To manage notifications about this bug go to:
https://bugs.launchpad.net/upstart/+bug/406397/+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 1833322] Re: Consider removing irqbalance from default install on desktop images

[Paride Legovini]

Hi, adding a couple of extra pointers here (I'm the Debian irqbalance
maintainer). This the Debian bug where the discussion on removing
irqbalance from the kernel Recommends happened:

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

In Debian irqbalance is not installed anymore by default since mid-2019
(clearly reflected by popcon: https://qa.debian.org/popcon-
graph.php?packages=irqbalance), and no bug was reported related to it
being missing.

Back in the day I asked upstream their take on irqbalance usefulness
with newer kernels, here is their reply:

https://github.com/Irqbalance/irqbalance/issues/151

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

** Bug watch added: github.com/Irqbalance/irqbalance/issues #151
   https://github.com/Irqbalance/irqbalance/issues/151

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

Title:
  Consider removing irqbalance from default install on desktop images

Status in irqbalance package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop";
  SUPPORT_URL="http://support.system76.com";
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues";
  PRIVACY_POLICY_URL="https://system76.com/privacy";
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/1833322/+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 2049318] Re: [SRU] free(): double free detected in tcache 2

[Paride Legovini]

Hi and thanks for working at this SRU. I have some comments on the
debdiff:

- Please specify the patch Author in the DEP-3 headers. See [1] for more
info on the header format.

- The patch description should not be "apply upstream patch", because
the patch is just the patch, it contains no information on where/how
it's applied. It is fine (actually: good) to use the original commit
message as the patch description. A multi-line description is OK, again
see [1].

- I see you dropped a tests which was present in the original patch. If
the test works fine on Jammy, let's keep it. If the test doesn't work on
Jammy, please explain why in the patch Description header.

- Please call the patch file something like 0002-nft-cache-avoid-double-
free-of-unrecognized-base-chains.patch to follow the naming style used
by other patches.

If the added upstream test (0004extra-base_0) allows the easy
verification that this fix works, it would be nice to have that in the
SRU test plan.

[1] https://dep-team.pages.debian.net/deps/dep3/

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

Title:
  [SRU] free(): double free detected in tcache 2

Status in iptables package in Ubuntu:
  Fix Released
Status in iptables source package in Jammy:
  Confirmed

Bug description:
  [ Impact ]

  iptables is unable to list the iptables rules or save the iptables
  rules if a nftables ruleset is defined which iptables does not
  recognize.

  [ Test Plan ]

  * Add an iptables rule.
- sudo iptables -A OUTPUT -p tcp --dport   -j REJECT

  * save the rules in a file
- sudo iptables-save > rules.txt

  * Convert the rule to nftables ruleset
- sudo iptables-nft-restore < rules.txt

  * List the nftables ruleset
- sudo nft list ruleset

  * Also confirm that iptables can list the old rule
- sudo iptables -L

  * Now add another nftables rule (this rule is taken from upstream test
  case)

  sudo nft -f - 

[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together

[Paride Legovini]

Hello Bill and thanks for this bug report. I can see the issue you
described here (thanks for the reproducer), however I believe it should
be filed/fixed upstream. Maybe [1] should be expanded to cover --remove-
source-files, as the two issues could be related.

Diverging from upstream (or from Debian) has a long-term maintenance
cost (e.g. rebasing the patch at every release) and can lead to
situations which are difficult to handle well: think of a bug that is
later fixed upstream but in a different way, with user-facing
differences. What to do then, break compatibility with the older Ubuntu
releases, or break compatibility with upstream?

While I agree this is a bug in my opinion it is not worth diverging from
upstream here. I am setting the status of this bug report to Triaged (it
is well understood) but with importance: Wishlist.

Should you disagree with my reasoning please comment back and change the
bug status back to New, we'll look at it again. Thanks!

[1] https://bugzilla.samba.org/show_bug.cgi?id=3844

** Bug watch added: Samba Bugzilla #3844
   https://bugzilla.samba.org/show_bug.cgi?id=3844

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

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

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

Title:
  rsync conceals file deletions from reporting when --dry-run --remove-
  source-files are used together

Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync has an astonishing and dangerous bug:

  The dry run feature (-n / --dry-run) inhibits reporting of file
  deletions when --remove-source-files is used. This is quite serious.
  People use --dry-run to see if an outcome will work as expected before
  a live run. When the simulated run shows *less* destruction than the
  live run, the consequences can be serious because rsync may
  unexpectedly destroy the only copy(*) of a file.

  Users rely on --dry-run. Although users probably expect --dry-run to
  have limitations, we don't expect destructive operations to be under
  reported. If it were reversed, such that the live run were less
  destructive than the dry run, this wouldn't be as serious.

  Reproducer:

  $ mkdir -p /tmp/src /tmp/dest
  $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt
  $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt
  $ cp /tmp/src/foo.txt /tmp/dest
  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt  foo.txt

  $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/
  (no output)

  $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/
  sender removed foo.txt

  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt

  (*) note when I say it can destroy the only copy of a file, another
  circumstance is needed: that is, rsync does not do a checksum by
  default.  It checks for identical files based on superficial
  parameters like name and date.  So it's possible that two files match
  in the default superficial comparison but differ in the actual
  content.  Losing a unique file in this scenario is perhaps a rare
  corner case, but this bug should be fixed nonetheless.  In the typical
  case of losing files at the source, there is still a significant
  inconvenience of trying to identify what files to copy back.

  Note this bug is similar but differs in a few ways:
  https://bugzilla.samba.org/show_bug.cgi?id=3844

  I've marked this as a security vulnerability because it causes
  unexpected data loss due to --dry-run creating a false expectation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1925381/+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 1919177] Re: Azure: issues with accelerated networking on Hirsute

[Paride Legovini]

** Changed in: cloud-init (Ubuntu)
   Status: New => Incomplete

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

Title:
  Azure: issues with accelerated networking on Hirsute

Status in cloud-init:
  Incomplete
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  [General]

  On Azure, when provisioning a Hirsute VM with Accelerated Networking
  enabled, sometimes part of the cloud-init configuration is not
  applied.

  Especially, in those cases, the public SSH key is not setup properly.

  [how to reproduce]

  Start a VM with AN enabled:

  ```
  az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South" 
 --image 
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size 
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY" 
--accelerated-networking
  ```

  After a moment, try to SSH: if you succeed, delete and recreate a new
  VM.

  [troubleshooting]

  To be able to connect into the VM, run:

  az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id 
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
  ```

  In "/run/cloud-init/instance-data.json", I can see:
  ```
   "publicKeys": [
    {
     "keyData": "",
     "path": "/home/ubuntu/.ssh/authorized_keys"
    }
   ],
  ```

  as expected.

  [workaround]

  As mentioned, Azure allows the user to run command into the VM without
  SSH connection. To do so, one can use the Azure CLI:

  az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
  RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"

  This example uses "ssh-import-id" but it's also possible to just echo
  a given public key into /home/ubuntu/.ssh/authorized_keys

  NOTE: this will only solves the SSH issue, I do not know if this bug
  affects other things. If so the user would have to apply those things
  manually.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919177/+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

[Paride Legovini]

Hi, I went a bit down the rabbit hole Sergio mentioned and found the
same old reports and nothing really useful. I'd also be curios to see if
the problem still occurs with the newer releases.

Did you see this happen on more that one machine/deployment?

The backtrace didn't suggest my anything, but maybe Sergio will have
better use for it.

-- 
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:
  New

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 1929854] Re: Vital and critical configuration files get overridden by system updates without warning

[Paride Legovini]

Hello Dominik and thanks for this bug report. An umbrella bug report
doesn't really help here, especially given that there's no single "reset
config files on updates" policy in Ubuntu. Actually it's quite the
contrary: as a Debian derivative Ubuntu basically inherits [1] and in
particular [2].

Please file individual bug reports against the affected packages,
possibly providing steps to reproduce the problem. In the case of
openssh-server I can say that the overwrite shouldn't happen, as
ssh_config is handles via ucf [3]. But let's discuss this in a dedicated
bug, once opened. I'll just add that the newer versions of openssh-
server support dropping custom config snippets in
/etc/ssh/sshd_config.d/, for easier handling of custom configurations.

Thanks!

[1] https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files
[2] https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[3] http://manpages.ubuntu.com/manpages/focal/man1/ucf.1.html

** 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 libx11 in Ubuntu.
https://bugs.launchpad.net/bugs/1929854

Title:
  Vital and critical configuration files get overridden by system
  updates without warning

Status in grub2 package in Ubuntu:
  New
Status in libx11 package in Ubuntu:
  New
Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  • In my /usr/share/X11/locale/en_US.UTF-8/Compose I have about 10'000 lines 
of special compose keys defined.
  • In my /boot/grub/grub.cfg I have a very complicated special setup for my 
various boot configurations, and a 5-sec timout for my EFI-config.
  • My /etc/ssh/sshd_config contains a well-balanced configuration 

  All these files are regularly overridden WITHOUT EVEN A SINGLE WARNING
  or ASKING BACK by ubuntu system setups (discover).

  I set all of them to read-only by root and no-access for group and
  other users, but they still get overridden by every other system
  update.  I even have a shutdown process in place which should actually
  make sure that changes to these files are reverted by writing a backup
  copy over any newly installed override — unfortunately, everything I
  did to run either a custom shutdown process or a startup process with
  systemd turned out to not work and be a nightmare to make work.

  How somebody could be as bold as to override vital configuration files
  like this without even asking  for consent is one of the strange
  miracles in this world which I'll probably never understand.  However,
  if "ubuntu" is really what it translates to, it should take a little
  bit more care about pre-existing configurations on systems on which it
  is set up and running well — until one system update suddenly
  jeopardizes the functioning of the entire system.  I'm pretty sure
  these are not the only configuration files which are carelessly just
  overridden.  They're just the ones every other update breaks my system
  and inflinges on my the costs of hours of research until I find out
  that — of course — it was an overridden critical system configuration
  again.  The really mean thing is that you don't notice anything when
  you run the update … only next time you start your system and of
  course are not aware anymore that you did a system update, the new
  (absolutely wrong and/or insufficent) settings are in place and shoot
  you in the leg.

  Take an example from gentoo's etc-update feature which lets you merge
  new configuration files with pre-existing ones using a diff3-update.
  I went away from gentoo for other reasons, but I always praised that
  feature.

  Please make sure immediately that critical configuration files do not
  get overridden if they are non-writable by root, and then gradually
  introduce a system that merges changes to configuration files with the
  current situation on the target system.  Or at least present the
  configs that would be changed in a particular directory, so that
  anybody who is interested in preserving local settings could merge
  them in a suitable way.

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
  Uname: Linux 5.8.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Thu May 27 18:48:15 2021
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
  InstallationDate: Installed on 2021-01-15 (132 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Rel

[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed

[Paride Legovini]

** Changed in: nss (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
  proposed

Status in nss package in Ubuntu:
  New

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
  >>>> CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at 

[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

[Paride Legovini]

Hello Barto,

If I understand it correctly you can create working images using 20.04
ISOs *right now*, but with the exact same tooling images created with
20.04.x ISOs do not work. I think you have been clear about this, but it
is of course very important to know that the only moving part is the ISO
image.

Given that you have console access to the machine, at least for a few
minutes before Virtualbox tears it down, can you please share the output
of the following commands?

 - ip addr
 - systemctl status
 - systemctl status ssh

My wild guess here is that for some reason the 20.04.x images get a
different Ethernet interface name (you hardcoded ens33 in cloud-config).

Also: can you login from the machine to itself (ssh mclibre@127.0.0.1)?

Also: can you share the contents of /etc/dhcp/dhclient.conf and
/etc/netplan/00-installer-config.yaml?

Thank you.

-- 
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 1964642] Re: Packer virtualbox ssh can't connect to unattended Ubuntu 20.04.1/2/3/4 but can connect to Ubuntu 20.4

[Paride Legovini]

** 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/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:
  Incomplete

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 1965076] Re: rsync --update incorrectly reports file "is newer" than itself

[Paride Legovini]

Hello Ian and thanks for this bug report. My question here is: is this
actually a bug?

The manpage for --update says:

  This forces rsync to skip any files which exist on the destination
  and have a modified time that is newer

It seems sensible to me to make this a '>=' comparison, and not a strict
'>' comparison: when considering modification times there's no need to
update a file which has the same timestamp of the source file.

In other words: I fail to see the problem here. Could you please
elaborate a bit more? 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/1965076

Title:
  rsync --update incorrectly reports file "is newer" than itself

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  rsync 3.2.3 has a broken "--update" option.See the examples below.
  The "--update" option incorrectly makes rsync say a file is newer than itself.
  Remove the "--update" option, and rsync correctly says the file is "uptodate".
  The right output should of course be "is uptodate" in all cases.
  This bug also shows up between machines if the source rsync is 3.1.3 and the 
destination is 3.2.3.
  The bug does not show up if the source rsync is 3.2.3 and the destination is 
3.1.3.

  $ touch foo
  $ rsync -avv --update foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is newer <=== THIS IS NOT CORRECT - A file can't be newer 
than itself.
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 38 bytes  received 96 bytes  268.00 bytes/sec
  total size is 0  speedup is 0.00

  $ rsync -avv foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is uptodate  <=== THIS IS CORRECT
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 41 bytes  received 106 bytes  294.00 bytes/sec
  total size is 0  speedup is 0.00

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: rsync 3.2.3-4ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19
  Uname: Linux 5.13.0-35-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 22:47:44 2022
  InstallationDate: Installed on 2022-03-16 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1965076/+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 1965076] Re: rsync --update incorrectly reports file "is newer" than itself

[Paride Legovini]

I see your point; my suggestion here is to file a bug upstream with your
findings:

  https://github.com/WayneD/rsync/issues

I don't think this should be tackled on the Ubuntu side, especially
given that the issue is really minor and unlikely to affect a
significant amount of users. As you say what changed is a double-
verbosity info message with no promise of stability, the actual behavior
of rsync is correct.

If you file a bug upstream please mention it here, we'll track it and
once fixed we'll consider applying the fix to the supported Ubuntu
releases. Thanks!


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

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

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

Title:
  rsync --update incorrectly reports file "is newer" than itself

Status in rsync package in Ubuntu:
  Confirmed

Bug description:
  rsync 3.2.3 has a broken "--update" option.See the examples below.
  The "--update" option incorrectly makes rsync say a file is newer than itself.
  Remove the "--update" option, and rsync correctly says the file is "uptodate".
  The right output should of course be "is uptodate" in all cases.
  This bug also shows up between machines if the source rsync is 3.1.3 and the 
destination is 3.2.3.
  The bug does not show up if the source rsync is 3.2.3 and the destination is 
3.1.3.

  $ touch foo
  $ rsync -avv --update foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is newer <=== THIS IS NOT CORRECT - A file can't be newer 
than itself.
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 38 bytes  received 96 bytes  268.00 bytes/sec
  total size is 0  speedup is 0.00

  $ rsync -avv foo .
  delta-transmission disabled for local transfer or --whole-file
  foo is uptodate  <=== THIS IS CORRECT
  total: matches=0  hash_hits=0  false_alarms=0 data=0
  sent 41 bytes  received 106 bytes  294.00 bytes/sec
  total size is 0  speedup is 0.00

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: rsync 3.2.3-4ubuntu1
  ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19
  Uname: Linux 5.13.0-35-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 22:47:44 2022
  InstallationDate: Installed on 2022-03-16 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1965076/+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 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used

[Paride Legovini]

Still no activity in the upstream issue, however I think OpenSSH 8.9
offers a mechanism that can help avoiding hitting MaxAuthTries in some
cases: "destination constraints", see documentation for -h in ssh-
add(1). AIUI constraining should limit the number of keys tried against
a given host, making reaching MaxAuthTries more difficult. More info:

  https://www.openssh.com/agent-restrict.html
  https://lwn.net/Articles/880458/

It is not clear to me if setting destination constraints also affects
the order in which keys are tried (narrower scope => higher priority).

Another workaround is preventing ssh to reach the agent:

  SSH_AUTH_SOCK= ssh -i  

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

Title:
  explicit key offered after all agent keys, auth can fail before
  explicit key used

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  New

Bug description:
  A user creates an ssh key and specifies it on the cmdline with 'ssh -i
  new_key user@host'.  The connection fails with the message "Too many
  authentication failures" displayed to the user.

  This would lead the user to believe that they failed to put the public
  portion of the new key on the destination and it will probably be hard
  for the average user to debug this.

  The root of this issue is that the user has a number of keys in
  ~/.ssh/ registered with their ssh agent.  The ssh command is offering
  each of these keys from the agent to the remote system before trying
  the explicit key from the command line.  There are enough agent keys
  to reach the failure limit (usually 5 keys) with the remote before
  they get to the explicit key.

  The solution today for the user is to head down into the ssh_config
  man page to find '-o IdentitiesOnly=yes' to skip the agent keys and
  only use the specified key.  But they're unlikely to do this because
  '-i' in the ssh man page doesn't suggest this and they'd only look for
  this if they actually understood the root cause of the problem, which
  is a bit cruel.

  We should consider changing the order of the keys offered to the
  remote to use explicit keys first followed by agent keys.  It would
  seem to me that this would honor the users intent of explicitly
  specifying a key to use.

  The current order makes this difficult for anyone fielding a user's
  authentication failure report as they must double check that ssh
  managed to actually try the key the user specified before it raised an
  error message about authentication failures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1872145/+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 1712223] Re: open-vm-tools does not work under wayland

[Paride Legovini]

Hello Alexander, note that Xorg is available in Jammy both as the native
graphical session and via xwayland. On this bug report: could you please
elaborate more on what exactly happens? In particular could you guide us
into reproducing the problem on a clean Jammy install, making clear
"what should happen" and "what actually happens" when facing the
problem?

As we're waiting for more information here I'm marking this bug report
as Incomplete.

Thanks!

** Changed in: open-vm-tools (Ubuntu)
   Status: Confirmed => Incomplete

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

Title:
  open-vm-tools does not work under wayland

Status in open-vm-tools package in Ubuntu:
  Incomplete
Status in wayland package in Ubuntu:
  New

Bug description:
  At first I thought this bug was caused with the recent changes in
  open-vm-tools 10.1.10; however, after restoring my VM to the snapshot
  that had 17.04 and re-performing the dist-upgrade with open-vm-tools
  and open-vm-tools-desktop held at 10.1.5 I am experiencing the same
  issue where VMWare Workstation no longer can interact with display
  resolution detection of the host monitor(s). Multiple monitor support
  is also lost in the update process.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: xorg 1:7.7+19ubuntu1
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.6-0ubuntu6
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Aug 21 17:09:59 2017
  DistUpgraded: 2017-08-07 09:05:02,559 DEBUG found components: 
{'artful-updates': {'multiverse', 'restricted', 'universe', 'main'}, 'artful': 
{'multiverse', 'restricted', 'universe', 'main'}, 'artful-security': 
{'multiverse', 'restricted', 'universe', 'main'}}
  DistroCodename: artful
  DistroVariant: ubuntu
  DkmsStatus:
   virtualbox, 5.1.26, 4.10.0-30-generic, x86_64: installed
   virtualbox, 5.1.26, 4.12.0-11-generic, x86_64: installed
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
 Subsystem: VMware SVGA II Adapter [15ad:0405]
  InstallationDate: Installed on 2016-11-30 (264 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: VMware, Inc. VMware Virtual Platform
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.12.0-11-generic 
root=UUID=dd284488-2aa1-430d-a510-0527b909f561 ro find_preseed=/preseed.cfg 
auto noprompt priority=critical locale=en_US quiet
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: Upgraded to artful on 2017-08-07 (14 days ago)
  dmi.bios.date: 07/02/2015
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd07/02/2015:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.
  version.compiz: compiz 1:0.9.13.1+17.10.20170720-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.82-1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.0~rc4-0ubuntu3
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.0~rc4-0ubuntu3
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.3-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.9.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20170309-0ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Mon Aug 21 16:27:55 2017
  xserver.configfile: default
  xserver.devices:
   inputPower Button KEYBOARD, id 6
   inputAT Translated Set 2 keyboard KEYBOARD, id 7
   inputVirtualPS/2 VMware VMMouse MOUSE, id 8
   inputVirtualPS/2 VMware VMMouse MOUSE, id 9
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs: Output
Virtual2Virtual3Virtual4Virtual5Virtual6
Virtual7Virtual8
  xserver.versio

[Touch-packages] [Bug 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

[Paride Legovini]

Hello testpi and thanks for this bug report. Can you reproduce this
issue from a fresh install on the Raspberry, and attempting a simple ssh
login instead of a git clone? Something on these lines:

-
ssh-keygen
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
killall ssh-agent || true
eval $(ssh-agent)
ssh-add
ssh localhost
-

I'll try to reproduce this issue myself but I don't have access to a
Rpi4 at the moment, but I should have soon. As we're waiting for more
information here I'm marking this report as Incomplete for now.

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  New

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1968876/+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 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

[Paride Legovini]

Also: you mention that "ssh agent crashes". What do you see exactly to
be able to tell it's a crash and not some other authentication or key
handling issue?

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  New

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1968876/+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 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

[Paride Legovini]

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

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1968876/+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 1968876] Re: ssh-agent: Error connecting to agent: Connection refused

[Paride Legovini]

I tried reproducing the issue on a Rpi4, cloning a repository via ssh
using pubkey authentication with a rsa2048 key stored in ssh-agent, it
worked fine. If you believe there's actually a bug here please provide
some steps we can follow to reproduce the issue from a clean Jammy
system, and we'll look into this again. 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/1968876

Title:
  ssh-agent: Error connecting to agent: Connection refused

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh 1:8.9p1-3
  Architecture: arm64
  CasperMD5CheckResult: pass
  CurrentDesktop: MATE

  raspberry pi 4. The keys are added, but for example, when cloning a
  repository via ssh, the ssh agent crashes, restarting does not help,
  the repository is not cloned. When launch the command ssh-add -L Error
  connecting to agent: Connection refused. I rolled back to the package
  version 1: 8.8p1-1 and everything works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1968876/+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 1969960] [NEW] Jammy's /etc/os-release missing LTS string in VERSION

[Paride Legovini]

Public bug reported:

[Description]

In Jammy (base-files 12ubuntu4) we have:

$ grep VERSION= /etc/os-release 
VERSION="22.04 (Jammy Jellyfish)"

but expected is:

VERSION="22.04 LTS (Jammy Jellyfish)"

Compare with Focal:

$ grep VERSION= /etc/os-release 
VERSION="20.04.4 LTS (Focal Fossa)"

[Impact]

Having VERSION without LTS is inconsistent with the previous LTS
releases and is wrong, as the official name of the release is "22.04
LTS". This can confuse users.

Any script relying on VERSION to detect if the Ubuntu version it is
running on in an LTS won't be work as expected.

[Test Plan]

1. grep VERSION= /etc/os-release 
2. check that it is: VERSION="22.04 LTS (Jammy Jellyfish)"

[Where problems could occur]

Software already packaged in Jammy may already have adapted to the fact
that VERSION doesn't have the LTS string in it.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Assignee: Paride Legovini (paride)
 Status: Triaged

** Changed in: base-files (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

** Changed in: base-files (Ubuntu)
   Status: New => Triaged

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

Title:
  Jammy's /etc/os-release missing LTS string in VERSION

Status in base-files package in Ubuntu:
  Triaged

Bug description:
  [Description]

  In Jammy (base-files 12ubuntu4) we have:

  $ grep VERSION= /etc/os-release 
  VERSION="22.04 (Jammy Jellyfish)"

  but expected is:

  VERSION="22.04 LTS (Jammy Jellyfish)"

  Compare with Focal:

  $ grep VERSION= /etc/os-release 
  VERSION="20.04.4 LTS (Focal Fossa)"

  [Impact]

  Having VERSION without LTS is inconsistent with the previous LTS
  releases and is wrong, as the official name of the release is "22.04
  LTS". This can confuse users.

  Any script relying on VERSION to detect if the Ubuntu version it is
  running on in an LTS won't be work as expected.

  [Test Plan]

  1. grep VERSION= /etc/os-release 
  2. check that it is: VERSION="22.04 LTS (Jammy Jellyfish)"

  [Where problems could occur]

  Software already packaged in Jammy may already have adapted to the
  fact that VERSION doesn't have the LTS string in it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1969960/+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 1971523] Re: Static build does not work for libmnl (-lmnl)

[Paride Legovini]

Hello Lars and thanks for this bug report. I can confirm this: libmnl-
dev 1.0.4-2 installs

  /usr/lib/x86_64-linux-gnu/libmnl.a

while libmnl-dev 1.0.4-3 does not. I tracked this down to this Debian
packaging change (see the debian/libmnl-dev.install diff):

https://salsa.debian.org/pkg-netfilter-team/pkg-
libmnl/-/commit/3526970e4dfb5598a9023496211c908e9ab7c9dc

Dropping the .a file looks like unintentional to me, at least by reading
the commit message. Ideally this should be fixed in Debian, to make
Debian benefit from the fix and keep the packages in sync, lowering the
maintenance work from the Ubuntu side.

Do you you think you can file a bug in Debian against the libmnl source
package and report it back here? This would speed up things. Thanks!

** Tags added: server-todo

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

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

Title:
  Static build does not work for libmnl (-lmnl)

Status in libmnl package in Ubuntu:
  Triaged

Bug description:
  Example;
  # gcc -o /tmp/hello /tmp/hello.c -lmnl
  (dynamic libs work)
  # gcc -static -o /tmp/hello /tmp/hello.c -lmnl
  /usr/bin/ld: cannot find -lmnl: No such file or directory

  
  My program uses both -lmnl and -lnetfilter_queue and in Ubuntu 20.04 the 
-lnetfilter_queue did not work and -lmnl worked for static builds. In Ubuntu 
22.04 the problem is reversed, -lnetfilter_queue works but -lmnl doesn't for 
static builds. This is very awkward during the transition 20.04->22.04 when 
both should be supported.

  I compensated in Ubuntu 20.04 by building netfilter_queue locally;
  https://github.com/Nordix/nfqueue-loadbalancer#build

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: libmnl0:amd64 1.0.4-3build2
  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: XFCE
  Date: Wed May  4 07:33:26 2022
  InstallationDate: Installed on 2018-09-07 (1334 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: libmnl
  UpgradeStatus: Upgraded to jammy on 2022-05-01 (2 days ago)

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

[Paride Legovini]

Hello Alvaro and thanks for this bug report. We have many systems
running Jammy and they're able to connect to GitHub with no issues. I
also tried with GitLab.com and it works just fine. This is not to
dismiss your report, but there's clearly something else involved in the
problem you're hitting. My suggestion is to try to reproduce the issue
from a freshly installed Jammy system, and if ssh *does* work there go
look for any relevant difference. I'm marking this report as Incomplete
for now, as we need more information from your side to move it forward.

** 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/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 1957104] Re: updating openssh-server fails, because port 22 is in use by systemd

[Paride Legovini]

Hello Thomas. You filed this bug against:

  DistroRelease: Ubuntu 21.10
  Package: openssh-server 1:8.4p1-6ubuntu2.1

By "Solved by a later version of systemd and sshd". Do you mean that you
found you can't reproduce the issue on Jammy (22.04 LTS)? Can you still
reproruce the issue on Impish? Thank you.

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

Title:
  updating openssh-server fails, because port 22 is in use by systemd

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  openssh-server tries to restart itself, but openssh-server reports
  port 22 in use. This is true: systemd has taken port 22 to start sshd
  if one connects to port 22.

  two solutions:
  1. dont start sshd after installing.
 configure it without starting it afterwards.
  2. stop systemd listening on port 22
 before starting sshd, then start sshd,
 terminate it after configuring, then
 start systemd listening on port 22 again.

  Second problem:
  starting ssh.service does not check if "/run/sshd" exists. This directory has 
to be created before sshd is started. Unclear if this is an error with sshd not 
creating this directory before dropping privileges or if this has to be done 
once while installing. IMHO the first is the case.

  
  Workaround:
  systemctl stop ssh.service
  systemctl disable ssh.service
  apt upgrade
  systemctl enable ssh.service
  killall sshd
  mkdir /run/sshd
  systemctl start ssh.service

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: openssh-server 1:8.4p1-6ubuntu2.1
  ProcVersionSignature: Ubuntu 5.13.0-23.23-generic 5.13.19
  Uname: Linux 5.13.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Tue Jan 11 19:11:47 2022
  InstallationDate: Installed on 2021-08-18 (146 days ago)
  InstallationMedia: Xubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  SSHDConfig: Error: command ['pkexec', '/usr/sbin/sshd', '-T'] failed with 
exit code 255: Missing privilege separation directory: /run/sshd
  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/1957104/+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 1971932] Re: error in rsync protocol data stream

[Paride Legovini]

Hello and thanks for this bug report. I tried to reproduce this locally
but I failed. We're certainly willing to investigate this, but first we
need some steps to reproduce the problem. Could you please try to
identify a somehow reliable way to reproduce the issue and share your
findings? 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/1971932

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

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

[Paride Legovini]

I found a (somehow stale) upstream PR that addresses this:

  https://github.com/openssh/openssh-portable/pull/250

We could include this as an Ubuntu patch, but it would be better to
first see it merged upstream. It may be worth pinging there.

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

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

-- 
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 1966886] Re: ssh-copy-id and Dropbear Server

[Paride Legovini]

** Tags added: 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 1971932] Re: error in rsync protocol data stream

[Paride Legovini]

Well, "large" can span orders of magnitude, depending who you ask. :-)

Can you please try to identify some steps to reproduce that include the
big file generation? For example:

  # 100MB file, random data (difficult to compress)
  head -c 100M /dev/urandom > foo

  # 100MB file, all 0s (easy to compress)
  head -c 100M /dev/zero > foo

Then you can try to rsync it to localhost via ssh to a different
directory (I assume you're using ssh and not the rsync protocol).
Thanks!

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

Title:
  error in rsync protocol data stream

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  When synchronizing to other systems, rsync exits with "error in rsync
  protocol data stream (code 12)".

  The problem occurs since ubuntu 22.04 LTS with two different
  destination systems not running ubuntu but plain debian. The error did
  not occur under 20.04 LTS.

  Synchronisation runs fine for most other files, but always stops at
  the same (relative large) file. The file itself has also been changed
  on a test basis to make sure the file is not the problem itself.

  Log snippet:
  

  ...
  chunk[46131] len=46120 offset=2127561720 sum1=2f48caf4
  chunk[46132] len=46120 offset=2127607840 sum1=5dfcb4ee
  chunk[46133] len=46120 offset=2127653960 sum1=d1037d81
  chunk[46134] len=8870 offset=2127700080 sum1=6deedc97
  send_files mapped 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX of size 
2135722584
  calling match_sums 
/path/backup/subdir/.thunderbird/profile/ImapMail/imap.domain.com/INBOX
  built hash table
  hash search b=46120 len=2135722584
  sum=1e1722dc k=46120
  hash search s->blength=46120 len=2135722584 count=46135
  potential match at 0 i=0 sum=1e1722dc
  match at 0 last_match=0 j=0 len=46120 n=0
  potential match at 46120 i=1 sum=c482d6b6
  match at 46120 last_match=46120 j=1 len=46120 n=0
  potential match at 92240 i=2 sum=b21c7e11
  match at 92240 last_match=92240 j=2 len=46120 n=0
  potential match at 138360 i=3 sum=d066473a
  match at 138360 last_match=138360 j=3 len=46120 n=0
  potential match at 184480 i=4 sum=a32a2984
  match at 184480 last_match=184480 j=4 len=46120 n=0
  potential match at 230600 i=5 sum=39cc049f
  match at 230600 last_match=230600 j=5 len=46120 n=0
  potential match at 276720 i=6 sum=ad3de98a
  match at 276720 last_match=276720 j=6 len=46120 n=0
  potential match at 322840 i=7 sum=83e16fa9
  match at 322840 last_match=322840 j=7 len=46120 n=0
  deflate on token returned 0 (8512 bytes left)
  rsync error: error in rsync protocol data stream (code 12) at token.c(476) 
[sender=3.2.3]
  [sender] _exit_cleanup(code=12, file=token.c, line=476): entered
  [sender] _exit_cleanup(code=12, file=token.c, line=476): about to call 
exit(12)

  Sender system: (rsync 3.2.3-8ubuntu3)
  -

  rsync  version 3.2.3  protocol version 31
  Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
  Web site: https://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
  batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
  symtimes, prealloc, stop-at, no crtimes
  Optimizations:
  SIMD, no asm, openssl-crypto
  Checksum list:
  xxh128 xxh3 xxh64 (xxhash) md5 md4 none
  Compress list:
  zstd lz4 zlibx zlib none

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

  Recipient systems: (rsync 3.1.3-6)
  --

  rsync  version 3.1.3  protocol version 31
  Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
  Web site: http://rsync.samba.org/
  Capabilities:
  64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
  socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
  append, ACLs, xattrs, iconv, symtimes, prealloc

  rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
  are welcome to redistribute it under certain conditions.  See the GNU
  General Public Licence for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1971932/+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 1946213] Re: strongswan: Fail to build against OpenSSL 3.0

[Paride Legovini]

The upstream commit [1] included as a patch in strongswan
(5.9.4-1ubuntu2) should be released in strongswan 5.9.5 [2].

[1] 
https://github.com/strongswan/strongswan/commit/b158c08c4b919b878ded10bb57e969ed7b3cabc3
[2] https://github.com/strongswan/strongswan/milestone/3?closed=1

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

Title:
  strongswan: Fail to build against OpenSSL 3.0

Status in OpenSSL:
  Fix Released
Status in strongSwan:
  New
Status in openssl package in Ubuntu:
  Fix Released
Status in strongswan package in Ubuntu:
  Fix Released

Bug description:
  Hello,

  As part of a rebuild against OpenSSL3, this package failed to build on one or
  several architectures. You can find the details of the rebuild at 

  https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html

  or for the amd64 failed build, directly at

  
https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0/+build/22099394/+files/buildlog_ubuntu-
  impish-amd64.strongswan_5.9.1-1ubuntu3.0~ssl3ppa1.1_BUILDING.txt.gz

  We're planning to transition to OpenSSL 3.0 for the 22.04 release, and 
consider
  this issue as blocking for this transition.

  You can find general migration informations at
  https://www.openssl.org/docs/manmaster/man7/migration_guide.html
  For your tests, you can build against libssl-dev as found in the PPA
  schopin/openssl-3.0.0

  The issue looks fixed upstream on master:
  
https://github.com/strongswan/strongswan/commit/72e5b3b7022ad14b245565a5aadcd097106af168

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/1946213/+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 1956954] Re: Can't load seccomp filter

[Paride Legovini]

Hi Nino, I found a RedHat bug [1] that describes a similar situation
(affected is dhclient on ppc64le, but the error is the same).

The suggested workaround is setting

  net.core.bpf_jit_limit = 262144000

via sysctl. I checked and on amd64 I find

  net.core.bpf_jit_limit = 264241152

while on an arm64 machine that's:

  net.core.bpf_jit_limit = 33554432

(both machines are running Bionic), so it looks arch-dependent indeed.
Could you please try bumping that value, and check if the issue goes
away?

If it does go away we can ask the kernel team what they think about
bumping it by default.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1647947

** Bug watch added: Red Hat Bugzilla #1647947
   https://bugzilla.redhat.com/show_bug.cgi?id=1647947

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1956954/+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 1956954] Re: Can't load seccomp filter

[Paride Legovini]

If you want to change the value without rebooting that's:

  sudo sysctl net.core.bpf_jit_limit=264241152

Add it to /etc/sysctl.conf if you want to set it automatically at boot,
but it's more meaningful to test as you said: wait for the issue to
happen and then change the value while the system is running.

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1956954/+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 1958453] Re: clamav-freshclam does not upgrade successfuly

[Paride Legovini]

Hello and thanks for your bug report. While you hit this issue while
upgrading clamav-freshclam, those hashfiles are owned by ucf(1), so I'm
reassigning the bug to the ucf package.

There isn't really enough information here for a developer to confirm
this issue is a bug, or to begin working on it, so I am marking this bug
Incomplete for now. If you can provide exact steps so that a developer
can reproduce the original problem, then please add them to this bug and
change the status back to New. Thanks!

** Package changed: clamav (Ubuntu) => ucf (Ubuntu)

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

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

Title:
  clamav-freshclam does not upgrade successfuly

Status in ucf package in Ubuntu:
  Incomplete

Bug description:
  When upgrading my email server:

  Setting up clamav-freshclam (0.103.5+dfsg-1~20.04.1) ...
  Replacing config file /etc/clamav/freshclam.conf with new version
  cp: '/var/lib/ucf/hashfile.5' and '/var/lib/ucf/hashfile.6' are the same file
  dpkg: error processing package clamav-freshclam (--configure):
   installed clamav-freshclam package post-installation script subprocess 
returned error exit status 1

  I chose to install the package maintainers configuration

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: clamav-freshclam 0.103.5+dfsg-1~20.04.1
  ProcVersionSignature: Ubuntu 5.4.0-94.106-generic 5.4.157
  Uname: Linux 5.4.0-94-generic x86_64
  NonfreeKernelModules: cpuid xt_conntrack xt_MASQUERADE nf_conntrack_netlink 
nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge stp llc 
aufs overlay dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua amd64_edac_mod 
edac_mce_amd kvm_amd ccp input_leds kvm macvlan mac_hid k10temp sch_fq_codel 
w83795 msr ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear radeon i2c_algo_bit ttm drm_kms_helper 
syscopyarea hid_generic sysfillrect sysimgblt fb_sys_fops usbhid pata_acpi ahci 
hid pata_atiixp i2c_piix4 drm libahci tg3
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Wed Jan 19 21:19:00 2022
  KernLog:
   
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IE.UTF-8
   SHELL=/bin/bash
  SourcePackage: clamav
  UpgradeStatus: Upgraded to focal on 2020-12-29 (386 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ucf/+bug/1958453/+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 1956954] Re: Can't load seccomp filter

[Paride Legovini]

Hi, glad to know it worked. There is some heuristics behind the default
bpf_jit_limit [1], it isn't a simple hardcoded value. We may discuss
bumping the default in Ubuntu, but I don't think that's a good idea: the
in-kernel heuristics has certainly been well thought, and just bumping
the number is likely to have other unintended consequences.

My take here is: your setup needs tuning, and that's what those config
knobs are for. Note that it's better to add a config file under
/etc/sysctl.d rather than modifying the default /etc/sysctl.conf.

Let me know if this makes sense for you. I'm leaving this bug marked
Incomplete for now.

[1]
https://github.com/torvalds/linux/blob/8efd0d9c316af470377894a6a0f9ff63ce18c177/kernel/bpf/core.c#L826

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

Title:
  Can't load seccomp filter

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  After migrating from Ubuntu 20 amd64 to aarch64 I started experiencing
  "can't load seccomp filter" when doing `apt update && apt upgrade` and
  "Kernel refuses to turn on BPF filters" when using Puppeteer.

  I wrote about it more extensively here:
  https://stackoverflow.com/questions/69892137/after-a-few-days-i-can-
  no-longer-start-puppeteer-until-i-restart-the-server

  
  lsb_release -rd
  ---
  Description:  Ubuntu 20.04.3 LTS
  Release:  20.04

  apt-cache policy seccomp
  ---
  seccomp:
Installed: (none)
Candidate: 2.5.1-1ubuntu1~20.04.2
Version table:
   2.5.1-1ubuntu1~20.04.2 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports 
focal-updates/main arm64 Packages
  500 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 
Packages
   2.4.3-1ubuntu1 500
  500 http://us-east-1.ec2.ports.ubuntu.com/ubuntu-ports focal/main 
arm64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1956954/+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 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange

[Paride Legovini]

That PR is still pending review, no movements there unfortunately.

-- 
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 portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh source package in Focal:
  Triaged
Status in openssh source package in Hirsute:
  Won't Fix

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: kex_input_ext_info: 
server-sig-algs=
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-with-mic
  debug1: Delegating credentials
  debug1: Delegating credentials
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-keyex
  Connection closed by 1.2.3.4 port 

  Server log:

  debug1: sshd version OpenSSH_8.2, OpenSSL 1.1.1f  31 Mar 2020
  debug1: private host key #0: ssh-rsa SHA256:REDACTED
  debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:R

[Touch-packages] [Bug 1959488] Re: Error loading key ".../id_ed25519.pub": error in libcrypto

[Paride Legovini]

Hello Thomas and thanks for your bug report. I have no problems adding
ed25519 keys to ssh-agent on a Jammy system. Could you please try the
following steps, which may help identifying where the problem is?
Thanks!

$ mkdir /tmp/ed25519test
$ cd /tmp/ed25519test

$ echo $SSH_AUTH_SOCK
/run/user/1000/openssh_agent

$ ssh-keygen -t ed25519 -C foobar -P '' -f ./test
Generating public/private ed25519 key pair.
Your identification has been saved in ./test
Your public key has been saved in ./test.pub
The key fingerprint is:
SHA256:EFUY6Ke0diCIoFQjCvhiUBzondDLMidZN4/bzkt1X6I foobar
The key's randomart image is: [...]

$ cat test.pub
ssh-ed25519 
C3NzaC1lZDI1NTE5IEqKBt+j+61A9GtPaA9RLEEHxBQpAgvUSkjpqlRpVXOh foobar

$ ssh-add ./test
Identity added: ./test (foobar)

$ ssh-add -L | grep foobar
ssh-ed25519 
C3NzaC1lZDI1NTE5IEqKBt+j+61A9GtPaA9RLEEHxBQpAgvUSkjpqlRpVXOh foobar


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

Title:
  Error loading key ".../id_ed25519.pub": error in libcrypto

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I can't add my ED25519 ssh-key to my ssh-agent. I am getting this
  error message:

  user@pc:~$ ssh-add ~/.ssh/id_ed25519.pub
  Error loading key "/home/user/.ssh/id_ed25519.pub": error in libcrypto

  I have setup key agent for KDE like this:

  user@pc:~$ cat ~/.config/plasma-workspace/env/ssh-agent.sh
  #!/bin/bash

  [ -n "$SSH\_AGENT\_PID" ] || eval "$(ssh-agent -s)"

  user@pc:~$ cat ~/.config/plasma-workspace/env/ssh-askpass.sh
  #!/bin/bash

  [ -n "$SSH\_ASKPASS" ] || export SSH\_ASKPASS=/usr/bin/ksshaskpass

  user@pcc:~$ cat ~/.config/plasma-workspace/shutdown/ssh-agent-shutdown.sh 
  #!/bin/bash

  [ -z "$SSH\_AGENT\_PID" ] || eval "$(ssh-agent -k)"

  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: openssh-client 1:8.7p1-4
  Uname: Linux 5.15.0-051500-generic x86_64
  ApportVersion: 2.20.11-0ubuntu76
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Sat Jan 29 16:43:55 2022
  InstallationDate: Installed on 2022-01-21 (7 days ago)
  InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 
(20220121)
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   ssh-askpass   N/A
   libpam-sshN/A
   keychain  N/A
   ssh-askpass-gnome N/A
  SSHClientVersion: OpenSSH_8.7p1 Ubuntu-4, OpenSSL 3.0.1 14 Dec 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/1959488/+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 1959365] Re: openssh-client tab completion faills if shopt failglob is set

[Paride Legovini]

I can reproduce this:

$ shopt -s failglob
$ ssh bash: no match: /etc/ssh/ssh_config.d/*.conf

but I believe the bugs belongs to the bash-completion package.

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

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

** Package changed: openssh (Ubuntu) => bash-completion (Ubuntu)

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

Title:
  openssh-client tab completion faills if shopt failglob is set

Status in bash-completion package in Ubuntu:
  Confirmed

Bug description:
  $ ssh 

  ends up looking like

  $ ssh bash: no match: /etc/ssh/ssh_config.d/*.conf
  $ _

  
  I have shopt failglob set in my bashrc as a personal preference and most 
other packages' tab completion can deal with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1959365/+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 1931104] Re: Test of dogtag-pki is failing on s390x due to LTO

[Paride Legovini]

I reviewed this issue again and I don't think we're ready to drop the
"Disable LTO on s390x" delta for now. There are newer NSS upstream
versions worth testing but in Ubuntu we're still at 3.68 for now.

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

Title:
  Test of dogtag-pki is failing on s390x due to LTO

Status in NSS:
  New
Status in nss package in Ubuntu:
  Triaged
Status in nss package in Fedora:
  Unknown

Bug description:
  The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
  Example:
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz

  Bad:
  Installing CA into /var/lib/pki/pki-tomcat.
  Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end 
closed connection without response'))
  ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote 
end closed connection without response'))
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 995, in spawn
  cert = deployer.setup_cert(client, tag)
    File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", 
line 355, in setup_cert
  return client.setupCert(request)
    File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
  response = self.connection.post(
    File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
  return func(self, *args, **kwargs)
    File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
  r = self.session.post(
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in 
post
  return self.request('POST', url, data=data, json=json, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
    File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
    File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in 
send
  raise ConnectionError(err, request=request)
   CA spawn failed:

  Good:
  nstalling CA into /var/lib/pki/pki-tomcat.
  Notice: Trust flag u is set automatically if the private key is present.
  /usr/lib/python3/dist-packages/urllib3/connection.py:455: 
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`, 
falling back to check for a `commonName` for now. This feature is being removed 
by major browsers and deprecated by RFC 2818. (See 
https://github.com/urllib3/urllib3/issues/497 for details.)
    warnings.warn(

  ==
  INSTALLATION SUMMARY
  ==
  ...

  The good test above was with:
  ii  libnss3:s390x2:3.61-1ubuntu2  s390xNetwork Security 
Service libraries
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server

  Worth to know, the good case test still fails later on with:
  IOException: SocketException cannot write on socket: Failed to write to 
socket: (-5938) Encountered end of file.
  ERROR: CalledProcessError: Command '['pki', '-d', 
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U', 
'https://i-dogtag:8443', 'securitydomain-join', '--session', 
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag', 
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']' 
returned non-zero exit status 255.
    File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in 
main
  scriptlet.spawn(deployer)
    File 
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
 line 1038, in spawn
  subsystem.join_security_domain(
    File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201, 
in join_security_domain
  subprocess.check_call(cmd)
    File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
  raise CalledProcessError(retcode, cmd)
  Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f 
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join 
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port 
8080 --secure-port 8443 TKS i-dogtag 8443
  Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log

  Well one issue at a time ... the current install issue first.

  Since it worked with the nss in -release I was upgrading this to the new nss.
  ii  389-ds-base1.4.4.11-2  s390x389 Directory Server suite - 
server
  ii  libnss3:s390x  2:3.63-1ubuntu1 s3

[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start

[Paride Legovini]

** Changed in: dnsmasq (Ubuntu)
 Assignee: Paride Legovini (paride) => (unassigned)

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1778073/+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 1778073] Re: dnsmasq and resolvconf hangs on start

[Paride Legovini]

** Changed in: dnsmasq (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1778073/+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 1778073] Re: dnsmasq and resolvconf hangs on start

[Paride Legovini]

Hi, I had another look at this one and Ciaby's analysis looks correct to
me, however I want to setup a full reproducer before attempting a fix. I
assigned the bug to myself.

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

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1778073/+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 1938144] Re: monitor_read: unpermitted request 48 on server while attempting GSSAPI key exchange

[Paride Legovini]

** Also affects: openssh (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: openssh (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

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

** Tags added: server-next

-- 
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 portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh source package in Focal:
  Triaged
Status in openssh source package in Hirsute:
  Triaged

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: kex_input_ext_info: 
server-sig-algs=
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next authentication method: gssapi-with-mic
  debug1: Delegating credentials
  debug1: Delegating credentials
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
  debug1: Next a

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Paride Legovini]

The only task that remains to tackled here is dnsmasq on Bionic.

By following the [Test Case] I verified that applying [1] fixes the bug
in Bionic. The first two hunks of the patch are already applied in the
Ubuntu package, what remains to apply is in the attached patch.

[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

** Patch added: "lp1785383-dnsmasq-bionic.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1785383/+attachment/5527343/+files/lp1785383-dnsmasq-bionic.patch

** Changed in: dnsmasq (Ubuntu Bionic)
 Assignee: (unassigned) => Paride Legovini (paride)

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

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

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case for bionic:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

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

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  
  More detailed test case for focal and later:

  install dnsmasq on a bionic system and start it, listening to an
  interface that is externally reachable, e.g. for a normal libvirt vm
  with interface name 'ens3':

  IFACE=ens3
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/

  note that the '1.2.3.4' address doesn't matter, any addr is ok.

  then setup a test system that can reach the dnsmasq system, and
  configure networkd to use the dnsmasq server, e.g. using config like:

  [Match]
  Name=ens3

  [Network]
  DHCP=yes
  DNS=DNSMASQ_IP_ADDRESS
  Domains=test

  [DHCPv4]
  UseDNS=no
  UseDomains=no

  replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
  dnsmasq is running, and replace 'ens3' with whatever the test system
  interface name is. Then restart systemd-networkd, and test:

  systemd-resolve --reset-server-features
  systemd-resolve --flush-caches
  host test.test

  The lookup using 'host' should complete immediately;.

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpa

[Touch-packages] [Bug 1944436] Re: Please backport support for "close_range" syscall

[Paride Legovini]

Reminds me of LP: #1943049. I mentioned this bug there, as we should
make sure that close_range doesn't bring us back to that same issue.

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

Title:
  Please backport support for "close_range" syscall

Status in libseccomp package in Ubuntu:
  New

Bug description:
  Please backport support for the "close_range" syscall .. may be as
  simple as cherrypicking

  
https://github.com/seccomp/libseccomp/commit/01e5750e7c84bb14e5a5410c924bed519209db06

  from upstream. I've hit problems running buildah in a systemd-nspawn
  container, but this will probably affect people trying to run modern
  code in other container systems as well, e.g. docker.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libseccomp2 2.5.1-1ubuntu1~20.04.1
  ProcVersionSignature: Ubuntu 5.4.0-84.94-generic 5.4.133
  Uname: Linux 5.4.0-84-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.20
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: Xpra
  Date: Tue Sep 21 15:10:54 2021
  InstallationDate: Installed on 2017-01-08 (1717 days ago)
  InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  SourcePackage: libseccomp
  UpgradeStatus: Upgraded to focal on 2021-09-02 (19 days ago)

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


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

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Paride Legovini]

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

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

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

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case for bionic:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

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

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  
  More detailed test case for focal and later:

  install dnsmasq on a bionic system and start it, listening to an
  interface that is externally reachable, e.g. for a normal libvirt vm
  with interface name 'ens3':

  IFACE=ens3
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/

  note that the '1.2.3.4' address doesn't matter, any addr is ok.

  then setup a test system that can reach the dnsmasq system, and
  configure networkd to use the dnsmasq server, e.g. using config like:

  [Match]
  Name=ens3

  [Network]
  DHCP=yes
  DNS=DNSMASQ_IP_ADDRESS
  Domains=test

  [DHCPv4]
  UseDNS=no
  UseDomains=no

  replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
  dnsmasq is running, and replace 'ens3' with whatever the test system
  interface name is. Then restart systemd-networkd, and test:

  systemd-resolve --reset-server-features
  systemd-resolve --flush-caches
  host test.test

  The lookup using 'host' should complete immediately;.

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Paride Legovini]

I dropped the verification-* as there were about the systemd SRU, while
I'm preparing the dnsmasq one at the moment.

** Description changed:

  [Impact]
- dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.
  
- [Fix]
- This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
+ dnsmasq 2.79 and below omits EDNS0 OPT records [1] when returning an
+ empty answer for a domain it is authoritative for. systemd-resolved
+ seems to get confused by this in certain circumstances; when using the
+ stub resolver and requesting an address for which there are no 
+ records, there can sometimes be a five second hang in resolution.
  
- Not sure if it is worth cherry picking? I imagine the most likely
- trigger will be dnsmasq on routers which are not likely to be running
- Ubuntu, but maybe just in case.
+ [1] https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS
  
- I also think there are some logic issues in systemd-resolved, upstream
- bug filed:
+ [Test Plan]
  
- https://github.com/systemd/systemd/issues/9785
+ Test case for bionic:
  
- [Test Case]
- Simple-ish test case for bionic:
- 
- ---
+ -
  IFACE=dummy0
  SUBNET=10.0.0
  
  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 --server=/test/ &
  
  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
- ---
+ -
  
- To reproduce the systemd-resolved side of the problem
+ [Where problems could occur]
  
- ---
- # as above, but
- # now configure systemd-resolved to look at only 10.0.0.1, then
+ Problems may occur in case a client queries dnsmasq and relies on EDNS0
+ not being available for behaving correctly. This covers cases where the
+ software querying dnsmasq is buggy or misconfigured.
  
- systemd-resolve --reset-server-features
- # should exhibit five second delay then connect, assuming sshd is running :)
- ssh test.test
- ---
+ [Development Fix]
  
+ Fixed upstream in dnsmasq >= 2.80.
  
- More detailed test case for focal and later:
+ [Stable Fix]
  
- install dnsmasq on a bionic system and start it, listening to an
- interface that is externally reachable, e.g. for a normal libvirt vm
- with interface name 'ens3':
+ Partial cherry-pick of upstream commit
+ 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
  
- IFACE=ens3
- dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,1.2.3.4 --server=/test/
- 
- note that the '1.2.3.4' address doesn't matter, any addr is ok.
- 
- then setup a test system that can reach the dnsmasq system, and
- configure networkd to use the dnsmasq server, e.g. using config like:
- 
- [Match]
- Name=ens3
- 
- [Network]
- DHCP=yes
- DNS=DNSMASQ_IP_ADDRESS
- Domains=test
- 
- [DHCPv4]
- UseDNS=no
- UseDomains=no
- 
- replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
- dnsmasq is running, and replace 'ens3' with whatever the test system
- interface name is. Then restart systemd-networkd, and test:
- 
- systemd-resolve --reset-server-features
- systemd-resolve --flush-caches
- host test.test
- 
- The lookup using 'host' should complete immediately;.
- 
- [Discussion]
- ProblemType: Bug
- DistroRelease: Ubuntu 18.04
- Package: dnsmasq-base 2.79-1
- ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
- Uname: Linux 4.15.0-23-generic x86_64
- ApportVersion: 2.20.9-0ubuntu7.2
- Architecture: amd64
- Date: Sat Aug  4 11:33:56 2018
- InstallationDate: Installed on 2018-05-31 (64 days ago)
- InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
- ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  LANG=en_GB.UTF-8
-  SHELL=/bin/bash
- SourcePackage: dnsmasq
- UpgradeStatus: No upgrade log present (probably fresh install)
+ The cherry-pick is partial because half if it is already in the package
+ .diff we have in Bionic.

** Tags removed: verification-done verification-done-bionic
verification-done-focal verification-done-groovy verification-done-
hirsute

** Description changed:

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

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Paride Legovini]

MP to fix this bug in Bionic, already reviewed and uploaded:

https://code.launchpad.net/~paride/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/409149

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

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

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

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

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

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

  [Where problems could occur]

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

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

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

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

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


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

[Touch-packages] [Bug 1922130] Re: Request addition of Fedora / Redhat "sftp-force-permissions" patch

[Paride Legovini]

** Bug watch added: OpenSSH Portable Bugzilla #1844
   https://bugzilla.mindrot.org/show_bug.cgi?id=1844

** Also affects: openssh via
   https://bugzilla.mindrot.org/show_bug.cgi?id=1844
   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/1922130

Title:
  Request addition of Fedora / Redhat "sftp-force-permissions" patch

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  Confirmed

Bug description:
  Fedora / Redhat ships openssh with a patch which adds "-m force
  permission" flag to sftp-server.

  This is quite a common feature request / support request on the
  various stackexchange sites -
  https://superuser.com/questions/332284/in-sftp-how-to-set-the-default-
  permission-for-all-files-in-a-folder

  You will see that someone has answered "add -m" there which is indeed
  the simplest answer by a distance but unfortunately it's a non
  standard patch:

  https://src.fedoraproject.org/rpms/openssh/blob/f34/f/openssh-6.7p1-sftp-
  force-permission.patch

  This I think should supersede #563216 because they have been shipping
  this in production presumably since at least 2015 (I see it in fedora
  22 branch), so it is a known stable patch compared to the one
  suggested there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/1922130/+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 1945787] Re: heimdal: fails to build, symbols don't match

[Paride Legovini]

Thanks for this bug report; I can reproduce the issue and will prepare
an upload with your debdiff.

** Changed in: heimdal (Ubuntu)
 Assignee: (unassigned) => Paride Legovini (paride)

** Tags added: server-next

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

Title:
  heimdal: fails to build, symbols don't match

Status in heimdal package in Ubuntu:
  New

Bug description:
  heimdal 7.7.0+dfsg-2ubuntu1 fails to build with

  dpkg-gensymbols: warning: debian/libroken18-heimdal/DEBIAN/symbols doesn't 
match completely debian/libroken18-heimdal.symbols
  --- debian/libroken18-heimdal.symbols 
(libroken18-heimdal_7.7.0+dfsg-2ubuntu1_riscv64)
  +++ dpkg-gensymbolsYtlvSr   2021-10-01 12:31:59.102451503 +
  @@ -42,7 +42,7 @@
rk_cloexec_dir@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_cloexec_file@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_cloexec_socket@HEIMDAL_ROKEN_1.0 1.6~git20131117
  - rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  +#MISSING: 7.7.0+dfsg-2ubuntu1# rk_closefrom@HEIMDAL_ROKEN_1.0 
1.4.0+git20110226
rk_copyhostent@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_dns_free_data@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
rk_dns_lookup@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  dh_makeshlibs: error: failing due to earlier errors

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1945787/+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 1432935] Re: ntpd -x steps clock on leap second (upstream bug: 2745)

[Paride Legovini]

Trusty is now in Extended Security Maintenance [1], and this bug doesn't
qualify for it, so it won't be fixed in that release.

[1] https://wiki.ubuntu.com/Releases

** Changed in: ntp (Ubuntu Trusty)
   Status: New => Won't Fix

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

Title:
  ntpd -x steps clock on leap second (upstream bug: 2745)

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

Bug description:
  in http://bugs.ntp.org/show_bug.cgi?id=2745
   | With older versions it was possible to use the -x option to avoid upsetting
   | applications running on the system when the clock is stepped due to a leap
   | second.
   | 
   | It seems in 4.2.6 was added support for inserting/deleting leap seconds on
   | systems without kernel discipline. However, the clock is now stepped even 
when
   | the -x option or tinker step is used to disable stepping.

  I'm not sure this bug could affect Ubuntu's ntp packages, but I
  believe that this information is IMPORTANT for some ubuntu users.

  Note: This bug is copied from
  https://rhn.redhat.com/errata/RHBA-2015-0690.html, thanks Red Hat.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1432935/+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 1849560] Re: Please revise the files installed in /etc/

[Paride Legovini]

I share Christian's concern on nobody actually caring about this. Given
the absence of activity in >1 year I'm marking this bug as Incomplete,
which is an invite for anybody interested to chime in.

In absence of feedback I doubt there will be any progress here, as the
direction to take isn't fully clear, and from our point of view the
openssh packages are behaving as expected.

** Changed in: openssh (Ubuntu)
   Status: Triaged => 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/1849560

Title:
  Please revise the files installed in /etc/

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  openssh-server and openssh-client install various files under /etc:

  /etc/ssh/*
  /etc/systemd/system/sshd.service

  Please see if these files can be moved elsewhere, in accordance with
  FHS: /etc should only contain files writable by the system
  administrator, and in Ubuntu Core 20 we should aim to have no writable
  files in /etc (as it will be included in images, avoid conflict
  resolution on upgrades).

  At a glance, it looks like /etc/systemd/system/sshd.service could be
  moved to /lib/systemd/system, and many of the files in /etc/ssh do
  have suitable locations elsewhere on the system, such as /var/lib/ for
  generated keys, /usr/share/ for default SSH configurations, etc.)

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


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

[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Paride Legovini]

The MP got reviewed and the dnsmasq upload is currently waiting in the
Bionic unapproved queue.

Being a format 1.0 package the diff [1] looks huge at first glance, but
the real changes are actually very limited (those in the MP).

[1]
https://launchpadlibrarian.net/560828569/dnsmasq_2.79-1ubuntu0.5.diff.gz

** Merge proposal linked:
   
https://code.launchpad.net/~paride/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/409149

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

Title:
  missing EDNS0 record confuses systemd-resolved

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

Bug description:
  [Impact]

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

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

  [Test Plan]

  Test case for bionic:

  -
  IFACE=dummy0
  SUBNET=10.0.0

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

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

  [Where problems could occur]

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

  [Development Fix]

  Fixed upstream in dnsmasq >= 2.80.

  [Stable Fix]

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

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

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


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

[Touch-packages] [Bug 1651044] Re: ProxyDHCP replies on invalid range

[Paride Legovini]

Hi,

I had a look at [1] and AIUI this wasn't recognized as an upstream bug.
I also can't find a relevant Debian bug about this issue. The bug
description says it affected Xenial, which is now in Extended Security
Maintenance, so it's a Won't Fix there.

For >= Bionic we need confirmation from an affected user the bug is
still present and valid. Waiting for feedback I'm marking this bug
report as Incomplete.

[1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/2016q4/011010.html

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

** Changed in: dnsmasq (Ubuntu)
   Importance: High => Undecided

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

Title:
  ProxyDHCP replies on invalid range

Status in dnsmasq package in Ubuntu:
  Incomplete

Bug description:
  In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, 
yet it replies even when it gets an IP on subnet=10.161.254.0/24.
  I've only seen this after clean system restart. If I restart dnsmasq later 
on, it works as expected.
  Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly 
initializes some networking information? I'm using network-manager with DHCP.

  Details:
  $ egrep -rv '^#|^$' /etc/dnsmasq.*
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
  
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
  /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from 
network", /ltsp/i386/pxelinux

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  2: enp2s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
  inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
 valid_lft 431873sec preferred_lft 431873sec
  inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link 
 valid_lft forever preferred_lft forever

  $ sudo netstat -nap | grep dnsmasq
  [sudo] password for administrator: 
  tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
  843/dnsmasq 
  tcp6   0  0 :::53   :::*LISTEN
  843/dnsmasq 
  udp0  0 0.0.0.0:53  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:67  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:69  0.0.0.0:* 
  843/dnsmasq 
  udp0  0 0.0.0.0:40110.0.0.0:* 
  843/dnsmasq 
  udp6   0  0 :::53   :::*  
  843/dnsmasq 
  udp6   0  0 :::69   :::*  
  843/dnsmasq 
  unix  2  [ ] DGRAM15746843/dnsmasq
 

  $ grep dnsmasq /var/log/syslog | tail -n 30
  Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP 
and caching DNS server...
  Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC 
loop-detect inotify
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 
-- 192.168.67.250, lease time 8h
  Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 
10.160.37.0
  Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
  Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in 
/var/run/dnsmasq/resolv.conf, wil

[Touch-packages] [Bug 1645002] Re: ssh sessions are not cleanly terminated on shutdown/restart with systemd

[Paride Legovini]

Xenial is now in Extended Security Maintenance and this bug doesn't
qualify for it, so the bugfix won't be SRUed there.

** Changed in: openssh (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 openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1645002

Title:
  ssh sessions are not cleanly terminated on shutdown/restart with
  systemd

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Won't Fix
Status in openssh source package in Yakkety:
  Fix Released
Status in openssh package in Debian:
  Fix Released

Bug description:
  In Ubuntu 16.04, a "reboot" command does not terminate the ssh
  session. This results in clients hanging, until timing out (sometimes
  as much as 120 seconds).

  This also introduces bugs to all  orchestration / automation tools which work 
over SSH, since they cannot issue their reboot equivalent for Ubuntu 16.04 
hosts. For example, have a look at this issue for Fabric:
  https://github.com/fabric/fabric/issues/1488

  The exact same bug has been fixed in Debian in version openssh/1:7.2p2-6. 
  There is a very detailed discussion in their bug tracker:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002/+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 1618719] Re: scp1 reports ssh1 is not supported

[Paride Legovini]

Xenial is now in Extended Security Maintenance and this bug doesn't
qualify for it, so this bug won't be fixed in that release.

** Changed in: openssh (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 openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1618719

Title:
  scp1 reports ssh1 is not supported

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

Bug description:
  For getting ssh protocol 1 support I installed the package 
openssh-client-ssh1.
  This works with .ssh/config host entries, when omitting any "Protocol 1" 
lines, but calling "ssh1 -1 host".
  This package also has the command scp1 included, but this command doesn't 
have ssh protocol 1 support:
  > corben@ubuntu:~$ scp1 -1 host:/path/to/file .
  > ssh1 is not supported
  Is the ssh protocol 1 support not included for scp1 during compile time?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1618719/+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 1608965] Re: ssh GSSAPI rekey failure

[Paride Legovini]

Yakkety reached EOL, while Xenial is now in Extended Security
Maintenance, and this bug doesn't qualify for it, so this bug won't be
fixed in those releases.

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

** Changed in: openssh (Ubuntu Yakkety)
   Status: Triaged => 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/1608965

Title:
  ssh GSSAPI rekey failure

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Won't Fix
Status in openssh source package in Yakkety:
  Won't Fix

Bug description:
  If I have ssh set up using GSSAPI with rekeying enabled, then the
  connection fails on rekey, and tries to do host-based verification
  'mid-session'.

  Steps to reproduce:

  $ ssh -vvv server.example.com
  
  debug1: Authenticating to ssh.example.com:22 as 'user'
  
  debug2: local client KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,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: peer server KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
  
  Last login: Tue Aug 02 10:47:20 2016 from foo

  # Then do 'kinit' on the client to get a new ticket...

  debug1: need rekeying
  debug1: SSH2_MSG_KEXINIT sent
  debug1: rekeying in progress
  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
  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,null
  [...]
  debug2: peer server KEXINIT proposal
  debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
  [...]
  debug1: kex: algorithm: curve25519-sha...@libssh.org
  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: expecting SSH2_MSG_KEX_ECDH_REPLY
  debug1: rekeying in progress
  debug1: rekeying in progress
  debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:w7yxbCZNBX4d5EAgmCrFYa3XUpDjvWiDOw4/YOY9q8E
  The authenticity of host 'server.example.com (10.0.0.1)' can't be established.
  ECDSA key fingerprint is SHA256:w7yxbCZNBX4d5EAgmCrFYa3XUpDjvWiDOw4/YOY9q8E.
  Are you sure you want to continue connecting (yes/no)? 
  Host key verification failed.

  It looks like the list of KEX algorithms differs between the initial
  connection, and the rekeying.

  This behaviour seems to occur with a client running 16.04 (openssh-
  client 1:7.2p2-4ubuntu1) but not on 15.10 (openssh-client
  1:6.9p1-2ubuntu0.2).

  ssh_config is as follows:

  HashKnownHosts no
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  GSSAPIRenewalForcesRekey yes
  GSSAPITrustDNS yes
  GSSAPIKeyExchange yes
  ForwardX11 yes
  ForwardX11Trusted yes

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1608965/+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 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

[Paride Legovini]

Hello Nahuel,

According to your reasoning I assume the "root" issue should still
affect the versions of rsync shipped with the newer Ubuntu releases.

I agree it would be nice for the behavior you describe to be documented,
but I don't think it's worth patching the Ubuntu package for it. I
recognize we have a papercut here, but I don't think the fix for it
belongs to Ubuntu; it should instead be driven (and thus also validated)
upstream. For this reason I'm marking this bug as a Won't Fix. Should
you disagree with my assessment please comment back and set the bug
status back to New, we'll look at it again. Thanks!

** Changed in: rsync (Ubuntu)
   Status: Triaged => Opinion

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

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1659950/+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 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

[Paride Legovini]

** Also affects: rsync via
   https://github.com/WayneD/rsync/issues/236
   Importance: Unknown
   Status: Unknown

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

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

To manage notifications about this bug go to:
https://bugs.launchpad.net/rsync/+bug/1659950/+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 1659950] Re: rsync -u --inplace --partial -a can't resume transfer

[Paride Legovini]

Thanks Nahuel! We're doing some retriage and cleanup of old bugs, and I
stumbled on this one :-)

I linked your upstream bug report to this bug, Launchpad will keep its
status in sync. You may have noticed that I didn't set the status of
this bug to Wontfix but to Opinion ("Doesn't fit with the project, but
can be discussed"), I think it fits better.

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

Title:
  rsync -u --inplace --partial -a can't resume transfer

Status in rsync:
  Unknown
Status in rsync package in Ubuntu:
  Opinion

Bug description:
  Suppose you have a file in hostA:

hostA$ ls -l /tmp/files
 -rw-rw-r-- 2 root root 563016 Jan 10 15:01 test.txt

  You download it from the hostB using:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  If the transfer is aborted, hostB will get only a partial file:

hostB$ ls -l /tmp/files
 -rw-rw-r-- 2 root root   2024 Jan 11 18:00 test.txt

  BUT the ctime/mtime of hostB/test.txt now is NEWER than hostA/test.txt(and 
mtime == ctime). So, if you run the same rsync -u command again:

hostB$ rsync -u --inplace --partial -a hostA::files/* .

  Rsync will SKIP THE FILE, because hostB/test.txt is "newer" than
  hostA/test.txt. So you CAN'T resume using rsync -u command, and you
  will think there are no differences.

  To avoid this bug, rsync must create the file with ctime=mtime=0. And
  if the file already exists before transfer, rsync -u must not change
  his current ctime/mtime. Ctime/mtime must be updated ONLY after the
  transfer was successfully completed.

  Note this is really need because there are scenarios where checksum
  comparison can't be used, only comparison by time. For example, to
  avoid deleting changes made in hostB to test.txt. Also I need to use
  --inplace.

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