date:20211112

The original bug report stated

> OpenSSL version is 1.1.1f
>
> The issue is not encountered if 
> http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

Does that mean you believe the double parsing issue is in one of the
patches in debian/patches in the Ubuntu package, and not an upstream
bug? If so, could you bisect the patches and see which one causes the
crash?

If not, please open an issue with OpenSSL upstream and link it here for
tracking.

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

Title:
  OpenSSL "double free" error

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

Bug description:
  "double free" error is seen when using curl utility. Error is from
  libcrypto.so which is part of the OpenSSL package. This happens only
  when OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  
  OpenSSL can be configured to use a dynamic engine by editing the default 
openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu 
systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids
   
  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

2021-11-12 Thread Andrea Righi

** Description changed:

+ [Impact]
+ 
  Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
  is always failing. Initially I thought it was a kernel issue, but
  debugging further I found that the reason is that with Impish we're
  using iptables-nft by default instead of iptables-legacy.
  
  This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
  source directory) is creating a bunch of network namespaces and checking
  the iptables counters for the defined policies, in particular this is
  the interesting part:
  
  check_ipt_policy_count()
  {
- ns=$1
+ ns=$1
  
- ip netns exec $ns iptables-save -c |grep policy | ( read c rest
- ip netns exec $ns iptables -Z
- if [ x"$c" = x'[0:0]' ]; then
- exit 0
- elif [ x"$c" = x ]; then
- echo "ERROR: No counters"
- ret=1
- exit 111
- else
- exit 1
- fi
- )
+ ip netns exec $ns iptables-save -c |grep policy | ( read c rest
+ ip netns exec $ns iptables -Z
+ if [ x"$c" = x'[0:0]' ]; then
+ exit 0
+ elif [ x"$c" = x ]; then
+ echo "ERROR: No counters"
+ ret=1
+ exit 111
+ else
+ exit 1
+ fi
+ )
  }
  
  If I use iptables-nft the counters are never [0:0] as they should be, so
  the test is failing. With iptables-legacy they are [0:0] and the test is
  passing.
  
- Any idea why this is happening and how I can debug this in iptables?
+ [Test case]
  
- Thanks in advance.
+ tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel source
+ code.
+ 
+ [Fix]
+ 
+ Apply iptables upstream commit:
+   
+ 5f1fcace ("iptables-nft: fix -Z option")
+ 
+ In this way also with iptables-nft the counters are reported correctly.
+ 
+ [Regression potential]
+ 
+ We may require other upstream commits now that the -Z option is working
+ properly with iptables-nft.

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

Title:
  iptables-save -c shows incorrect counters with iptables-nft

Status in iptables package in Ubuntu:
  New
Status in iptables source package in Impish:
  New
Status in iptables source package in Jammy:
  New

Bug description:
  [Impact]

  Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
  is always failing. Initially I thought it was a kernel issue, but
  debugging further I found that the reason is that with Impish we're
  using iptables-nft by default instead of iptables-legacy.

  This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
  source directory) is creating a bunch of network namespaces and
  checking the iptables counters for the defined policies, in particular
  this is the interesting part:

  check_ipt_policy_count()
  {
  ns=$1

  ip netns exec $ns iptables-save -c |grep policy | ( read c rest
  ip netns exec $ns iptables -Z
  if [ x"$c" = x'[0:0]' ]; then
  exit 0
  elif [ x"$c" = x ]; then
  echo "ERROR: No counters"
  ret=1
  exit 111
  else
  exit 1
  fi
  )
  }

  If I use iptables-nft the counters are never [0:0] as they should be,
  so the test is failing. With iptables-legacy they are [0:0] and the
  test is passing.

  [Test case]

  tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
  source code.

  [Fix]

  Apply iptables upstream commit:

  5f1fcace ("iptables-nft: fix -Z option")

  In this way also with iptables-nft the counters are reported
  correctly.

  [Regression potential]

  We may require other upstream commits now that the -Z option is
  working properly with iptables-nft.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1949603/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

I've implemented the workaround in systemd's debian/test/tests-in-lxd.

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

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

The proposed patch looks ok.

The version numbers are interesting. Impish release is at
1.8.7-1ubuntu2, and impish upload  1.8.7-1ubuntu3 got only published
into Jammy.

So the correct version numbers to use will be ubuntu4 for jammy and 2.1
for impish, I will correct that for SRU.

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

Title:
  iptables-save -c shows incorrect counters with iptables-nft

Status in iptables package in Ubuntu:
  New
Status in iptables source package in Impish:
  New
Status in iptables source package in Jammy:
  New

Bug description:
  [Impact]

  Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
  is always failing. Initially I thought it was a kernel issue, but
  debugging further I found that the reason is that with Impish we're
  using iptables-nft by default instead of iptables-legacy.

  This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
  source directory) is creating a bunch of network namespaces and
  checking the iptables counters for the defined policies, in particular
  this is the interesting part:

  check_ipt_policy_count()
  {
  ns=$1

  ip netns exec $ns iptables-save -c |grep policy | ( read c rest
  ip netns exec $ns iptables -Z
  if [ x"$c" = x'[0:0]' ]; then
  exit 0
  elif [ x"$c" = x ]; then
  echo "ERROR: No counters"
  ret=1
  exit 111
  else
  exit 1
  fi
  )
  }

  If I use iptables-nft the counters are never [0:0] as they should be,
  so the test is failing. With iptables-legacy they are [0:0] and the
  test is passing.

  [Test case]

  tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
  source code.

  [Fix]

  Apply iptables upstream commit:

  5f1fcace ("iptables-nft: fix -Z option")

  In this way also with iptables-nft the counters are reported
  correctly.

  [Regression potential]

  We may require other upstream commits now that the -Z option is
  working properly with iptables-nft.

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


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

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

2021-11-12 Thread dan purdy

** Changed in: gzip (Ubuntu)
 Assignee: (unassigned) => dan purdy (purdydan317)

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

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

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

Bug description:
  [impact]

  gzip/libgzip fails for systemd services using
  MemoryDenyWriteExecute=yes

  [test case]

  note this only fails on ppc64el

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

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

  run systemctl daemon-reload, and start the service:

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

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

  [regression potential]

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

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

  [scope]

  this is needed only in b

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

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


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

[Touch-packages] [Bug 1950794] [NEW] DHCPv4 (IAID+DUID) networking broken in LXC containers

Public bug reported:

DHCPv4 networking does not work in the default IAID+DUID
(ClientIdentifier=duid) mode in LXC containers, using systemd-networkd
v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem.

Reproducer:
$ lxc launch ubuntu-daily:jammy jj
$ lxc exec jj bash
# add-apt-repository ppa:ci-train-ppa-service/4704
# apt install systemd # install systemd 249.5-2ubuntu1
# cat /etc/systemd/network/00-test.network
[Match]
Name=eth0

[Network]
DHCP=ipv4
# systemctl restart systemd-networkd.service
# networkctl 
IDX LINK TYPE OPERATIONAL SETUP
[...]
611 eth0 ethercarrier failed  

