[Touch-packages] [Bug 1951943] Re: Engine crashes when loading the configuration more than once

2021-11-23 Thread Dimitri John Ledkov
** Description changed:

  [Impact]
  
-  * Engine crashes when loading the configuration more than once
+  * Engine crashes when loading the configuration more than once
  
-  * Upstream started to avoid loading engines twice by using dynamic ids
+  * Upstream started to avoid loading engines twice by using dynamic ids
  to track the loaded engines correctly
  
-  * OpenSSL 3 merge https://github.com/openssl/openssl/pull/17073 (bugfix
+  * OpenSSL 3 merge https://github.com/openssl/openssl/pull/17073 (bugfix
  & testcase)
  
-  * OpenSSL 1.1.1 backports:
+  * OpenSSL 1.1.1 backports:
  
https://github.com/openssl/openssl/commit/9b06ebb1edfddffea083ba36090af7eb7cad207b
 (bugfix)
- https://github.com/openssl/openssl/pull/17083 (test case)
+ 
https://github.com/openssl/openssl/commit/6d022b04748c2a89b7f032a41965df19c584e0cf
 (test case)
  
  [Test Plan]
  
-  * https://github.com/openssl/openssl/issues/17023 lists multiple ways
+  * https://github.com/openssl/openssl/issues/17023 lists multiple ways
  how one can trigger the issue at hand, but also test case implements
  this issue too by explicitly attempting to load an engine multiple times
  and checking that it is operational.
  
  [Where problems could occur]
  
-  * Separately we have started to fix userspace packages that needlessly
+  * Separately we have started to fix userspace packages that needlessly
  load configuration files multiple times, which used to trigger this
  issue. The codepaths changed are with engine use, how they are
  loaded/unloaded/used. It is possible that this fix will make some
  engines to start working and be used resulting in new behaviour. But
  also exposing bugs in the engines that previously were installed &
  configured but not actually used.
  
  [Other Info]
-  
-  * Previous bug reports about this issues are:
+ 
+  * Previous bug reports about this issues are:
  https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1921518
  https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528

** Description changed:

  [Impact]
  
   * Engine crashes when loading the configuration more than once
  
   * Upstream started to avoid loading engines twice by using dynamic ids
  to track the loaded engines correctly
  
-  * OpenSSL 3 merge https://github.com/openssl/openssl/pull/17073 (bugfix
- & testcase)
+  * OpenSSL 3
+ 
https://github.com/openssl/openssl/commit/81c11349c2a0e945aa3dfc6bd81c957363dd2011
 (bugfix)
+ 
https://github.com/openssl/openssl/commit/38e2957249c90317a26a080c7e7eb186dd5b6598
 (test case)
  
   * OpenSSL 1.1.1 backports:
  
https://github.com/openssl/openssl/commit/9b06ebb1edfddffea083ba36090af7eb7cad207b
 (bugfix)
- 
https://github.com/openssl/openssl/commit/6d022b04748c2a89b7f032a41965df19c584e0cf
 (test case)
+ https://github.com/openssl/openssl/pull/17083 (test case)
  
  [Test Plan]
  
   * https://github.com/openssl/openssl/issues/17023 lists multiple ways
  how one can trigger the issue at hand, but also test case implements
  this issue too by explicitly attempting to load an engine multiple times
  and checking that it is operational.
  
  [Where problems could occur]
  
   * Separately we have started to fix userspace packages that needlessly
  load configuration files multiple times, which used to trigger this
  issue. The codepaths changed are with engine use, how they are
  loaded/unloaded/used. It is possible that this fix will make some
  engines to start working and be used resulting in new behaviour. But
  also exposing bugs in the engines that previously were installed &
  configured but not actually used.
  
  [Other Info]
  
   * Previous bug reports about this issues are:
  https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1921518
  https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528

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

Title:
  Engine crashes when loading the configuration more than once

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  New

Bug description:
  [Impact]

   * Engine crashes when loading the configuration more than once

   * Upstream started to avoid loading engines twice by using dynamic
  ids to track the loaded engines correctly

   * OpenSSL 3
  
https://github.com/openssl/openssl/commit/81c11349c2a0e945aa3dfc6bd81c957363dd2011
 (bugfix)
  
https://github.com/openssl/openssl/commit/38e2957249c90317a26a080c7e7eb186dd5b6598
 (test case)

   * OpenSSL 1.1.1 backports:
  
https://github.com/openssl/openssl/commit/9b06ebb1edfddffea083ba36090af7eb7cad207b
 (bugfix)
  https://github.com/openssl/openssl/pull/17083 (test case)

  [Test Plan]

   * 

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

2021-11-23 Thread Dimitri John Ledkov
** Changed in: iptables (Ubuntu Jammy)
   Status: New => Fix Committed

-- 
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:
  Fix Committed
Status in iptables source package in Impish:
  New
Status in iptables source package in Jammy:
  Fix Committed

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


Re: [Touch-packages] [Bug 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf

2021-11-23 Thread Dimitri John Ledkov
On Tue, Nov 23, 2021 at 1:40 PM Jason A. Donenfeld
<1892...@bugs.launchpad.net> wrote:
>
> I think he meant to post this on
> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317
>

That makes a lot more sense. Commented my opinion there about the need
for key generation tooling.

Regards,

Dimitri.

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

Title:
  systemd package missing resolvconf(8) compatibility symlink, and a
  Provides: resolvconf

Status in systemd package in Ubuntu:
  Won't Fix
Status in wireguard package in Ubuntu:
  Confirmed
Status in systemd package in Debian:
  Incomplete

Bug description:
  By default Ubuntu now uses systemd to manage the nameservers in
  resolv.conf, so resolvconf and openresolv seem to be redundant.
  However, it appears that systemd's resolvectl is compatable with
  resolvconf style commands if symlinked as resolvconf.

  I'm not really sure how deb packaging works, but if it possible to
  check for the resolvconf command, and if not found just symlink
  /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work
  without additional packages.

  See
  
https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8)
  for more info.

  Apologies if there is a better place to direct this info.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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 1892798] Re: systemd package missing resolvconf(8) compatibility symlink, and a Provides: resolvconf

2021-11-23 Thread Dimitri John Ledkov
@ahasenack I feel a bit lost here. This bug report is about how one
should or shouldn't propagate DNS servers after establishing a wireguard
based connection.

This has nothing to do w.r.t. creating keys.

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

Title:
  systemd package missing resolvconf(8) compatibility symlink, and a
  Provides: resolvconf

Status in systemd package in Ubuntu:
  Won't Fix
Status in wireguard package in Ubuntu:
  Confirmed
Status in systemd package in Debian:
  Incomplete

Bug description:
  By default Ubuntu now uses systemd to manage the nameservers in
  resolv.conf, so resolvconf and openresolv seem to be redundant.
  However, it appears that systemd's resolvectl is compatable with
  resolvconf style commands if symlinked as resolvconf.

  I'm not really sure how deb packaging works, but if it possible to
  check for the resolvconf command, and if not found just symlink
  /usr/bin/resolvectl to /usr/sbin/resolvconf then wg-quick will work
  without additional packages.

  See
  
https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1#compatibility%20with%20resolvconf(8)
  for more info.

  Apologies if there is a better place to direct this info.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892798/+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-23 Thread Dimitri John Ledkov
Thank you for working with OpenSSL upstream, explaining the issue at
hand, for everyone to eventually understand what is going on, and
finally coming up with a solution on the OpenSSL side of the APIs that
is accepted by upstream into development v3 branch and stable 1.1.1
branch.

I have started paperwork to pick up these changes at
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951943

As far as I can tell it would be desirable to ship in 5 current Ubuntu
stable series, hence using a new bug to track landing those updates.

-- 
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 wget package in Ubuntu:
  Fix Released
Status in wget source package in Focal:
  Fix Committed

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.

  Regression test:

  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)

  
  [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/wget/+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 1951943] [NEW] Engine crashes when loading the configuration more than once

2021-11-23 Thread Dimitri John Ledkov
Public bug reported:

[Impact]

 * Engine crashes when loading the configuration more than once

 * Upstream started to avoid loading engines twice by using dynamic ids
to track the loaded engines correctly

 * OpenSSL 3 merge https://github.com/openssl/openssl/pull/17073 (bugfix
& testcase)

 * OpenSSL 1.1.1 backports:
https://github.com/openssl/openssl/commit/9b06ebb1edfddffea083ba36090af7eb7cad207b
 (bugfix)
https://github.com/openssl/openssl/pull/17083 (test case)

[Test Plan]

 * https://github.com/openssl/openssl/issues/17023 lists multiple ways
how one can trigger the issue at hand, but also test case implements
this issue too by explicitly attempting to load an engine multiple times
and checking that it is operational.

[Where problems could occur]

 * Separately we have started to fix userspace packages that needlessly
load configuration files multiple times, which used to trigger this
issue. The codepaths changed are with engine use, how they are
loaded/unloaded/used. It is possible that this fix will make some
engines to start working and be used resulting in new behaviour. But
also exposing bugs in the engines that previously were installed &
configured but not actually used.

[Other Info]
 
 * Previous bug reports about this issues are:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1921518
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528

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

** Affects: openssl (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Hirsute)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Impish)
 Importance: Undecided
 Status: New

** Affects: openssl (Ubuntu Jammy)
 Importance: Undecided
 Status: New

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

** Also affects: openssl (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

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

** Also affects: openssl (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

Title:
  Engine crashes when loading the configuration more than once

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  New
Status in openssl source package in Jammy:
  New

Bug description:
  [Impact]

   * Engine crashes when loading the configuration more than once

   * Upstream started to avoid loading engines twice by using dynamic
  ids to track the loaded engines correctly

   * OpenSSL 3 merge https://github.com/openssl/openssl/pull/17073
  (bugfix & testcase)

   * OpenSSL 1.1.1 backports:
  
https://github.com/openssl/openssl/commit/9b06ebb1edfddffea083ba36090af7eb7cad207b
 (bugfix)
  https://github.com/openssl/openssl/pull/17083 (test case)

  [Test Plan]

   * https://github.com/openssl/openssl/issues/17023 lists multiple ways
  how one can trigger the issue at hand, but also test case implements
  this issue too by explicitly attempting to load an engine multiple
  times and checking that it is operational.

  [Where problems could occur]

   * Separately we have started to fix userspace packages that
  needlessly load configuration files multiple times, which used to
  trigger this issue. The codepaths changed are with engine use, how
  they are loaded/unloaded/used. It is possible that this fix will make
  some engines to start working and be used resulting in new behaviour.
  But also exposing bugs in the engines that previously were installed &
  configured but not actually used.

  [Other Info]
   
   * Previous bug reports about this issues are:
  https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1921518
  https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1951943/+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 1943530] Re: link libkrb5 with openssl

2021-11-18 Thread Dimitri John Ledkov
> Do we even know for sure this krb5-k5tls is enough for fips
compliance, and that it replaces *all* crypto code in kerberos with
openssl calls?

No it does not. But intention is to make the over the network
communications with TLS to be FIPS-TLS compliant which is cheaper to
certify when reusing a certified TLS component library.


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

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

Title:
  link libkrb5 with openssl

Status in krb5 package in Ubuntu:
  Confirmed

Bug description:
  In Ubuntu we provide a cryptographic core based on a small set of
  packages that we FIPS certify [0]. Applications and libraries should
  not bundle their own crypto code but should use the cryptographic core
  to benefit from the certification, but also importantly to reduce bugs
  due to small cryptographic libraries that that are not studied as much
  as more popular counterparts. This bug is to change libkrb5 to use the
  openssl crypto code instead of bundling its own on the next ubuntu
  release.

  [0]. https://ubuntu.com/security/fips

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

2021-11-18 Thread Dimitri John Ledkov
Autopkgtests have now all passed.

-- 
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:
  Fix Committed

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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

2021-11-18 Thread Dimitri John Ledkov
@arighi suggests used to be installed when one used to provide "needs-
suggests" restrictions or some such, but that got deprecated, so no
suggests are not getting installed by default.

However, we have a multi year MIR to seed and install nftables by
default let me check the status of that
https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/1887187

-- 
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 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible

2021-11-15 Thread Dimitri John Ledkov
** Changed in: initramfs-tools (Ubuntu)
   Status: New => Triaged

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

** Also affects: initramfs-tools (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Jammy)
   Importance: Undecided
 Assignee: Dimitri John Ledkov (xnox)
   Status: Triaged

** Also affects: initramfs-tools (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

Title:
  Missing all modules for usb nics in initrd which makes PXE boot
  impossible

Status in initramfs-tools package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Focal:
  New
Status in initramfs-tools source package in Hirsute:
  New
Status in initramfs-tools source package in Impish:
  New
Status in initramfs-tools source package in Jammy:
  Triaged

Bug description:
  initrd taken from the live iso for PXE boot does not contain USB NIC
  drivers which makes PXE installation/netboot impossible via usb.

  This is the case on 20.04 server iso (both hwe and normal
  kernel/initrd) and desktop iso.

  "kernel/drivers/net/usb" is empty and needs to be included in the
  initramfs build.

  As most modern thin laptops lack physical rj45 ethernet this is a big
  issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: initramfs-tools 0.136ubuntu6.6
  ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18
  Uname: Linux 5.8.0-64-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Nov 15 16:47:45 2021
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago)

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

2021-11-12 Thread Dimitri John Ledkov
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 1940528] Re: curl 7.68 does not init OpenSSL correctly

2021-11-12 Thread Dimitri John Ledkov
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 1940656] Re: Potential use after free bugs in 1.1.1

2021-11-12 Thread Dimitri John Ledkov
** 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 1940656] Re: Potential use after free bugs in 1.1.1

2021-11-12 Thread Dimitri John Ledkov
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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

2021-11-12 Thread Dimitri John Ledkov
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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft

2021-11-12 Thread Dimitri John Ledkov
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 1940656] Re: Potential use after free bugs in 1.1.1

2021-11-11 Thread Dimitri John Ledkov
There is now only a transient ADT regression in Regression in linux-
hwe-5.13 (armhf), which is not a valid ADT because armhf ADT runs in lxd
containers and does not boot the requested kernel.

Please release this package.

-- 
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 1946965] Re: python3-defaults: py3versions -i does not list python3.10 when it is installed

2021-10-20 Thread Dimitri John Ledkov
Is this needed in focal too?

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

Title:
  python3-defaults: py3versions -i does not list python3.10 when it is
  installed

Status in python3-defaults package in Ubuntu:
  New
Status in python3-defaults source package in Impish:
  Fix Committed

Bug description:
  Test case:

  $ sudo apt install python3.9 python3.10
  ...
  $ py3versions -i
  python3.9

  Expected output:

  $ py3versions -i
  python3.10 python3.9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1946965/+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 1942260] Re: compress firmware in /lib/firmware

2021-10-19 Thread Dimitri John Ledkov
** Also affects: linux-firmware-raspi2 (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  compress firmware in /lib/firmware

Status in initramfs-tools package in Ubuntu:
  New
Status in linux-firmware package in Ubuntu:
  New
Status in linux-firmware-raspi2 package in Ubuntu:
  New

Bug description:
  Some facts:
   - The linux kernel has supported loading xz compressed firmware since 5.3
   - The size of /lib/firmware in impish is ~650Mb (and growing)
   - The compressed size of firmware could be ~230Mb

  It would be nice to install compressed firmware to save space.

  Here are the plans from the Fedora project:
  https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1942260/+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 1932329] Re: Benchmark if we can compress kernel modules

2021-10-19 Thread Dimitri John Ledkov
** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Benchmark if we can compress kernel modules

Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  In Progress

Bug description:
  Symbol: MODULE_COMPRESS_ZSTD [=n]
  Type  : bool

  = Impacts to measure and observe =

  == Disk space ==

  * Inspect linux-modules-* and linux-modules-extra* deb package
  Installed-Size and Download-Size changes, i.e.

  $ apt show linux-modules-5.8.0-53-generic linux-modules-
  extra-5.8.0-53-generic  | grep -e Package: -e Size:

  Package: linux-modules-5.8.0-53-generic
  Installed-Size: 81.5 MB
  Download-Size: 15.5 MB

  Package: linux-modules-extra-5.8.0-53-generic
  Installed-Size: 215 MB
  Download-Size: 41.5 MB

  In theory, there should not be a significant change in the Download-
  size. It is desired that there is a significant reduction in
  Installed-Size. Modules take up about 300MB and normally one has upto
  three kernel version installed, resulting in about of 1GB of disk
  space that one constantly pays for.

  == Boot Speed ==

  In theory, boot speed may either improve or regress. It depends if
  disk IO is slower than decompression speed, meaning loading compressed
  modules is faster.

  Also one has to observe the changes in the initrd size. zstd(zstd)
  compression may result in slight growth, which shouldn't impact boot
  speed too much.

  = Outcomes =

  If installed size savings can be achieved without regressing bootspeed
  we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932329/+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 1942260] Re: compress firmware in /lib/firmware

2021-10-19 Thread Dimitri John Ledkov
** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  compress firmware in /lib/firmware

Status in initramfs-tools package in Ubuntu:
  New
Status in linux-firmware package in Ubuntu:
  New

Bug description:
  Some facts:
   - The linux kernel has supported loading xz compressed firmware since 5.3
   - The size of /lib/firmware in impish is ~650Mb (and growing)
   - The compressed size of firmware could be ~230Mb

  It would be nice to install compressed firmware to save space.

  Here are the plans from the Fedora project:
  https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1942260/+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 1671536] Re: Default initrd is LZMA compressed, yet rebuilt initramfs are gzip?

2021-10-18 Thread Dimitri John Ledkov
I believe livecd-rootfs and live-build have been fixed for this.

** Changed in: cloud-images
   Status: New => Fix Released

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Fix Released

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

Title:
  Default initrd is LZMA compressed, yet rebuilt initramfs are gzip?

Status in cloud-images:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  $ file ~/Downloads/xenial-server-cloudimg-amd64-initrd-generic
  /home/xnox/Downloads/xenial-server-cloudimg-amd64-initrd-generic: LZMA 
compressed data, streamed

  Yet, in the base image I don't see that initramfs config options set
  COMPRESS=lzma. Thus first boot is lzma, yet on package upgrades i
  guess initrd would be regenerated as gzip...

  Isn't the fact that all of our images use lzma and/or xz compression
  means we should switch Ubuntu default to lzma and/or xz as well?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1671536/+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 1944082] Re: initramfs-tools: zstd uses too much memory in mkinitramfs

2021-10-18 Thread Dimitri John Ledkov
In general we optimize for bootspeed, at the expense of generation time.
It is often the case that we can complete the boot on systems smaller
than required to recreate files for such boot. I.e. impossible to
install/upgrade packages.

Are you experiencing failure to create initrd, where previously you
could? a 512MB instance should still be able to create zstd compressed
initrd and boot.

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Incomplete

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

Title:
  initramfs-tools: zstd uses too much memory in mkinitramfs

Status in initramfs-tools package in Ubuntu:
  Incomplete

Bug description:
  Changing the default compression method of initramfs to zstd using
  hardcoded compression flag "-19 -T0" takes 200MB memory in return for
  40MB reduction of disk IO. I think it is too much memory usage for
  some fraction of seconds while booting.

  The default compression method of initramfs was changed in Bug #1931725 for 
impish but the runtime memory usage was not discussed well.
  the test results by modifying compression command in /usr/sbin/mkinitramfs on 
a small VM (amd64, 512MB RAM, 1vCPU, with 5.13.0-16-generic image) 
  | RSSmax | initrd size
  zstd -q -19 -T0 |  214MB |  64MB (+-0MB)
  zstd -q -3 -T1  |   44MB |  84MB (+20MB)
  lz4 -9 -l   |   15MB | 107MB (+43MB)

  Since the hardcoded flag uses "-T0", more memory will be used if more CPU 
threads are available.
  Please reconsider the default compression method or patch the hardcoded flag 
to "-3 -T1" (=zstd default).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1944082/+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 1941649] Re: switch to zstd by default breaks booting focal LTS kernel

2021-10-18 Thread Dimitri John Ledkov
partial upgrades are not supported, and during upgrades we generally do
not recreate initrds for old kernels.

Meaning one should have at least .old kernel+initrd pair bootable.

It is more of linux bug maybe that v5.4 does not support zstd compressed
initrd?

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

Title:
  switch to zstd by default breaks booting focal LTS kernel

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  While trying to track down a behavior difference between focal and
  impish, I installed focal's kernel in an impish userspace and
  attempted to boot it. The boot failed, unable to find root. While GRUB
  reported that it had loaded the initramfs, no initramfs messages were
  emitted during boot. I tracked this down to initramfs-tools having
  switched to use zstd compression by default. zstd decompression does
  not appear to be supported by the LTS 5.4 kernel - it appears to have
  been added upstream in v5.9. I imagine this is likely to cause
  problems with partial-upgrade scenarios.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1941649/+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 1946343] Re: Stale os-release file after possible upgrade from 20.04.2 to 20.04.3

2021-10-08 Thread Dimitri John Ledkov
It looks like it is this platform:

http://oem.archive.canonical.com/dists/focal-somerville-bulbasaur/

But I don't see any packages called oem-release or where they came from.

Dear reporter, what's the output of:

$ apt-cache policy oem-release

?


** Also affects: dell
   Importance: Undecided
   Status: New

** Changed in: dell
   Importance: Undecided => Critical

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

Title:
  Stale os-release file after possible upgrade from 20.04.2 to 20.04.3

Status in Dell Ubuntu Project:
  New
Status in OEM Priority Project:
  New
Status in base-files package in Ubuntu:
  Invalid

Bug description:
  Refer: https://answers.launchpad.net/ubuntu/+question/698949

  I recently bought a Dell laptop with Ubuntu pre-installed in it. Looks
  like it came with Ubuntu 20.04.2 and OEM Linux Kernel in it. After my
  initial login (on October 1, 2021), the 'Software Updater' GUI
  prompted me for updates, which I went ahead with.

  However at the end of it, I noticed that I was still at 20.04.2 with
  Linux Kernel at 5.10.0-1045-oem.

  lsb_release -a
  ---

  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.2 LTS (fossa-bulbasaur X55.1)
  Release:20.04
  Codename:   focal

  uname -a
  -
  Linux dev-linux 5.10.0-1045-oem #47-Ubuntu SMP Wed Aug 18 10:41:03 UTC 2021 
x86_64 x86_64 x86_64 GNU/Linux

  Then I manually tried sudo apt update and sudo apt upgrade / dist-
  upgrade from the terminal, but nothing got upgraded. When I invoked
  the GUI 'Software Updater' again, it showed me that my system was
  already up-to-date. However, as 20.04.3 was released end of Aug 2021,
  I was expecting that I should be at that release after my initial
  updates.

  Since that didn't happen, I asked a question regarding this in
  askubuntu followed by launchpad
  https://answers.launchpad.net/ubuntu/+question/698949, thinking my
  update had failed for some unknown reason.

  However, based on some inputs from other users, we were able to narrow
  down the problem to /usr/lib/os-release file not having the right
  contents in it. Every other file including /usr/lib/os-release.oem-
  release, /etc/issue, /etc/issue.net specifies that I am on 20.04.3.
  Whereas only /usr/lib/os-release (and its symlink /etc/release)
  specifies my current release as 20.04.2.

  Even the lsb_release -a command always displays the output of
  /usr/lib/os-release file only.

  $ cat /usr/lib/os-release
  NAME="Ubuntu"
  VERSION="20.04.2 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.2 LTS (fossa-bulbasaur X55.1)"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

  $ cat /usr/lib/os-release.oem-release
  NAME="Ubuntu"
  VERSION="20.04.3 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.3 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

  $ cat /etc/issue
  Ubuntu 20.04.3 LTS \n \l

  $ cat /etc/issue.net
  Ubuntu 20.04.3 LTS

  If you look at the timestamp of these files, strangely os-release had
  a newer timestamp of Oct 1 compared to other files.

  $ ls -l /usr/lib/os-release
  -rw-r--r-- 1 root root 406 Oct 1 20:31 /usr/lib/os-release

  $ ls -l /usr/lib/os-release.oem-release
  -rw-r--r-- 1 root root 382 Aug 4 07:53 /usr/lib/os-release.oem-release

  $ ls -l /etc/issue
  -rw-r--r-- 1 root root 26 Aug 4 07:53 /etc/issue

  $ ls -l /etc/issue.net
  -rw-r--r-- 1 root root 19 Aug 4 07:53 /etc/issue.net

  Please note that, other software package updates, and linux kernel
  updates are happening automatically without any issues so far for me.
  Few days back even got a new kernel update.

  $ uname -a
  Linux vivek-dev-linux 5.10.0-1049-oem #51-Ubuntu SMP Mon Sep 27 11:01:10 UTC 