A workaround is to avoid IAID+DUID mode via:
[DHCPv4]
#ClientIdentifier=mac
ClientIdentifier=duid-only

Interesting logs:
Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link
Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set 
IAID: Device or resource busy
Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set 
IAID+DUID: Device or resource busy
Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is initialized: 
Device or resource busy
Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed

** Affects: lxd (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "debug.log"
   https://bugs.launchpad.net/bugs/1950794/+attachment/5540425/+files/debug.log

** Summary changed:

- DHCPv4 networking broken in LXC containers (IAID+DUID / ClientIdentifier=duid)
+ DHCPv4 (IAID+DUID) networking broken in LXC containers

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

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

Title:
  DHCPv4 (IAID+DUID) networking broken in LXC containers

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  DHCPv4 networking does not work in the default IAID+DUID
  (ClientIdentifier=duid) mode in LXC containers, using systemd-networkd
  v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem.

  Reproducer:
  $ lxc launch ubuntu-daily:jammy jj
  $ lxc exec jj bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # cat /etc/systemd/network/00-test.network
  [Match]
  Name=eth0

  [Network]
  DHCP=ipv4
  # systemctl restart systemd-networkd.service
  # networkctl 
  IDX LINK TYPE OPERATIONAL SETUP
  [...]
  611 eth0 ethercarrier failed  

  A workaround is to avoid IAID+DUID mode via:
  [DHCPv4]
  #ClientIdentifier=mac
  ClientIdentifier=duid-only

  Interesting logs:
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set 
IAID: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set 
IAID+DUID: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is 
initialized: Device or resource busy
  Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+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 1950787] [NEW] systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

Public bug reported:

systemd-sysusers.service/systemd.exec fails to start in privileged containers, 
due to being unable to properly mount /dev for passing credentials, caused by 
the following config in the .service unit:
```
# Optionally, pick up a root password and shell for the root user from a
# credential passed to the service manager. This is useful for importing this
# data from nspawn's --set-credential= switch.
LoadCredential=passwd.hashed-password.root
LoadCredential=passwd.plaintext-password.root
LoadCredential=passwd.shell.root
```

Reproducer:
$ lxc profile set default security.privileged "true"
$ lxc launch ubuntu-daily:jammy test
$ lxc exec test bash
# add-apt-repository ppa:ci-train-ppa-service/4704
# apt install systemd # install systemd 249.5-2ubuntu1
# systemctl restart systemd-sysusers
# systemctl status systemd-sysusers
# system --status=failed
$ lxc profile set default security.privileged "false"

A workaround is to disable it via:
$ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
[Service]
LoadCredential=

Interesting logs:
Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to 
fd store.
Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