2021 x86_64 x86_64 x86_64 GNU/Linux

  Workarounds Attempted
  -
  1. Commented out all non-ubuntu external sources from /etc/apt/*.list. Then 
performed an apt clean + update + upgrade. But still nothing happened and the 
same issue remained. 

  2. Tried performing apt-install --reinstall base-files. But still
  nothing changed:

  $ sudo apt install --reinstall base-files
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
  Need to get 60.6 kB of archives.
  After this 

[Touch-packages] [Bug 1946343] Re: Stale os-release file after possible upgrade from 20.04.2 to 20.04.3

2021-10-08 Thread Dimitri John Ledkov
** Also affects: oem-priority
   Importance: Undecided
   Status: New

** Changed in: oem-priority
   Importance: Undecided => Critical

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

Title:
  Stale os-release file after possible upgrade from 20.04.2 to 20.04.3

Status in OEM Priority Project:
  New
Status in base-files package in Ubuntu:
  Invalid

Bug description:
  Refer: https://answers.launchpad.net/ubuntu/+question/698949

  I recently bought a Dell laptop with Ubuntu pre-installed in it. Looks
  like it came with Ubuntu 20.04.2 and OEM Linux Kernel in it. After my
  initial login (on October 1, 2021), the 'Software Updater' GUI
  prompted me for updates, which I went ahead with.

  However at the end of it, I noticed that I was still at 20.04.2 with
  Linux Kernel at 5.10.0-1045-oem.

  lsb_release -a
  ---

  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.2 LTS (fossa-bulbasaur X55.1)
  Release:20.04
  Codename:   focal

  uname -a
  -
  Linux dev-linux 5.10.0-1045-oem #47-Ubuntu SMP Wed Aug 18 10:41:03 UTC 2021 
x86_64 x86_64 x86_64 GNU/Linux

  Then I manually tried sudo apt update and sudo apt upgrade / dist-
  upgrade from the terminal, but nothing got upgraded. When I invoked
  the GUI 'Software Updater' again, it showed me that my system was
  already up-to-date. However, as 20.04.3 was released end of Aug 2021,
  I was expecting that I should be at that release after my initial
  updates.

  Since that didn't happen, I asked a question regarding this in
  askubuntu followed by launchpad
  https://answers.launchpad.net/ubuntu/+question/698949, thinking my
  update had failed for some unknown reason.

  However, based on some inputs from other users, we were able to narrow
  down the problem to /usr/lib/os-release file not having the right
  contents in it. Every other file including /usr/lib/os-release.oem-
  release, /etc/issue, /etc/issue.net specifies that I am on 20.04.3.
  Whereas only /usr/lib/os-release (and its symlink /etc/release)
  specifies my current release as 20.04.2.

  Even the lsb_release -a command always displays the output of
  /usr/lib/os-release file only.

  $ cat /usr/lib/os-release
  NAME="Ubuntu"
  VERSION="20.04.2 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.2 LTS (fossa-bulbasaur X55.1)"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

  $ cat /usr/lib/os-release.oem-release
  NAME="Ubuntu"
  VERSION="20.04.3 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.3 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/;
  SUPPORT_URL="https://help.ubuntu.com/;
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

  $ cat /etc/issue
  Ubuntu 20.04.3 LTS \n \l

  $ cat /etc/issue.net
  Ubuntu 20.04.3 LTS

  If you look at the timestamp of these files, strangely os-release had
  a newer timestamp of Oct 1 compared to other files.

  $ ls -l /usr/lib/os-release
  -rw-r--r-- 1 root root 406 Oct 1 20:31 /usr/lib/os-release

  $ ls -l /usr/lib/os-release.oem-release
  -rw-r--r-- 1 root root 382 Aug 4 07:53 /usr/lib/os-release.oem-release

  $ ls -l /etc/issue
  -rw-r--r-- 1 root root 26 Aug 4 07:53 /etc/issue

  $ ls -l /etc/issue.net
  -rw-r--r-- 1 root root 19 Aug 4 07:53 /etc/issue.net

  Please note that, other software package updates, and linux kernel
  updates are happening automatically without any issues so far for me.
  Few days back even got a new kernel update.

  $ uname -a
  Linux vivek-dev-linux 5.10.0-1049-oem #51-Ubuntu SMP Mon Sep 27 11:01:10 UTC 
2021 x86_64 x86_64 x86_64 GNU/Linux

  Workarounds Attempted
  -
  1. Commented out all non-ubuntu external sources from /etc/apt/*.list. Then 
performed an apt clean + update + upgrade. But still nothing happened and the 
same issue remained. 

  2. Tried performing apt-install --reinstall base-files. But still
  nothing changed:

  $ sudo apt install --reinstall base-files
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
  Need to get 60.6 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 base-files 
amd64 11ubuntu5.4 [60.6 kB]
  Fetched 60.6 kB in 1s (55.7 kB/s)
  (Reading database ... 191154 files and directories currently installed.)

[Touch-packages] [Bug 1942357] Re: Regression in openssl 1.0.1f for trusty/esm after last update

2021-09-21 Thread Dimitri John Ledkov
** Changed in: openssl (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  Regression in openssl 1.0.1f for trusty/esm after last update

Status in openssl package in Ubuntu:
  Invalid
Status in openssl source package in Trusty:
  Fix Released

Bug description:
  A security regression was reported by Johannes Wegener that is causing
  a regression in the last openssl1.0.1f in trusty/esm.

  [How to reproduce]
  1. Install Openssl/libssl1.0.0 Version 1.0.1f-1ubuntu2.27+esm3 on
  ubuntu 14.04
  2. openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n 
'/-BEGIN/,/-END/p' > wikipedia.pem 
  3. openssl x509 -noout -ocsp_uri -in wikipedia.pem 

  Expected it prints: http://r3.o.lencr.org
  Issue: it's not printing anything.

  Thanks Johannes for report this issue.

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

2021-09-14 Thread Dimitri John Ledkov
** Changed in: curl (Ubuntu Focal)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

-- 
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 1940656] Re: Potential use after free bugs in 1.1.1

2021-09-14 Thread Dimitri John Ledkov
** Changed in: openssl (Ubuntu Focal)
   Status: Incomplete => In Progress

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

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

Title:
  Potential use after free bugs in 1.1.1

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-09-14 Thread Dimitri John Ledkov
I would agree that any hypothetical use-after-free / double-free errors
are usually also security vulnerabilities. But these ones were
discovered with static analysis and/or affecting engine use, in error
conditions only. Thus connectivity must already be failing / denied,
before one can trip these ones up. Not sure if one can further stage an
attack by staging a connection failure, and try to disclose information
from that.

Will ping security team about it.

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

Title:
  Potential use after free bugs in 1.1.1

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-09-14 Thread Dimitri John Ledkov
No I'm not able to reproduce the issues anymore. Hence I need detailed
logs from you. Including tracebacks with debug symbols installed, and
strace too. Because I have never seen "bus error" on my side.

-- 
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 1943530] Re: link libkrb5 with openssl

2021-09-14 Thread Dimitri John Ledkov
krb5 (1.13~alpha1+dfsg-1) experimental; urgency=low

  [ Benjamin Kaduk ]
  * New upstream prerelease:
- Add support for accessing KDCs via an https proxy using the MS-KKDCP
  protocol, using a plugin provided by the new krb5-k5tls package, which
  uses openssl for the TLS implementation.  The openssl-using code is
  confined to a separate, runtime-loadable, plugin module, in a separate
  package, to ameliorate concerns about GPL code that links libkrb5 running
  into issues with the openssl license.  The Kerberos license is both
GPL and OpenSSL compatible.  There might be an issue if an application
was GPL licensed and someone used the OpenSSL plugin with that
application.  Even that is probably fine provided that no one
distributes a combination that tends to encourage such usage.  There's
an existing krb5-pkinit plugin that also links to OpenSSL, but at time
of integration into Debian no GPLed applications in the archive called
APIs that would cause that plugin to be loaded.

The above concerns are still valid, and given that currently OpenSSL is
neither GPLv2 or GPLv3 compatible doing this may not be feasible
immediately.

The licensing choices will have to be re-evaluated again, once OpenSSL
v3 is the default OpenSSL implementation in the archive, which is GPLv3
compatible.

** Tags removed: rls-ii-incoming
** Tags added: rls-ii-wontfix

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

Title:
  link libkrb5 with openssl

Status in krb5 package in Ubuntu:
  New

Bug description:
  In Ubuntu we provide a cryptographic core based on a small set of
  packages that we FIPS certify [0]. Applications and libraries should
  not bundle their own crypto code but should use the cryptographic core
  to benefit from the certification, but also importantly to reduce bugs
  due to small cryptographic libraries that that are not studied as much
  as more popular counterparts. This bug is to change libkrb5 to use the
  openssl crypto code instead of bundling its own on the next ubuntu
  release.

  [0]. https://ubuntu.com/security/fips

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1943530/+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 1943530] Re: link libkrb5 with openssl

2021-09-14 Thread Dimitri John Ledkov
** Tags added: rls-ii-incoming rls-jj-incoming

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

Title:
  link libkrb5 with openssl

Status in krb5 package in Ubuntu:
  New

Bug description:
  In Ubuntu we provide a cryptographic core based on a small set of
  packages that we FIPS certify [0]. Applications and libraries should
  not bundle their own crypto code but should use the cryptographic core
  to benefit from the certification, but also importantly to reduce bugs
  due to small cryptographic libraries that that are not studied as much
  as more popular counterparts. This bug is to change libkrb5 to use the
  openssl crypto code instead of bundling its own on the next ubuntu
  release.

  [0]. https://ubuntu.com/security/fips

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1943530/+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-08-27 Thread Dimitri John Ledkov
@Vladimir

This is an improvement.

Previously we were getting: double free or corruption (out)
But now it is: Bus error
So some progress has been made.

Can you please install debug symbols, and generate a complete traceback
with debug symbols? or a core dump with debug symbols? (libcurl4-dbgsym
curl-dbgsym libssl1.1-dbgsym)

Also which libpka are you using? Were debug symbols compiled for it, and
can you share it? Is it just the latest build from github?

I have not previously seen Bus error when debugging this issue => on
arm64 it is usually non-aligned memory access coming from somewhere.

-- 
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 1928989] Re: expiring trust anchor compatibility issue

2021-08-27 Thread Dimitri John Ledkov
Attempted trusty backport, but failing at making it pass all the
existing unit tests. Asking for help. At the moment it seems to me that
trusty will remain unfixed.

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64 1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved 

[Touch-packages] [Bug 1940635] Re: systemd-networkd failing to acquire a DHCP6 lease from dnsmasq on armhf

2021-08-26 Thread Dimitri John Ledkov
We must build armhf glibc which is y2038 safe, like our v5.1+ kernels
are (bionic-hwe and up). Thus yes, glibc should assume TIME64 SYSCALLS,
on armhf.

Also, maybe our farm can move to focal and focal kernel; or like at
least to bionic-hwe kernel.

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

Title:
  systemd-networkd failing to acquire a DHCP6 lease from dnsmasq on
  armhf

Status in glibc package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-networkd is failing to acquire a DCHP6 lease from dnsmasq on
  armhf since glibc 2.34-0ubuntu1, failing systemd (tests-name=networkd-
  test.py) and netplan.io (test-name=ethernets) tests on armhf.

  Reproducer:
  * Setup an armhf container, e.g. via:
  autopkgtest systemd --test-name=networkd-test.py --shell -U 
--apt-pocket=proposed=src:systemd,src:glibc -s -- lxd 
autopkgtest/ubuntu/impish/armhf
  * It will fail and drop you into the shell
  * cd test/ && apt install python3-nose
  * nosetests3 -v -s -m "test_.*_dhcp_ip6" networkd-test.py

  
  This is unrelated to the recent dnsmasq changes (LP: #1894619), as that would 
fail on all architectures, not just armhf.

  It still passes inside an amd64 LXD container, so it is also not related to 
armhf being tested inside a container. But it shows the difference between 
armhf vs amd64 container, that on armhf we're missing the DHCPSOLICIT (and 
therefore DHCPREPLY) messages, as can be seen from the dnsmasq log:
  dnsmasq-dhcp[]: DHCPSOLICIT(router_eth42) 
00:02:00:00:ab:11:57:1e:20:2f:9e:56:5f:34 
  dnsmasq-dhcp[]: DHCPREPLY(router_eth42) 2600::1f 
00:02:00:00:ab:11:57:1e:20:2f:9e:56:5f:34 autopkgtest-lxd-rtypaf

  The issue is most probably the same that causes the currently failing
  netplan.io/ethernets autopkgtest on armhf, if tested against glibc
  2.34-0ubuntu1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1940635/+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-08-26 Thread Dimitri John Ledkov
Vladimir, I did this in the same location as before -
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4654

-- 
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 1921518] Re: OpenSSL "double free" error

2021-08-25 Thread Dimitri John Ledkov
1.1.1f-1ubuntu2.8 is security-only update to address CVE-2021-3711 &
CVE-2021-3712

The fixes from this bug report have been rebased on top of the security-
only update in the PPA provided earlier. It has been carrying
1.1.1f-1ubuntu2.9 since yesterday.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3711

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3712

-- 
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 1939544] Re: Merge the 1.1.1k version from Debian

2021-08-25 Thread Dimitri John Ledkov
Please merge 1.1.1l with the CVE fixes

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

Title:
  Merge the 1.1.1k version from Debian

Status in openssl package in Ubuntu:
  Fix Committed

Bug description:
  Impish currently ships with a version based on the upstream 1.1.1j,
  while Debian bullseye/sid has 1.1.1k. Let's merge!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1939544/+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-08-24 Thread Dimitri John Ledkov
The updated openssl package does not change any behaviour w.r.t. config
or engine use. It only has three patches applied to prevent potential
use-after-free errors. It also relies on installing the new PKA engine
with patches from github.

Has the new PKA engine been recompiled and installed correctly?

When installed on my system, the engines configured continued to be
used, and I can observe PKA debug output when using `openssl s_client
-connect` or `curl`.

Note, that `speed` command, by default does not use engines, even when
configured in /etc/ssl/openssl.cnf. One must pass `-engine ID` option to
it to use an engine.

-- 
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 1921518] Re: OpenSSL "double free" error

2021-08-23 Thread Dimitri John Ledkov
@vladimir sokolovsky

Note, that the proposed PPA is built for all architectures, and all
configurations of the packages in questions as used in Ubuntu. Meaning,
they are all compiled in multiple configurations, which are mutually
incompatible. To ensure one installs the upgraded packages suitable for
ones own system, one should not download all/any/individual debs from
the archive, but instead one should only download and upgrade the
packages that are already present on ones own system only.

For example, your comments indicate that incompatible packages were
downloaded and attempted to be forcefully installed, breaking your
system.

Please revert the system to stock configurate.

Enable the ppa as mentioned in https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4654 "Adding this PPA to your system" I.e.
specifically `sudo add-apt-repository ppa:ci-train-ppa-service/4654`
followed by `sudo apt update; sudo apt full-upgrade`

This should only install relevant packages for your system from the
proposed ppa, specifically things like "libssl1.1 openssl cur libcurl4"
in the deb format for the arm64 server architecture only.

Do not install any packages that have udeb in the name, they are not
used on servers and have incompatible configuration.

The above is preferred.

If you do not have direct access to launchpad PPA on your system under
test, you can use pull-pkg utility from ubuntu-dev-tools to download
packages you require, but then you must be extra careful to upgrade only
the matching set of packages. For example

$ pull-pkg -D ppa --ppa ci-train-ppa-service/4654 --arch arm64 --pull debs 
openssl focal
$ pull-pkg -D ppa --ppa ci-train-ppa-service/4654 --arch arm64 --pull debs curl 
focal

Transfer the debs to your system under test.
Check packages that are already installed, and upgrade only the ones that are 
already on your system.
I.e.
$ dpkg -l | grep -e 7.68.0 -e 1.1.1f
$ sudo apt install ./curl_*.deb ./libssl1.1_*.deb ./openssl_*.deb 
./libcurl4_*.deb

If needed, you can also use pull-pkg tool to download debug symbols
packages to assist in debugging. And again only install debug symbols
packages for the libraries and packages already present on your system;
as again there are debug symbols provided for all configurations, which
are incompatible with each other and cannot be all installed
simultaneously.

-- 
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 1832356] Re: Upgrade OpenSSH to 7.9p1-10 or better in stable series

2021-08-23 Thread Dimitri John Ledkov
** Changed in: openssh (Ubuntu Bionic)
   Status: Confirmed => Won't Fix

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

Title:
  Upgrade OpenSSH to 7.9p1-10 or better in stable series

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Won't Fix
Status in openssh source package in Cosmic:
  Won't Fix
Status in openssh source package in Disco:
  Fix Released
Status in openssh source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * 18.04 LTS release with a long support time frame
   * There are two versions of OpenSSL shipped in 18.04:
 - obsolete 1.0.2
 - current long term supported 1.1.1 series
   * OpenSSH in 18.04 is the only package in main using libcrypto from 1.0.2
   * The fact that OpenSSH uses a different libcrypto implementation impacts 
certification, 
 compliance, and security maintenance.
   * Furthermore OpenSSH does not benefit from hardware accelerated crypto, as 
available in 1.1.1
   * Thus there is a desire to upgrade OpenSSH in 18.04 from 1:7.6p1-4 to 
1:7.9p1-10 and compile 
 against OpenSSL 1.1.1
   * 1:7.9p1-10 is currently shipped in Disco/Eoan, and it is likely that 20.04 
will ship with 
 1:8.0p1 or newer. Thus security maintainance burden is slightly increased. 
However, 1:7.9p1-10
 is likely to be shipped in the next stable Debian release, and supported 
there for a long-ish
 time including debian-lts efforts. Thus there are some synergies.

  [Upstream Changelogs]

   * https://www.openssh.com/txt/release-7.9
   * https://www.openssh.com/txt/release-7.8
   * https://www.openssh.com/txt/release-7.7

  [Test Case]

   * Install openssh-server and openssh-client, check that they depend on 
libssl1.1 and do not depend 
 on libssl1.0
   
   * Check that there are no new connectivity issues between old/new servers 
and clients,
 at the very least between various Ubuntu releases in the public clouds.

  [Regression Potential]

  v7.9

   * ssh(1), sshd(8): the setting of the new CASignatureAlgorithms
 option (see below) bans the use of DSA keys as certificate
 authorities.

  DSA keys as certificate authorities are widely banned already. May
  affect connectivity.

   * sshd(8): the authentication success/failure log message has
 changed format slightly. It now includes the certificate
 fingerprint (previously it included only key ID and CA key
 fingerprint).

  This may impact log parsers, i.e. logwatch and similar. Possibly worth
  a NEWS entry.

  v7.8

   * ssh-keygen(1): write OpenSSH format private keys by default
 instead of using OpenSSL's PEM format. The OpenSSH format,
 supported in OpenSSH releases since 2014 and described in the
 PROTOCOL.key file in the source distribution, offers substantially
 better protection against offline password guessing and supports
 key comments in private keys. If necessary, it is possible to write
 old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
 when generating or updating a key.

  Normally, it shouldn't matter which format newly generated keys use.
  Existing keys remain unchanged. Systems that automatically
  generate/parse/store keys may be impacted. The risk here is low. As
  potential mitigation we can revert the default back to PEM for the SRU
  into bionic.

   * sshd(8): remove internal support for S/Key multiple factor
 authentication. S/Key may still be used via PAM or BSD auth.

  S/Key is not widely deployed. Most common OTP implementations use PAM
  stack, and use HOTP, TOTP, Yubikey and similar one time passwords,
  rather than S/Key. This is deemed low.

   * ssh(1): remove vestigal support for running ssh(1) as setuid. This
 used to be required for hostbased authentication and the (long
 gone) rhosts-style authentication, but has not been necessary for
 a long time. Attempting to execute ssh as a setuid binary, or with
 uid != effective uid will now yield a fatal error at runtime.

  This is security and hardening improvement. We do not ship sshd
  setuid.

   * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
 HostbasedAcceptedKeyTypes options have changed. These now specify
 signature algorithms that are accepted for their respective
 authentication mechanism, where previously they specified accepted
 key types. This distinction matters when using the RSA/SHA2
 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
 certificate counterparts. Configurations that override these
 options but omit these algorithm names may cause unexpected
 authentication failures (no action is required for configurations
 that accept the default for these options).

  This is potentially a problem. We can add upgrade hooks to warn users
  about these, or abort the 

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

2021-08-20 Thread Dimitri John Ledkov
New curl & openssl will take some time to appear in focal-updates, as
focal-updates are frozen for 20.04.3 release on 26th of August at the
moment.

See https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-
release-status-tracking/22948

-- 
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 1921518] Re: OpenSSL "double free" error

2021-08-20 Thread Dimitri John Ledkov
Whilst I have identified broken/racy/incomplete behaviours in both curl
and openssl in ubuntu focal 20.04 and created SRUs for them in the above
mentioned bug reports; these do not fix crashes of the old PKA 1.0.0
engine.

Also PKA 1.0.0 does not appear to be compatible with 20.04 userspace
anymore.

The fix I have proposed for the PKA engine
https://github.com/Mellanox/pka/pull/37/files must be shipped on all
systems / any distribution.

If you can reproduce any new issues whilst using openssl & curl from
https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4654/+packages and whilst using up to date PKA
with my pull request merged, please provide further details.

As it stands, I don't see any crashes on any systems, once _all_ of the
above are applied.

-- 
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 1921518] Re: OpenSSL "double free" error

2021-08-20 Thread Dimitri John Ledkov
Openssl bug report
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656

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

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

** Changed in: openssl (Ubuntu Focal)
   Importance: Critical => Undecided

** Changed in: openssl (Ubuntu)
   Importance: Critical => Undecided

-- 
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 1940656] Re: Potential use after free bugs in 1.1.1

2021-08-20 Thread Dimitri John Ledkov
** Patch added: 
"lp-1940656-4-Prevent-use-after-free-of-global_engine_lock.patch"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+attachment/5519404/+files/lp-1940656-4-Prevent-use-after-free-of-global_engine_lock.patch

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-08-20 Thread Dimitri John Ledkov
** Patch added: "lp-1940656-3-engine-fix-double-free-on-error-path.patch"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+attachment/5519403/+files/lp-1940656-3-engine-fix-double-free-on-error-path.patch

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-08-20 Thread Dimitri John Ledkov
** Patch added: "lp-1940656-2-ts-fix-double-free-on-error-path.patch"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+attachment/5519402/+files/lp-1940656-2-ts-fix-double-free-on-error-path.patch

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-08-20 Thread Dimitri John Ledkov
** Patch added: "lp-1940656-1-srp-fix-double-free.patch"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940656/+attachment/5519401/+files/lp-1940656-1-srp-fix-double-free.patch

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

Bug description:
  [Impact]

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

  [Test Plan]

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

   * Check that all autopkgtests pass and there no regressions

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

  [Where problems could occur]

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

  [Other Info]

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

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


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


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

2021-08-20 Thread Dimitri John Ledkov
Public bug reported:

[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.

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

** Affects: openssl (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Description changed:

  [Impact]
  
-  * There have been multiple use-after-free bugs fixed in OpenSSL 1.1.1
+  * 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.1-stable and openssl-3.
+ These patches are in 1.1.1h+ and openssl-3.
  
  [Test Plan]
  
-  * The fixes were applied upstream without clear reproducers, or unit
+  * The fixes were applied upstream without clear reproducers, or unit
  tests
  
-  * Check that all autopkgtests pass and there no regressions
+  * Check that all autopkgtests pass and there no regressions
  
-  * Configure and use openssl with any engine and ensure that it
+  * 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
+  * 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.
+ 
+  * 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.

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

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

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

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 

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

2021-08-19 Thread Dimitri John Ledkov
Building test package in https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4654

But also uploaded it into focal unapproved, which is currently soft
frozen.

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

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

2021-08-19 Thread Dimitri John Ledkov
Curl bug report
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528

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

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 1940528] Re: curl 7.68 does not init OpenSSL correctly

2021-08-19 Thread Dimitri John Ledkov
** Patch added: "lp1940528-openssl-use-OPENSSL_init_ssl-with-1.1.0.patch"
   
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1940528/+attachment/5519059/+files/lp1940528-openssl-use-OPENSSL_init_ssl-with-1.1.0.patch

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

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 1940528] [NEW] curl 7.68 does not init OpenSSL correctly

2021-08-19 Thread Dimitri John Ledkov
Public bug reported:

[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

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

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

** Affects: curl (Ubuntu Focal)
 Importance: Undecided
 Status: Confirmed

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

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

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

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

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

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

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

2021-08-19 Thread Dimitri John Ledkov
Found curl missuse of openssl api; Found missing use-after-free fixes in
openssl; in addition to the pka engine fixes that are possible.

Imho all three should be fixed.

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

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 1921518] Re: OpenSSL "double free" error

2021-08-19 Thread Dimitri John Ledkov
Cannot reproduce the issue when using `openssl s_client -connect` or
when using `wget` so it is specific to curl + openssl + engine at the
moment.

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

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 1921518] Re: OpenSSL "double free" error

2021-08-18 Thread Dimitri John Ledkov
It appears that engine is destroyed multiple times.

Please see https://github.com/Mellanox/pka/pull/37 which can help to
guard against that.

Meanwhile I'm continuing to research as to why engine is destroyed
multiple times.

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

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 1921518] Re: OpenSSL "double free" error

2021-08-18 Thread Dimitri John Ledkov
** Changed in: openssl (Ubuntu)
   Importance: Undecided => Critical

** Information type changed from Private Security to Public Security

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

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 1928989] Re: expiring trust anchor compatibility issue

2021-08-18 Thread Dimitri John Ledkov
psqlodbc confuses me, as if clusters fail to create. Seems unrelated to
openssl changes.

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64 1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]


  [Where problems could occur]

   * Changes as to how the trust 

[Touch-packages] [Bug 1938588] Re: Ubuntu Server 18.04.5 install fails: TSC_DEADLINE disabled due to errata

2021-08-17 Thread Dimitri John Ledkov
inclusion of the package on the iso is one thing; it is a different
thing to build the boot initrd with microcode included. I do not believe
that d-i base installation media ever create d-i initrd with microcode
included. Thus even if package is included on the ISO it will not be
present in the d-i initrd.

Live based isos all should have microcode in the initrd they boot.

Given that the boards are buggy, it's best to download the firmware
update from your motherboard manufacturer to update the firmware & cpu
microcode of the board itself using like Freedos boot. Then from that
point on, all/any boots and installs of anything will at least have
working microcode.

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

Title:
  Ubuntu Server 18.04.5 install fails: TSC_DEADLINE disabled due to
  errata

Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Focal:
  New

Bug description:
  We have several factory-fresh Mitac industrial motherboards
  (https://www.mitacmct.com/IndustrialMotherboard_PH13FEI_PH13FEI) that
  we are unable to install Ubuntu Server 18.04.5 on.  When we boot from
  the installation media we get the following error and the installation
  hangs (see attached screenshot, I've transcribed the error below too)

  ```
  [0.00] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update 
microcode to version: 0x52 (or later)
  [0.157025] ACPI Exception: AE_BAD_PARAMETER, Could not install PciConfig 
handler for Root Bridge PCI0 (20170831/evrgnini-241)
  ```

  Googling the microcode bug, the normal advice appears to be "boot into
  an older, functioning kernel, update the `intel-microcode` package,
  and then reboot."  But in this situation there is no older kernel to
  boot into; there is no OS installed _at all_ on these boards yet.  I'm
  booting from a USB drive loaded with the latest version of Ubuntu
  Server 18.04.

  The only work-around I've found that works so far is to install Ubuntu
  Desktop 18.04, which can boot successfully on these boards, perform
  the minimal desktop installation, then use the desktop install to
  update the `intel-microcode` package, reboot, and then finally install
  Ubuntu Server.  This is obviously not convenient needing to install a
  complete desktop OS just so I can update the microcode, and then
  immediately wiping it to install what I wanted in the first place.

  I have not tried Ubuntu 20.x or 21.x; I need to use Ubuntu 18.04
  because these motherboards are being installed into robots that will
  be running ROS Melodic (ROS Noetic runs on 20.04, but these robots
  don't have Noetic support yet).

  I have tried the following to modify the Ubuntu Server ISO, without
  success:

  1- Adding the microcode to initrd
  ---

  I unpacked the contents of the Ubuntu Server ISO, decompressed
  install/initrd.gz, and used the bash script here
  https://www.kernel.org/doc/html/latest/x86/microcode.html to add the
  intel-microcode firmware to the image.  Then I recompressed initrd.gz,
  and rebuild the ISO using xorisso.  This did not have any effect:
  Ubuntu Server still encountered the same error when trying to install.

  
  2- Using initrd from Ubuntu Desktop 18.04.5
  --

  I downloaded & unpacked Ubuntu Desktop 18.04.5 and replaced Ubuntu
  Server's install/initrd.gz with Ubuntu Desktop's casper/initrd
  (updating txt.cfg and grub.cfg to load the uncompressed initrd instead
  of the .gz that Ubuntu Server normally uses).  Then I rebuilt the
  Ubuntu Server with xorisso again.

  The resulted in the system booting, but immediately dropping into an
  initramfs busybox shell, saying boot files were missing.  I assume
  this is because Ubuntu Server uses the `boot=casper` flag in order to
  boot into the live desktop session.

  
  At this point I'm running out of ideas for how to be able to make Ubuntu 
Server's installation media work with these boards.  Ubuntu Desktop has no 
problem booting on them, so it's obviously something specific to the Ubuntu 
Server image, but I'm not sure exactly what or how to fix it.

  If you need any additional information/logs/etc... please let me know
  and I'll be happy to provide them.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1938588/+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 1928989] Re: expiring trust anchor compatibility issue

2021-08-12 Thread Dimitri John Ledkov
python3.5 ADT regression is in xenial-updates regression, because the
test certificates it uses have expired.

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

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64 1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

2021-08-12 Thread Dimitri John Ledkov
Download of canonical.com with faketime 2021-10-01 also works.

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64 1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]


  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

2021-08-12 Thread Dimitri John Ledkov
ruby2.3 is not a regression on all other arches, not sure why s390x is
the only "working" arch with failing test.

retried psqlodbc

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64 1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null   100%[>]  30.21K
  --.-KB/sin 0.001s

  2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]


  [Where problems 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

2021-08-12 Thread Dimitri John Ledkov
Reproduced the bug with:

# dpkg-query -W libssl1.0.0 openssl
libssl1.0.0:amd64   1.0.2g-1ubuntu4.19
openssl 1.0.2g-1ubuntu4.19

# openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
verify depth is 1
CONNECTED(0003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) 
Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140540576667288:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

# upgrading

# dpkg-query -W libssl1.0.0 openssl
libssl1.0.0:amd64   1.0.2g-1ubuntu4.20
openssl 1.0.2g-1ubuntu4.20

# # openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
verify depth is 1
CONNECTED(0003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) 
Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot 
R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
 0 s:/CN=expired-root-ca-test.germancoding.com
   i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
 1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
 2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
---
Server certificate
-BEGIN CERTIFICATE-
MIIGgTCCBWmgAwIBAgITAPqeXD5BcpT3tXI8aoDSYano7DANBgkqhkiG9w0BAQsF



connection is successful.

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 

[Touch-packages] [Bug 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
** Patch removed: "chmod-reference.patch"
   
https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1938886/+attachment/5515876/+files/chmod-reference.patch

** Patch added: "chmod-reference.patch"
   
https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1938886/+attachment/5515888/+files/chmod-reference.patch

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  Invalid
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  Invalid
Status in debhelper package in Ubuntu:
  Triaged
Status in debugedit package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
** Patch added: "chmod-reference.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938886/+attachment/5515876/+files/chmod-reference.patch

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  Invalid
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  Invalid
Status in debhelper package in Ubuntu:
  Triaged
Status in debugedit package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
** Changed in: bash (Ubuntu)
   Status: New => Invalid

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

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

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

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

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  Invalid
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  Invalid
Status in debhelper package in Ubuntu:
  Triaged
Status in debugedit package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
Based on https://elixir.bootlin.com/linux/latest/source/fs/inode.c#L1928
it seems that setuid and capabilities will be stipped, thus currently
our implementation of dh_strip causes to loose setuid and capabilities.


No idea why this is working with fakeroot when Rules-Requires-Root is set to 
binary-targets.
And doesn't when it is set to "no".

chmod +s debian/virtualbox/usr/lib/virtualbox/VBoxSDL
ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwsr-sr-x 1 xnox xnox 166208 Aug  4 18:59 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
$ cat debian/control | grep Rules
Rules-Requires-Root: no
$ fakeroot dh_strip -pvirtualbox
$ ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwxr-xr-x 1 xnox xnox 166208 Aug  4 18:59 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

$ chmod +s debian/virtualbox/usr/lib/virtualbox/VBoxSDL
$ ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwsr-sr-x 1 xnox xnox 166208 Aug  4 18:59 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
$ sed '/Rules-Requires-Root/s/no/binary-targets/' -i debian/control 
$ cat debian/control | grep Rules
Rules-Requires-Root: binary-targets
$ fakeroot dh_strip -pvirtualbox
$ ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwxr-xr-x 1 xnox xnox 166208 Aug  4 19:01 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  New
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938938] [NEW] apparmor denials for gnutls configuration

2021-08-04 Thread Dimitri John Ledkov
Public bug reported:

gnutls library can be configured using /etc/gnutls/config for example to
allow small keys and TLS versions below v1.2

however, if application is confined and has an apparmor profile and uses
gnutls it will ignore such file, if it is not allowed to read it.

For example:

[  382.586297] audit: type=1400 audit(1628068663.214:162):
apparmor="DENIED" operation="open" profile="msmtp"
name="/etc/gnutls/config" pid=18621 comm="sendmail" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0


[25379.358122] audit: type=1400 audit(1628093660.328:163): apparmor="DENIED" 
operation="open" profile="/usr/bin/evince" name="/etc/gnutls/config" pid=53262 
comm="evince" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[25460.754092] audit: type=1400 audit(1628093741.726:164):
apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/etc/gnutls/config" pid=53347 comm="dbus" requested_mask="r"
denied_mask="r" fsuid=7 ouid=0

How can we allow to read /etc/gnutls/config for all apps that use
gnutls?

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

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

Title:
  apparmor denials for gnutls configuration

Status in apparmor package in Ubuntu:
  New

Bug description:
  gnutls library can be configured using /etc/gnutls/config for example
  to allow small keys and TLS versions below v1.2

  however, if application is confined and has an apparmor profile and
  uses gnutls it will ignore such file, if it is not allowed to read it.

  For example:

  [  382.586297] audit: type=1400 audit(1628068663.214:162):
  apparmor="DENIED" operation="open" profile="msmtp"
  name="/etc/gnutls/config" pid=18621 comm="sendmail" requested_mask="r"
  denied_mask="r" fsuid=0 ouid=0

  
  [25379.358122] audit: type=1400 audit(1628093660.328:163): apparmor="DENIED" 
operation="open" profile="/usr/bin/evince" name="/etc/gnutls/config" pid=53262 
comm="evince" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

  [25460.754092] audit: type=1400 audit(1628093741.726:164):
  apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
  name="/etc/gnutls/config" pid=53347 comm="dbus" requested_mask="r"
  denied_mask="r" fsuid=7 ouid=0

  How can we allow to read /etc/gnutls/config for all apps that use
  gnutls?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1938938/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
separately I'm not sure who/what/why stips setuid bits on file creation
through redirect.

is it like some kind of a CVE in bash/dash? kernel protection?

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  New
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
- objcopy/strip changed in 2.36.1, not keeping file attributes of the
  original file. Work around that in dh_strip to write to a temporary
  file and cat'ing this to the original file to keep the original
  attributes.

which is broken for setuid files.

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

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

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

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  New
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
dh_strip does

strip --remove-section=.comment --remove-section=.note --strip-unneeded -o 
/tmp/OdGxqpWWsW/stripeIrB_j debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so
cat '/tmp/OdGxqpWWsW/stripeIrB_j' > 
'debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so'

which behaves differently under root and non-root.

specifically `cat anything > file` will strip setuid bits from file,
irrespective of umask.

As root:
cat /dev/null > foo
chmod +s foo
ls -latr foo
-rwSr-Sr-- 1 root root 0 Aug  4 18:36 foo
cat /dev/null > foo
ls -latr foo
-rwSr-Sr-- 1 root root 0 Aug  4 18:36 foo

As mere mortal:

cat /dev/null > foo
chmod +s foo
ls -latr foo
-rwSr-Sr-- 1 xnox xnox 0 Aug  4 18:34 foo
cat /dev/null > foo
ls -latr foo
-rw-r-Sr-- 1 xnox xnox 0 Aug  4 18:34 foo

I really do not understand why mere-mortal strips user uid, keeps group
uid, and root doesn't do that.

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in bash package in Ubuntu:
  New
Status in binutils package in Ubuntu:
  New
Status in dash package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
With debugedit v5.0 things are still the same

https://launchpadlibrarian.net/551609214/buildlog_ubuntu-impish-
amd64.virtualbox_6.1.26-dfsg-2ubuntu1_BUILDING.txt.gz

the setuid bit is lost.

I guess we need to dig deeper into dh_strip activities, to see
what/where/how it is lost. Maybe it is lost before debugedit.

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in binutils package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1938886/+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 1938886] Re: rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwsr-sr-x 1 buildd buildd 406824 Aug  4 15:51 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

dh_strip --dbgsym-migration='virtualbox-dbg'

ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwxr-xr-x 1 buildd buildd 166208 Aug  4 15:52 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in binutils package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1938886/+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 1938886] [NEW] rrr:no dh_strip or strip loose setuid bit

2021-08-04 Thread Dimitri John Ledkov
Public bug reported:

Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

I have rebuilt an earlier version of virtualbox, that sets Rules-
Requires-Root: no and added extra ls statements to find where/when/why
setuid bits are getting lost after fixperms.

make[1]: Leaving directory '/<>'
   debian/rules override_dh_strip
make[1]: Entering directory '/<>'
ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
...
dh_strip --dbgsym-migration='virtualbox-dbg'
debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
a7cf3c43c8b18c3261d2d4737a475bf730ad1554

ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
-rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

It seems to me that either dh_strip or something it calls (strip,
debugedit) looses the setuid permission in hirsute and up.

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

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

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

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

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

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

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

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

Title:
  rrr:no dh_strip or strip loose setuid bit

Status in binutils package in Ubuntu:
  New
Status in debhelper package in Ubuntu:
  New
Status in debugedit package in Ubuntu:
  New
Status in virtualbox package in Ubuntu:
  New

Bug description:
  Over at https://launchpadlibrarian.net/550715513/buildlog_ubuntu-
  hirsute-amd64.virtualbox_6.1.22-dfsg-2~ubuntu1.21.04.2_BUILDING.txt.gz

  I have rebuilt an earlier version of virtualbox, that sets Rules-
  Requires-Root: no and added extra ls statements to find where/when/why
  setuid bits are getting lost after fixperms.

  make[1]: Leaving directory '/<>'
 debian/rules override_dh_strip
  make[1]: Entering directory '/<>'
  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwsr-sr-x 1 buildd buildd 406808 Jul 29 14:34 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  ...
  dh_strip --dbgsym-migration='virtualbox-dbg'
  debugedit: debian/virtualbox/usr/lib/virtualbox/VBoxSDL.so: Unknown DWARF 
DW_FORM_0x1f20
  a7cf3c43c8b18c3261d2d4737a475bf730ad1554

  ls -latr debian/virtualbox/usr/lib/virtualbox/VBoxSDL
  -rwxr-xr-x 1 buildd buildd 166208 Jul 29 14:35 
debian/virtualbox/usr/lib/virtualbox/VBoxSDL

  It seems to me that either dh_strip or something it calls (strip,
  debugedit) looses the setuid permission in hirsute and up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1938886/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting

2021-07-27 Thread Dimitri John Ledkov
But the things mentioned in systemd issue were supposedly resolved, and
https://github.com/systemd/systemd/commit/d84af414180a4a8a7dd8772fc9d5302b5f9f28c9
is in focal already.. so is there something else not working in
focal?

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

Title:
  systemd-time-wait-sync.service stuck in "activating" state after boot,
  blocks timers from starting

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

Bug description:
  [impact]

  systemd-time-wait-sync service sometimes misses sync completed event
  and remains in 'activating' state

  [test case]

  this isn't consistently reproducable, see original description for
  test case

  [regression potential]

  possible problems with the systemd-time-wait-sync service completing
  too early or not completing on time

  [scope]

  this is needed only for f

  this is fixed upstream with commit
  f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is
  fixed in h and later already

  the service does not exist in b so this does not apply there

  [original description]

  When I start my server running Ubuntu 20.04 the systemd-time-wait-
  sync.service is stuck in "activating" state. I noticed this because
  none of the systemd timer units triggered, because all the timers
  depend on systemd-time-wait-sync.service. Running "systemctl restart
  systemd-time-wait-sync.service" manually works around the problem.

  Some logs and command outputs:

  raek@mizar:~$ lsb_release -rd
  Description:Ubuntu 20.04.2 LTS
  Release:20.04

  raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service
    systemd-time-wait-sync.service  
 loaded activating start start Wait Until Kernel Time 
Synchronized

  raek@mizar:~$ systemctl status systemd-time-wait-sync.service
  ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
   Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; 
enabled; vendor preset: enabled)
   Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago
     Docs: man:systemd-time-wait-sync.service(8)
     Main PID: 514 (systemd-time-wa)
    Tasks: 1 (limit: 9415)
   Memory: 972.0K
   CGroup: /system.slice/systemd-time-wait-sync.service
   └─514 /lib/systemd/systemd-time-wait-sync

  Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 
time Thu 2021-07-22 09:06:52.216338 UTC
  Warning: journal has been rotated since unit was started, output may be 
incomplete.

  raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service
  -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 
CEST. --
  Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 
time Thu 2021-07-22 09:06:52.216338 UTC

  raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service
  systemd: /lib/systemd/system/systemd-time-wait-sync.service

  raek@mizar:~$ apt-cache policy systemd
  systemd:
    Installed: 245.4-4ubuntu3.11
    Candidate: 245.4-4ubuntu3.11
    Version table:
   *** 245.4-4ubuntu3.11 500
  500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3.10 500
  500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
   245.4-4ubuntu3.8 400
  400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
   245.4-4ubuntu3 500
  500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one

2021-07-23 Thread Dimitri John Ledkov
I am quite surprised by this behaviour.

Especially since, `quilt push -a; debuild -S` works find, unpacks fine,
applies fine etc.

Quite a weird limitation imho. Do you think this warrants an upstream
dpkg bug report?

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

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

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

Bug description:
  [impact]

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

  [test case]

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

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

  Test builds are available in the following ppa:

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

  [regression potential]

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

  [scope]

  this is needed only for g and later

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

  [other info]

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

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


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


[Touch-packages] [Bug 1936948] Re: Dependency loop via sockets.target

2021-07-20 Thread Dimitri John Ledkov
i.e. basic.target is too much there.

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

Title:
  Dependency loop via sockets.target

Status in dbus package in Ubuntu:
  New

Bug description:
  basic.target waits for dbus.socket (via sockets.target) AND
  dbus.socket waits for basic.target, too, delaying dbus-daemon startup.
  At some point a timeout happens, dbus is started and all queued
  services try to start registering to the bus at the same time.

  All services registering at the same time, seems to be triggering bugs
  like this more often:
  https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538/

  This happens since Hirsute (dbus 1.12.20-1ubuntu3), where the
  following delta was added:

  Index: dbus-1.12.20/bus/dbus.socket.in
  ===
  --- dbus-1.12.20.orig/bus/dbus.socket.in
  +++ dbus-1.12.20/bus/dbus.socket.in
  @@ -1,5 +1,9 @@
   [Unit]
   Description=D-Bus System Message Bus Socket
  +# Do not stop on shutdown
  +DefaultDependencies=no
  +Wants=sysinit.target
  +After=sysinit.target basic.target

   [Socket]
   ListenStream=@DBUS_SYSTEM_SOCKET@

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1936948/+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 1936948] Re: Dependency loop via sockets.target

2021-07-20 Thread Dimitri John Ledkov
What the patch was supposed to do is to list

Default Dependencies from
https://www.freedesktop.org/software/systemd/man/systemd.socket.html#

But drop/negate shutdown related ones.

Thus it should have been

1) Before= dependency on sockets.target
2) After= and Wants= dependency on sysinit.target

Requires=sysinit.target is downgraded to Wants to prevent attempting to
stop dbus.service on shutdown.

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

Title:
  Dependency loop via sockets.target

Status in dbus package in Ubuntu:
  New

Bug description:
  basic.target waits for dbus.socket (via sockets.target) AND
  dbus.socket waits for basic.target, too, delaying dbus-daemon startup.
  At some point a timeout happens, dbus is started and all queued
  services try to start registering to the bus at the same time.

  All services registering at the same time, seems to be triggering bugs
  like this more often:
  https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1871538/

  This happens since Hirsute (dbus 1.12.20-1ubuntu3), where the
  following delta was added:

  Index: dbus-1.12.20/bus/dbus.socket.in
  ===
  --- dbus-1.12.20.orig/bus/dbus.socket.in
  +++ dbus-1.12.20/bus/dbus.socket.in
  @@ -1,5 +1,9 @@
   [Unit]
   Description=D-Bus System Message Bus Socket
  +# Do not stop on shutdown
  +DefaultDependencies=no
  +Wants=sysinit.target
  +After=sysinit.target basic.target

   [Socket]
   ListenStream=@DBUS_SYSTEM_SOCKET@

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1936948/+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 1934936] Re: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is dif

2021-07-20 Thread Dimitri John Ledkov
** Changed in: heimdal (Ubuntu)
   Status: Confirmed => In Progress

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

Title:
  package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade:
  trying to overwrite shared
  '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is
  different from other instances of package libwind0-heimdal:i386

Status in heimdal package in Ubuntu:
  In Progress

Bug description:
  fresh 21.10 install and 1 reboot later it said there was additional
  updates and while doing so the error popped up

  ProblemType: Package
  DistroRelease: Ubuntu 21.10
  Package: libwind0-heimdal 7.7.0+dfsg-2build1
  ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21
  Uname: Linux 5.11.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul  8 01:45:16 2021
  DuplicateSignature:
   package:libwind0-heimdal:7.7.0+dfsg-2build1
   Unpacking libwind0-heimdal:i386 (7.7.0+dfsg-2build1) over (7.7.0+dfsg-2) ...
   dpkg: error processing archive 
/tmp/apt-dpkg-install-8FDC3J/53-libwind0-heimdal_7.7.0+dfsg-2build1_i386.deb 
(--unpack):
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  ErrorMessage: trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  InstallationDate: Installed on 2021-06-05 (32 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  Python3Details: /usr/bin/python3.9, Python 3.9.6, python3-minimal, 3.9.4-1
  PythonDetails: N/A
  RebootRequiredPkgs:
   libc6
   libc6
  RelatedPackageVersions:
   dpkg 1.20.9ubuntu2
   apt  2.3.6
  SourcePackage: heimdal
  Title: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: 
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  UpgradeStatus: Upgraded to impish on 2021-07-07 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1934936/+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 1934936] Re: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is dif

2021-07-16 Thread Dimitri John Ledkov
In i386 build log I see

Searching for duplicated docs in dependency libroken18-heimdal...
  symlinking changelog.Debian.gz in libwind0-heimdal to file in 
libroken18-heimdal

I don't see something similar in adm64.

As if the trimming of the changelog entries got done before doing
symlinks, instead of after.

I would have hoped that all packages are processed and things got
symlinked first, then trimmed, in the same way on every arch.

Lots of sadness.

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

Title:
  package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade:
  trying to overwrite shared
  '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is
  different from other instances of package libwind0-heimdal:i386

Status in heimdal package in Ubuntu:
  Confirmed

Bug description:
  fresh 21.10 install and 1 reboot later it said there was additional
  updates and while doing so the error popped up

  ProblemType: Package
  DistroRelease: Ubuntu 21.10
  Package: libwind0-heimdal 7.7.0+dfsg-2build1
  ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21
  Uname: Linux 5.11.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul  8 01:45:16 2021
  DuplicateSignature:
   package:libwind0-heimdal:7.7.0+dfsg-2build1
   Unpacking libwind0-heimdal:i386 (7.7.0+dfsg-2build1) over (7.7.0+dfsg-2) ...
   dpkg: error processing archive 
/tmp/apt-dpkg-install-8FDC3J/53-libwind0-heimdal_7.7.0+dfsg-2build1_i386.deb 
(--unpack):
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  ErrorMessage: trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  InstallationDate: Installed on 2021-06-05 (32 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  Python3Details: /usr/bin/python3.9, Python 3.9.6, python3-minimal, 3.9.4-1
  PythonDetails: N/A
  RebootRequiredPkgs:
   libc6
   libc6
  RelatedPackageVersions:
   dpkg 1.20.9ubuntu2
   apt  2.3.6
  SourcePackage: heimdal
  Title: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: 
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  UpgradeStatus: Upgraded to impish on 2021-07-07 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1934936/+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 1934936] Re: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is dif

2021-07-16 Thread Dimitri John Ledkov
Is this debhelper or binary-package-mangler bug then?

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

Title:
  package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade:
  trying to overwrite shared
  '/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is
  different from other instances of package libwind0-heimdal:i386

Status in heimdal package in Ubuntu:
  Confirmed

Bug description:
  fresh 21.10 install and 1 reboot later it said there was additional
  updates and while doing so the error popped up

  ProblemType: Package
  DistroRelease: Ubuntu 21.10
  Package: libwind0-heimdal 7.7.0+dfsg-2build1
  ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21
  Uname: Linux 5.11.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Thu Jul  8 01:45:16 2021
  DuplicateSignature:
   package:libwind0-heimdal:7.7.0+dfsg-2build1
   Unpacking libwind0-heimdal:i386 (7.7.0+dfsg-2build1) over (7.7.0+dfsg-2) ...
   dpkg: error processing archive 
/tmp/apt-dpkg-install-8FDC3J/53-libwind0-heimdal_7.7.0+dfsg-2build1_i386.deb 
(--unpack):
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  ErrorMessage: trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  InstallationDate: Installed on 2021-06-05 (32 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  Python3Details: /usr/bin/python3.9, Python 3.9.6, python3-minimal, 3.9.4-1
  PythonDetails: N/A
  RebootRequiredPkgs:
   libc6
   libc6
  RelatedPackageVersions:
   dpkg 1.20.9ubuntu2
   apt  2.3.6
  SourcePackage: heimdal
  Title: package libwind0-heimdal 7.7.0+dfsg-2build1 failed to install/upgrade: 
trying to overwrite shared 
'/usr/share/doc/libwind0-heimdal/changelog.Debian.gz', which is different from 
other instances of package libwind0-heimdal:i386
  UpgradeStatus: Upgraded to impish on 2021-07-07 (0 days ago)

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


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


[Touch-packages] [Bug 1929854] Re: Vital and critical configuration files get overridden by system updates without warning

2021-07-15 Thread Dimitri John Ledkov
sshd_config is user modifyable and maintained. Some options can be
changed using dpkg-reconfigure openssh-server but otherwise changes to
it should be preserved.

Can you please provide steps to reproduce changes to sshd_config getting
lost?

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

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

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

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

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

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

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

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

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

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
  Uname: Linux 5.8.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Thu May 27 18:48:15 2021
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
  InstallationDate: Installed on 2021-01-15 (132 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  MachineType: LENOVO 20QQS0KL13
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-53-generic 
root=UUID=35cef147-e021-4bdd-b8db-31a3192c8a6a ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/04/2020
  dmi.bios.release: 1.23
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2NET38W (1.23 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20QQS0KL13
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: ZF211710
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.14
  dmi.modalias: 

[Touch-packages] [Bug 1929854] Re: Vital and critical configuration files get overridden by system updates without warning

2021-07-15 Thread Dimitri John Ledkov
/boot/grub/grub.cfg is a generated file that must not be modified by
hand. Instead one is supposed to modify things like /etc/default/grub
/etc/default/grub.d/* /etc/grub.d/*

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

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

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

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

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

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

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

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

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

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

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
  Uname: Linux 5.8.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.7
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Thu May 27 18:48:15 2021
  DistUpgraded: Fresh install
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) 
(prog-if 00 [VGA controller])
 Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
  InstallationDate: Installed on 2021-01-15 (132 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  MachineType: LENOVO 20QQS0KL13
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-53-generic 
root=UUID=35cef147-e021-4bdd-b8db-31a3192c8a6a ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/04/2020
  dmi.bios.release: 1.23
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N2NET38W (1.23 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20QQS0KL13
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: ZF211710
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.14
  dmi.modalias: 

[Touch-packages] [Bug 1932542] Re: Add support for zstd

2021-07-15 Thread Dimitri John Ledkov
(bionic-amd64)root@ottawa:/tmp# dpkg-query -W initramfs-tools liblz4-tool zstd
initramfs-tools 0.130ubuntu3.13
liblz4-tool 0.0~r131-2ubuntu3.1
zstd1.3.3+dfsg-2ubuntu1.2

(bionic-amd64)root@ottawa:/tmp# mkinitramfs -c zstd -o zstd-initrd.img 
4.15.0-150-generic
(bionic-amd64)root@ottawa:/tmp# mkinitramfs -c lz4 -o lz4-initrd.img 
4.15.0-150-generic
(bionic-amd64)root@ottawa:/tmp# unmkinitramfs ./zstd-initrd.img zstd-unpacked
(bionic-amd64)root@ottawa:/tmp# unmkinitramfs ./lz4-initrd.img lz4-unpacked  
(bionic-amd64)root@ottawa:/tmp# ls zstd-unpacked/
bin  conf  etc  init  lib  lib64  run  sbin  scripts
(bionic-amd64)root@ottawa:/tmp# ls lz4-unpacked/
bin  conf  etc  init  lib  lib64  run  sbin  scripts

(bionic-amd64)root@ottawa:/tmp# file zstd-initrd.img 
zstd-initrd.img: Zstandard compressed data (v0.8+), Dictionary ID: None
(bionic-amd64)root@ottawa:/tmp# file lz4-initrd.img 
lz4-initrd.img: LZ4 compressed data (v0.1-v0.9)

All is good.

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

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

Title:
  Add support for zstd

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Committed
Status in initramfs-tools source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * initramfs-tools in impish has changed default initrd compression to
  zstd. To allow compressing and uncompressing such initrds on Focal LTS
  release we should backport zstd support in the mkinitramfs &
  unmkinitramffs tooling. For example ubuntu-cdimage uses unmkinitramfs
  tool to unpack and inspect impish initrds on a focal host.

   * Cherrypicking the feature from 0.138 release, which is also present
  in Hirsute and Impish.

  [Test Plan]

   * Create initrd with zstd $ mkinitramfs -c zstd -o zstd-initrd.img

   * Uncompress it with $ unmkinitramfs ./zstd-initrd.img zstd-initrd-
  unpacked

   * For bionic also repeat the same with lz4.

  [Where problems could occur]

   * This adds support for zstd compressed initrd in both mkinitramfs
  and unmkinitramfs. However our GA kernels do not support zstd
  compressed initrds. And depends on zstd package is not added either.
  Meaning one still has to install zstd to gain the unpack support.
  Changing initramfs.conf to zstd may result in unbootable instance when
  used with GA kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932542/+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 1928989] Re: expiring trust anchor compatibility issue

2021-07-13 Thread Dimitri John Ledkov
** Description changed:

  [Impact]
  
   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.
  
  [Test Plan]
  
   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  
   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  
   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com
  
  setup:
  
  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem
  
  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
  
  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
  
  good result:
  connection successful
  
  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  
  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.
  
+ [Testcase #2]
+ 
+ $ sudo apt install ca-certificates wget faketime
+ 
+ # Good connectivity
+ $ wget -O /dev/null https://canonical.com
+ --2021-07-13 11:54:20--  https://canonical.com/
+ Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
+ Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
+ HTTP request sent, awaiting response... 200 OK
+ Length: 30933 (30K) [text/html]
+ Saving to: '/dev/null'
+ 
+ /dev/null   100%[>]  30.21K
+ --.-KB/sin 0.001s
+ 
+ 2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]
+ 
+ # Jump to october to experience failure
+ $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
+ --2021-10-01 00:00:00--  https://canonical.com/
+ Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
+ Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
+ ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
+   Issued certificate has expired.
+ To connect to canonical.com insecurely, use `--no-check-certificate'.
+ 
+ # upgrade to new openssl, to see that connectivity is restored, even in 
october
+ $ dpkg-query -W libssl1.0.0
+ libssl1.0.0:amd64 1.0.2g-1ubuntu4.20
+ 
+ $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
+ --2021-10-01 00:00:00--  https://canonical.com/
+ Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
+ Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
+ HTTP request sent, awaiting response... 200 OK
+ Length: 30933 (30K) [text/html]
+ Saving to: '/dev/null'
+ 
+ /dev/null   100%[>]  30.21K
+ --.-KB/sin 0.001s
+ 
+ 2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]
+ 
+ 
  [Where problems could occur]
  
   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).
  
  [Other Info]
  
   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

2021-07-09 Thread Dimitri John Ledkov
PPA with these changes available from https://launchpad.net/~ci-train-
ppa-service/+archive/ubuntu/4594

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+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 1928989] Re: expiring trust anchor compatibility issue

2021-07-09 Thread Dimitri John Ledkov
ADT results at https://bileto.ubuntu.com/excuses/4594/xenial.html

** Description changed:

  [Impact]
  
   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.
  
  [Test Plan]
  
   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  
   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  
   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com
  
  setup:
  
  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem
  
  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
  
  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
  
  good result:
  connection successful
  
  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  
  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.
  
  [Where problems could occur]
  
   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).
  
  [Other Info]
  
   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.
  
  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817
  
  Currently openssl in xenial and earlier will not establish a connection,
  if any parts of the trust chain have expired, even though alternative
  non-expired chains are available.
  
  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
  
+ Note only the new default flag is backported on its own. The other
+ changes to more strongly verify additional auxiliary trust OIDs and key
+ usage are not backported.
+ 
  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates 

[Touch-packages] [Bug 1928989] Re: expiring trust anchor compatibility issue

2021-07-09 Thread Dimitri John Ledkov
python3.5 has stopped passing its testsuite due to expried test certs.
Thus upload of openssl has triggered regression in python3.5

I've cherrypicked updated test certs and keys, but to cherry-pick those
cleanly, I also had to cherrypick an earlier bug fix. All of these are
unmodified from 3.5.10 release. With these patches in place python3.5
testsuite passes with both current and proposed update of openssl.

** Patch added: "xenial_python3.5_content.diff"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+attachment/5510069/+files/xenial_python3.5_content.diff

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

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Confirmed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this 

[Touch-packages] [Bug 1923845] Re: Please compress packages with zstd by default

2021-07-05 Thread Dimitri John Ledkov
@ubuntu-sru-bot

regressions triggered by reprepro have been retried, and have been now
cleared.

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

Title:
  Please compress packages with zstd by default

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

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

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

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

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

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

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

[Touch-packages] [Bug 1923845] Re: Please compress packages with zstd by default

2021-07-05 Thread Dimitri John Ledkov
See reprepro verification comments at
https://bugs.launchpad.net/ubuntu/+source/reprepro/+bug/1933363

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

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

Title:
  Please compress packages with zstd by default

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

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

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

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

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

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

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

[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-07-05 Thread Dimitri John Ledkov
@superm1 yes I have, it is now pulled into v5.14
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c484419efc09e7234c667aa72698cb79ba8d8ed

I will request it to be included in linux-stable series.

Note that in Impish we have now switched to zstd compression for the
initramfs, as it has even better bootspeed performance.

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

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+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 1932542] Re: Add support for zstd

2021-07-01 Thread Dimitri John Ledkov
Uploading to ubuntu (via sftp to upload.ubuntu.com):
  Uploading initramfs-tools_0.130ubuntu3.13.dsc: done.
  Uploading initramfs-tools_0.130ubuntu3.13.tar.xz: done.
  Uploading initramfs-tools_0.130ubuntu3.13_source.buildinfo: done.
  Uploading initramfs-tools_0.130ubuntu3.13_source.changes: done.
Successfully uploaded packages

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => In Progress

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

Title:
  Add support for zstd

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * initramfs-tools in impish has changed default initrd compression to
  zstd. To allow compressing and uncompressing such initrds on Focal LTS
  release we should backport zstd support in the mkinitramfs &
  unmkinitramffs tooling. For example ubuntu-cdimage uses unmkinitramfs
  tool to unpack and inspect impish initrds on a focal host.

   * Cherrypicking the feature from 0.138 release, which is also present
  in Hirsute and Impish.

  [Test Plan]

   * Create initrd with zstd $ mkinitramfs -c zstd -o zstd-initrd.img

   * Uncompress it with $ unmkinitramfs ./zstd-initrd.img zstd-initrd-
  unpacked

   * For bionic also repeat the same with lz4.

  [Where problems could occur]

   * This adds support for zstd compressed initrd in both mkinitramfs
  and unmkinitramfs. However our GA kernels do not support zstd
  compressed initrds. And depends on zstd package is not added either.
  Meaning one still has to install zstd to gain the unpack support.
  Changing initramfs.conf to zstd may result in unbootable instance when
  used with GA kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932542/+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 1932542] Re: Add support for zstd

2021-07-01 Thread Dimitri John Ledkov
** Description changed:

  [Impact]
  
   * initramfs-tools in impish has changed default initrd compression to
  zstd. To allow compressing and uncompressing such initrds on Focal LTS
  release we should backport zstd support in the mkinitramfs &
  unmkinitramffs tooling. For example ubuntu-cdimage uses unmkinitramfs
  tool to unpack and inspect impish initrds on a focal host.
  
-  * Cherrypicking the feature from 0.138 release, which is also present
+  * Cherrypicking the feature from 0.138 release, which is also present
  in Hirsute and Impish.
  
  [Test Plan]
  
   * Create initrd with zstd $ mkinitramfs -c zstd -o zstd-initrd.img
  
   * Uncompress it with $ unmkinitramfs ./zstd-initrd.img zstd-initrd-
  unpacked
  
+  * For bionic also repeat the same with lz4.
+ 
  [Where problems could occur]
  
   * This adds support for zstd compressed initrd in both mkinitramfs and
  unmkinitramfs. However our GA kernels do not support zstd compressed
  initrds. And depends on zstd package is not added either. Meaning one
  still has to install zstd to gain the unpack support. Changing
  initramfs.conf to zstd may result in unbootable instance when used with
  GA kernel.

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

Title:
  Add support for zstd

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  New
Status in initramfs-tools source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * initramfs-tools in impish has changed default initrd compression to
  zstd. To allow compressing and uncompressing such initrds on Focal LTS
  release we should backport zstd support in the mkinitramfs &
  unmkinitramffs tooling. For example ubuntu-cdimage uses unmkinitramfs
  tool to unpack and inspect impish initrds on a focal host.

   * Cherrypicking the feature from 0.138 release, which is also present
  in Hirsute and Impish.

  [Test Plan]

   * Create initrd with zstd $ mkinitramfs -c zstd -o zstd-initrd.img

   * Uncompress it with $ unmkinitramfs ./zstd-initrd.img zstd-initrd-
  unpacked

   * For bionic also repeat the same with lz4.

  [Where problems could occur]

   * This adds support for zstd compressed initrd in both mkinitramfs
  and unmkinitramfs. However our GA kernels do not support zstd
  compressed initrds. And depends on zstd package is not added either.
  Meaning one still has to install zstd to gain the unpack support.
  Changing initramfs.conf to zstd may result in unbootable instance when
  used with GA kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932542/+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 1928989] Re: expiring trust anchor compatibility issue

2021-06-28 Thread Dimitri John Ledkov
** Patch added: "lp1928989.patch"
   
https://bugs.launchpad.net/ubuntu/xenial/+source/openssl/+bug/1928989/+attachment/5507665/+files/lp1928989.patch

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

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  New

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(0003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(0003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -BEGIN CERTIFICATE-

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+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 1928989] Re: expiring trust anchor compatibility issue

2021-06-28 Thread Dimitri John Ledkov
** Description changed:

  [Impact]
  
-  * openssl fails to talk to letsencrypt website past September 2021,
+  * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.
  
  [Test Plan]
  
-  * Import staging cert equivalent to ISRG Root X1
+  * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  
-  * Import expired staging cert equivalen tto DST Root CA X3
+  * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  
-  * Test connectivity to the expired-root-ca test website
+  * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com
  
  setup:
  
  apt install openssl
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem
  
  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
  
  bad result:
  connection failed
+ verify depth is 1
+ CONNECTED(0003)
+ depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
+ verify error:num=10:certificate has expired
+ notAfter=Jan 30 14:01:15 2021 GMT
+ 140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
+ 
  
  good result:
  connection successful
+ 
+ verify depth is 1
+ CONNECTED(0003)
+ depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
+ verify return:1
+ depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
+ verify return:1
+ depth=0 CN = expired-root-ca-test.germancoding.com
+ verify return:1
+ ---
+ Certificate chain
+  0 s:/CN=expired-root-ca-test.germancoding.com
+i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
+  1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
+i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
+  2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
+i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
+ ---
+ Server certificate
+ -BEGIN CERTIFICATE-
+ 
  
  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.
  
  [Where problems could occur]
  
-  * Changes as to how the trust paths are built in TLS connection may
+  * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).
  
  [Other Info]
  
-  * Background info
-  * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.
+  * Background info
+  * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.
  
  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817
  
  Currently openssl in xenial and earlier will not establish a connection,
  if any parts of the trust chain have expired, even though alternative
  non-expired chains are available.
  
  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
  
  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

** Description changed:

  [Impact]
  
   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.
  
  [Test Plan]
  
   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  
   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  
   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com
  
  setup:
  
- apt install openssl
+ apt install openssl 

[Touch-packages] [Bug 1932542] Re: Add support for zstd

2021-06-25 Thread Dimitri John Ledkov
** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

Title:
  Add support for zstd

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  New
Status in initramfs-tools source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * initramfs-tools in impish has changed default initrd compression to
  zstd. To allow compressing and uncompressing such initrds on Focal LTS
  release we should backport zstd support in the mkinitramfs &
  unmkinitramffs tooling. For example ubuntu-cdimage uses unmkinitramfs
  tool to unpack and inspect impish initrds on a focal host.

   * Cherrypicking the feature from 0.138 release, which is also present
  in Hirsute and Impish.

  [Test Plan]

   * Create initrd with zstd $ mkinitramfs -c zstd -o zstd-initrd.img

   * Uncompress it with $ unmkinitramfs ./zstd-initrd.img zstd-initrd-
  unpacked

  [Where problems could occur]

   * This adds support for zstd compressed initrd in both mkinitramfs
  and unmkinitramfs. However our GA kernels do not support zstd
  compressed initrds. And depends on zstd package is not added either.
  Meaning one still has to install zstd to gain the unpack support.
  Changing initramfs.conf to zstd may result in unbootable instance when
  used with GA kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932542/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method

2021-06-24 Thread Dimitri John Ledkov
@cborntra

v5.13 ubuntu kernel's s390 configuration with zstd -22 --ultra
compression is 8.5 MB, whereas gzip -9 is 11M.

Thus for gzip to win at bootspeed the decompression speed has to
compensate for 2.5M of i/o and be faster than zstd.

Unaccelerated decompression comparison still gives me faster
decompression with less i/o with zstd compressed kernel image.

At Canonical we still do not have z15 mainframe available for us to
benchmark this.

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

Title:
  initramfs-tools & kernel: use zstd as the default compression method

Status in Ubuntu on IBM z Systems:
  New
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  New

Bug description:
  Turns out that loading is always the slow part in loading initramfs
  into memory and decompressing it since decompression is always the
  final 10-20% or so of the task.  It therefore makes sense to use a
  good compressor that shrinks the initramfs as much as possible with
  little decompression overhead.

  Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in
  decompression, the image size is much smaller with zstd than lz4, and
  since ~80-90% of the boot time is loading the image it makes sense to
  use zstd.

  Attached is a libreoffice spread sheet showing typical load and
  decompression times for a fairly standard 3.4 GHZ intel box with data
  for load times for a 5400 RPM, 7200 RPM and SATA SSD drives.

  The conclusions from the test results (attached) show:

  1. Loading time is always significantly slower than decompression time.
  2. ZSTD is 5x slower than LZ4 in decompression speed but produces far
  better compressed images
  3. Given that loading time is the major factor in loading +
  decompression, ZSTD is best for kernel and initramfs boot timings.

  (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3
  /kernel-compression-method.txt for some raw data on drive load speeds
  for the same UEFI box I did a couple of years ago).

  amd64 supports zstd, but s390x does not. Will use this bug to enable
  zstd support on s390x.

  Upstream submitted patch
  
https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931725/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method

2021-06-24 Thread Dimitri John Ledkov
decompression speed only needs to be faster than i/o speed, once that is
reached the best compression ratio results in the fastest bootspped.

for kernel image zstd is used with -22 --ultra, thus I can compare it
with zlib -9.

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

Title:
  initramfs-tools & kernel: use zstd as the default compression method

Status in Ubuntu on IBM z Systems:
  New
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  New

Bug description:
  Turns out that loading is always the slow part in loading initramfs
  into memory and decompressing it since decompression is always the
  final 10-20% or so of the task.  It therefore makes sense to use a
  good compressor that shrinks the initramfs as much as possible with
  little decompression overhead.

  Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in
  decompression, the image size is much smaller with zstd than lz4, and
  since ~80-90% of the boot time is loading the image it makes sense to
  use zstd.

  Attached is a libreoffice spread sheet showing typical load and
  decompression times for a fairly standard 3.4 GHZ intel box with data
  for load times for a 5400 RPM, 7200 RPM and SATA SSD drives.

  The conclusions from the test results (attached) show:

  1. Loading time is always significantly slower than decompression time.
  2. ZSTD is 5x slower than LZ4 in decompression speed but produces far
  better compressed images
  3. Given that loading time is the major factor in loading +
  decompression, ZSTD is best for kernel and initramfs boot timings.

  (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3
  /kernel-compression-method.txt for some raw data on drive load speeds
  for the same UEFI box I did a couple of years ago).

  amd64 supports zstd, but s390x does not. Will use this bug to enable
  zstd support on s390x.

  Upstream submitted patch
  
https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931725/+subscriptions

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


  1   2   3   4   5   6   7   8   9   10   >