** Affects: lxd (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

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

** Description changed:

  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  
  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"
  
  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=
  
  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning
- 
- Debug logs:
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Job 350 
systemd-sysusers.service/restart finished, result=done
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Converting job 
systemd-sysusers.service/restart -> systemd-sysusers.service/start
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: 
ConditionNeedsUpdate=/etc succeeded.
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Passing 0 fds to 
service
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: About to execute 
systemd-sysusers
- Nov 12 12:09:44 test systemd[1]: systemd-sysusers.service: Forked 
systemd-sysusers as 430
- Nov 12 12:09:44 test systemd[430]: Successfully forked off '(sd-mkdcreds)' as 
PID 431.
- Nov 12 12:09:44 test systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/systemd_2dsysusers_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
- Nov 12 12:09:44 test systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/systemd_2dsysusers_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
- Nov 12 12:09:44 test

[Touch-packages] [Bug 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

This commit seems to be related:
https://github.com/lxc/distrobuilder/commit/33a4302ca5a62ed9eb9009dcc5059aecfb55ba41
But why does it not work in privileged containers?

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Stéphane Graber

Privileged containers have a much stricter apparmor policy applied than 
unprivileged containers.
That's because unprivileged containers primarily rely on the user namespace to 
prevent breakout and taking over of the host whereas privileged containers rely 
entirely on apparmor.

As apparmor isn't particularly good at dealing with mounts, especially
with mount namespaces, there is no safe way for us to allow this
operation in privileged containers.

As you point out above, we've recently started using a systemd generator
to dynamically generate unit overrides based on the environment, letting
us disable specific features that interfere with container security.


This is used in all of the community images, so in this case you could try it 
by using "images:ubuntu/jammy" instead of "ubuntu-daily:jammy". We've been 
considering getting the generator into the lxd-agent-loader package which is 
included in all Ubuntu images though so far we've found it to be too volatile 
for that (we were updating it up to twice a week for a while...).

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Stéphane Graber

If this only fails in privileged containers, then I probably wouldn't
worry about it too much, those aren't the default and a LOT of things
break in privileged containers, so I don't think it's worth doing distro
changes to accommodate this, assuming the container otherwise still
boots.

For cases like this one, it's usually been hard to make a solid case for
a change of behavior in upstream systemd. There are a few places like
the devices cgroup where permission errors are considered non-fatal
which then accommodates containers quite well, but the same isn't true
with the isolation security features which this one ties into.

In an ideal world, AppArmor would allow us to craft a policy which:
 - Allows for mount namespaces
 - Allows for bind-mounts of restricted paths
 - Applies the parent's policy onto the bind-mount target
 - Properly support mount propagation flags in a way that can't be abuse to 
allow all mounts

But as it stands, AppArmor is entirely path based, so a policy that
applies to /proc will not apply to /proc bind-mount to /blah/proc (which
is effectively what systemd does) and so causes all confinement to be
bypassable. Additionally, there are (or were in some versions at least)
issues with processing those mount propagation flags you see in your log
(shared/slave/...) and allowing a bind-mount to be marked using one of
those flags would incorrectly cause the parser or the kernel (not quite
sure which) to allow ALL mounts...

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

2021-11-12 Thread Stéphane Graber

Closing the LXD task as there's not really anything we can do there.

The options here are pretty much:
 - Do nothing, if it's just privileged containers, it's usually not a big deal
 - Significantly rework apparmor mount handling logic and policies so this can 
be safely allowed
 - Ship unit overrides, either though lxd-agent-loader, through a systemd patch 
or a similar distro mechanism

Closing the LXD task as there currently isn't any change we can make to
our policies to safely allow this.

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

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)

** Attachment added: "debug.log"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950787/+attachment/5540415/+files/debug.log

** Description changed:

  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
+ ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
+ ```
  
  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"
  
  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=
  
  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

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

Title:
  systemd-sysusers cannot mount /dev in privileged containers (to pass
  credentials)

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-sysusers.service/systemd.exec fails to start in privileged 
containers, due to being unable to properly mount /dev for passing credentials, 
caused by the following config in the .service unit:
  ```
  # Optionally, pick up a root password and shell for the root user from a
  # credential passed to the service manager. This is useful for importing this
  # data from nspawn's --set-credential= switch.
  LoadCredential=passwd.hashed-password.root
  LoadCredential=passwd.plaintext-password.root
  LoadCredential=passwd.shell.root
  ```

  Reproducer:
  $ lxc profile set default security.privileged "true"
  $ lxc launch ubuntu-daily:jammy test
  $ lxc exec test bash
  # add-apt-repository ppa:ci-train-ppa-service/4704
  # apt install systemd # install systemd 249.5-2ubuntu1
  # systemctl restart systemd-sysusers
  # systemctl status systemd-sysusers
  # system --status=failed
  $ lxc profile set default security.privileged "false"

  A workaround is to disable it via:
  $ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
  [Service]
  LoadCredential=

  Interesting logs:
  Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) 
to fd store.
  Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
  Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev 
(MS_REC|MS_SLAVE ""): Permission denied
  Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up 
credentials: Protocol error
  Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step 
CREDENTIALS spawning

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

In addition to the changelog versions it seems to me that the debdiff is
potentially a bit missleading:

1) the shell testcases are not executed neither during build, nor during
autopkgtest. As they seem to need root, it would be nice to add
autopkgtest that would do:

cd iptables/tests/shell; ./run-tests.sh --host

as root.

2) the patched in new test case is patched as a regular text file, and
thus is not picked up by ./run-tests.sh harness, because executable bit
is lost. Hence debian/rules should probably `chmod +x` in the clean
target. And then autopkgtest either needs to have restriction requires
build; or also chmod that new test case before running ./run-tests.sh
--host.

Given this new test case is supposed to catch this regression, enabling
this test suite in autopkgtest would be worth while for jammy.

Can you attempt to fix above things?

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

Title:
  iptables-save -c shows incorrect counters with iptables-nft

Status in iptables package in Ubuntu:
  New
Status in iptables source package in Impish:
  New
Status in iptables source package in Jammy:
  New

Bug description:
  [Impact]

  Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
  is always failing. Initially I thought it was a kernel issue, but
  debugging further I found that the reason is that with Impish we're
  using iptables-nft by default instead of iptables-legacy.

  This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
  source directory) is creating a bunch of network namespaces and
  checking the iptables counters for the defined policies, in particular
  this is the interesting part:

  check_ipt_policy_count()
  {
  ns=$1

  ip netns exec $ns iptables-save -c |grep policy | ( read c rest
  ip netns exec $ns iptables -Z
  if [ x"$c" = x'[0:0]' ]; then
  exit 0
  elif [ x"$c" = x ]; then
  echo "ERROR: No counters"
  ret=1
  exit 111
  else
  exit 1
  fi
  )
  }

  If I use iptables-nft the counters are never [0:0] as they should be,
  so the test is failing. With iptables-legacy they are [0:0] and the
  test is passing.

  [Test case]

  tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
  source code.

  [Fix]

  Apply iptables upstream commit:

  5f1fcace ("iptables-nft: fix -Z option")

  In this way also with iptables-nft the counters are reported
  correctly.

  [Regression potential]

  We may require other upstream commits now that the -Z option is
  working properly with iptables-nft.

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


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

[Touch-packages] [Bug 1940656] Re: Potential use after free bugs in 1.1.1

I currently do not have a more regular smartcard setup to test out a
hardware pk11 engine with openssl, which is typically the most common
one. But I can use software gost engine to test out that algos provided
by the engine operate correctly.

Installed openssl from proposed, and gost engine.

$ dpkg -l | grep -e 1.1.1f -e openssl

ii  libengine-gost-openssl1.1  1.1.0.3-1amd64
Loadable module for openssl implementing GOST algorithms
ii  libssl1.1:amd641.1.1f-1ubuntu2.9amd64Secure 
Sockets Layer toolkit - shared libraries
ii  openssl1.1.1f-1ubuntu2.9amd64Secure 
Sockets Layer toolkit - cryptographic utility

Without engine configured, connectivity fails to GOST only website:

# openssl s_client -connect tlsgost.cryptopro.ru:443
CONNECTED(0003)
140163445085504:error:1425F102:SSL 
routines:ssl_choose_client_version:unsupported 
protocol:../ssl/statem/statem_lib.c:1941:


Configured gost engine, and connect to GOST only website:

# openssl s_client -connect tlsgost.cryptopro.ru:443 
CONNECTED(0003)
depth=0 CN = id-GostR3410-2001-CryptoPro-XchA-ParamSet_256noauth
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = id-GostR3410-2001-CryptoPro-XchA-ParamSet_256noauth
verify error:num=21:unable to verify the first certificate
verify return:1
...
New, TLSv1.0, Cipher is GOST2012-GOST8912-GOST8912
Server public key is 256 bit
...
GET /
...
 TLS connection with id-GostR3410-2001-CryptoPro-XchA-ParamSet no auth 
requred.


Connectivity using algos provided by a crypto engine worked.

Note that certificate was not verified, as we don't currently ship GOST
CA certificates.

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

Title:
  Potential use after free bugs in 1.1.1

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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

[Touch-packages] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

Arguably it should run before apt-daily-upgrade too. apt-daily-upgrade
is the one locking dpkg; apt-daily locks apt lists (and cache)
directory.

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

Title:
  cloud-init sometimes fails on dpkg lock due to concurrent apt-
  daily.service execution

Status in APT:
  Fix Released
Status in cloud-init:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  A cloud-config that contains packages to install (see below) or
  'package_upgrade' will run 'apt-get update'.  That can sometimes fail as a
  result of contention with the apt-daily.service that updates that information.

  Cloud-config showing the problem is just like:

    $ cat my.yaml
    #cloud-config
    packages: ['hello']

  [Test Case]
  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  a.) launch an instance with proposed version of cloud-init and some user-data.
     This is platform independent.  The test case demonstrates lxd.
     $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \
     "package_upgrade: true" > config.yaml
     $ release=xenial
     $ ref=proposed-$release
     $ ./lxc-proposed-snapshot --proposed --publish $release $ref;

  b.) start the instance
     $ name=$release-1693361
     $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml)
     $ sleep 1
     $ lxc exec $name -- tail -f /var/log/cloud-init.log 
/var/log/cloud-init-output.log
     # watch this boot.

   c.) Look for evidence of systemd failure
     journalctl -o short-precise | grep -i break
     journalctl -o short-precise | grep -i order

  [Regression Potential]
  Regression chance here is low.  Its possible that ordering loops
  could occur.  When that does happen, journalctl will mention it.  
Unfortunately
  in such cases systemd somewhat randomly picks a service to kil so behavior
  is somewhat undefined.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=11121fe4

  === End SRU Template ===

  apt-daily is now a systemd service rather than being invoked by
  cron.daily.  If one builds a custom AMI it is possible that the apt-
  daily.timer will fire during boot.  This can fire at the same time
  cloud-init is running and if cloud-init loses the race the invocation
  of apt (e.g. use of "packages:" in the config) will fail.

  There is a lot of discussion online about this change to apt-daily
  (e.g. unattended upgrades happening during business hours, delaying
  boot, etc.) and discussion of potential systemd changes regarding
  timers firing during boot (c.f.
  https://github.com/systemd/systemd/issues/5659).

  While it would be better to solve this in apt itself, I suggest that
  cloud-init be defensive when calling apt and implement some retry
  mechanism.

  Various instances of people running into this issue:

  https://github.com/chef/bento/issues/609
  https://clusterhq.atlassian.net/browse/FLOC-4486
  https://github.com/boxcutter/ubuntu/issues/73
  
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/apt/+bug/1693361/+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 1946096] Re: Support manual firmware upgrading for Foxconn and Quectel modems.

2021-11-12 Thread Jerry Lee

[Where problems could occur] is updated

** Description changed:

[Impact]

The modem certification requires that different modem firmware is used for
different network carrier.
This needs the firmware upgrading capability during the modem certification
process.

The modem manufacture vendors (Foxconn and Quectel) provided utilities to do
modem's firmware upgrading manually.(LP#1943774, LP#1943780)
These utilities are verified to be working when the recent versions(> v
1.18.2) of ModemManager are used with.

To support manual firmware upgrading on the current Focal release which is
using ModemManager v 1.16.6, we need to apply some patches from v 1.18.2.
The requested upstream patches are listed as below:
* for Quectel EM160 4G
**
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/83ac82470589a3672092a0ba0be855093b1cf5e2
* for Foxconn T99W175
**
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/21ae558fe3600c84b3ca7dcd9bf50a3ba576c7c9
**https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/76e700f4fd703f952208993330ab098305c13d6b
**
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/52bf2c641171ded9e617022f40497c8984520371
**
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/33e2b023ef01bea9da37ae2beb192f7d92bce47a
**
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/f72046701659073fbfa97516e155865647acb154

The firmware upgrading was verified using the patched ModemManager v 1.16.6
with the following 2 modems:
* Foxconn SDX55 T99W175 5G sub6 PCIE Modem
* Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem

[Test Plan]

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

[Where problems could occur]

The requested update has 2 parts:

1. Informative
-1.1 Provide more information about modems whose drivers use WWAN subsystem
in kernel 5.13
-1.2 Modem manufacture's private utilities can use this information to do
modem's FW upgrading manually
+ 1.1 Provide more information about modems whose drivers use WWAN subsystem
in kernel 5.13
+ 1.2 Modem manufacture's private utilities can use this information to do
modem's FW upgrading manually

2. Changes are specific to Foxconn and Quectel modems
-2.1 Modified code are only used by Foxconn and Quectel modems during their
FW upgrading. (matched by vendor_id and product_id)
+ 2.1 Modified code are only used by Foxconn and Quectel modems during their
FW upgrading. (matched by vendor_id and product_id)

In current Ubuntu's certification records for modem:
* No other modem uses WWAN subsystem in kernel 5.13
* Modem's FW update is not supported via ModemManager ( < v1.18 )

There is no certificated modems can do the firmware upgrading flow for the
regression test.
This update should not affect existing modems.

+ The problem would be limited to these two mentioned modems.
+ Each carrier mapping .conf file is for a specific modem.
+ ModemManager will load one of the carrier mapping conf files via the modem
manufacturer’s plugin ( if the PCIe VID & PID is matched by the plugin.)
+ We cannot verify if the carrier mapping is correct. This relies on the
manufacturer to provide the correct mapping.
+
+ The carrier mapping .conf files is verified by modem’s manufacture according
to the tested SIM card published by different countries.
+ Modem manufacturer confirmed that the content in the .conf file is absolutely
correct.
+
+
[Other Info]

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

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

Title:
Support manual firmware upgrading for Foxconn and Quectel modems.

Status in OEM Priority Project:
In Progress
Status in modemmanager package in Ubuntu:
New

Bug description:
[Impact]

The modem certification requires that different modem firmware is used for
different network carrier.
This needs the firmware upgrading capability during the modem certification
process.

To support manual firmware upgrading on the current Focal release which is
using

[Touch-packages] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

2021-11-12 Thread David Reis

This is not fixed, it just affected me on Ubuntu 20.04.3 LTS, resulting
in the the subsequent server configuration failing completely because
awscli and jq were missing.

Output:

Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:config' at 
Fri, 12 Nov 2021 11:05:29 +. Up 18.13 seconds.
Get:1 http://eu-central-1.ec2.archive.ubuntu.com/ubuntu focal InRelease [265 kB]
[... more Gets]
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2764 
(unattended-upgr)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is 
another process using it?
Cloud-init v. 21.3-1-g6803368d-0ubuntu1~20.04.4 running 'modules:final' at Fri, 
12 Nov 2021 11:05:30 +. Up 19.15 seconds.
2021-11-12 11:05:38,955 - util.py[WARNING]: Package upgrade failed
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2764 
(unattended-upgr)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is 
another process using it?
2021-11-12 11:05:38,999 - util.py[WARNING]: Failed to install packages: 
['awscli', 'nmap', 'tcpdump', 'bind9utils', 'curl', 'wget', 'vim', 'jq', 
'htop', 'tmux', 'git', 'iotop', 'iftop', 'fail2ban']
2021-11-12 11:05:38,999 - cc_package_update_upgrade_install.py[WARNING]: 2 
failed with exceptions, re-raising the last one
2021-11-12 11:05:39,000 - util.py[WARNING]: Running module 
package-update-upgrade-install ()
 failed

Note: Before=apt-daily.service is only set on cloud-final.service.

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

Title:
  cloud-init sometimes fails on dpkg lock due to concurrent apt-
  daily.service execution

Status in APT:
  Fix Released
Status in cloud-init:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  A cloud-config that contains packages to install (see below) or
  'package_upgrade' will run 'apt-get update'.  That can sometimes fail as a
  result of contention with the apt-daily.service that updates that information.

  Cloud-config showing the problem is just like:

    $ cat my.yaml
    #cloud-config
    packages: ['hello']

  [Test Case]
  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  a.) launch an instance with proposed version of cloud-init and some user-data.
     This is platform independent.  The test case demonstrates lxd.
     $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \
     "package_upgrade: true" > config.yaml
     $ release=xenial
     $ ref=proposed-$release
     $ ./lxc-proposed-snapshot --proposed --publish $release $ref;

  b.) start the instance
     $ name=$release-1693361
     $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml)
     $ sleep 1
     $ lxc exec $name -- tail -f /var/log/cloud-init.log 
/var/log/cloud-init-output.log
     # watch this boot.

   c.) Look for evidence of systemd failure
     journalctl -o short-precise | grep -i break
     journalctl -o short-precise | grep -i order

  [Regression Potential]
  Regression chance here is low.  Its possible that ordering loops
  could occur.  When that does happen, journalctl will mention it.  
Unfortunately
  in such cases systemd somewhat randomly picks a service to kil so behavior
  is somewhat undefined.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=11121fe4

  === End SRU Template ===

  apt-daily is now a systemd service rather than being invoked by
  cron.daily.  If one builds a custom AMI it is possible that the apt-
  daily.timer will fire during boot.  This can fire at the same time
  cloud-init is running and if cloud-init loses the race the invocation
  of apt (e.g. use of "packages:" in the config) will fail.

  There is a lot of discussion online about this change to apt-daily
  (e.g. unattended upgrades happening during business hours, delaying
  boot, etc.) and discussion of potential systemd changes regarding
  timers firing during boot (c.f.
  https://github.com/systemd/systemd/issues/5659).

  While it would be better to solve this in apt itself, I suggest that
  cloud-init be defensive when calling apt and implement some retry
  mechanism.

  Various instances of people running into this issue:

  https://github.com/chef/bento/issues/609
  https://clusterhq.atlassian.net/browse/FLOC-4486
  https://github.com/boxcutter/ubuntu/issues/73

[Touch-packages] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

2021-11-12 Thread David Reis

Ah, thanks, I wasn't aware they're distinct. So would simply adding apt-
daily-upgrade.service to the Before via cloud-init's bootcmd and then
issuing a daemon-reload be a suitable workaround? There's a 30s window
until the upgrade process starts if apt's history.log is to be trusted.
That is probably enough to be somewhat reliable.

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

Title:
  cloud-init sometimes fails on dpkg lock due to concurrent apt-
  daily.service execution

Status in APT:
  Fix Released
Status in cloud-init:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  A cloud-config that contains packages to install (see below) or
  'package_upgrade' will run 'apt-get update'.  That can sometimes fail as a
  result of contention with the apt-daily.service that updates that information.

  Cloud-config showing the problem is just like:

    $ cat my.yaml
    #cloud-config
    packages: ['hello']

  [Test Case]
  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  a.) launch an instance with proposed version of cloud-init and some user-data.
     This is platform independent.  The test case demonstrates lxd.
     $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \
     "package_upgrade: true" > config.yaml
     $ release=xenial
     $ ref=proposed-$release
     $ ./lxc-proposed-snapshot --proposed --publish $release $ref;

  b.) start the instance
     $ name=$release-1693361
     $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml)
     $ sleep 1
     $ lxc exec $name -- tail -f /var/log/cloud-init.log 
/var/log/cloud-init-output.log
     # watch this boot.

   c.) Look for evidence of systemd failure
     journalctl -o short-precise | grep -i break
     journalctl -o short-precise | grep -i order

  [Regression Potential]
  Regression chance here is low.  Its possible that ordering loops
  could occur.  When that does happen, journalctl will mention it.  
Unfortunately
  in such cases systemd somewhat randomly picks a service to kil so behavior
  is somewhat undefined.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=11121fe4

  === End SRU Template ===

  apt-daily is now a systemd service rather than being invoked by
  cron.daily.  If one builds a custom AMI it is possible that the apt-
  daily.timer will fire during boot.  This can fire at the same time
  cloud-init is running and if cloud-init loses the race the invocation
  of apt (e.g. use of "packages:" in the config) will fail.

  There is a lot of discussion online about this change to apt-daily
  (e.g. unattended upgrades happening during business hours, delaying
  boot, etc.) and discussion of potential systemd changes regarding
  timers firing during boot (c.f.
  https://github.com/systemd/systemd/issues/5659).

  While it would be better to solve this in apt itself, I suggest that
  cloud-init be defensive when calling apt and implement some retry
  mechanism.

  Various instances of people running into this issue:

  https://github.com/chef/bento/issues/609
  https://clusterhq.atlassian.net/browse/FLOC-4486
  https://github.com/boxcutter/ubuntu/issues/73
  
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/apt/+bug/1693361/+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 1921518] Re: OpenSSL "double free" error

Further analysis of why config files are being loaded twice shows that
these are bugs in curl and wget, both call CONF_modules_load_file
directly during their initialization functions, while it is also being
called from OPENSSL_init_crypto and similar top-level functions:

For wget:

(gdb) bt
#0  CONF_modules_load_file (filename=filename@entry=0x0, 
appname=appname@entry=0x0, flags=flags@entry=50) at 
../crypto/conf/conf_mod.c:114
#1  0x77c7da10 in openssl_config_int (settings=) at 
../crypto/conf/conf_sap.c:69
#2  0x77d14234 in ossl_init_config () at ../crypto/init.c:293
#3  ossl_init_config_ossl_ () at ../crypto/init.c:291
#4  0x7796947f in __pthread_once_slow (once_control=0x77e717e0 
, init_routine=0x77d14220 ) at 
pthread_once.c:116
#5  0x77969535 in __GI___pthread_once 
(once_control=once_control@entry=0x77e717e0 , 
init_routine=init_routine@entry=0x77d14220 ) at 
pthread_once.c:143
#6  0x77d7f74d in CRYPTO_THREAD_run_once 
(once=once@entry=0x77e717e0 , init=init@entry=0x77d14220 
) at ../crypto/threads_pthread.c:118
#7  0x77d148b8 in OPENSSL_init_crypto (settings=0x7fffdc50, 
opts=64) at ../crypto/init.c:701
#8  OPENSSL_init_crypto (opts=opts@entry=64, 
settings=settings@entry=0x7fffdc50) at ../crypto/init.c:620
#9  0x77c7d9ae in OPENSSL_config (appname=appname@entry=0x0) at 
../crypto/conf/conf_sap.c:39
#10 0x55598237 in ssl_init () at ../../src/openssl.c:178
#11 0x5557cbc5 in gethttp (u=u@entry=0x555e63e0, 
original_url=original_url@entry=0x555e63e0, hs=hs@entry=0x7fffe110, 
dt=dt@entry=0x7fffe4f0, proxy=proxy@entry=0x0, 
iri=iri@entry=0x555e63b0, count=1) at ../../src/http.c:3209
#12 0x555808f3 in http_loop (u=u@entry=0x555e63e0, 
original_url=original_url@entry=0x555e63e0, 
newloc=newloc@entry=0x7fffe408, local_file=local_file@entry=0x7fffe410, 
referer=referer@entry=0x0, dt=dt@entry=0x7fffe4f0, proxy=0x0, 
iri=0x555e63b0)
at ../../src/http.c:4356
#13 0x5558c594 in retrieve_url (orig_parsed=0x555e63e0, 
origurl=0x555e7600 "https://google.de/;, file=0x7fffe4f8, 
newloc=0x7fffe500, refurl=0x0, dt=0x7fffe4f0, recursive=false, 
iri=0x555e63b0, register_status=true) at ../../src/retr.c:973
#14 0x555644bb in main (argc=, argv=) at 
../../src/main.c:2165
(gdb) c
Continuing.

Breakpoint 1, CONF_modules_load_file (filename=filename@entry=0x0, 
appname=appname@entry=0x0, flags=flags@entry=48) at 
../crypto/conf/conf_mod.c:114
114 in ../crypto/conf/conf_mod.c
(gdb) bt
#0  CONF_modules_load_file (filename=filename@entry=0x0, 
appname=appname@entry=0x0, flags=flags@entry=48) at 
../crypto/conf/conf_mod.c:114
#1  0x555982c0 in ssl_init () at ../../src/openssl.c:202
#2  0x5557cbc5 in gethttp (u=u@entry=0x555e63e0, 
original_url=original_url@entry=0x555e63e0, hs=hs@entry=0x7fffe110, 
dt=dt@entry=0x7fffe4f0, proxy=proxy@entry=0x0, 
iri=iri@entry=0x555e63b0, count=1) at ../../src/http.c:3209
#3  0x555808f3 in http_loop (u=u@entry=0x555e63e0, 
original_url=original_url@entry=0x555e63e0, 
newloc=newloc@entry=0x7fffe408, local_file=local_file@entry=0x7fffe410, 
referer=referer@entry=0x0, dt=dt@entry=0x7fffe4f0, proxy=0x0, 
iri=0x555e63b0)
at ../../src/http.c:4356
#4  0x5558c594 in retrieve_url (orig_parsed=0x555e63e0, 
origurl=0x555e7600 "https://google.de/;, file=0x7fffe4f8, 
newloc=0x7fffe500, refurl=0x0, dt=0x7fffe4f0, recursive=false, 
iri=0x555e63b0, register_status=true) at ../../src/retr.c:973
#5  0x555644bb in main (argc=, argv=) at 
../../src/main.c:2165

For curl:

Breakpoint 1, CONF_modules_load_file (filename=filename@entry=0x0, 
appname=appname@entry=0x0, flags=flags@entry=48) at 
../crypto/conf/conf_mod.c:114
114 ../crypto/conf/conf_mod.c: No such file or directory.
(gdb) bt
#0  CONF_modules_load_file (filename=filename@entry=0x0, 
appname=appname@entry=0x0, flags=flags@entry=48) at 
../crypto/conf/conf_mod.c:114
#1  0x77f95313 in Curl_ossl_init () at vtls/openssl.c:1052
#2  0x77f5fa20 in global_init (flags=3, memoryfuncs=) at 
easy.c:158
#3  0xf0af in main_init (config=0x7fffe540) at tool_main.c:158
#4  main (argc=4, argv=0x7fffe6d8) at tool_main.c:296
(gdb) c
Continuing.
[New Thread 0x766f4700 (LWP 2866)]
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0[Thread 0x766f4700 (LWP 2866) exited]

Thread 1 "curl" hit Breakpoint 1, CONF_modules_load_file 
(filename=filename@entry=0x0, appname=appname@entry=0x0, flags=flags@entry=50) 
at ../crypto/conf/conf_mod.c:114
114 in ../crypto/conf/conf_mod.c
(gdb) bt
#0  CONF_modules_load_file

[Touch-packages] [Bug 1921518] Re: OpenSSL "double free" error

In wget, this was fixed upstream in

commit 14e3712b8c39165219fa227bd11f6feae7b09a33
Author: Eneas U de Queiroz 
Date:   Mon Apr 22 11:03:25 2019 -0300

* src/openssl.c: fix ssl_init for openssl 1.1.1

ssl_init fails with openssl 1.1.1 when openssl.cnf is not found.
Redundant calls to intialization functions were removed as
OPENSSL_config takes care of them for openssl versions < 1.1.0.
For versions > 1.1.0, OPENSSL_init_ssl is preferred.

Signed-off-by: Eneas U de Queiroz 
Copyright-paperwork-exempt: Yes

diff --git a/src/openssl.c b/src/openssl.c
index a1502173..03737d7a 100644
--- a/src/openssl.c
+++ b/src/openssl.c
@@ -174,7 +174,9 @@ ssl_init (void)
 #if OPENSSL_VERSION_NUMBER >= 0x00907000
   if (ssl_true_initialized == 0)
 {
-#if OPENSSL_API_COMPAT < 0x1010L
+#if !defined(LIBRESSL_VERSION_NUMBER) && (OPENSSL_VERSION_NUMBER >= 
0x1010L)
+  OPENSSL_init_ssl (OPENSSL_INIT_LOAD_CONFIG | 
OPENSSL_INIT_ENGINE_ALL_BUILTIN, NULL);
+#else
   OPENSSL_config (NULL);
 #endif
   ssl_true_initialized = 1;
@@ -194,21 +196,9 @@ ssl_init (void)
   goto error;
 }
 
-#if OPENSSL_VERSION_NUMBER >= 0x00907000
-  OPENSSL_load_builtin_modules();
-#ifndef OPENSSL_NO_ENGINE
-  ENGINE_load_builtin_engines();
-#endif
-  CONF_modules_load_file(NULL, NULL,
-  CONF_MFLAGS_DEFAULT_SECTION|CONF_MFLAGS_IGNORE_MISSING_FILE);
-#endif
-#if OPENSSL_API_COMPAT >= 0x1010L
-  OPENSSL_init_ssl(0, NULL);
-#else
+#if defined(LIBRESSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x1010L)
   SSL_library_init ();
   SSL_load_error_strings ();
-#endif
-#if OPENSSL_VERSION_NUMBER < 0x1010L
   SSLeay_add_all_algorithms ();
   SSLeay_add_ssl_algorithms ();
 #endif

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

Title:
  OpenSSL "double free" error

Status in curl package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Incomplete
Status in wget package in Ubuntu:
  Fix Released
Status in curl source package in Focal:
  Triaged
Status in openssl source package in Focal:
  Incomplete
Status in wget source package in Focal:
  Triaged

Bug description:
  "double free" error is seen when using curl utility. Error is from
  libcrypto.so which is part of the OpenSSL package. This happens only
  when OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  
  OpenSSL can be configured to use a dynamic engine by editing the default 
openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu 
systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids
   
  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

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


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

[Touch-packages] [Bug 1940656] Re: Potential use after free bugs in 1.1.1

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

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

Title:
  Potential use after free bugs in 1.1.1

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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

[Touch-packages] [Bug 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

2021-11-12 Thread Andrea Righi

@xnox interestingly enough 2 tests are failing with nft and 1 test in
legacy running `./run-tests.sh --host`:

W: [FAILED]  ././testcases/ipt-restore/0004-restore-race_0: expected 0 but 
got 1
...
I: legacy results: [OK] 49 [FAILED] 1 [TOTAL] 50

W: [FAILED]  ././testcases/ipt-restore/0004-restore-race_0: expected 0 but 
got 1
W: [FAILED]  ././testcases/nft-only/0009-needless-bitwise_0: expected 0 but 
got 127
...
I: nft results: [OK] 48 [FAILED] 2 [TOTAL] 50

So it's definitely worth running this one, now it'd be nice to
understand the failures. Looking...

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

Title:
  iptables-save -c shows incorrect counters with iptables-nft

Status in iptables package in Ubuntu:
  New
Status in iptables source package in Impish:
  New
Status in iptables source package in Jammy:
  New

Bug description:
  [Impact]

  Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
  is always failing. Initially I thought it was a kernel issue, but
  debugging further I found that the reason is that with Impish we're
  using iptables-nft by default instead of iptables-legacy.

  This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
  source directory) is creating a bunch of network namespaces and
  checking the iptables counters for the defined policies, in particular
  this is the interesting part:

  check_ipt_policy_count()
  {
  ns=$1

  ip netns exec $ns iptables-save -c |grep policy | ( read c rest
  ip netns exec $ns iptables -Z
  if [ x"$c" = x'[0:0]' ]; then
  exit 0
  elif [ x"$c" = x ]; then
  echo "ERROR: No counters"
  ret=1
  exit 111
  else
  exit 1
  fi
  )
  }

  If I use iptables-nft the counters are never [0:0] as they should be,
  so the test is failing. With iptables-legacy they are [0:0] and the
  test is passing.

  [Test case]

  tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
  source code.

  [Fix]

  Apply iptables upstream commit:

  5f1fcace ("iptables-nft: fix -Z option")

  In this way also with iptables-nft the counters are reported
  correctly.

  [Regression potential]

  We may require other upstream commits now that the -Z option is
  working properly with iptables-nft.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1949603/+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 1950806] [NEW] package ufw 0.36-6ubuntu1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 1

2021-11-12 Thread Kay-Uwe Höpcke

Public bug reported:

No details

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: ufw 0.36-6ubuntu1
ProcVersionSignature: Ubuntu 5.8.0-55.62~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-55-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
Date: Fri Nov 12 15:00:27 2021
DuplicateSignature:
 package:ufw:0.36-6ubuntu1
 Setting up ufw (0.36-6ubuntu1) ...
 [Errno 5] Input/output error
 dpkg: error processing package ufw (--configure):
  installed ufw package post-installation script subprocess returned error exit 
status 1
ErrorMessage: installed ufw package post-installation script subprocess 
returned error exit status 1
InstallationDate: Installed on 2021-06-21 (143 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
PackageArchitecture: all
Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
PythonDetails: N/A
RelatedPackageVersions:
 dpkg 1.19.7ubuntu3
 apt  2.0.6
SourcePackage: ufw
Title: package ufw 0.36-6ubuntu1 failed to install/upgrade: installed ufw 
package post-installation script subprocess returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ufw (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package focal need-duplicate-check

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

Title:
  package ufw 0.36-6ubuntu1 failed to install/upgrade: installed ufw
  package post-installation script subprocess returned error exit status
  1

Status in ufw package in Ubuntu:
  New

Bug description:
  No details

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: ufw 0.36-6ubuntu1
  ProcVersionSignature: Ubuntu 5.8.0-55.62~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-55-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Nov 12 15:00:27 2021
  DuplicateSignature:
   package:ufw:0.36-6ubuntu1
   Setting up ufw (0.36-6ubuntu1) ...
   [Errno 5] Input/output error
   dpkg: error processing package ufw (--configure):
installed ufw package post-installation script subprocess returned error 
exit status 1
  ErrorMessage: installed ufw package post-installation script subprocess 
returned error exit status 1
  InstallationDate: Installed on 2021-06-21 (143 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.6
  SourcePackage: ufw
  Title: package ufw 0.36-6ubuntu1 failed to install/upgrade: installed ufw 
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/ufw/+bug/1950806/+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 1921518] Re: OpenSSL "double free" error

I have uploaded a fixed wget for focal, verified that it only loads the
config file once.

** Description changed:

- "double free" error is seen when using curl utility. Error is from
- libcrypto.so which is part of the OpenSSL package. This happens only
- when OpenSSL is configured to use a dynamic engine.
+ [Impact]
+ openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.
+ 
+ [Test plan]
+ Run the command of the package being tested in
+ 
+ gdb  -ex "break CONF_modules_load_file" -ex "run" --args
+ 
+ and make sure it only breaks one.
+ 
+ [Where problems could occur]
+ 
+ wget: This is an upstream change that changes initialization and is in
+ use in later releases. Since it mostly removes an unneeded call to the
+ load file function, a regression could be a config file being ignored,
+ but it seems unlikely given the use in later releases
+ 
+ [Original bug report]
+ "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.
  
  OpenSSL version is 1.1.1f
  
  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.
  
- 
- OpenSSL can be configured to use a dynamic engine by editing the default 
openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu 
systems.
+ OpenSSL can be configured to use a dynamic engine by editing the default
+ openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu
+ systems.
  
  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:
  
  +openssl_conf = conf_section
  +
-  # Extra OBJECT IDENTIFIER info:
-  #oid_file  = $ENV::HOME/.oid
-  oid_section= new_oids
-  
+  # Extra OBJECT IDENTIFIER info:
+  #oid_file  = $ENV::HOME/.oid
+  oid_section= new_oids
+ 
  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +
  
  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.
  
  # curl -O https://tpo.pe/pathogen.vim
  
  double free or corruption (out)
  
  Aborted (core dumped)

** Changed in: wget (Ubuntu Focal)
   Status: Triaged => In Progress

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

Title:
  OpenSSL "double free" error

Status in curl package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Incomplete
Status in wget package in Ubuntu:
  Fix Released
Status in curl source package in Focal:
  Triaged
Status in openssl source package in Focal:
  Incomplete
Status in wget source package in Focal:
  In Progress

Bug description:
  [Impact]
  openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.

  [Test plan]
  Run the command of the package being tested in

  gdb  -ex "break CONF_modules_load_file" -ex "run" --args

  and make sure it only breaks one.

  [Where problems could occur]

  wget: This is an upstream change that changes initialization and is in
  use in later releases. Since it mostly removes an unneeded call to the
  load file function, a regression could be a config file being ignored,
  but it seems unlikely given the use in later releases

  [Original bug report]
  "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  OpenSSL can be configured to use a dynamic engine by editing the
  default openssl config file which is located at '/etc/ssl/openssl.cnf'
  on Ubuntu systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids

  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:

[Touch-packages] [Bug 1940528] Re: curl 7.68 does not init OpenSSL correctly

Reuploaded curl into focal proposed, with series fix & on top of
security upload that has happened since.

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

Title:
  curl 7.68 does not init OpenSSL correctly

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

Bug description:
  [Impact]

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

  [Test Plan]

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

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

   * curl any https website

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

  is good output from fixed curl.

  Whereas:

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

  is bad output from currently broken curl.

  [Where problems could occur]

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

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

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


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

[Touch-packages] [Bug 1921518] Re: OpenSSL "double free" error

There are possibly more applications with broken initialization that
need fixes, we will run a search for CONF_modules_load_file in all
Ubuntu packages to hopefully "catch them all".

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

Title:
  OpenSSL "double free" error

Status in curl package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Incomplete
Status in wget package in Ubuntu:
  Fix Released
Status in curl source package in Focal:
  Triaged
Status in openssl source package in Focal:
  Incomplete
Status in wget source package in Focal:
  In Progress

Bug description:
  [Impact]
  openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.

  [Test plan]
  Run the command of the package being tested in

  gdb  -ex "break CONF_modules_load_file" -ex "run" --args

  and make sure it only breaks one.

  [Where problems could occur]

  wget: This is an upstream change that changes initialization and is in
  use in later releases. Since it mostly removes an unneeded call to the
  load file function, a regression could be a config file being ignored,
  but it seems unlikely given the use in later releases

  [Original bug report]
  "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  OpenSSL can be configured to use a dynamic engine by editing the
  default openssl config file which is located at '/etc/ssl/openssl.cnf'
  on Ubuntu systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids

  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1921518/+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 1921518] Re: OpenSSL "double free" error

The fix for curl is being tracked in bug 1940528

** No longer affects: curl (Ubuntu)

** No longer affects: curl (Ubuntu Focal)

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

Title:
  OpenSSL "double free" error

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

Bug description:
  [Impact]
  openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.

  [Test plan]
  Run the command of the package being tested in

  gdb  -ex "break CONF_modules_load_file" -ex "run" --args

  and make sure it only breaks one.

  [Where problems could occur]

  wget: This is an upstream change that changes initialization and is in
  use in later releases. Since it mostly removes an unneeded call to the
  load file function, a regression could be a config file being ignored,
  but it seems unlikely given the use in later releases

  [Original bug report]
  "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  OpenSSL can be configured to use a dynamic engine by editing the
  default openssl config file which is located at '/etc/ssl/openssl.cnf'
  on Ubuntu systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids

  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1921518] Re: OpenSSL "double free" error

2021-11-12 Thread Steve Langasek

How will you test that the change does not regress any wget behavior?

** Changed in: wget (Ubuntu Focal)
   Status: In Progress => Incomplete

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

Title:
  OpenSSL "double free" error

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

Bug description:
  [Impact]
  openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.

  [Test plan]
  Run the command of the package being tested in

  gdb  -ex "break CONF_modules_load_file" -ex "run" --args

  and make sure it only breaks one.

  [Where problems could occur]

  wget: This is an upstream change that changes initialization and is in
  use in later releases. Since it mostly removes an unneeded call to the
  load file function, a regression could be a config file being ignored,
  but it seems unlikely given the use in later releases

  [Original bug report]
  "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  OpenSSL can be configured to use a dynamic engine by editing the
  default openssl config file which is located at '/etc/ssl/openssl.cnf'
  on Ubuntu systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids

  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1921518] Re: OpenSSL "double free" error

> How will you test that the change does not regress any wget behavior?

In default Ubuntu configuration, either no openssl configuration is provided, 
or it contains no settings that affect wget. This code path changes how/when 
openssl configuration is loaded and used by openssl. One should verify that:
1) wget continues to work without openssl.cnf
2) wget continues to work with stock ubuntu unmodified openssl.cnf
3) wget continue to honor and use custom TLS settings that one may have 
specified in openssl.cnf (for example custom engine)

The above three test scenarios cover the changes or regressions that may
occur from applying the proposed patch.

(ps. similar for the curl SRU as well)

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

Title:
  OpenSSL "double free" error

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

Bug description:
  [Impact]
  openssl config file is being loaded twice, causing engines to be loaded twice 
if specified therein, causing double free errors and other strange behavior.

  [Test plan]
  Run the command of the package being tested in

  gdb  -ex "break CONF_modules_load_file" -ex "run" --args

  and make sure it only breaks one.

  [Where problems could occur]

  wget: This is an upstream change that changes initialization and is in
  use in later releases. Since it mostly removes an unneeded call to the
  load file function, a regression could be a config file being ignored,
  but it seems unlikely given the use in later releases

  [Original bug report]
  "double free" error is seen when using curl utility. Error is from 
libcrypto.so which is part of the OpenSSL package. This happens only when 
OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  OpenSSL can be configured to use a dynamic engine by editing the
  default openssl config file which is located at '/etc/ssl/openssl.cnf'
  on Ubuntu systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids

  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

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


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

[Touch-packages] [Bug 1940528] Re: curl 7.68 does not init OpenSSL correctly

Not only patch was missing, it was partially missing. reuploading again.

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

Title:
  curl 7.68 does not init OpenSSL correctly

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

Bug description:
  [Impact]

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

  [Test Plan]

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

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

   * curl any https website

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

  is good output from fixed curl.

  Whereas:

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

  is bad output from currently broken curl.

  [Where problems could occur]

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

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

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


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

[Touch-packages] [Bug 1950844] [NEW] External mouse and external keyboard is not detected

2021-11-12 Thread Prajjwal Majumder

Public bug reported:

My Hp-255-G8 Notebook pc is not detecting my external mouse and
keyboard. It works well when I switch it on, then after some time, it
does not work (both mouse and keyboard). Then after restarting the PC it
again works well and then again gets disconnected.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.11.0-40.44~20.04.2-generic 5.11.22
Uname: Linux 5.11.0-40-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Nov 13 10:07:12 2021
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c2) (prog-if 
00 [VGA controller])
   Subsystem: Hewlett-Packard Company Picasso [103c:87d1]
InstallationDate: Installed on 2021-11-02 (10 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
MachineType: HP HP 255 G8 Notebook PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-40-generic 
root=UUID=4b338a56-a661-410b-8e21-622b327a1bbe ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/18/2021
dmi.bios.release: 15.25
dmi.bios.vendor: Insyde
dmi.bios.version: F.25
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 87D1
dmi.board.vendor: HP
dmi.board.version: 38.25
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 38.25
dmi.modalias: 
dmi:bvnInsyde:bvrF.25:bd08/18/2021:br15.25:efr38.25:svnHP:pnHP255G8NotebookPC:pvrType1ProductConfigId:sku3K1G7PA#ACJ:rvnHP:rn87D1:rvr38.25:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5336AN HP 200
dmi.product.name: HP 255 G8 Notebook PC
dmi.product.sku: 3K1G7PA#ACJ
dmi.product.version: Type1ProductConfigId
dmi.sys.vendor: HP
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.105-3~20.04.2
version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.3
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

** Affects: xorg (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal ubuntu

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

Title:
  External mouse and external keyboard is not detected

Status in xorg package in Ubuntu:
  New

Bug description:
  My Hp-255-G8 Notebook pc is not detecting my external mouse and
  keyboard. It works well when I switch it on, then after some time, it
  does not work (both mouse and keyboard). Then after restarting the PC
  it again works well and then again gets disconnected.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.11.0-40.44~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Nov 13 10:07:12 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c2) (prog-if 
00 [VGA controller])
 Subsystem: Hewlett-Packard Company Picasso [103c:87d1]
  InstallationDate: Installed on 2021-11-02 (10 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: HP HP 255 G8 Notebook PC
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-40-generic 
root=UUID=4b338a56-a661-410b-8e21-622b327a1bbe ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/18/2021
  dmi.bios.release: 15.25
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.25
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 87D1
  dmi.board.vendor: HP
  dmi.board.version: 38.25
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 38.25
  dmi.modalias: 
dmi:bvnInsyde:bvrF.25:bd08/18/2021:br15.25:efr38.25:svnHP:pnHP255G8NotebookPC:pvrType1ProductConfigId:sku3K1G7PA#ACJ:rvnHP:rn87D1:rvr38.25:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5336AN HP 200

[Touch-packages] [Bug 1921518] Re: OpenSSL "double free" error