[Touch-packages] [Bug 1597017] Re: mount rules grant excessive permissions

2024-03-29 Thread Steve Beattie
** Description changed:

+ SRU Team; the packages for focal-proposed and jammy-proposed are
+ intended as security updates prepared by the Ubuntu Security team (and
+ have built in a ppa with only the security pockets enabled). However,
+ because the fix makes mount rules in apparmor policy be treated more
+ restrictively than they were prior to this update, we would like these
+ packages to gain more widespread testing.
+ 
+ Risk of Regression:
+ 
+ The update for this issue causes the apparmor parser, the tool that
+ translates written policy into the enforcement data structures used by
+ the kernel, to generate more strict policy for mount rules, like the
+ example below. They are not common in apparmor policy generally, but can
+ appear in policies written for container managers to restrict
+ containers, and thus can potentially break container startup.
+ 
+ The packages prepared for focal-proposed and jammy-proposed have tested
+ with the versions of snapd, lxc, libvirt, and docker in the ubuntu
+ archive, but conainter managers outside of the ubunty archive may run
+ into issues, hence the need for testing and policy adjustments.
+ 
+ Original Report:
+ 
  The rule
-   mount options=(rw,make-slave) -> **,
+   mount options=(rw,make-slave) -> **,
  
  ends up allowing
-   mount -t proc proc /mnt
+   mount -t proc proc /mnt
  
  which it shouldn't as it should be restricted to commands with a make-
  slave flag

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

Title:
  mount rules grant excessive permissions

Status in AppArmor:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  In Progress
Status in apparmor source package in Jammy:
  In Progress

Bug description:
  SRU Team; the packages for focal-proposed and jammy-proposed are
  intended as security updates prepared by the Ubuntu Security team (and
  have built in a ppa with only the security pockets enabled). However,
  because the fix makes mount rules in apparmor policy be treated more
  restrictively than they were prior to this update, we would like these
  packages to gain more widespread testing.

  Risk of Regression:

  The update for this issue causes the apparmor parser, the tool that
  translates written policy into the enforcement data structures used by
  the kernel, to generate more strict policy for mount rules, like the
  example below. They are not common in apparmor policy generally, but
  can appear in policies written for container managers to restrict
  containers, and thus can potentially break container startup.

  The packages prepared for focal-proposed and jammy-proposed have
  tested with the versions of snapd, lxc, libvirt, and docker in the
  ubuntu archive, but conainter managers outside of the ubunty archive
  may run into issues, hence the need for testing and policy
  adjustments.

  Original Report:

  The rule
    mount options=(rw,make-slave) -> **,

  ends up allowing
    mount -t proc proc /mnt

  which it shouldn't as it should be restricted to commands with a make-
  slave flag

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


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


[Touch-packages] [Bug 1597017] Re: mount rules grant excessive permissions

2024-03-06 Thread Steve Beattie
** Also affects: apparmor (Ubuntu)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

Title:
  mount rules grant excessive permissions

Status in AppArmor:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  In Progress
Status in apparmor source package in Jammy:
  In Progress

Bug description:
  The rule
mount options=(rw,make-slave) -> **,

  ends up allowing
mount -t proc proc /mnt

  which it shouldn't as it should be restricted to commands with a make-
  slave flag

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


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


[Touch-packages] [Bug 2004101] Re: package libsasl2-2:amd64 2.1.27+dfsg2-3ubuntu1.1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting c

2023-02-08 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

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

Status in cyrus-sasl2 package in Ubuntu:
  New

Bug description:
  IDK

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/2004101/+subscriptions


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


[Touch-packages] [Bug 2000359] Re: posix_ipc in test_regression_testsuite from ubuntu_qrt_apparmor failed on K-5.19 arm64 (Unable to run test sub-executable)

2023-01-03 Thread Steve Beattie
This has been fixed in the regression tests in the upstream AppArmor
project, and that patch has been incorporated into the lp:qa-regression-
testing script for apparmor (thanks Georgia!), so tests for the kernel
should not fail in this way now.

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

Title:
  posix_ipc in test_regression_testsuite from ubuntu_qrt_apparmor failed
  on K-5.19 arm64 (Unable to run test sub-executable)

Status in ubuntu-kernel-tests:
  New
Status in apparmor package in Ubuntu:
  New
Status in apparmor source package in Kinetic:
  New

Bug description:
  Issue found on Kinetic 5.19 ARM64 systems,

  The ApparmorTestsuites.test_regression_testsuite in
  ubuntu_qrt_apparmor will fail with posix_ipc test:

  running posix_ipc
  Fatal Error (posix_mq_rcv): Unable to run test sub-executable

  It's a bit hard to find which one is failing, here is the test output
  of ApparmorTestsuites.test_regression_testsuite:

  == BEGIN OF TEST OUPTUT ==
  running aa_exec

  running access
  xfail: ACCESS file rx (r)
  xfail: ACCESS file rwx (r)
  xfail: ACCESS file r (wx)
  xfail: ACCESS file rx (wx)
  xfail: ACCESS file rwx (wx)
  xfail: ACCESS dir rwx (r)
  xfail: ACCESS dir r (wx)
  xfail: ACCESS dir rx (wx)
  xfail: ACCESS dir rwx (wx)

  running at_secure

  running introspect

  running capabilities
  (ptrace)
  (sethostname)
  (setdomainname)
  (setpriority)
  (setscheduler)
  (reboot)
  (chroot)
  (mlockall)
  (net_raw)

  running changeprofile

  running onexec

  running changehat

  running changehat_fork

  running changehat_misc

  *** A 'Killed' message from bash is expected for the following test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309514 Killed  $testexec "$@" > $outfile 2>&1

  *** A 'Killed' message from bash is expected for the following test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309547 Killed  $testexec "$@" > $outfile 2>&1

  running chdir

  running clone

  running coredump
  *** A 'Segmentation Fault' message from bash is expected for the following 
test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309797 Segmentation fault  (core dumped) $testexec "$@" > 
$outfile 2>&1

  *** A 'Segmentation Fault' message from bash is expected for the following 
test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309826 Segmentation fault  $testexec "$@" > $outfile 2>&1

  *** A 'Segmentation Fault' message from bash is expected for the following 
test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309861 Segmentation fault  $testexec "$@" > $outfile 2>&1

  *** A 'Segmentation Fault' message from bash is expected for the following 
test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309896 Segmentation fault  $testexec "$@" > $outfile 2>&1

  *** A 'Segmentation Fault' message from bash is expected for the following 
test
  
/tmp/testlibxbcgpuwp/source/kinetic/apparmor-3.0.7/tests/regression/apparmor/prologue.inc:
 line 264: 309931 Segmentation fault  $testexec "$@" > $outfile 2>&1
  XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement)

  running deleted

  running environ

  running exec

  running exec_qual

  running fchdir

  running fd_inheritance

  running fork

  running i18n

  running link

  running link_subset

  running mkdir

  running mmap

  running mount
  using mount rules ...

  running mult_mount

  running named_pipe

  running namespaces

  running net_raw

  running open

  running openat

  running pipe

  running pivot_root
   kernel does not support pivot_root domain transitions - skipping tests ...

  running posix_ipc
  Fatal Error (posix_mq_rcv): Unable to run test sub-executable

  running ptrace
     using ptrace v6 tests ...

  running pwrite

  running query_label

  running regex

  running rename

  running readdir

  running rw

  running socketpair

  running swap

  running sd_flags

  running setattr

  running symlink

  running syscall
   WARNING: syscall sysctl not supported by kernel headers, skipping tests ...

  running sysv_ipc
  Required feature 'ipc/sysv_mqueue' not available.. Skipping tests ...

  running tcp

  running unix_fd_server

  running unix_socket_pathname
  xpass: AF_UNIX pathname socket (dgram); confined server w/ access (rw)
  xpass: AF_UNIX pathname socket (dgram); confined client w/ access (rw)

  running unix_socket_abstract

  running unix_socket_unnamed
  xpass: AF_UNIX unnamed 

[Touch-packages] [Bug 1998321] Re: tzdata 2022g release

2022-12-01 Thread Steve Beattie
Ack from the Ubuntu Security team for these updates to go to the
security pocket as well, as per
https://wiki.ubuntu.com/StableReleaseUpdates#tzdata .

Thanks.

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

Title:
  tzdata 2022g release

Status in tzdata package in Ubuntu:
  New
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed

Bug description:
  The 2022g release contains the following changes:

  * The northern edge of Chihuahua changes to US timekeeping.
  * Much of Greenland stops changing clocks after March 2023.
  * Fix some pre-1996 timestamps in northern Canada.
  * C89 is now deprecated; please use C99 or later.
  * Portability fixes for AIX, libintl, MS-Windows, musl, z/OS
  * In C code, use more C23 features if available.
  * C23 timegm now supported by default
  * Fixes for unlikely integer overflows

  Changes to future timestamps:

  In the Mexican state of Chihuahua, the border strip near the US will
  change to agree with nearby US locations on 2022-11-30. The strip's
  western part, represented by Ciudad Juárez, switches from -06 all year
  to -07/-06 with US DST rules, like El Paso, TX. The eastern part,
  represented by Ojinaga, will observe US DST next year, like Presidio,
  TX.  (Thanks to Heitor David Pinto.) A new Zone America/Ciudad_Juarez
  splits from America/Ojinaga.

  Much of Greenland, represented by America/Nuuk, stops observing winter
  time after March 2023, so its daylight saving time becomes standard
  time.  (Thanks to Jonas Nyrup and Jürgen Appel.)

  ICU change: https://unicode-org.atlassian.net/browse/ICU-22217
  CLDR: https://unicode-org.atlassian.net/browse/CLDR-16181

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [ Test Case for all releases ]
  1) dpkg -s tzdata | grep ^Version
  2) zdump -v America/Ciudad_Juarez | grep -v NULL | tail -n 1
    -> should have output, last dates should be in 2499

  
  [Test case for releases >= 20.04 LTS]

  from datetime import datetime, timedelta
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Ciudad_Juarez"))
  assert(tz.utcoffset(datetime(2022, 12, 1)) == timedelta(hours=-7))

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

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


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


[Touch-packages] [Bug 1995601] Re: tzdata 2022f ICU data update

2022-11-15 Thread Steve Beattie
These updates have been pocket copied into the security pockets for
kinetic, jammy, and focal. Thanks

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

Title:
  tzdata 2022f ICU data update

Status in tzdata package in Ubuntu:
  Triaged
Status in tzdata source package in Focal:
  Fix Released
Status in tzdata source package in Jammy:
  Fix Released
Status in tzdata source package in Kinetic:
  Fix Released
Status in tzdata source package in Lunar:
  Triaged

Bug description:
  The ICU data we embed in tzdata was out of sync on the 2022f-0ubuntu1
  upload, still matching the 2022e data instead. It's been updated
  upstream, so we need to do another round of SRUs for it:

  https://github.com/unicode-org/icu-
  data/commit/ad9d2568d02b2130f1ba34f876fc82cad32c522f

  The following Python script should work with the update and crash on
  obsolete data:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Chihuahua"))
  before = datetime(2022, 10, 1)
  after = datetime(2022, 11, 2)
  assert(tz.utcoffset(before) == tz.utcoffset(after))

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


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


[Touch-packages] [Bug 1995209] Re: tzdata 2022f release

2022-10-31 Thread Steve Beattie
Ack from the Security Team for the tzdata updates to go to security
pocket. Thanks!

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

Title:
  tzdata 2022f release

Status in tzdata package in Ubuntu:
  New
Status in tzdata source package in Xenial:
  New
Status in tzdata source package in Bionic:
  New
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Jammy:
  Fix Committed
Status in tzdata source package in Kinetic:
  Fix Committed

Bug description:
  New timezone data, with the following timezones impacted:
  - Mexico will no longer observe DST except near the US border.
Chihuahua moves to year-round -06 on 2022-10-30.
  - Fiji no longer observes DST.

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


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


[Touch-packages] [Bug 1992692] Re: tzdata 2022e release

2022-10-20 Thread Steve Beattie
tzdata updates were published to both trusty/esm and xenial/esm. Thanks!

** Also affects: tzdata (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: tzdata (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

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

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

Title:
  tzdata 2022e release

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Trusty:
  Fix Released
Status in tzdata source package in Xenial:
  Fix Released
Status in tzdata source package in Bionic:
  New
Status in tzdata source package in Focal:
  New
Status in tzdata source package in Jammy:
  New

Bug description:
  New timezone data, with the following timezones impacted:
  - Palestine transitions are now Saturdays at 02:00. This means 2022 falls
    back 10-29 at 02:00, not 10-28 at 01:00.
  - Simplify three Ukraine zones into one.
  - Jordan and Syria switch from +02/+03 with DST to year-round +03.

  icu update to 2022e: https://unicode-
  org.atlassian.net/browse/ICU-22178

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v Asia/Gaza | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
  2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
  always_before = datetime(2022, 10, 1)
  now_before = datetime(2022, 10, 29)
  always_after = datetime(2022, 11, 1)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022c.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

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


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


[Touch-packages] [Bug 1992692] Re: tzdata 2022e release

2022-10-18 Thread Steve Beattie
FYI, because of the way python has incorrectly handled timezomes in the
past, the python3-icu tests fail, at least when run in a timezone that
is -0700 for releases like bionic and older. For example, taking the
very similar testcase for the prior 2022c update in LP: #1986984, on
ubuntu 18.04 it results:

ubuntu@sec-bionic-amd64:~$ apt policy tzdata | grep Installed:

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

  Installed: 2022c-0ubuntu0.18.04.0
ubuntu@sec-bionic-amd64:~$ python3
Python 3.6.9 (default, Jun 29 2022, 11:45:57) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> from icu import ICUtzinfo, TimeZone
>>> tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
>>> always_before = datetime(2022, 9, 1)
>>> now_before = datetime(2022, 9, 8)
>>> always_after = datetime(2022, 9, 12)
>>> assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
>>> assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))
Traceback (most recent call last):
  File "", line 1, in 
AssertionError
>>> tz.utcoffset(now_before)
datetime.timedelta(-1, 75600)
>>> tz.utcoffset(always_after)
datetime.timedelta(-1, 75600)

For ensuring the ESM releases were handling the changes correctly, I
created a python3-tz[1] based script at https://git.launchpad.net/qa-
regression-testing/tree/scripts/test-tzdata.py and in fact, just pushed
an added testcase for this bug that looks like
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-
tzdata.py#n95

Thanks.

[1] The pytz project documents a lot of the issues with timezone
handling in older pythons at their project page:
https://pytz.sourceforge.net/

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

Title:
  tzdata 2022e release

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Bionic:
  New
Status in tzdata source package in Focal:
  New
Status in tzdata source package in Jammy:
  New

Bug description:
  New timezone data, with the following timezones impacted:
  - Palestine transitions are now Saturdays at 02:00. This means 2022 falls
    back 10-29 at 02:00, not 10-28 at 01:00.
  - Simplify three Ukraine zones into one.
  - Jordan and Syria switch from +02/+03 with DST to year-round +03.

  icu update to 2022e: https://unicode-
  org.atlassian.net/browse/ICU-22178

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v Asia/Gaza | grep 'Oct.*2022'
-> should indicate Oct 29, not Oct 28
  2) zdump -v Asia/Damascus | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("Asia/Gaza"))
  always_before = datetime(2022, 10, 1)
  now_before = datetime(2022, 10, 29)
  always_after = datetime(2022, 11, 1)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022c.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

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


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


[Touch-packages] [Bug 1892559] Re: [MIR] ccid opensc pcsc-lite

2022-09-13 Thread Steve Beattie
** Changed in: ccid (Ubuntu)
 Assignee: Ray Veldkamp (rayveldkamp) => Ubuntu Security Team 
(ubuntu-security)

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

Title:
  [MIR] ccid opensc pcsc-lite

Status in ccid package in Ubuntu:
  In Progress
Status in opensc package in Ubuntu:
  Incomplete
Status in pam-pkcs11 package in Ubuntu:
  Invalid
Status in pcsc-lite package in Ubuntu:
  New
Status in pcsc-perl package in Ubuntu:
  Invalid
Status in pcsc-tools package in Ubuntu:
  Invalid

Bug description:
  ==> ccid <==
  [Availability]
  ccid is in universe, and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs for ccid are listed in our database.
  Doesn't appear to bind to a socket.
  No privileged executables, but does have udev rules.
  Probably needs a security review.

  [Quality assurance]
  No test suite.
  Does require odd hardware that we'll probably need to buy.
  I don't see debconf questions.
  ccid is well maintained in Debian by upstream author.
  One open wishlist bug in BTS, harmless.

  One open bug in launchpad, not security, but looks very frustrating
  for the users. The upstream author was engaged but it never reached
  resolution.  https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

  Has a debian/watch file.
  Quilt packaging.

  P: ccid source: no-dep5-copyright
  P: ccid source: package-uses-experimental-debhelper-compat-version 13

  [Dependencies]
  Minimal dependencies, in main

  [Standards compliance]
  Appears to satisfy FHS and Debian policy

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  ccid provides drivers to interact with usb-connected smart card readers.

  ==> libpam-pkcs11 <==
  [Availability]
  Source package pam-pkcs11 is in universe and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs in our database.
  Doesn't appear to bind to sockets.
  No privileged executables (but is a PAM module).
  As a PAM module this will require a security review.

  [Quality assurance]
  The package does not call pam-auth-update in its postinst #1650366
  Does not ask questions during install.
  One Ubuntu bug claims very poor behaviour if a card isn't plugged in.
  No Debian bugs.
  Occasional updates in Debian by long-term maintainer.
  Does require odd hardware that we'll probably need to buy.
  Does not appear to run tests during build.
  Has scary warnings in the build logs.
  Has a debian/watch file.

  Ancient standards version; other smaller lintian messages, mostly
  documentation problems.

  Quilt packaging.

  [Dependencies]
  Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1
  All are in main.

  [Standards compliance]
  The package does not call pam-auth-update in its postinst #1650366
  Otherwise looks to conform to FHS and Debian policies

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  This PAM module can use CRLs and full-chain verification of certificates.
  It can also do LDAP, AD, and Kerberos username mapping.

  ==> libpcsc-perl <==
  [Availability]
  Source package pcsc-perl is in universe, builds for all architectures,
  plus i386

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  There are no cves for pcsc-perl in our database.
  No privileged executables.
  Doesn't appear to bind to sockets.
  Probably needs a security review.

  [Quality assurance]
  Library package not intended to be used directly.
  No debconf questions.
  No bugs in Debian.
  No bugs in Ubuntu.
  Does require odd hardware that we'll probably need to buy.
  Tests exist, not run during the build; probably can't run during the build.
  Includes debian/watch file.
  A handful of lintian issues
  Quilt packaging.

  [Dependencies]
  libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0.
  All are in main.

  [Standards compliance]
  One oddity, Card.pod is stored in 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/
  Many other perl packages have .pod files in these directory trees so maybe
  it's fine, but it seems funny all the same.

  Otherwise appears to satisfy FHS and Debian policy.

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background 

[Touch-packages] [Bug 1703821] Re: Dovecot and Apparmor complains at operation file_inherit

2022-08-04 Thread Steve Beattie
** Changed in: apparmor (Ubuntu)
   Status: Expired => Fix Released

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

Title:
  Dovecot and Apparmor complains at operation file_inherit

Status in AppArmor:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in dovecot package in Ubuntu:
  Fix Released
Status in apparmor source package in Bionic:
  Incomplete
Status in dovecot source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  Users report that while running dovecot there are some issues reported
  by AppArmor, specifically regarding "file_inherit" operations:

  Jul 12 13:31:19 myserver kernel: [ 3905.672577] audit: type=1400
  audit(1499859079.016:363): apparmor="ALLOWED" operation="file_inherit"
  profile="/usr/lib/dovecot/anvil" pid=3766 comm="anvil" family="unix"
  sock_type="stream" protocol=0 requested_mask="send receive"
  denied_mask="send receive" addr=none peer_addr=none
  peer="/usr/sbin/dovecot"

  Jul 12 13:31:19 myserver kernel: [ 3905.672578] audit: type=1400
  audit(1499859079.016:364): apparmor="ALLOWED" operation="file_inherit"
  profile="/usr/sbin/dovecot" pid=3766 comm="anvil" family="unix"
  sock_type="stream" protocol=0 requested_mask="send receive"
  denied_mask="send receive" addr=none peer_addr=none
  peer="/usr/lib/dovecot/anvil"

  This is likely caused by an anonymous socket communication channel
  between dovecot and anvil.

  A fix in the dovecot AppArmor policy was already merged upstream
  in commit 1ce8cd21, which is being backported in this SRU.
  There was a change upstream that renamed the dovecot profile, so it was
  necessary to make a small change on the backport to reference the
  correct profile name.

  [Test Plan]

  Clone the qa-regression-testing repo
  https://git.launchpad.net/qa-regression-testing
  Setup the machine according to the instructions in the README.multipurpose-vm 
- specifically the Email section.

  Run the dovecot tests from the qa-regression-testing repo:
  python3 ./script test-dovecot.py

  After running the tests, check dmesg for no DENIED messages:
  dmesg | grep DENIED

  [Where problems could occur]

  This update broadens the dovecot policy, so it won't to cause any
  issues regarding a behavior that was previously allowed and it is now
  denied.
  In addition, the dovecot policy is already in complain mode in
  bionic.

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


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


[Touch-packages] [Bug 1976123] Re: package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed cups package post-installation script subprocess was killed by signal (Bus error), core dumped

2022-06-14 Thread Steve Beattie
Hi, thanks for reporting your issue. One possible cuase for this is that
it seems your system is having disk problems, as seen in the dmesg
output:

[13489.632083] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[13489.632092] ata4.00: BMDMA stat 0x25
[13489.632097] ata4.00: failed command: READ DMA
[13489.632106] ata4.00: cmd c8/00:88:30:ea:23/00:00:00:00:00/e0 tag 0 dma 69632 
in
res 51/40:47:68:ea:23/00:00:00:00:00/e0 Emask 0x9 
(media error)
[13489.632111] ata4.00: status: { DRDY ERR }
[13489.632115] ata4.00: error: { UNC }
[13489.638118] ata4.00: configured for UDMA/133
[13489.638146] sd 3:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[13489.638151] sd 3:0:0:0: [sda] tag#0 Sense Key : Medium Error [current] 
[13489.638154] sd 3:0:0:0: [sda] tag#0 Add. Sense: Unrecovered read error - 
auto reallocate failed
[13489.638160] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 23 ea 30 00 00 88 
00
[13489.638163] print_req_error: I/O error, dev sda, sector 2353768

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

Title:
  package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed
  cups package post-installation script subprocess was killed by signal
  (Bus error), core dumped

Status in cups package in Ubuntu:
  New

Bug description:
  ubuntu 16 worked but 18 doesn't upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-180.189-generic 4.15.18
  Uname: Linux 4.15.0-180-generic i686
  ApportVersion: 2.20.9-0ubuntu7.28
  Architecture: i386
  CupsErrorLog:
   E [27/May/2022:08:22:50 -0600] [cups-deviced] PID 1020 (gutenprint52+usb) 
stopped with status 1!
   W [27/May/2022:13:27:55 -0600] CreateProfile failed: 
org.freedesktop.ColorManager.AlreadyExists:profile id 
\'PHOTOSMART-P1000-Gray..\' already exists
   W [27/May/2022:13:27:55 -0600] CreateProfile failed: 
org.freedesktop.ColorManager.AlreadyExists:profile id 
\'PHOTOSMART-P1000-RGB..\' already exists
   W [27/May/2022:13:48:08 -0600] Notifier for subscription 13 (dbus://) went 
away, retrying!
   W [27/May/2022:13:48:08 -0600] Notifier for subscription 18 (dbus://) went 
away, retrying!
  Date: Fri May 27 12:07:06 2022
  ErrorMessage: installed cups package post-installation script subprocess was 
killed by signal (Bus error), core dumped
  InstallationDate: Installed on 2022-05-27 (0 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release i386 (20170801)
  Lpstat: device for PHOTOSMART-P1000: 
hp:/usb/PhotoSmart_P1000?serial=MX16A1D0P8HP
  Papersize: letter
  PpdFiles: PHOTOSMART-P1000: HP Photosmart p1000, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.15.0-180-generic 
root=UUID=d36f19e0-4269-404a-96cd-f6c837cca4b9 ro quiet splash vt.handoff=1
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-180-generic 
root=UUID=d36f19e0-4269-404a-96cd-f6c837cca4b9 ro quiet splash vt.handoff=1
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.4
   apt  1.6.14
  SourcePackage: cups
  Title: package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed 
cups package post-installation script subprocess was killed by signal (Bus 
error), core dumped
  UpgradeStatus: Upgraded to bionic on 2022-05-27 (0 days ago)
  dmi.bios.date: 04/29/2005
  dmi.bios.vendor: Intel Corp.
  dmi.bios.version: EV91510A.86A.0444.2005.0429.2108
  dmi.board.name: D915GAV
  dmi.board.vendor: Intel Corporation
  dmi.board.version: AAC64134-600
  dmi.chassis.type: 2
  dmi.modalias: 
dmi:bvnIntelCorp.:bvrEV91510A.86A.0444.2005.0429.2108:bd04/29/2005:svn:pn:pvr:rvnIntelCorporation:rnD915GAV:rvrAAC64134-600:cvn:ct2:cvr:

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


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


[Touch-packages] [Bug 1976123] Re: package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed cups package post-installation script subprocess was killed by signal (Bus error), core dumped

2022-06-14 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed
  cups package post-installation script subprocess was killed by signal
  (Bus error), core dumped

Status in cups package in Ubuntu:
  New

Bug description:
  ubuntu 16 worked but 18 doesn't upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: cups 2.2.7-1ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-180.189-generic 4.15.18
  Uname: Linux 4.15.0-180-generic i686
  ApportVersion: 2.20.9-0ubuntu7.28
  Architecture: i386
  CupsErrorLog:
   E [27/May/2022:08:22:50 -0600] [cups-deviced] PID 1020 (gutenprint52+usb) 
stopped with status 1!
   W [27/May/2022:13:27:55 -0600] CreateProfile failed: 
org.freedesktop.ColorManager.AlreadyExists:profile id 
\'PHOTOSMART-P1000-Gray..\' already exists
   W [27/May/2022:13:27:55 -0600] CreateProfile failed: 
org.freedesktop.ColorManager.AlreadyExists:profile id 
\'PHOTOSMART-P1000-RGB..\' already exists
   W [27/May/2022:13:48:08 -0600] Notifier for subscription 13 (dbus://) went 
away, retrying!
   W [27/May/2022:13:48:08 -0600] Notifier for subscription 18 (dbus://) went 
away, retrying!
  Date: Fri May 27 12:07:06 2022
  ErrorMessage: installed cups package post-installation script subprocess was 
killed by signal (Bus error), core dumped
  InstallationDate: Installed on 2022-05-27 (0 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release i386 (20170801)
  Lpstat: device for PHOTOSMART-P1000: 
hp:/usb/PhotoSmart_P1000?serial=MX16A1D0P8HP
  Papersize: letter
  PpdFiles: PHOTOSMART-P1000: HP Photosmart p1000, hpcups 3.16.3
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.15.0-180-generic 
root=UUID=d36f19e0-4269-404a-96cd-f6c837cca4b9 ro quiet splash vt.handoff=1
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-180-generic 
root=UUID=d36f19e0-4269-404a-96cd-f6c837cca4b9 ro quiet splash vt.handoff=1
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.4
   apt  1.6.14
  SourcePackage: cups
  Title: package cups 2.2.7-1ubuntu2.8 failed to install/upgrade: installed 
cups package post-installation script subprocess was killed by signal (Bus 
error), core dumped
  UpgradeStatus: Upgraded to bionic on 2022-05-27 (0 days ago)
  dmi.bios.date: 04/29/2005
  dmi.bios.vendor: Intel Corp.
  dmi.bios.version: EV91510A.86A.0444.2005.0429.2108
  dmi.board.name: D915GAV
  dmi.board.vendor: Intel Corporation
  dmi.board.version: AAC64134-600
  dmi.chassis.type: 2
  dmi.modalias: 
dmi:bvnIntelCorp.:bvrEV91510A.86A.0444.2005.0429.2108:bd04/29/2005:svn:pn:pvr:rvnIntelCorporation:rnD915GAV:rvrAAC64134-600:cvn:ct2:cvr:

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


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


[Touch-packages] [Bug 1892559] Re: [MIR] ccid opensc pcsc-lite

2022-05-11 Thread Steve Beattie
** Tags added: sec-407

** Tags added: sec-408 sec-409

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

Title:
  [MIR] ccid opensc pcsc-lite

Status in ccid package in Ubuntu:
  In Progress
Status in opensc package in Ubuntu:
  Incomplete
Status in pam-pkcs11 package in Ubuntu:
  Invalid
Status in pcsc-lite package in Ubuntu:
  New
Status in pcsc-perl package in Ubuntu:
  Invalid
Status in pcsc-tools package in Ubuntu:
  Invalid

Bug description:
  ==> ccid <==
  [Availability]
  ccid is in universe, and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs for ccid are listed in our database.
  Doesn't appear to bind to a socket.
  No privileged executables, but does have udev rules.
  Probably needs a security review.

  [Quality assurance]
  No test suite.
  Does require odd hardware that we'll probably need to buy.
  I don't see debconf questions.
  ccid is well maintained in Debian by upstream author.
  One open wishlist bug in BTS, harmless.

  One open bug in launchpad, not security, but looks very frustrating
  for the users. The upstream author was engaged but it never reached
  resolution.  https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

  Has a debian/watch file.
  Quilt packaging.

  P: ccid source: no-dep5-copyright
  P: ccid source: package-uses-experimental-debhelper-compat-version 13

  [Dependencies]
  Minimal dependencies, in main

  [Standards compliance]
  Appears to satisfy FHS and Debian policy

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  ccid provides drivers to interact with usb-connected smart card readers.

  ==> libpam-pkcs11 <==
  [Availability]
  Source package pam-pkcs11 is in universe and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs in our database.
  Doesn't appear to bind to sockets.
  No privileged executables (but is a PAM module).
  As a PAM module this will require a security review.

  [Quality assurance]
  The package does not call pam-auth-update in its postinst #1650366
  Does not ask questions during install.
  One Ubuntu bug claims very poor behaviour if a card isn't plugged in.
  No Debian bugs.
  Occasional updates in Debian by long-term maintainer.
  Does require odd hardware that we'll probably need to buy.
  Does not appear to run tests during build.
  Has scary warnings in the build logs.
  Has a debian/watch file.

  Ancient standards version; other smaller lintian messages, mostly
  documentation problems.

  Quilt packaging.

  [Dependencies]
  Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1
  All are in main.

  [Standards compliance]
  The package does not call pam-auth-update in its postinst #1650366
  Otherwise looks to conform to FHS and Debian policies

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  This PAM module can use CRLs and full-chain verification of certificates.
  It can also do LDAP, AD, and Kerberos username mapping.

  ==> libpcsc-perl <==
  [Availability]
  Source package pcsc-perl is in universe, builds for all architectures,
  plus i386

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  There are no cves for pcsc-perl in our database.
  No privileged executables.
  Doesn't appear to bind to sockets.
  Probably needs a security review.

  [Quality assurance]
  Library package not intended to be used directly.
  No debconf questions.
  No bugs in Debian.
  No bugs in Ubuntu.
  Does require odd hardware that we'll probably need to buy.
  Tests exist, not run during the build; probably can't run during the build.
  Includes debian/watch file.
  A handful of lintian issues
  Quilt packaging.

  [Dependencies]
  libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0.
  All are in main.

  [Standards compliance]
  One oddity, Card.pod is stored in 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/
  Many other perl packages have .pod files in these directory trees so maybe
  it's fine, but it seems funny all the same.

  Otherwise appears to satisfy FHS and Debian policy.

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  Dependency of pcsc-tools; this library provides 

[Touch-packages] [Bug 1971895] Re: Warning messages from stat printed on installation with no user crontabs

2022-05-10 Thread Steve Beattie
** Also affects: cron (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: cron (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

Title:
  Warning messages from stat printed on installation with no user
  crontabs

Status in cron package in Ubuntu:
  Confirmed
Status in cron source package in Xenial:
  Triaged
Status in cron source package in Bionic:
  Triaged

Bug description:
  On installation of cron on a new system, or (I expect) an upgrade with
  no user crontab files the following is printed:

  Setting up cron (3.0pl1-128.1ubuntu1.1) ...
  stat: cannot stat '*': No such file or directory
  stat: cannot stat '*': No such file or directory
  stat: cannot stat '*': No such file or directory
  Warning: * is not a regular file!

  This is related to the fix for CVE-2017-9525 introduced in
  3.0pl1-128.1ubuntu1.1. The for loop at line 66 of cron.postinst needs
  to have a guard like the following added to it:

  [ "$tab_name" = "*" ] && continue

  We have observed this with Bionic, I haven't checked any other Ubuntu
  releases.

  Cheers,
  Andrew

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


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


[Touch-packages] [Bug 1967626] Re: 22.04 beta Network Manager still sets wrong IPv6 routing

2022-05-10 Thread Steve Beattie
Given that this issue is public in the freedesktop gitlab instance, I'm
making this issue public here as well.

** 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 network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1967626

Title:
  22.04 beta Network Manager still sets wrong IPv6 routing

Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi,

  that's a bug I've already reported earlier both to ubuntu and network-
  manager upstream, and nobody seems to care about.

  I'm using an AVM FritzBox, a router family very common in Germany and
  Europe for DSL and DOCSIS, but saw reports of people confirming the
  problem with other routers.

  The router sends ICMPv6 router advertisements, which contain for both
  the configured site-local address and the provider-assigned world-
  routable address range both a

  * prefix information 
  * router advertisement on itself

  All other OS and machines I have, including

  * Debian
  * Ubuntu Server
  * Ubuntu Core
  * Raspberry Pi OS
  * Other Linuxes
  * MacOS
  *...

  correctly set a link route on the network device for both the official
  and the site local address.

  Only Ubuntu Desktop machines with that damned Network Manager set a
  route to the router instead of a link route.

  The consequence is, that IPv6 still works, but significantly to slow,
  since packages are not switched on the network switch, but routed on
  the router, which dramatically decreases speed.

  
  I've reported this upstream to Network Manager, see the discussion on 

  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/840

  but they do not even seem to understand the issue (Network Manager
  written by people not really understanding routing...)

  Their point of view is that the router will fix things by sending
  redirects. However, ICMPv6 redirects are considered a security problem
  and usually recommended to be turned off.

  The answer from NetworkManager developers is to fix the router, not
  the Network Manager to stop sending router advertisings, but can't
  explain why all other OS and other Linux distributions, including
  Ubuntu server and Ubuntu core do it correctly, and just NM doing it
  wrong.

  So Ubuntu/NetworkManagers unability to fix or even notice this
  essential problem forces people to either accept terribly slow IPv6
  traffic in local networks, or to leave the machine open for ICMPv6
  redirects, which, in general, is a security flaw and vulnerable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1967626/+subscriptions


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


[Touch-packages] [Bug 1214787] Re: busybox crashed with signal 7

2022-05-05 Thread Steve Beattie
** Information type changed from Private to Public

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

Title:
  busybox crashed with signal 7

Status in busybox package in Ubuntu:
  New

Bug description:
  busybox crashed with signal 7

  ProblemType: Crash
  DistroRelease: Ubuntu 13.10
  Package: busybox-static 1:1.20.0-8.1ubuntu1
  ProcVersionSignature: Ubuntu 3.11.0-3.7-generic 3.11.0-rc6
  Uname: Linux 3.11.0-3-generic i686
  ApportVersion: 2.12.1-0ubuntu2
  Architecture: i386
  CasperVersion: 1.336
  Date: Wed Aug 21 12:56:53 2013
  Dependencies:
   
  Disassembly: => 0x80a7990:Cannot access memory at address 0x80a7990
  ExecutablePath: /bin/busybox
  LiveMediaBuild: Ubuntu 13.10 "Saucy Salamander" - Alpha i386 (20130821)
  MarkForUpload: True
  ProcCmdline: /bin/busybox tail -f /var/log/installer/debug -f /var/log/syslog 
-q
  ProcEnviron:
   LANG=en_US.UTF-8
   TERM=xterm
   PATH=(custom, no user)
  ProcMaps:
   08048000-081fc000 r-xp  07:00 12 /bin/busybox
   081fc000-081fe000 rw-p 001b3000 07:00 12 /bin/busybox
   081fe000-08203000 rw-p  00:00 0 
   b771c000-b771d000 r-xp  00:00 0  [vdso]
   bfa43000-bfa64000 rw-p  00:00 0  [stack]
  Signal: 7
  SourcePackage: busybox
  StacktraceTop:
   ?? ()
   ?? ()
   ?? ()
  Title: busybox crashed with signal 7
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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


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


[Touch-packages] [Bug 1914279] Re: linux from security may force reboots without complete dkms modules

2022-04-12 Thread Steve Beattie
All work for this report has been completed, I believe the linux and
linux-meta tasks can be closed out as well.

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

** Changed in: linux-meta (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
  linux from security may force reboots without complete dkms modules

Status in acpi-call package in Ubuntu:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in backport-iwlwifi-dkms package in Ubuntu:
  Fix Released
Status in bcmwl package in Ubuntu:
  Fix Released
Status in dahdi-linux package in Ubuntu:
  Fix Released
Status in dkms package in Ubuntu:
  Fix Released
Status in dm-writeboost package in Ubuntu:
  Fix Released
Status in evdi package in Ubuntu:
  Fix Released
Status in gost-crypto package in Ubuntu:
  Fix Released
Status in iptables-netflow package in Ubuntu:
  Fix Released
Status in liblzf package in Ubuntu:
  Fix Released
Status in lime-forensics package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux-meta package in Ubuntu:
  Fix Released
Status in lttng-modules package in Ubuntu:
  Fix Released
Status in nvidia-graphics-drivers-340 package in Ubuntu:
  Fix Released
Status in openafs package in Ubuntu:
  New
Status in oss4 package in Ubuntu:
  Fix Released
Status in r8168 package in Ubuntu:
  Fix Released
Status in rtl8812au package in Ubuntu:
  Fix Released
Status in sysdig package in Ubuntu:
  Fix Released
Status in unattended-upgrades package in Ubuntu:
  Invalid
Status in update-manager package in Ubuntu:
  Invalid
Status in v4l2loopback package in Ubuntu:
  Fix Released
Status in virtualbox package in Ubuntu:
  Fix Released
Status in virtualbox-hwe package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Fix Released
Status in acpi-call source package in Focal:
  Fix Released
Status in backport-iwlwifi-dkms source package in Focal:
  Fix Released
Status in bcmwl source package in Focal:
  Fix Released
Status in dahdi-linux source package in Focal:
  Fix Released
Status in dm-writeboost source package in Focal:
  Fix Released
Status in evdi source package in Focal:
  Fix Released
Status in gost-crypto source package in Focal:
  Fix Released
Status in iptables-netflow source package in Focal:
  Fix Released
Status in liblzf source package in Focal:
  Fix Released
Status in lime-forensics source package in Focal:
  Fix Released
Status in lttng-modules source package in Focal:
  Fix Released
Status in nvidia-graphics-drivers-340 source package in Focal:
  Fix Released
Status in oss4 source package in Focal:
  Fix Released
Status in r8168 source package in Focal:
  Fix Released
Status in rtl8812au source package in Focal:
  Fix Released
Status in sysdig source package in Focal:
  Fix Released
Status in v4l2loopback source package in Focal:
  Fix Released
Status in virtualbox source package in Focal:
  Fix Released
Status in virtualbox-hwe source package in Focal:
  Fix Released
Status in zfs-linux source package in Focal:
  Fix Released

Bug description:
  Whilst discussing

  https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-
  ubuntu-desktop-installation-media/20606

  We have noticed a reference to somebody not having working backport-
  iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8
  switch.

  However, kernel meta switch was pushed to security pocket, but the
  dkms modules are all in -updates only.

  This may result in people automatically installing the new kernel with
  unatanded upgrades; dkms modules failing to build; and a reboot
  required flag left on disk.

  At this point launching update manager will not offer to install dkms
  modules from updates, and will guide the users to reboot. which
  will then cause them to boot the new kernel without the dkms modules
  that might be providing networking for them.

  Should dkms modules SRUs always getting published into -security
  pocket, as well as the -updates pocket?

  Should linux maintainer scripts prevent touching reboot required flag
  if any dkms modules fail to build?

  Should apt / unattanded-upgrades / update-manager always update dkms
  modules with kernels?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1914279/+subscriptions


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


[Touch-packages] [Bug 1948698] Re: Update tzdata to version 2021e

2021-10-26 Thread Steve Beattie
Okay from the Ubuntu Security team for these tzdata updates to land in
security pockets. Thanks!

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

Title:
  Update tzdata to version 2021e

Status in tzdata package in Ubuntu:
  In Progress
Status in tzdata source package in Bionic:
  In Progress
Status in tzdata source package in Focal:
  In Progress
Status in tzdata source package in Hirsute:
  In Progress
Status in tzdata source package in Impish:
  In Progress

Bug description:
  New upstream version affecting the following timestamp:

  $region/$timezone = Asia/Gaza

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v Asia/Gaza 2021

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  [Test Case for releases >= 20.04 LTS]
  1) sudo apt-get install python3-icu
  2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo, 
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Pacific/Apia')); 
print(str(tz.utcoffset(datetime(2021, 9, 26'

  Additionally, an upstream update of tzdata removed the 'old' SystemV
  timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
  and earlier releases. Subsequently, these should be checked for using
  the following:

  [Test Case for releases <= 20.04 LTS]
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

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


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


[Touch-packages] [Bug 1945527] Re: Update tzdata to version 2021a-2

2021-10-21 Thread Steve Beattie
This was fixed for xenial/esm with tzdata 2021a-2ubuntu0.16.04+esm1 and
for trusty/esm with tzdata 2021a-2ubuntu0.14.04+esm1. Thanks Brian, for
preparing these updates!

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

** Also affects: tzdata (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

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

Title:
  Update tzdata to version 2021a-2

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Trusty:
  Fix Released
Status in tzdata source package in Xenial:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Released
Status in tzdata source package in Focal:
  Fix Released
Status in tzdata source package in Hirsute:
  Fix Released

Bug description:
  New upstream version affecting the following timestamp:

  $region/$timezone = Pacific/Apia

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Pacific/Apia'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v Pacific/Apia | grep 2021

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  [Test Case for releases >= 20.04 LTS]
  1) sudo apt-get install python3-icu
  2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo, 
TimeZone; tz = ICUtzinfo(TimeZone.createTimeZone('Pacific/Apia')); 
print(str(tz.utcoffset(datetime(2021, 9, 27'

  Additionally, an upstream update of tzdata removed the 'old' SystemV
  timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
  and earlier releases. Subsequently, these should be checked for using
  the following:

  [Test Case for releases <= 20.04 LTS]
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

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


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


[Touch-packages] [Bug 1755447] Re: issue 32185: SSLContext.wrap_socket sends SNI Extension when server_hostname is IP

2021-10-20 Thread Steve Beattie
I am not aware of a security impact from this issue, so if it is to be
addressed in xenial ESM, it would eed to go through a support request.
closing the xenial tasks as Won't Fix.

** Changed in: python2.7 (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: python3.5 (Ubuntu Xenial)
   Status: New => Won't Fix

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

Title:
  issue 32185: SSLContext.wrap_socket sends SNI Extension when
  server_hostname is IP

Status in Python:
  Fix Released
Status in python2.7 package in Ubuntu:
  Fix Released
Status in python3.6 package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python2.7 source package in Trusty:
  Won't Fix
Status in python3.4 source package in Trusty:
  Won't Fix
Status in python2.7 source package in Xenial:
  Won't Fix
Status in python3.5 source package in Xenial:
  Won't Fix
Status in python2.7 source package in Artful:
  Won't Fix
Status in python3.6 source package in Artful:
  Won't Fix
Status in python3.7 source package in Artful:
  Won't Fix
Status in python2.7 source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python2.7 package in Debian:
  New
Status in python3.4 package in Debian:
  New
Status in python3.5 package in Debian:
  New

Bug description:
  the fix for https://bugs.python.org/issue32185 needs backports for the
  stable releases.

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


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


[Touch-packages] [Bug 1755447] Re: issue 32185: SSLContext.wrap_socket sends SNI Extension when server_hostname is IP

2021-10-20 Thread Steve Beattie
For python2.7, this was fixed in
https://github.com/python/cpython/commit/a5c9112300ecd492ed6cc9759dc8028766401f61
which landed in 2.7.15, so has been fixed in bionic-updates and newer.

** Changed in: python2.7 (Ubuntu Bionic)
   Status: New => Fix Released

** Changed in: python2.7 (Ubuntu)
   Status: New => Fix Released

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

Title:
  issue 32185: SSLContext.wrap_socket sends SNI Extension when
  server_hostname is IP

Status in Python:
  Fix Released
Status in python2.7 package in Ubuntu:
  Fix Released
Status in python3.6 package in Ubuntu:
  Fix Released
Status in python3.7 package in Ubuntu:
  Fix Released
Status in python2.7 source package in Trusty:
  Won't Fix
Status in python3.4 source package in Trusty:
  Won't Fix
Status in python2.7 source package in Xenial:
  Won't Fix
Status in python3.5 source package in Xenial:
  Won't Fix
Status in python2.7 source package in Artful:
  Won't Fix
Status in python3.6 source package in Artful:
  Won't Fix
Status in python3.7 source package in Artful:
  Won't Fix
Status in python2.7 source package in Bionic:
  Fix Released
Status in python3.6 source package in Bionic:
  Fix Released
Status in python3.7 source package in Bionic:
  Fix Released
Status in python2.7 package in Debian:
  New
Status in python3.4 package in Debian:
  New
Status in python3.5 package in Debian:
  New

Bug description:
  the fix for https://bugs.python.org/issue32185 needs backports for the
  stable releases.

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


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


[Touch-packages] [Bug 1352007] Re: avconv crashed with SIGSEGV in paint_mouse_pointer()

2021-09-30 Thread Steve Beattie
** Information type changed from Private to Public

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

Title:
  avconv crashed with SIGSEGV in paint_mouse_pointer()

Status in libav package in Ubuntu:
  New

Bug description:
  Just grabbing x11.

  ProblemType: Crash
  DistroRelease: Ubuntu 14.10
  Package: libav-tools 6:10.2-2
  ProcVersionSignature: Ubuntu 3.16.0-6.11-generic 3.16.0-rc7
  Uname: Linux 3.16.0-6-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.14.5-0ubuntu3
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Sun Aug  3 23:10:45 2014
  ExecutablePath: /usr/bin/avconv
  InstallationDate: Installed on 2014-05-29 (66 days ago)
  InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.1)
  ProcCmdline: avconv -f x11grab -s 1920x1080 -r 30 -i :0.0 -qscale 0 grab.webm
  SegvAnalysis:
   Segfault happened at: 0x7f199618555d:movzwl 0x8(%rax),%edx
   PC (0x7f199618555d) ok
   source "0x8(%rax)" (0x0008) not located in a known VMA region (needed 
readable region)!
   destination "%edx" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: libav
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/libavdevice.so.54
   ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.55
   ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.55
   av_read_frame () from /usr/lib/x86_64-linux-gnu/libavformat.so.55
   ?? ()
  Title: avconv crashed with SIGSEGV in av_read_frame()
  UpgradeStatus: Upgraded to utopic on 2014-05-31 (63 days ago)
  UserGroups: libvirtd

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


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


[Touch-packages] [Bug 1368481] Re: avconv assert failure: avconv: /build/buildd/libav-11~beta1/libavcodec/put_bits.h:139: put_bits: Assertion `n <= 31 && value < (1U << n)' failed.

2021-09-30 Thread Steve Beattie
** Information type changed from Private to Public

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

Title:
  avconv assert failure: avconv:
  /build/buildd/libav-11~beta1/libavcodec/put_bits.h:139: put_bits:
  Assertion `n <= 31 && value < (1U << n)' failed.

Status in Bombono DVD:
  New
Status in libav package in Ubuntu:
  New

Bug description:
  This bug is on bombono-dvd which while it builds off of libav11 it fails as 
per crash
  Add. info from details -
  avconv: /build/buildd/libav-11~beta1/libavcodec/put_bits.h:139: put_bits: 
Assertion `n <= 31 && value < (1U << n)' failed.
  ERR: avconv failure: broken by signal SIGABRT/SIGIOT

  ProblemType: Crash
  DistroRelease: Ubuntu 14.10
  Package: libav-tools 6:11~beta1-2
  ProcVersionSignature: Ubuntu 3.16.0-14.20-generic 3.16.2
  Uname: Linux 3.16.0-14-generic x86_64
  ApportVersion: 2.14.7-0ubuntu2
  Architecture: amd64
  AssertionMessage: avconv: 
/build/buildd/libav-11~beta1/libavcodec/put_bits.h:139: put_bits: Assertion `n 
<= 31 && value < (1U << n)' failed.
  CurrentDesktop: Unity
  Date: Thu Sep 11 20:45:16 2014
  ExecutablePath: /usr/bin/avconv
  InstallationDate: Installed on 2014-09-12 (0 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140911)
  ProcCmdline: avconv -i /home/username/Videos/Jacquie\ Lee_\ _I\ Put\ a\ 
Spell\ on\ You_\ -\ The\ Voice\ Highlight.mp4 -target ntsc-dvd -g 18 -b 600 
-maxrate 900 -minrate 0 -bufsize 1835008 -packetsize 2048 -muxrate 1008 
-b:a 448000 -aspect 16:9 -s 720x480 -b 5000k -b:a 320k -y -mbd rd -trellis 2 
-cmp 2 -subcmp 2 /home/username/.cache/bombono-dvd-video/1.Jacquie\ Lee_\ _I\ 
Put\ a\ Spell\ on\ You_\ -\ The\ Voice\ Highlight.mp4.mpg
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   LANGUAGE=en_US
   XDG_RUNTIME_DIR=
  Signal: 6
  SourcePackage: libav
  StacktraceTop:
   __assert_fail_base (fmt=0x7f82e3a1b748 "%s%s%s:%u: %s%sAssertion `%s' 
failed.\n%n", assertion=assertion@entry=0x7f82e5da7f9c "n <= 31 && value < (1U 
<< n)", file=file@entry=0x7f82e5da8088 
"/build/buildd/libav-11~beta1/libavcodec/put_bits.h", line=line@entry=139, 
function=function@entry=0x7f82e5da82c4 "put_bits") at assert.c:92
   __GI___assert_fail (assertion=0x7f82e5da7f9c "n <= 31 && value < (1U << n)", 
file=0x7f82e5da8088 "/build/buildd/libav-11~beta1/libavcodec/put_bits.h", 
line=139, function=0x7f82e5da82c4 "put_bits") at assert.c:101
   ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.56
   ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.56
   ?? () from /usr/lib/x86_64-linux-gnu/libavformat.so.56
  Title: avconv assert failure: avconv: 
/build/buildd/libav-11~beta1/libavcodec/put_bits.h:139: put_bits: Assertion `n 
<= 31 && value < (1U << n)' failed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

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


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


[Touch-packages] [Bug 980943] Re: ffmpeg crashed with SIGSEGV in __libc_start_main()

2021-09-30 Thread Steve Beattie
** Attachment removed: "CoreDump.gz"
   
https://bugs.launchpad.net/ubuntu/+source/libav/+bug/980943/+attachment/3059934/+files/CoreDump.gz

** Information type changed from Private to Public Security

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

Title:
  ffmpeg crashed with SIGSEGV in __libc_start_main()

Status in libav package in Ubuntu:
  New

Bug description:
  ffmpeg crashed ffmpeg -i test.avi -f flv rtmp:localhost/live/test.flv

  ProblemType: Crash
  DistroRelease: Ubuntu 12.04
  Package: libav-tools 4:0.8.1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
  Uname: Linux 3.2.0-23-generic x86_64
  ApportVersion: 2.0.1-0ubuntu2
  Architecture: amd64
  Date: Thu Apr 12 17:05:34 2012
  ExecutablePath: /usr/bin/ffmpeg
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  ProcCmdline: ffmpeg -y -threads 2 -vf yadif=1 -i /dev/video0 -re -vcodec copy 
-acodec copy -f mpegts /tmp/fifo -re -vcodec copy -acodec copy -f mpegts 
/home/iced/nas4/live -re -acodec libmp3lame -ar 22000 -ab 48k -s 640x480 
-vcodec libx264 -b 1240k -flags +loop+mv4 -cmp 256 -partitions 
+parti4x4+partp8x8+partb8x8 -subq 7 -trellis 1 -refs 5 -coder 0 -me_range 16 
-keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 1240k -maxrate 1240k 
-bufsize 1240k -rc_eq blurCplx^(1-qComp) -qcomp 0.6 -qdiff 4 -level 41 -r 25 -g 
90 -async 2 -profile:v high -f flv rtmp://localhost/live/test2_1240 -re -acodec 
libmp3lame -ar 22000 -ab 48k -vcodec libx264 -b 1500k -r 25 -bt 1500k -maxrate 
2500k -bufsize 1500k -level 41 -partitions +parti4x4+partp8x8+partb8x8 -subq 7 
-trellis 1 -sc_threshold 40 -profile:v high -deinterlace -f flv 
rtmp://localhost/live/test2_1500
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   LANGUAGE=en_GB:en
   SHELL=/bin/bash
  SegvAnalysis:
   Segfault happened at: 0x40721e:  mov0x20(%rcx),%edx
   PC (0x0040721e) ok
   source "0x20(%rcx)" (0x0020) not located in a known VMA region (needed 
readable region)!
   destination "%edx" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: libav
  StacktraceTop:
   ?? ()
   ?? ()
   ?? ()
   __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
   ?? ()
  Title: ffmpeg crashed with SIGSEGV in __libc_start_main()
  UpgradeStatus: Upgraded to precise on 2012-02-27 (45 days ago)
  UserGroups:

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


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


[Touch-packages] [Bug 1943328] Re: display 1920x1080 not showing in setting

2021-09-14 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  display 1920x1080 not showing in setting

Status in xorg package in Ubuntu:
  New

Bug description:
  display 1920x1080 not showing in setting. i cant change my display.
  everything looks bigger and ugly

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.11.0-34.36~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-34-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Sep 11 19:27:58 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation 4th Generation Core Processor Family Integrated Graphics 
Controller [8086:041e] (rev 06) (prog-if 00 [VGA controller])
 Subsystem: Micro-Star International Co., Ltd. [MSI] 4th Generation Core 
Processor Family Integrated Graphics Controller [1462:7817]
  InstallationDate: Installed on 2021-09-10 (0 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  MachineType: MSI MS-7817
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-34-generic 
root=UUID=bb5421d7-dc24-45ad-8107-199e6e049a18 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/10/2018
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V1.10
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: H81M-P33 (MS-7817)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To be filled by O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: MSI
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV1.10:bd07/10/2018:br4.6:svnMSI:pnMS-7817:pvr1.0:skuTobefilledbyO.E.M.:rvnMSI:rnH81M-P33(MS-7817):rvr1.0:cvnMSI:ct3:cvr1.0:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7817
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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


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


[Touch-packages] [Bug 1943417] Re: Xorg freeze

2021-09-14 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  Xorg freeze

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu freezes frequently. can't even able to shutdown the system so i
  have to press the power button

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: xorg 1:7.7+22ubuntu1
  ProcVersionSignature: Ubuntu 5.11.0-34.36-generic 5.11.22
  Uname: Linux 5.11.0-34-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 13 11:36:03 2021
  DistUpgraded: Fresh install
  DistroCodename: hirsute
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GpuHangFrequency: Continuously
  GpuHangReproducibility: I don't know
  GpuHangStarted: Within the last week or two
  GraphicsCard:
   Intel Corporation CometLake-U GT2 [UHD Graphics] [8086:9b41] (rev 02) 
(prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company UHD Graphics [103c:85f1]
  InstallationDate: Installed on 2021-08-24 (19 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 30c9:0035 Luxvisions Innotech Limited HP TrueVision 
HD Camera
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 1M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
   |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
   |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
   |__ Port 5: Dev 2, If 2, Class=Application Specific Interface, Driver=, 
480M
  MachineType: HP HP Laptop 15s-du1xxx
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-34-generic 
root=UUID=b978107e-eaec-49de-9940-8be83bba3111 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  Title: Xorg freeze
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/31/2021
  dmi.bios.release: 15.43
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.43
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 85F1
  dmi.board.vendor: HP
  dmi.board.version: 37.28
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 37.28
  dmi.modalias: 
dmi:bvnInsyde:bvrF.43:bd03/31/2021:br15.43:efr37.28:svnHP:pnHPLaptop15s-du1xxx:pvrType1ProductConfigId:sku25U57PA#ACJ:rvnHP:rn85F1:rvr37.28:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP Notebook
  dmi.product.name: HP Laptop 15s-du1xxx
  dmi.product.sku: 25U57PA#ACJ
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~21.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200714-1ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

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


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


[Touch-packages] [Bug 1940202] Re: touchpad

2021-08-25 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  touchpad

Status in xorg package in Ubuntu:
  New

Bug description:
  touchpad not work and `` this symbol automatic type then work my pc

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: xorg 1:7.7+22ubuntu1
  ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22
  Uname: Linux 5.11.0-31-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: unknown
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Aug 17 08:16:32 2021
  DistUpgraded: 2021-06-27 20:32:09,566 DEBUG Running PostInstallScript: 
'/usr/lib/ubuntu-advantage/upgrade_lts_contract.py'
  DistroCodename: hirsute
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
 Subsystem: Dell HD Graphics 620 [1028:0789]
  InstallationDate: Installed on 2020-10-13 (307 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  MachineType: Dell Inc. Inspiron 14-3467
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-31-generic 
root=UUID=0418c796-3730-4ee7-8506-36b30300434a ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: Upgraded to hirsute on 2021-06-27 (50 days ago)
  dmi.bios.date: 01/13/2021
  dmi.bios.release: 2.14
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 2.14.0
  dmi.board.name: 0KNKX3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr2.14.0:bd01/13/2021:br2.14:svnDellInc.:pnInspiron14-3467:pvr:rvnDellInc.:rn0KNKX3:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 14-3467
  dmi.product.sku: 0789
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~21.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.2
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.3-0ubuntu0.2
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200714-1ubuntu1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

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


-- 
Mailing list: https://launchpad.net/~touch-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-19 Thread Steve Beattie
The Ubuntu Security Team is okay with publishig the xenial openssl in
proposed (1.0.2g-1ubuntu4.20) to xenial-security and updates. I didn't
see any symbol changes or dependency changes in the binaries that would
have indicated that building against xenial-updates was a problem.

Thanks!

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

[Touch-packages] [Bug 1939265] Re: Having graphic driver error.

2021-08-10 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  Having graphic driver error.

Status in xorg package in Ubuntu:
  New

Bug description:
  When I tried to install cairo dock, there were some lines in the
  outline of the dock, I thought that there was a graphic driver error
  because my friend has the same pc as mine and he has no error So i
  think there is a bug in my grapic driver. Please find my problem and
  try to resolve it

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.11.0-25.27~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Aug  9 09:54:21 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation 4 Series Chipset Integrated Graphics Controller 
[8086:2e32] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Intel Corporation 4 Series Chipset Integrated Graphics 
Controller [8086:d612]
 Subsystem: Intel Corporation 4 Series Chipset Integrated Graphics 
Controller [8086:d612]
  InstallationDate: Installed on 2021-07-19 (21 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-25-generic 
root=UUID=22616f1b-9a57-4931-ad0b-42a9c59e4e21 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/26/2009
  dmi.bios.vendor: Intel Corp.
  dmi.bios.version: TYG4110H.86A.0036.2009.1126.2047
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: DG41TY
  dmi.board.vendor: Intel Corporation
  dmi.board.version: AAE47335-302
  dmi.chassis.type: 3
  dmi.modalias: 
dmi:bvnIntelCorp.:bvrTYG4110H.86A.0036.2009.1126.2047:bd11/26/2009:svn:pn:pvr:rvnIntelCorporation:rnDG41TY:rvrAAE47335-302:cvn:ct3:cvr:
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.2~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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


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


[Touch-packages] [Bug 1796402] Re: systemd: reexec state injection: fgets() on overlong lines leads to line splitting

2021-07-28 Thread Steve Beattie
This was fixed in Ubuntu packages in
https://ubuntu.com/security/notices/USN-3816-1 ; adjusting the state to
reflect that a fix was released.

Thanks.

** Changed in: systemd (Ubuntu)
   Status: Invalid => Fix Released

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

Title:
  systemd: reexec state injection: fgets() on overlong lines leads to
  line splitting

Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd: reexec state injection: fgets() on overlong lines leads to
  line splitting

  [I am sending this bug report to Ubuntu, even though it's an upstream
  bug, as requested at
  
https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#security-vulnerability-reports
  .]

  When systemd re-executes (e.g. during a package upgrade), state is
  serialized into a memfd before the execve(), then reloaded after the
  execve(). Serialized data is stored as text, with key-value pairs
  separated by newlines. Values are escaped to prevent control character
  injection.

  Lines associated with a systemd unit are read in unit_deserialize()
  using fgets():

  char line[LINE_MAX], *l, *v;
  [...]
  if (!fgets(line, sizeof(line), f)) {
  if (feof(f))
  return 0;
  return -errno;
  }

  LINE_MAX is 2048:

  /usr/include/bits/posix2_lim.h:#define LINE_MAX _POSIX2_LINE_MAX
  /usr/include/bits/posix2_lim.h:#define _POSIX2_LINE_MAX 2048

  
  When fgets() encounters overlong input, it behaves dangerously. If a
  line is more than 2047 characters long, fgets() will return the first
  2047 characters and leave the read cursor in the middle of the
  overlong line. Then, when fgets() is called the next time, it
  continues to read data from offset 2047 in the line as if a new line
  started there. Therefore, if an attacker can inject an overlong value
  into the serialized state somehow, it is possible to inject extra
  key-value pairs into the serialized state.

  A service that has `NotifyAccess != none` can send a status message to
  systemd that will be stored as a property of the service. When systemd
  re-executes, this status message is stored under the key
  "status-text".
  Status messages that are sent to systemd are received by
  manager_dispatch_notify_fd(). This function has a receive buffer of
  size NOTIFY_BUFFER_MAX==PIPE_BUF==4096.

  Therefore, a service with `NotifyAccess != none` can trigger this bug.

  
  Reproducer:

  Create a simple service with NotifyAccess by copying the following
  text into /etc/systemd/system/notify_test.service (assuming that your
  home directory is /home/user):

  =
  [Unit]
  Description=jannh test service for systemd notifications

  [Service]
  Type=simple
  NotifyAccess=all
  FileDescriptorStoreMax=100
  User=user
  ExecStart=/home/user/test_service
  Restart=always

  [Install]
  WantedBy=multi-user.target
  =

  Create a small binary that sends an overlong status when it starts up:

  =
  user@ubuntu-18-04-vm:~$ cat test_service.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int sock = socket(AF_UNIX, SOCK_DGRAM, 0);
if (sock == -1) err(1, "socket");
struct sockaddr_un addr = {
.sun_family = AF_UNIX,
.sun_path = "/run/systemd/notify"
};
if (connect(sock, (struct sockaddr *), sizeof(addr))) err(1, 
"connect");

char message[0x2000] = "STATUS=";
memset(message+7, 'X', 2048-1-12);
strcat(message, "main-pid=13371337");
struct iovec iov = {
.iov_base = message,
.iov_len = strlen(message)
};
union {
struct cmsghdr cmsghdr;
char buf[CMSG_SPACE(sizeof(struct ucred))];
} control = { .cmsghdr = {
.cmsg_level = SOL_SOCKET,
.cmsg_type = SCM_CREDENTIALS,
.cmsg_len = CMSG_LEN(sizeof(struct ucred))
}};
struct ucred *ucred = (void*)(control.buf + CMSG_ALIGN(sizeof(struct 
cmsghdr)));
ucred->pid = getpid();
ucred->uid = getuid();
ucred->gid = getgid();
struct msghdr msghdr = {
.msg_iov = ,
.msg_iovlen = 1,
.msg_control = ,
.msg_controllen = sizeof(control)
};
if (sendmsg(sock, , 0) != strlen(message)) err(1, "sendmsg");

while (1) pause();
  }
  user@ubuntu-18-04-vm:~$ gcc -o test_service test_service.c
  user@ubuntu-18-04-vm:~$
  =

  Install the service, and start it. Then run strace against systemd,
  and run:

  =
  root@ubuntu-18-04-vm:~# systemctl daemon-reexec
  

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

2021-07-21 Thread Steve Beattie
Assigning the verification and publication to xenial-security to myself.
Thanks.

** Changed in: openssl (Ubuntu Xenial)
 Assignee: (unassigned) => Steve Beattie (sbeattie)

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

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

[Touch-packages] [Bug 1932331] Re: ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

2021-06-30 Thread Steve Beattie
The root issue is likely something in the utf-8 handling code in glibc
on arm64 hirsute and impish; the reproducer is:

  bash -c 'i=210; echo -n $(printf "\\$(printf "%03o" $i)") | od -An -t uC'
  210 138

running valgrind in a default environemnt (so LANG=en_US.UTF-8) turned
up

==46656== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==46653== Conditional jump or move depends on uninitialised value(s)
==46653==at 0x48EA5EC: utf8_internal_loop (loop.c:336)
==46653==by 0x48EA5EC: __gconv_transform_utf8_internal (skeleton.c:620)
==46653==by 0x494BF57: mbrtowc (mbrtowc.c:86)
==46653==by 0x17FFBB: command_substitute (in /usr/bin/bash)

and running the test with LANG=C results in the trailing artifact (138)
to not show up.

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

Title:
  ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

Status in AppArmor:
  In Progress
Status in apparmor package in Ubuntu:
  New

Bug description:
  It only affects arm64:

  ...
   06/15 13:09:11 ERROR| utils:0153| [stderr] running i18n

   06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test
   'i18n (194) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_Š_post"
   RW' was expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_Š_post failed - Permission denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (195) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_Ê_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_Ê_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (196) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test 'i18n 
(197) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post" RW' was 
expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post failed - Permission denied'
  ...

  
  Full log without LP manging the formatting: 
http://paste.ubuntu.com/p/3PHcCWb9Jw/plain/

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

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


[Touch-packages] [Bug 1932331] Re: ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

2021-06-30 Thread Steve Beattie
Georgia's patch was committed in the upstream apparmor project in
https://gitlab.com/apparmor/apparmor/-/commit/458a981b6242e8b1cce1599ca95d89dcd10f60e7
in https://gitlab.com/apparmor/apparmor/-/merge_requests/765 and was
cherrypicked to the apparmor-3.0 branch amongst others in
https://gitlab.com/apparmor/apparmor/-/commit/0729b13293d775dfd6ec4c9a3b9313b6e125d540
.

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

Title:
  ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

Status in AppArmor:
  In Progress
Status in apparmor package in Ubuntu:
  New

Bug description:
  It only affects arm64:

  ...
   06/15 13:09:11 ERROR| utils:0153| [stderr] running i18n

   06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test
   'i18n (194) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_Š_post"
   RW' was expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_Š_post failed - Permission denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (195) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_Ê_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_Ê_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (196) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test 'i18n 
(197) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post" RW' was 
expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post failed - Permission denied'
  ...

  
  Full log without LP manging the formatting: 
http://paste.ubuntu.com/p/3PHcCWb9Jw/plain/

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

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


[Touch-packages] [Bug 1932331] Re: ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

2021-06-29 Thread Steve Beattie
** Also 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/1932331

Title:
  ubuntu_qrt_apparmor: i18n test fails on arm64 Hirsute / Impish

Status in AppArmor:
  In Progress
Status in apparmor package in Ubuntu:
  New

Bug description:
  It only affects arm64:

  ...
   06/15 13:09:11 ERROR| utils:0153| [stderr] running i18n

   06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test
   'i18n (194) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_Š_post"
   RW' was expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_Š_post failed - Permission denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (195) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_Ê_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_Ê_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed.
  Test 'i18n (196) OPEN (octal)
  "/tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post" RW' was expected to
  'pass'. Reason for failure 'FAIL: open
  /tmp/sdtest.411763-18905-et6mgO/file_ÄŠ_post failed - Permission
  denied'

  06/15 13:09:11 ERROR| utils:0153| [stderr] Error: open failed. Test 'i18n 
(197) OPEN (octal) "/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post" RW' was 
expected to 'pass'. Reason for failure 'FAIL: open 
/tmp/sdtest.411763-18905-et6mgO/file_ÅŠ_post failed - Permission denied'
  ...

  
  Full log without LP manging the formatting: 
http://paste.ubuntu.com/p/3PHcCWb9Jw/plain/

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

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


[Touch-packages] [Bug 1152187] Re: [MIR] systemd

2021-05-27 Thread Steve Beattie
Yes, the systemd-container package will end up in main, likely for the
current package in bionic-updates, and thus will be reflected that way
in rmadison etc.

For the record, ack from the Ubuntu Security Team on promoting the
systemd-container binary from universe to main in bionic.

Thanks.

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

Title:
  [MIR] systemd

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Incomplete

Bug description:
  * The package is in universe and built on all archs:
  https://launchpad.net/ubuntu/+source/systemd/44-10ubuntu1

  * Rationale:

  - in a first step we want systemd-services promoted to replace ubuntu-
  system-services

  -  We will also want to move from consolekit to logind soon
  (https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303
  -consolekit-logind-migration)

  - udev has been merged in the systemd source upstream so we will want
  to build it from there at some point as well

  we don't plan to use the systemd init system at this point

  * Security:

  there has been some security issues in the past
  http://secunia.com/advisories/search/?search=systemd
  http://secunia.com/advisories/48220/
  http://secunia.com/advisories/48208/
  http://secunia.com/advisories/48331/

  Those are mostly logind issue and have been fixed upstream.

  Our current package is outdated but we do plan to update it before
  starting using logind. There should be no issue with the services

  * Quality:
  - there is no RC bug in debian: 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=systemd
  - there is no bug open in launchpad: 
https://launchpad.net/ubuntu/+source/systemd/+bugs
  - upstream is active and responsive to issues

  The desktop bugs team is subscribed to the package in launchpad,
  foundations/desktop will maintain the package and look to the bug
  reports regularly.

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

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


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

2021-05-10 Thread Steve Beattie
The Ubuntu Security team is +1 on disallowing purely numeric usernames,
as they are too easily confused with UIDs.

I think our preference would be to disallow leading numeric digits
entirely so that for example, 0x0 and 0o0 would be blocked as well, to
try to prevent both user and programmatic confusion.

Probably adduser should also be made consistent with whatever change is
made to useradd. The package provided adduser.conf files do have a
NAME_REGEX option (in addition to the --force-badname option) but AFAICT
is commented out by default (the commented out regex is
"^[a-z][-a-z0-9_]*\$" but I'm not sure that's appropriate in a UTF-8
world.)

It would be good to have testcase and documentation for this captured
somewhere.

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

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

Status in shadow package in Ubuntu:
  New
Status in shadow source package in Focal:
  New
Status in shadow source package in Groovy:
  New
Status in shadow source package in Hirsute:
  New
Status in shadow source package in Impish:
  New

Bug description:
  [Description]

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

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

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

  ..

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

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

  And pam-systemd shows the following message:

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

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

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

  
  [Other info]

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

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

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


[Touch-packages] [Bug 1925411] [NEW] apparmor adt test failure blocking tcpdump migration

2021-04-21 Thread Steve Beattie
Public bug reported:

tcpdump has a sync from debian 4.99.0-2 that is currently blocked in
hirsute-proposed due to a regression in the apparmor adt tests. The
reason for this failure is that 'compile-policy' testcase is failing;
this test ensures that various apparmor policies included in packages
are accepted by the apparmor policy parser.

In the new version of tcpdump 4.99.0-2, the tcpdump binary is installed
into /usr/bin/tcpdump, and the tcpdump apparmor policy has been renamed
from usr.sbin.tcpdump to usr.bin.tcpdump to match. The apparmor adt test
however was not also changed to match, and so fails with:

  Addition succeeded for "/usr/sbin/ntpd".
  Testing usr.sbin.tcpdump
  File /etc/apparmor.d/usr.sbin.tcpdump not found, skipping...
  autopkgtest [15:35:53]: test compile-policy: ---]
  autopkgtest [15:35:54]: test compile-policy:  - - - - - - - - - - results - - 
- - - - - - - -
  compile-policy   FAIL non-zero exit status 2

causing the entire adt test to fail.

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

Title:
  apparmor adt test failure blocking tcpdump migration

Status in apparmor package in Ubuntu:
  New

Bug description:
  tcpdump has a sync from debian 4.99.0-2 that is currently blocked in
  hirsute-proposed due to a regression in the apparmor adt tests. The
  reason for this failure is that 'compile-policy' testcase is failing;
  this test ensures that various apparmor policies included in packages
  are accepted by the apparmor policy parser.

  In the new version of tcpdump 4.99.0-2, the tcpdump binary is
  installed into /usr/bin/tcpdump, and the tcpdump apparmor policy has
  been renamed from usr.sbin.tcpdump to usr.bin.tcpdump to match. The
  apparmor adt test however was not also changed to match, and so fails
  with:

Addition succeeded for "/usr/sbin/ntpd".
Testing usr.sbin.tcpdump
File /etc/apparmor.d/usr.sbin.tcpdump not found, skipping...
autopkgtest [15:35:53]: test compile-policy: ---]
autopkgtest [15:35:54]: test compile-policy:  - - - - - - - - - - results - 
- - - - - - - - -
compile-policy   FAIL non-zero exit status 2

  causing the entire adt test to fail.

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

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


[Touch-packages] [Bug 1895839] Re: CVE-2020-24977

2021-04-12 Thread Steve Beattie
Please note that upstream has indicated that this issue only affects the
xmllint binary, and not the shared library.

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

Title:
  CVE-2020-24977

Status in libxml2 package in Ubuntu:
  Fix Released
Status in libxml2 source package in Hirsute:
  Fix Released
Status in libxml2 package in Debian:
  Fix Released

Bug description:
  GNOME project libxml2 v2.9.10 and earlier have a global buffer over-
  read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.

  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977

  Upstream patch: 
  
https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2

  Bug report: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178

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

-- 
Mailing list: https://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 1923432] Re: apparmor-utils: missing CAP_CHECKPOINT_RESTORE in /etc/apparmor/severity.db

2021-04-12 Thread Steve Beattie
On Mon, Apr 12, 2021 at 03:07:45PM -, Andrea Righi wrote:
> @sbeattie sorry I didn't notice your comment, I can post another debdiff
> that includes the proper upstream commit.

Probably would be for the best for when we do a merge in the I
cycle, to make identifying which patches can be dropped that much
easier. Thanks.

-- 
Steve Beattie


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

Title:
  apparmor-utils: missing CAP_CHECKPOINT_RESTORE in
  /etc/apparmor/severity.db

Status in apparmor package in Ubuntu:
  New
Status in apparmor source package in Hirsute:
  New

Bug description:
  It looks like /etc/apparmor/severity.db is missing the new capability
  CAP_CHECKPOINT_RESTORE.

  This causes the following regression test failure:

ERROR: capability CAP_CHECKPOINT_RESTORE not found in severity.db
make: *** [Makefile:81: check_severity_db] Error 1

  This new capability is correctly supported by the parser already (see
  d/p/ubuntu/parser-Add-support-for-cap-checkpoint-restore.patch), so we
  probably need to update severity.db as well.

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

-- 
Mailing list: https://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 1923432] [NEW] apparmor-utils: missing CAP_CHECKPOINT_RESTORE in /etc/apparmor/severity.db

2021-04-12 Thread Steve Beattie
This is https://gitlab.com/apparmor/apparmor/-/merge_requests/656
upstream, and was addressed in
https://gitlab.com/apparmor/apparmor/-/merge_requests/656/diffs?commit_id=2c2dbdc3a3012ce06371edc1e9be6f58711d8565
on the master branch and was cherrypicked to the apparmor 3.0 branch in
https://gitlab.com/apparmor/apparmor/-/commit/80efc15e18a6bb0d0abd2821cb03bf6be51cc517
This should be safe to cherrypick for hirsute.

(Similar cherrypicks occurred for prior AppArmor branches.)

-- 
Steve Beattie


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

Title:
  apparmor-utils: missing CAP_CHECKPOINT_RESTORE in
  /etc/apparmor/severity.db

Status in apparmor package in Ubuntu:
  New
Status in apparmor source package in Hirsute:
  New

Bug description:
  It looks like /etc/apparmor/severity.db is missing the new capability
  CAP_CHECKPOINT_RESTORE.

  This causes the following regression test failure:

ERROR: capability CAP_CHECKPOINT_RESTORE not found in severity.db
make: *** [Makefile:81: check_severity_db] Error 1

  This new capability is correctly supported by the parser already (see
  d/p/ubuntu/parser-Add-support-for-cap-checkpoint-restore.patch), so we
  probably need to update severity.db as well.

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

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


[Touch-packages] [Bug 1921485] Re: Bosch CERT Advisory: OpenSSL Multiple Vulnerabilities

2021-03-30 Thread Steve Beattie
This was addressed in https://ubuntu.com/security/notices/USN-4891-1 .

** Information type changed from Private Security to Public Security

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

Title:
  Bosch CERT Advisory: OpenSSL Multiple Vulnerabilities

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Description

  Multiple vulnerabilities have been reported in OpenSSL, which can be
  exploited by malicious people to bypass certain security restrictions
  and cause a DoS (Denial of Service).

  1

  An error when validating CA certificates can be exploited to bypass
  certificate validation checks.

  Successful exploitation of the vulnerability #1 requires the
  X509_V_FLAG_X509_STRICT flag to be enabled (not enabled by default)
  and an application to either not set a purpose for certificate
  verification or override the default purpose.

  2

  A NULL-pointer deference error when handling renegotiation ClientHello
  messages can be exploited to crash the OpenSSL TLS server.

  Successful exploitation of the vulnerability #2 requires an OpenSSL
  server with TLSv1.2 and renegotiation enabled (enabled by default).

  The vulnerabilities are reported in versions prior to 1.1.1k.

  Affected Software

  The following software is affected by the described vulnerability.
  Please check the vendor links below to see if exactly your version is
  affected.

  OpenSSL 1.x

  Solution

  Update to version 1.1.1k.

  References

  1. https://www.openssl.org/news/vulnerabilities.html 

  2. https://www.openssl.org/news/secadv/20210325.txt 


  
  Please provide a fix as soon as possible.

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

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


[Touch-packages] [Bug 1921690] Re: I dont know

2021-03-30 Thread Steve Beattie
Thank you for using Ubuntu and taking the time to report a bug. Your
report should contain, at a minimum, the following information so we can
better find the source of the bug and work to resolve it.

Submitting the bug about the proper source package is essential. For
help see https://wiki.ubuntu.com/Bugs/FindRightPackage . Additionally,
in the report please include:

1) The release of Ubuntu you are using, via 'cat /etc/lsb-release' or System -> 
About Ubuntu.
2) The version of the package you are using, via 'dpkg -l PKGNAME | cat' or by 
checking in Synaptic.
3) What happened and what you expected to happen.

The Ubuntu community has also created debugging procedures for a wide
variety of packages at https://wiki.ubuntu.com/DebuggingProcedures .
Following the debugging instructions for the affected package will make
your bug report much more complete. Thanks!


** Package changed: ubuntu => xorg (Ubuntu)

** Information type changed from Private Security to Public

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

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

Title:
  I dont know

Status in xorg package in Ubuntu:
  Invalid

Bug description:
  I dont know

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-45.51~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-45-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Mar 29 00:50:07 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
 Subsystem: Lenovo HD Graphics 620 [17aa:3988]
  InstallationDate: Installed on 2021-03-16 (13 days ago)
  InstallationMedia: Ubuntu 20.04.2 LTS "Focal Fossa" - Release amd64 (20210204)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 0cf3:e300 Qualcomm Atheros Communications 
   Bus 001 Device 003: ID 06cb:0081 Synaptics, Inc. 
   Bus 001 Device 002: ID 13d3:5621 IMC Networks EasyCamera
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: LENOVO 80X6
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-generic 
root=UUID=fa69165d-92ad-4dfe-9070-67261b9c30f3 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/14/2017
  dmi.bios.release: 1.21
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 1YCN21WW(V1.06)
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: Lenovo YOGA 720-13IKB
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 31
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo YOGA 720-13IKB
  dmi.ec.firmware.release: 1.21
  dmi.modalias: 
dmi:bvnLENOVO:bvr1YCN21WW(V1.06):bd04/14/2017:br1.21:efr1.21:svnLENOVO:pn80X6:pvrLenovoYOGA720-13IKB:rvnLENOVO:rnLenovoYOGA720-13IKB:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA720-13IKB:
  dmi.product.family: IDEAPAD
  dmi.product.name: 80X6
  dmi.product.sku: LENOVO_MT_80X6_BU_idea_FM_Lenovo YOGA 720-13IKB
  dmi.product.version: Lenovo YOGA 720-13IKB
  dmi.sys.vendor: LENOVO
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1kisak1~f
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1~kisak1~f
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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


[Touch-packages] [Bug 388605] Re: [MIR] rsyslog

2021-03-30 Thread Steve Beattie
Ack by the Ubuntu Security team to move rsyslog-gnutls to main, both for
hirsute, and for bionic, focal, and groovy. Thanks!

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

Title:
  [MIR] rsyslog

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  New
Status in rsyslog source package in Focal:
  New
Status in rsyslog source package in Groovy:
  New
Status in rsyslog source package in Hirsute:
  Fix Released

Bug description:
  Binary package hint: rsyslog

  We want to make rsyslog the new default syslogger.

  See https://wiki.ubuntu.com/MainInclusionReport/rsyslog

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

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


[Touch-packages] [Bug 1919285] Re: Nvidia

2021-03-16 Thread Steve Beattie
** Information type changed from Private Security to Public

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

Title:
  Nvidia

Status in xorg package in Ubuntu:
  New

Bug description:
  My ubuntu resolution stuck at 648 * 480 after update

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.8.0-45.51~20.04.1-generic 5.8.18
  Uname: Linux 5.8.0-45-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 16 10:47:35 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: I just need to know a workaround
  GraphicsCard:
   NVIDIA Corporation GF119M [GeForce GT 520M] [10de:1050] (rev a1) (prog-if 00 
[VGA controller])
 Subsystem: Sony Corporation GF119M [GeForce GT 520M] [104d:9089]
  InstallationDate: Installed on 2021-03-16 (0 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: Sony Corporation VPCF225FG
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-generic 
root=UUID=07adf20e-fc3e-4113-9c16-70e8baf8bb71 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/05/2011
  dmi.bios.release: 11.90
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: R1190V3
  dmi.board.asset.tag: N/A
  dmi.board.name: VAIO
  dmi.board.vendor: Sony Corporation
  dmi.board.version: N/A
  dmi.chassis.asset.tag: N/A
  dmi.chassis.type: 10
  dmi.chassis.vendor: Sony Corporation
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 11.90
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrR1190V3:bd09/05/2011:br11.90:efr11.90:svnSonyCorporation:pnVPCF225FG:pvrC6090QKJ:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
  dmi.product.family: VAIO
  dmi.product.name: VPCF225FG
  dmi.product.sku: N/A
  dmi.product.version: C6090QKJ
  dmi.sys.vendor: Sony Corporation
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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


[Touch-packages] [Bug 1916893] Re: Regression - upate python2.7 for cover CVE-2021-3177 modifying unicode parts cause serious regressions

2021-02-25 Thread Steve Beattie
** 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 python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1916893

Title:
  Regression - upate python2.7 for cover CVE-2021-3177 modifying unicode
  parts cause serious regressions

Status in python2.7 package in Ubuntu:
  New

Bug description:
  [Scenario]
  A security update was made for python2.7 in xenial and bionic that can cause 
a serious regression since it is modifying unicode code for python2.7.

  [Issue]
  It can cause a serious break in the way python prints, rprs, unicode 
information, causing serious damage for any application that is running 
python2.7 in that scenario.

  [More info]
  https://ubuntu.com/security/CVE-2021-3177

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1916893/+subscriptions

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


[Touch-packages] [Bug 1904615] Re: cpio symlink traversal

2021-02-09 Thread Steve Beattie
Hello Yiğit,

Sorry for the delay in responding to this issue. This issue was
originally identified as CVE-2015-1197 and fixed around the same time
frame. It was addressed in upstream cpio commit
https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=45b0ee2b407913c533f7ded8d6f8cbeec16ff6ca
in a differently taken approach when vendors fixed the issue in 2015.
This differening behavior change resulted in the debian maintainer
undoing the symlink mangling portion of the fix via
https://salsa.debian.org/lamby/pkg-
cpio/-/commit/1d1163018b2ca240a6a1c9404f7e05c3bfa62f94 and this is what
has landed in focal and newer.

Relevant debian bug reports:

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

upstream thread about the issue:

  https://lists.gnu.org/archive/html/bug-cpio/2019-11/msg00013.html

Alas, at this time, it does not appear to have been addressed upstream.

Thanks for the report.

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

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

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

** Package changed: ubuntu => cpio (Ubuntu)

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

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

Title:
  cpio symlink traversal

Status in cpio package in Ubuntu:
  Confirmed

Bug description:
  Summary:
  A malicious file may be able to overwrite arbitrary files

  Steps to reproduce:
  1- Download "dirsymlink.cpio"
  2- Extract it with "cpio -i < dirsymlink.cpio" command

  Proof of concept:
  dirsymlink.mp4

  Version:
  Ubuntu 20.10

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

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


[Touch-packages] [Bug 1909608] Re: networkmanager sets DNS server configuration without proper dns-search/dns-priority causing DNS requests leak to ISP (openconnect+split-tunnel+non-split DNS)

2021-02-09 Thread Steve Beattie
Hi Adam,

Marking public given the public bug reports elsewhere.

It looks like upstream addressed this in network-manager 1.28, which has
not made it into Ubuntu yet.

** Information type changed from Private Security to Public Security

** Changed in: network-manager (Ubuntu)
   Status: New => Confirmed

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

Title:
  networkmanager sets DNS server configuration without proper dns-search
  /dns-priority causing DNS requests leak to ISP (openconnect+split-
  tunnel+non-split DNS)

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  
  VPN server configuration is split tunneling (default route is local ISP) with 
"global/primary/main" DNS pushed from VPN (it's important to note that it's not 
split DNS).

  REDACTED@REDACTED:~$ ip r
  default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
  10.0.0.0/24 dev vpn0 proto static scope link metric 50 

  VPN (OpenConnect) provides own DNS servers without "DNS Domain".
  Connection syslog:

  Dec 29 08:48:28 REDACTED NetworkManager[1038]:   Data:   Internal DNS: 
192.168.100.10
  Dec 29 08:48:28 REDACTED NetworkManager[1038]:   Data:   Internal DNS: 
192.168.100.11
  Dec 29 08:48:28 REDACTED NetworkManager[1038]:   Data:   DNS Domain: 
'(none)'

  All DNS requests should be routed through VPN yet the dns-priority and
  dns-search configuration restricts it from doing so:

  Dec 29 20:30:38 REDACTED systemd-resolved[1017]: Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying 
transaction with reduced feature level UDP.
  Dec 29 20:30:41 REDACTED systemd-resolved[1017]: message repeated 48 times: [ 
Server returned error NXDOMAIN, mitigating potential DNS violation 
DVE-2018-0001, retrying transaction with reduced feature level UDP.]

  I can confirm that changing dns-search to wildcard: ~. and dns-
  priority to -50 is resolving the issue.

  REDACTED@REDACTED:~$ nmcli c show vpn.example.com | grep ipv4.dns
  ipv4.dns:   --
  ipv4.dns-search:--
  ipv4.dns-options:   --
  ipv4.dns-priority:  50

  REDACTED@REDACTED:~$ resolvectl status
  Link 5 (vpn0)
Current Scopes: none
  DefaultRoute setting: no  
 LLMNR setting: yes 
  MulticastDNS setting: no  
DNSOverTLS setting: no  
DNSSEC setting: no  
  DNSSEC supported: no  
  Link 3 (wlo1)
Current Scopes: DNS
  DefaultRoute setting: yes
 LLMNR setting: yes
  MulticastDNS setting: no 
DNSOverTLS setting: no 
DNSSEC setting: no 
  DNSSEC supported: no 
Current DNS Server: 8.8.8.8
   DNS Servers: 8.8.8.8
8.8.4.4
DNS Domain: ~. 

  
  REDACTED@REDACTED:~$ nmcli c modify vpn.example.com ipv4.dns-search ~.
  REDACTED@REDACTED:~$ nmcli c modify vpn.example.com ipv4.dns-priority -50 

  REDACTED@REDACTED:~$ nmcli c show vpn.example.com | grep ipv4.dns
  ipv4.dns:   --
  ipv4.dns-search:~.
  ipv4.dns-options:   --
  ipv4.dns-priority:  -50

  VPN Restart and our new settings are working properly:

  REDACTED@REDACTED:~$ resolvectl status
  Link 5 (vpn0)
Current Scopes: DNS  
  DefaultRoute setting: yes  
 LLMNR setting: yes  
  MulticastDNS setting: no   
DNSOverTLS setting: no   
DNSSEC setting: no   
  DNSSEC supported: no   
Current DNS Server: 192.168.100.10
   DNS Servers: 192.168.100.10
192.168.100.11
DNS Domain: ~.  
  Link 3 (wlo1)
Current Scopes: none
  DefaultRoute setting: no  
 LLMNR setting: yes 
  MulticastDNS setting: no  
DNSOverTLS setting: no  
DNSSEC setting: no  
  DNSSEC supported: no  

  When OpenConnect receives "DNS Domain" (split DNS configuration)
  everything works as intended:

  Dec 29 08:46:32 REDACTED NetworkManager[1038]:   Data:   Internal DNS: 
192.168.100.10
  Dec 29 08:46:32 REDACTED NetworkManager[1038]:   Data:   Internal DNS: 
192.168.100.11
  Dec 29 08:46:32 REDACTED NetworkManager[1038]:   Data:   DNS Domain: 
'example.com'

  REDACTED@REDACTED  ~  resolvectl status
  Link 6 (vpn0)
Current Scopes: DNS  
  DefaultRoute setting: yes  
 LLMNR setting: yes  
  MulticastDNS setting: no   
DNSOverTLS setting: no   
DNSSEC setting: no   
  DNSSEC supported: no   
Current DNS Server: 192.168.100.10
   DNS Servers: 192.168.100.10
192.168.100.11
DNS Domain: example.com
  
  PR for the bug in 

[Touch-packages] [Bug 1912091] Re: Memory Leak GNU Tar 1.33

2021-02-09 Thread Steve Beattie
** Changed in: tar (Ubuntu)
   Status: New => Triaged

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

Title:
  Memory Leak GNU Tar 1.33

Status in tar package in Ubuntu:
  Triaged

Bug description:
  
  An issue was discovered in GNU Tar 1.33 and earlier. There is a memory leak 
in read_header() in list.c in the tar application. Occastionally, ASAN detects 
an out of bounds memory read. Valgrind confirms the memory leak in the standard 
tar tool installed by default. This degrades the availability of the tar tool, 
and could potentially result in other memory-related issues.

  Common Weakness Enumeration IDs for reference:
  CWE-401: Missing Release of Memory after Effective Lifetime
  CWE-125: Out-of-bounds Read

  Attached to this report is a PoC malcrafted file "1311745-out-
  bounds.tar"

  VALGRIND OUTPUT:
  valgrind tar -xf 1311745-out-bounds.tar 
  ==3776== Memcheck, a memory error detector
  ==3776== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
  ==3776== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
  ==3776== Command: tar -xf output/1311745-out-bounds.tar
  ==3776== 
  tar: Unexpected EOF in archive
  tar: Exiting with failure status due to previous errors
  ==3776== 
  ==3776== HEAP SUMMARY:
  ==3776== in use at exit: 1,311,761 bytes in 2 blocks
  ==3776==   total heap usage: 52 allocs, 50 frees, 1,349,212 bytes allocated
  ==3776== 
  ==3776== LEAK SUMMARY:
  ==3776==definitely lost: 1,311,745 bytes in 1 blocks
  ...

  NOTE: Version 1.30, 1.32, 1.33 were tested and confirmed to be
  vulnerable.

  lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  apt-cache policy tar
  tar:
Installed: 1.30+dfsg-7ubuntu0.20.04.1
Candidate: 1.30+dfsg-7ubuntu0.20.04.1

  ---
  Carlos

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

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


[Touch-packages] [Bug 1914279] Re: linux from security may force reboots without complete dkms modules

2021-02-09 Thread Steve Beattie
Hi Dimitri, I don't know that all dkms SRUs need to go to the security
pockets, but ones that fix build issues surely do, given the problems
that a dkms build failure causes in package installs.

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

Title:
  linux from security may force reboots without complete dkms modules

Status in apt package in Ubuntu:
  Invalid
Status in dkms package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in linux-meta package in Ubuntu:
  New
Status in unattended-upgrades package in Ubuntu:
  Invalid
Status in update-manager package in Ubuntu:
  Invalid

Bug description:
  Whilst discussing

  https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-
  ubuntu-desktop-installation-media/20606

  We have noticed a reference to somebody not having working backport-
  iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8
  switch.

  However, kernel meta switch was pushed to security pocket, but the
  dkms modules are all in -updates only.

  This may result in people automatically installing the new kernel with
  unatanded upgrades; dkms modules failing to build; and a reboot
  required flag left on disk.

  At this point launching update manager will not offer to install dkms
  modules from updates, and will guide the users to reboot. which
  will then cause them to boot the new kernel without the dkms modules
  that might be providing networking for them.

  Should dkms modules SRUs always getting published into -security
  pocket, as well as the -updates pocket?

  Should linux maintainer scripts prevent touching reboot required flag
  if any dkms modules fail to build?

  Should apt / unattanded-upgrades / update-manager always update dkms
  modules with kernels?

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

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


[Touch-packages] [Bug 1914839] Re: package upgrade should replace /etc/ssl/certs/ca-certificates.crt atomically

2021-02-09 Thread Steve Beattie
Ah yes, /usr/sbin/update-ca-certificates is deleting the ca-
certificates.crt shortly before atomically moving the new version into
place.

It looks like a fic was committed in debian for this a couple of weeks ago: 
 
 
https://salsa.debian.org/debian/ca-certificates/-/commit/8f8f4a525bd6a6c8a8d13530cda194d60275313d

but has not landed there.

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

** Also affects: ca-certificates (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920348
   Importance: Unknown
   Status: Unknown

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

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

Title:
  package upgrade should replace /etc/ssl/certs/ca-certificates.crt
  atomically

Status in ca-certificates package in Ubuntu:
  Confirmed
Status in ca-certificates package in Debian:
  Unknown

Bug description:
  While upgrading the ca-certificates package, a process got the error:

  SSL_ca_file /etc/ssl/certs/ca-certificates.crt does not exist

  This file should be replaced atomically, with no time gap where the
  file does not exist.

  (I am flagging this as a security vulnerability because, while I did
  not experience any security issue, I can imagine at least the
  possibility of this being exploitable in some way in some
  circumstances.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1914839/+subscriptions

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


[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-04 Thread Steve Beattie
For fixing this via an SRU for focal and groovy, the Ubuntu Security
team is okay with the result of this going to the security pocket,
assuming the update is built in a ppa where only security updates are
enabled.

Thanks!

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

Title:
  use the size of the data when determing the server response

Status in whoopsie package in Ubuntu:
  Fix Released
Status in whoopsie source package in Focal:
  New
Status in whoopsie source package in Groovy:
  New
Status in whoopsie source package in Hirsute:
  Fix Released

Bug description:
  whoopsie's server_response code is using "g_string_append" instead of
  "g_string_append_len" which has the knock on effect of sending too
  much data to its "handle_response". This ends up being a problem if
  the daisy servers are running on Ubuntu 18.04 instead of Ubuntu 16.04.

  Here's an example when using whoopsie on groovy to send a crash to a
  bionic daisy server:

  [15:35:30] Sent; server replied with: No error
  [15:35:30] Response code: 200
  [15:35:30] Initial response data is: 2bbb776e-64e6-11eb-a8d6-00163eddedf4 
OOPSID
  0

  [15:35:30] Got command: OOPSID

  We can see a fair number of extra characters (\n0\n\n) after the OOSID
  command.

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

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


[Touch-packages] [Bug 1913482] Re: Update tzdata to version 2021a

2021-01-31 Thread Steve Beattie
Hi Brian, thanks for preparing the debdiffs. I built, tested, and
published the updated tzdata packages to the trusty/esm and precise/esm
archives.

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

Title:
  Update tzdata to version 2021a

Status in tzdata package in Ubuntu:
  In Progress
Status in tzdata source package in Xenial:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Released
Status in tzdata source package in Focal:
  Fix Released
Status in tzdata source package in Groovy:
  Fix Released

Bug description:
  New upstream version affecting the following timestamp:

  - South Sudan changes from +03 to +02 on 2021-02-01 at 00:00.

  $region/$timezone = Africa/Juba

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Africa/Juba'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v Africa/Juba | grep 2021

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  [Test Case for releases >= 20.04 LTS]
  1) sudo apt-get install python3-icu
  2) python3 -c 'from datetime import datetime; from icu import ICUtzinfo, 
TimeZone; tz = ICUtzinfo(TimeZone.creat eTimeZone('Africa/Juba')); 
print(str(tz.utcoffset(datetime(2021, 2, 1'

  Additionally, an upstream update of tzdata removed the 'old' SystemV
  timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
  and earlier releases. Subsequently, these should be checked for using
  the following:

  [Test Case for releases <= 20.04 LTS]
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

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

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


[Touch-packages] [Bug 1904082] Re: apport's log collecting leaks MAC addresses maybe helping WiFi attacks?

2021-01-21 Thread Steve Beattie
** 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 apport in Ubuntu.
https://bugs.launchpad.net/bugs/1904082

Title:
  apport's log collecting leaks MAC addresses maybe helping WiFi
  attacks?

Status in apport package in Ubuntu:
  New

Bug description:
  Some people configure their Internet WiFi modems such that
  only certain devices, defined by their MAC addresses, can
  (try to?) connect.  I am aware this is VERY WEAK "security"
  since MAC addresses are easily spoofed.

  It occurs to me that the logs collected by apport-cli(1)
  and friends, when reporting a bug, contain the system's
  MAC addresses.  Those logs are normally publicly readable
  by anyone browsing Launchpad.  That means villains could
  reap (collect) MAC addresses to spoof and try to obtain an
  unintended WiFi connection.  (Isn't necessarily easy since
  the attacker would have(?) to be within range of the modem
  to try?)

  I am NOT saying this has happened — I have no idea.

  I just wanted to bring this hypothetical(?) problem/attack
  to your attention.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apport 2.20.11-0ubuntu27.12
  ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
  Uname: Linux 5.4.0-53-generic x86_64
  ApportLog:
   
  ApportVersion: 2.20.11-0ubuntu27.12
  Architecture: amd64
  CasperMD5CheckResult: skip
  CrashReports:
   664:1000:125:0:2020-11-13 03:00:18.498740147 +0100:2020-11-13 
03:00:18.498740147 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.upload
   600:118:125:37:2020-11-13 03:00:19.490721528 +0100:2020-11-13 
03:00:19.490721528 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.uploaded
   640:1000:125:798567:2020-11-13 03:00:16.626756668 +0100:2020-11-13 
03:00:17.626756668 +0100:/var/crash/_usr_bin_kglobalaccel5.1000.crash
  Date: Fri Nov 13 03:03:36 2020
  InstallationDate: Installed on 2020-10-19 (24 days ago)
  InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1911211] Re: Please upgrade to openssl 1.1.1g or later for 20.04

2021-01-20 Thread Steve Beattie
** Changed in: openssl (Ubuntu)
   Status: New => Invalid

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

Title:
  Please upgrade to openssl 1.1.1g or later for 20.04

Status in openssl package in Ubuntu:
  Invalid

Bug description:
  There is a CVE for openssl (
  https://www.openssl.org/news/vulnerabilities.html#CVE-2020-1967 )
  which has been resolved in openssl v1.1.1g. The currently-shipped
  version for Ubuntu 20.04 is 1.1.1f.  I do see 1.1.1i as a branch in
  launchpad, but that appears to be an import from Debian Sid.

  Please upgrade as you are able. I would be willing to test this
  package. Thank you!

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

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


[Touch-packages] [Bug 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions

2021-01-18 Thread Steve Beattie
Oh, I was expecting that it would also be desirable to SRU this back to
focal, as I expected CONFIG_SECURITY_DMESG_RESTRICT to come back with
the HWE kernels, but looking at the config for linux-hwe-5.8, it appears
that the old behavior was kept.

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

Title:
  /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT
  restrictions

Status in rsyslog package in Ubuntu:
  In Progress
Status in rsyslog source package in Groovy:
  In Progress
Status in rsyslog source package in Hirsute:
  In Progress

Bug description:
  [Impact]

  In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the
  Ubuntu kernel starting with Groovy and onward, in an effort to
  restrict access to the kernel log buffer from unprivileged users.

  It seems we have overlooked /var/log/dmesg, as it is still mode 0644,
  while /var/log/kern.log, /var/log/syslog are all 0640:

  $ ll /var/log
  -rw-r--r--   1 root  adm 81768 Jan 18 09:09 dmesg
  -rw-r-   1 syslogadm 24538 Jan 18 13:05 
kern.log
  -rw-r-   1 syslogadm213911 Jan 18 13:22 syslog

  Change /var/log/dmesg to 0640 to close the information leak.

  [Testcase]

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  [0.00] kernel: Linux version 5.8.0-36-generic 
(buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld 
(GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 
11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18)
  [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---

  If you install the package in the following ppa:

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

  $ sudo systemctl daemon-reload
  $ sudo systemctl start dmesg.service

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  cat: /var/log/dmesg: Permission denied

  [Where problems could occur]

  Some users or log scraper programs might need to view the kernel log
  buffers, and in this case, their underlying service accounts should be
  added to the 'adm' group.

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

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


[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2021-01-18 Thread Steve Beattie
*** This bug is a duplicate of bug 1912122 ***
https://bugs.launchpad.net/bugs/1912122

** This bug has been marked a duplicate of bug 1912122
   /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT 
restrictions

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions

2021-01-18 Thread Steve Beattie
The Ubuntu Security team would like to see this fixed, though it
probably would be worth adding the following change to the service file
so that on log rotation the permissions are corrected as well:

-ExecStartPre=-/usr/bin/savelog -q -p -n -c 5 /var/log/dmesg
+ExecStartPre=-/usr/bin/savelog -m640 -q -p -n -c 5 /var/log/dmesg

Thanks!

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

Title:
  /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT
  restrictions

Status in rsyslog package in Ubuntu:
  In Progress
Status in rsyslog source package in Groovy:
  In Progress
Status in rsyslog source package in Hirsute:
  In Progress

Bug description:
  [Impact]

  In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the
  Ubuntu kernel starting with Groovy and onward, in an effort to
  restrict access to the kernel log buffer from unprivileged users.

  It seems we have overlooked /var/log/dmesg, as it is still mode 0644,
  while /var/log/kern.log, /var/log/syslog are all 0640:

  $ ll /var/log
  -rw-r--r--   1 root  adm 81768 Jan 18 09:09 dmesg
  -rw-r-   1 syslogadm 24538 Jan 18 13:05 
kern.log
  -rw-r-   1 syslogadm213911 Jan 18 13:22 syslog

  Change /var/log/dmesg to 0640 to close the information leak.

  [Testcase]

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  [0.00] kernel: Linux version 5.8.0-36-generic 
(buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld 
(GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 
11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18)
  [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---

  If you install the package in the following ppa:

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

  $ sudo systemctl daemon-reload
  $ sudo systemctl start dmesg.service

  $ sudo adduser dave
  $ su dave
  $ groups
  dave
  $ cat /var/log/kern.log
  cat: /var/log/kern.log: Permission denied
  $ cat /var/log/syslog
  cat: /var/log/syslog: Permission denied
  $ cat /var/log/dmesg
  cat: /var/log/dmesg: Permission denied

  [Where problems could occur]

  Some users or log scraper programs might need to view the kernel log
  buffers, and in this case, their underlying service accounts should be
  added to the 'adm' group.

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

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


[Touch-packages] [Bug 1909698] Re: new upstream release 2020f

2021-01-11 Thread Steve Beattie
Hi Brian,

Thanks for the trusty and precise debdiffs. I have gone ahead and
published the updates to trusty-esm and precise-esm, after verifying the
fixes.

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

Title:
  new upstream release 2020f

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Xenial:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Released
Status in tzdata source package in Focal:
  Fix Released
Status in tzdata source package in Groovy:
  Fix Released

Bug description:
  New upstream version, affecting the following timestamp:
    - Volgograd switches to Moscow time on 2020-12-27 at 02:00.

  The ICU timezone data has not yet been updated upstream so those
  changes will be included in a later SRU.

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with "zdump -v
  $region/$timezone_that_changed" (this needed to be greped for in
  /usr/share/zoneinfo/). [For example: "zdump -v Africa/Casablanca".]
  This is compared to the same output after the updated package got
  installed. If those are different the verification is considered done.

  $region/$timezone = Europe/Volgograd

  Additionally, an upstream update of tzdata removed the "old" SystemV
  timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS
  and earlier releases. Subsequently, these should be checked for using
  the following:

  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v
  SystemV/MST7 | cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original Description]
  https://www.iana.org/time-zones tzdata 2020f already exists, please update 
the package.

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

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


[Touch-packages] [Bug 1901020] Re: new upstream release 2020d

2020-10-29 Thread Steve Beattie
After confirming the behavior around SystemV timezones and changed
timezones, tzdata 2020d-0ubuntu0.12.04 and tzdata 2020d-
0ubuntu0.14.04+esm1 are now published in their respective ESM releases.

Thanks for preparing the updates, Brian!

** Changed in: tzdata (Ubuntu Precise)
   Status: In Progress => Fix Released

** Changed in: tzdata (Ubuntu Trusty)
   Status: In Progress => Fix Released

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

Title:
  new upstream release 2020d

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Precise:
  Fix Released
Status in tzdata source package in Trusty:
  Fix Released
Status in tzdata source package in Xenial:
  Fix Committed
Status in tzdata source package in Bionic:
  Fix Committed
Status in tzdata source package in Focal:
  Fix Committed
Status in tzdata source package in Groovy:
  Fix Committed

Bug description:
  New upstream version, affecting the following future timestamps:
    - Fiji starts DST later than usual, on 2020-12-20.
    - Palestine ends DST earlier than predicted, on 2020-10-24.
- Revised predictions for Morocco's changes starting in 2023.
- Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08.
- Macquarie Island has stayed in sync with Tasmania since 2011.
- Casey, Antarctica is at +08 in winter and +11 in summer since 2018.

  Additionally, upstream removed the "old" SystemV timezones, but the
  SRU will ensure that they are kept. Subsequently, these should be
  checked for using the following:

  zdump -v SystemV/MST7
  zdump -v America/Phoenix

  The information returned by SystemV/MST7 should be included in
  America/Phoenix's output.

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with "zdump -v
  $region/$timezone_that_changed" (this needed to be greped for in
  /usr/share/zoneinfo/). [For example: "zdump -v Africa/Casablanca".]
  This is compared to the same output after the updated package got
  installed. If those are different the verification is considered done.

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

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


[Touch-packages] [Bug 1881447] Re: package ca-certificates 20180409 failed to install/upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 1

2020-10-28 Thread Steve Beattie
Hey Vern,

Sorry you were having difficulties. 'sudo apt install -f' should cause
apt to attempt to finish installing packages that had problems during
the post install phase, where the error that is tripped over (like the
dangling symlink in /etc/ssl/certs) has been resolved.

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

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

Title:
  package ca-certificates 20180409 failed to install/upgrade: installed
  ca-certificates package post-installation script subprocess returned
  error exit status 1

Status in ca-certificates package in Ubuntu:
  Incomplete

Bug description:
  Upgrading from 16.04 LTS to 18.04 LTS. This is a WEB server with a
  Let's Encrypt certificate.

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: ca-certificates 20180409
  ProcVersionSignature: Ubuntu 4.4.0-179.209-generic 4.4.219
  Uname: Linux 4.4.0-179-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  Date: Sat May 30 20:00:50 2020
  ErrorMessage: installed ca-certificates package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2017-09-16 (987 days ago)
  InstallationMedia: Ubuntu-Server 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.12ubuntu0.1
  SourcePackage: ca-certificates
  Title: package ca-certificates 20180409 failed to install/upgrade: installed 
ca-certificates package post-installation script subprocess returned error exit 
status 1
  UpgradeStatus: Upgraded to bionic on 2020-05-31 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1881447/+subscriptions

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


[Touch-packages] [Bug 1901020] Re: new upstream release 2020d

2020-10-27 Thread Steve Beattie
Thanks Brian, these look good, will take these into Trusty and Precise
ESM.

(For the record, I noticed that the 2020d dropped the US/Pacific-New
timezone, which was a symlink to the US/Pacific timezone. Testing
demonstrated that a system with a configured Pacific-New timezone
functioned correctly post package upgrade. See debian bug 815200 for
details on why it was dropped.)

Also, Ubuntu Security Team ack on publishing the xenial, bionic, focal,
and groovy versions to the respective -security pockets for those
releases, despite building in -proposed; there are no binaries or
dependencies that should cause an issue.

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

Title:
  new upstream release 2020d

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Precise:
  In Progress
Status in tzdata source package in Trusty:
  In Progress
Status in tzdata source package in Xenial:
  In Progress
Status in tzdata source package in Bionic:
  In Progress
Status in tzdata source package in Focal:
  In Progress
Status in tzdata source package in Groovy:
  Fix Committed

Bug description:
  New upstream version, affecting the following future timestamps:
    - Fiji starts DST later than usual, on 2020-12-20.
    - Palestine ends DST earlier than predicted, on 2020-10-24.
- Revised predictions for Morocco's changes starting in 2023.
- Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08.
- Macquarie Island has stayed in sync with Tasmania since 2011.
- Casey, Antarctica is at +08 in winter and +11 in summer since 2018.

  Additionally, upstream removed the "old" SystemV timezones, but the
  SRU will ensure that they are kept. Subsequently, these should be
  checked for using the following:

  zdump -v SystemV/MST7
  zdump -v America/Phoenix

  The information returned by SystemV/MST7 should be included in
  America/Phoenix's output.

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with "zdump -v
  $region/$timezone_that_changed" (this needed to be greped for in
  /usr/share/zoneinfo/). [For example: "zdump -v Africa/Casablanca".]
  This is compared to the same output after the updated package got
  installed. If those are different the verification is considered done.

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

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


[Touch-packages] [Bug 1901020] Re: new upstream release 2020d

2020-10-27 Thread Steve Beattie
** Changed in: tzdata (Ubuntu Precise)
   Status: New => In Progress

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

** Changed in: tzdata (Ubuntu Precise)
 Assignee: (unassigned) => Steve Beattie (sbeattie)

** Changed in: tzdata (Ubuntu Trusty)
 Assignee: (unassigned) => Steve Beattie (sbeattie)

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

Title:
  new upstream release 2020d

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Precise:
  In Progress
Status in tzdata source package in Trusty:
  In Progress
Status in tzdata source package in Xenial:
  In Progress
Status in tzdata source package in Bionic:
  In Progress
Status in tzdata source package in Focal:
  In Progress
Status in tzdata source package in Groovy:
  Fix Committed

Bug description:
  New upstream version, affecting the following future timestamps:
    - Fiji starts DST later than usual, on 2020-12-20.
    - Palestine ends DST earlier than predicted, on 2020-10-24.
- Revised predictions for Morocco's changes starting in 2023.
- Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08.
- Macquarie Island has stayed in sync with Tasmania since 2011.
- Casey, Antarctica is at +08 in winter and +11 in summer since 2018.

  Additionally, upstream removed the "old" SystemV timezones, but the
  SRU will ensure that they are kept. Subsequently, these should be
  checked for using the following:

  zdump -v SystemV/MST7
  zdump -v America/Phoenix

  The information returned by SystemV/MST7 should be included in
  America/Phoenix's output.

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with "zdump -v
  $region/$timezone_that_changed" (this needed to be greped for in
  /usr/share/zoneinfo/). [For example: "zdump -v Africa/Casablanca".]
  This is compared to the same output after the updated package got
  installed. If those are different the verification is considered done.

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

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


[Touch-packages] [Bug 856489] Re: Improper verification of updated key via apt-key net-update

2020-10-24 Thread Steve Beattie
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2011-3374

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

Title:
  Improper verification of updated key via apt-key net-update

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Lucid:
  Fix Released
Status in apt source package in Maverick:
  Fix Released
Status in apt source package in Natty:
  Fix Released
Status in apt source package in Oneiric:
  Fix Released
Status in apt source package in Hardy:
  Fix Released

Bug description:
  As reported on full-disclosure:
  http://seclists.org/fulldisclosure/2011/Sep/221

  CVE request here:
  http://www.openwall.com/lists/oss-security/2011/09/22/5

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

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


[Touch-packages] [Bug 1899046] Re: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

2020-10-08 Thread Steve Beattie
That is correct (apparmor-notify package needs an added dependency on
python3-psutil). We have an upload in progress to address it.

Thanks!

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

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

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

Title:
  /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apparmor.  This problem was most recently seen with package version 
3.0.0~beta1-0ubuntu6, the problem page at 
https://errors.ubuntu.com/problem/69bb6832fe7b294bd7e2d75970fdc903f412c409 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

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

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


[Touch-packages] [Bug 1887577] Re: DEP8: Invalid capability setuid

2020-09-21 Thread Steve Beattie
The fix for this is included in the apparmor 3.0.0~beta1-0ubuntu5 upload
into groovy-proposed, which is waiting to migrate to groovy.

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

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

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

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


[Touch-packages] [Bug 1385013] Re: proper fix for apparmor mediation of lower (encrypted) filesystem

2020-08-25 Thread Steve Beattie
** Changed in: apparmor (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: ecryptfs-utils (Ubuntu)
   Status: Fix Released => Confirmed

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

Title:
  proper fix for apparmor mediation of lower (encrypted) filesystem

Status in apparmor package in Ubuntu:
  Confirmed
Status in ecryptfs-utils package in Ubuntu:
  Confirmed

Bug description:
  This is the proper fix for LP: #359338 which is needed for user data
  encryption.

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

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


[Touch-packages] [Bug 1883793] Re: systemd-resolved leaks mDNS queries to DNS

2020-08-18 Thread Steve Beattie
** 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1883793

Title:
  systemd-resolved leaks mDNS queries to DNS

Status in systemd package in Ubuntu:
  New

Bug description:
  On a freshly installed ubuntu focal machine, access to local machines
  advertised via mDNS is now broken. This is a regression wrt eoan where
  it used to work.

  Trying to ping something like .local invariably results in
  pinging 40.68.249.35 because systemd-resolved passes the query to the
  DNS even if .local is reserved for multicast DNS and for some reasons
  .local seems to resolve to 40.68.249.35.  This happens even
  if the avahi daemon is up and running.

  Stopping systemd-resolved makes the mDNS resolution work as expected.

  Not only this breaks standard workflows, but it also means that anyone
  pretending to be 40.68.249.35 on the network could probably
  impersonate any local host.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.1
  ProcVersionSignature: Ubuntu 5.4.0-37.41-generic 5.4.41
  Uname: Linux 5.4.0-37-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Tue Jun 16 23:43:22 2020
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2020-02-16 (121 days ago)
  InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-37-generic 
root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /usr/lib/systemd/system/user@.service → 
/usr/lib/systemd/system/user@.service.d/timeout.conf
   
   2 overridden configuration files found.
  UpgradeStatus: Upgraded to focal on 2020-05-23 (24 days ago)
  dmi.bios.date: 10/02/2019
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 1.07.04RTR1
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: N141CU
  dmi.board.vendor: SCHENKER
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.product.name: SCHENKER_SLIM14_SSL14L19
  dmi.product.sku: Not Applicable
  dmi.product.version: Not Applicable
  dmi.sys.vendor: SCHENKER

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

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


[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.

2020-08-18 Thread Steve Beattie
Closing ntp task for groovy.

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

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

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

Title:
  [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
  library.

Status in ntp package in Ubuntu:
  Invalid
Status in openssl package in Ubuntu:
  Fix Released
Status in ntp source package in Bionic:
  Fix Released
Status in openssl source package in Bionic:
  Invalid

Bug description:
  [Impact]
  In FIPS mode on Bionic MD5 is semi-disabled causing some applications to 
segfault.

  ntpq uses crypto hashes to authenticate its requests. By default it
  uses md5. However, when compiled with openssl it creates a lists of
  acceptable hashes from openssl that can be used.

  This issue is only applicable in bionic and when using fips-openssl.

  [Test Steps]
  Test case:
  sudo apt install ntp
  ntpq -p
  Segmentation fault (core dumped)

  What happens there is ntpq wants to iterate all available digests
  (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this
  task.

  EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
  For FIPS mode it adds:
  EVP_add_digest(EVP_md5());

  What happens later in ntpq is (list_md_fn function inside ntpq.c):
  ctx = EVP_MD_CTX_new();
  EVP_DigestInit(ctx, EVP_get_digestbyname(name));
  EVP_DigestFinal(ctx, digest, _len);

  First digest it gets is MD5, but while running EVP_DigestInit for it, it gets 
to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
  #ifdef OPENSSL_FIPS
  if (FIPS_mode()) {
  if (!(type->flags & EVP_MD_FLAG_FIPS)
  && !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
  EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
  return 0;
  }
  }
  #endif

  Due to type->flags for MD5 being 0 there's an error set 
(EVP_R_DISABLED_FOR_FIPS).
  After getting back to ntpq.c:
  ctx->engine and ctx->digest are not set (due to the mentioned error), hence

  inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
  OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
  causes a segfault (ctx->digest is NULL).

  So either MD5 shouldn't be added in FIPS mode or it should have the
  EVP_MD_FLAG_FIPS to be properly initialized.

  [Regression Potential]

  I don't think this should regress ntpq + openssl from the Ubuntu
  archive.

  Current archive ntpq + openssl behaviour:
  openssl includes all message digests and hands ntpq a sorted digest-list.
  ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well 
and sticks all digests into its list regardless if it is working or not.

  i.e.
  ntpq> help keytype
  function: set key type to use for authenticated requests, one of:
  MD4, MD5, RIPEMD160, SHA1, SHAKE128

  If somehow openssl library is corrupted and sends back erroneous
  results, its possible the authentication will just not ever work.

  Newly fixed archive ntpq + oenssl beahviour:
  openssl includes all message digests and hands ntpq a sorted digest-list.
  ntpq checks each one and includes each working digest. With a non-corrupted 
openssl, everything works fine and ntpq includes each into its list. Ends up 
with a list identical to the one above.

  If somehow opensll library is corrupted and sends back erroneous
  results, ntpq will hopefully catch it by checking return code and
  include only those algos that appear to be working. Its possible
  authentication will work for ntpq.

  The difference will be seen in ntpq + fips-openssl. ntpq will check
  return, and for fips-not-approved algos, return will indicate an
  error. So these algos will be skipped and ntpq will not include into
  its digest list. Resulting in a much shorter list of only fips-
  approved algos.

  i.e.
  ntpq> help keytype
  function: set key type to use for authenticated requests, one of:
  SHA1, SHAKE128

  Since md5 is ntpq's default auth algo, this will need to be changed to one of 
the above algos in the config files.
  But I think it is somewhat understood that MD5 is bad in a FIPS environment.

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

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


[Touch-packages] [Bug 1887577] Re: DEP8: Invalid capability setuid

2020-07-27 Thread Steve Beattie
This is due to a change in behavior in make 4.3. It was addressed in the
upstream merge request
https://gitlab.com/apparmor/apparmor/-/merge_requests/461 and was
cherrypicked into the apparmor 2.13 branch via merge request
https://gitlab.com/apparmor/apparmor/-/merge_requests/465.

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  New

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

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

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


[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2020-07-19 Thread Steve Beattie
I also hit this again in focal on 2020-06-25, with an update to systemd
245.4-4ubuntu3.1; I had previously updated dbus to 1.12.16-2ubuntu2.1 on
2020-06-17 without event. It's still an issue at least with updates to
systemd in focal.

Similar messages end up in the journal:

Jun 25 13:04:55 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:04:55 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:04:55 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:04:55 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:09 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:09 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:09 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:09 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:09 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:09 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:09 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:09 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:09 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:09 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:10 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:10 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:10 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:10 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:10 kryten dbus-daemon[1541]: Unknown group "power" in message bus 
configuration file
Jun 25 13:05:10 kryten systemd[1]: Reloading.
Jun 25 13:05:11 kryten systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update 
the unit file accordingly.
Jun 25 13:05:11 kryten systemd[1]: /lib/systemd/system/fancontrol.service:11: 
PIDFile= references a path below legacy directory /var/run/, updating 
/var/run/fancontrol.pid → /run/fancontrol.pid; please update the unit file 
accordingly.
Jun 25 13:05:36 kryten systemd[1]: We couldn't coldplug 
machine-qemu\x2d1\x2dkeybase\x2dbionic\x2damd64.scope, proceeding anyway: 
Connection timed out
Jun 25 13:05:36 kryten dbus-daemon[1541]: [system] Reloaded configuration
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=switcheroo-control comm="systemd" 
exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=polkit comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=colord comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten systemd[1]: NetworkManager.service: Unexpected error 
response from GetNameOwner(): Connection terminated
Jun 25 13:05:36 kryten ModemManager[1689]:   Caught signal, shutting 
down...
Jun 25 13:05:36 kryten thermald[1605]: [WARN]Terminating ...
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=upower comm="systemd" exe="/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten audit[1541]: USER_AVC pid=1541 uid=105 auid=4294967295 
ses=4294967295 msg='apparmor="DENIED" operation="dbus_signal"  bus="system" 
path="/org/freedesktop/NetworkManager" 
interface="org.freedesktop.NetworkManager" member="CheckPermissions" 
name=":1.9" mask="receive" pid=4082 label="bitlbee" pe>
 exe="/usr/bin/dbus-daemon" sauid=105 
hostname=? addr=? terminal=?'
Jun 25 13:05:36 kryten audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 msg='unit=accounts-daemon comm="systemd" 
exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 25 13:05:36 kryten systemd[1]: udisks2.service: Unexpected error response 
from GetNameOwner(): Connection terminated
Jun 25 13:05:36 kryten bluetoothd[1536]: Terminating
Jun 25 13:05:36 kryten systemd[1]: switcheroo-control.service: Unexpected error 
response from GetNameOwner(): Connection terminated
Jun 25 13:05:36 kryten avahi-daemon[1535]: Got SIGTERM, quitting.
Jun 25 13:05:36 kryten systemd[1]: 

[Touch-packages] [Bug 1884265] Re: [fips] Not fully initialized digest segfaulting some client applications

2020-07-14 Thread Steve Beattie
** Changed in: openssl (Ubuntu Bionic)
   Status: New => Confirmed

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

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

Title:
  [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
  library.

Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Bionic:
  Confirmed

Bug description:
  [Impact]
  In FIPS mode on Bionic MD5 is semi-disabled causing some applications to 
segfault.

  ntpq uses crypto hashes to authenticate its requests. By default it
  uses md5. However, when compiled with openssl it creates a lists of
  acceptable hashes from openssl that can be used.

  [Test Steps]
  Test case:
  sudo apt install ntp
  ntpq -p
  Segmentation fault (core dumped)

  What happens there is ntpq wants to iterate all available digests
  (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this
  task.

  EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
  For FIPS mode it adds:
  EVP_add_digest(EVP_md5());

  What happens later in ntpq is (list_md_fn function inside ntpq.c):
  ctx = EVP_MD_CTX_new();
  EVP_DigestInit(ctx, EVP_get_digestbyname(name));
  EVP_DigestFinal(ctx, digest, _len);

  First digest it gets is MD5, but while running EVP_DigestInit for it, it gets 
to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
  #ifdef OPENSSL_FIPS
  if (FIPS_mode()) {
  if (!(type->flags & EVP_MD_FLAG_FIPS)
  && !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
  EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
  return 0;
  }
  }
  #endif

  Due to type->flags for MD5 being 0 there's an error set 
(EVP_R_DISABLED_FOR_FIPS).
  After getting back to ntpq.c:
  ctx->engine and ctx->digest are not set (due to the mentioned error), hence

  inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
  OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
  causes a segfault (ctx->digest is NULL).

  So either MD5 shouldn't be added in FIPS mode or it should have the
  EVP_MD_FLAG_FIPS to be properly initialized.

  [Regression Potential]

  I don't think this should regress ntpq + openssl from the Ubuntu
  archive.

  Current archive ntpq + openssl behaviour:
  openssl includes all message digests and hands ntpq a sorted digest-list. 
  ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well 
and sticks all digests into its list regardless if it is working or not.

  i.e.  
  ntpq> help keytype
  function: set key type to use for authenticated requests, one of:
  MD4, MD5, RIPEMD160, SHA1, SHAKE128

  If somehow openssl library is corrupted and sends back erroneous
  results, its possible the authentication will just not ever work.

  Newly fixed archive ntpq + oenssl beahviour:
  openssl includes all message digests and hands ntpq a sorted digest-list.
  ntpq checks each one and includes each working digest. With a non-corrupted 
openssl, everything works fine and ntpq includes each into its list. Ends up 
with a list identical to the one above.
   
  If somehow opensll library is corrupted and sends back erroneous results, 
ntpq will hopefully catch it by checking return code and include only those 
algos that appear to be working. Its possible authentication will work for ntpq.

  The difference will be seen in ntpq + fips-openssl. ntpq will check
  return, and for fips-not-approved algos, return will indicate an
  error. So these algos will be skipped and ntpq will not include into
  its digest list. Resulting in a much shorter list of only fips-
  approved algos.

  i.e.
  ntpq> help keytype
  function: set key type to use for authenticated requests, one of:
  SHA1, SHAKE128

  Since md5 is ntpq's default auth algo, this will need to be changed to one of 
the above algos in the config files. 
  But I think it is somewhat understood that MD5 is bad in a FIPS environment.

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

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


[Touch-packages] [Bug 1885562] Re: [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode

2020-07-14 Thread Steve Beattie
** Changed in: nss (Ubuntu)
   Status: New => In Progress

** Changed in: nss (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 nss in Ubuntu.
https://bugs.launchpad.net/bugs/1885562

Title:
  [fips] freebl_fipsSoftwareIntegrityTest fails in FIPS mode

Status in nss package in Ubuntu:
  In Progress
Status in nss source package in Bionic:
  In Progress

Bug description:
  In FIPS mode there are some additional checks performed.

  They lead to verifying binaries signatures. Those signatures are
  shipped in the libnss3 package as *.chk files installed in
  /usr/lib/$(DEB_HOST_MULTIARCH)/nss. Along with those files are the
  libraries themselves (libfreebl3.so  libfreeblpriv3.so  libnssckbi.so
  libnssdbm3.so  libsoftokn3.so).

  Those libraries are symlinked to be present in /usr/lib/$(DEB_HOST_MULTIARCH):
  ls -l /usr/lib/x86_64-linux-gnu/libfreeblpriv3.so
  lrwxrwxrwx 1 root root 21 Jun 10 18:54 
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.so -> nss/libfreeblpriv3.so

  The client binaries are linked against the symlinks, so when the verification 
happens (lib/freebl/shvfy.c) the mkCheckFileName function takes path to the 
symlink to the shlib and replaces the .so extension with .chk.
  Then it tries to open that file. Obviosly it fails, because the actual file 
is in /usr/lib/$(DEB_HOST_MULTIARCH)/nss.

  [Test case]
  sudo apt install chrony
  sudo chronyd -d
  chronyd: util.c:373 UTI_IPToRefid: Assertion `MD5_hash >= 0' failed.

  Potential solutions:
  Solution A:
  Drop the /usr/lib/$(DEB_HOST_MULTIARCH)/nss directory and put all signatures 
and libs in /usr/lib/$(DEB_HOST_MULTIARCH).

  Solution B:
  Create symlinks to *.chk files in /usr/lib/$(DEB_HOST_MULTIARCH) (like it is 
done for *.so).

  Solution C:
  Implement and upstream NSS feature of resolving symlinks and looking for 
*.chk where the symlinks lead to.

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

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


[Touch-packages] [Bug 1452115] Re: Python interpreter binary is not compiled as PIE

2020-07-14 Thread Steve Beattie
** Changed in: python3.7 (Ubuntu)
   Status: New => Confirmed

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

Title:
  Python interpreter binary is not compiled as PIE

Status in Python:
  New
Status in python2.7 package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.6 package in Ubuntu:
  Confirmed
Status in python3.7 package in Ubuntu:
  Confirmed
Status in python3.8 package in Ubuntu:
  Confirmed
Status in python3.8 package in Debian:
  New

Bug description:
  The python2.7 binary (installed at /usr/bin/python2.7; package version
  2.7.6-8) is not compiled as a position independent executable (PIE).
  It appears that the python compilation process is somewhat arcane and
  the hardening wrapper probably doesn't do the trick for it.

  This is incredibly dangerous as it means that any vulnerability within
  a native module (e.g. ctypes-based), or within python itself will
  expose an incredibly large amount of known memory contents at known
  addresses (including a large number of dangerous instruction
  groupings). This enables ROP-based (https://en.wikipedia.org/wiki
  /Return-oriented_programming) to abuse the interpreter itself to
  bypass non-executable page protections.

  I have put together an example vulnerable C shared object (with a buffer 
overflow) accessed via python through the ctypes interface as an example. This 
uses a single ROP "gadget" on top of using the known PLT location for system(3) 
(https://en.wikipedia.org/wiki/Return-to-libc_attack) to call "id". The example 
code is accessible at:
  - https://gist.github.com/ChaosData/ae6076cb1c3cc7b0a367

  I'm not exactly familiar enough with the python build process to say
  where exactly an -fPIE needs to be injected into a script/makefile,
  but I feel that given the perceived general preference for ctypes-
  based modules over python written ones, as the native code
  implementations tend to be more performant, this feels like a large
  security hole within the system. Given the nature of this "issue," I'm
  not 100% sure of where it is best reported, but from what I can tell,
  this conflicts with the Ubuntu hardening features and is definitely
  exploitable should a native module contain a sufficiently exploitable
  vulnerability that allows for control of the instruction register.

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

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


[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2020-06-30 Thread Steve Beattie
Updated groovy debdiff against the merge from debian currently in
groovy-proposed.

** Patch added: "rsyslog_8.2006.0-2ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5388559/+files/rsyslog_8.2006.0-2ubuntu2.debdiff

** Patch removed: "rsyslog_8.2001.0-1ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5386928/+files/rsyslog_8.2001.0-1ubuntu2.debdiff

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  New

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2020-06-24 Thread Steve Beattie
Focal version.

** Patch added: "rsyslog_8.2001.0-1ubuntu1.1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5386929/+files/rsyslog_8.2001.0-1ubuntu1.1.debdiff

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  New

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2020-06-24 Thread Steve Beattie
Fixed debdiff to add the bug reference for groovy.

** Patch removed: "rsyslog_8.2001.0-1ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5386642/+files/rsyslog_8.2001.0-1ubuntu2.debdiff

** Patch added: "rsyslog_8.2001.0-1ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5386928/+files/rsyslog_8.2001.0-1ubuntu2.debdiff

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  New

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2020-06-24 Thread Steve Beattie
Debdiff for groovy attached:

  - adds a second ExecStartPost entru to chmod /var/log/dmesg
  - adjusts the savelog(8) call in ExecStartPre to set the permission mode to 
640 explicitly when rotating dmesg logs

** Patch added: "rsyslog_8.2001.0-1ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+attachment/5386642/+files/rsyslog_8.2001.0-1ubuntu2.debdiff

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  New

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1884887] [NEW] rsyslogd dmesg unit leaves /var/log/dmesg* world readable

2020-06-24 Thread Steve Beattie
Public bug reported:

[Impact]

The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
eoan, focal, and groovy create /var/log/dmesg* with the following
permissions:

  -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

Most other system logs in /var/log/ are only readable by root and group
adm.

While it's true that the kernel dmesg buffer by default can be read by
anyone using the dmesg(1) command, this can be disabled by setting the
sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
is thwarted by the world readable nature of /var/log/dmesg.

The reason dmesg output is sensitive is that it sometimes contains
kernel addresses for diagnosing kernel problems, but attackers looking
to attack a kernel are also interested in kernel addresses and other
information that shows up there.

[Test Case]

To reproduce:

 $ ls -l /var/log/dmesg*

should show only root and group adm access like so:

 -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
 -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
 -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

and not world readable:

 -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

[Regression Potential]

It's possible tools like apport and others might expect /var/log/dmesg
to be world-readable.

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

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

Title:
  rsyslogd dmesg unit leaves /var/log/dmesg* world readable

Status in rsyslog package in Ubuntu:
  New

Bug description:
  [Impact]

  The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in
  eoan, focal, and groovy create /var/log/dmesg* with the following
  permissions:

-rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  Most other system logs in /var/log/ are only readable by root and
  group adm.

  While it's true that the kernel dmesg buffer by default can be read by
  anyone using the dmesg(1) command, this can be disabled by setting the
  sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure
  is thwarted by the world readable nature of /var/log/dmesg.

  The reason dmesg output is sensitive is that it sometimes contains
  kernel addresses for diagnosing kernel problems, but attackers looking
  to attack a kernel are also interested in kernel addresses and other
  information that shows up there.

  [Test Case]

  To reproduce:

   $ ls -l /var/log/dmesg*

  should show only root and group adm access like so:

   -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg
   -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0
   -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz

  and not world readable:

   -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg

  [Regression Potential]

  It's possible tools like apport and others might expect /var/log/dmesg
  to be world-readable.

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

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


[Touch-packages] [Bug 1811861] Re: incorrect permissions on /var/log after debootstrap

2020-06-23 Thread Steve Beattie
Thanks for clarifying, closing.

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

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

Title:
  incorrect permissions on /var/log after debootstrap

Status in rsyslog package in Ubuntu:
  Invalid

Bug description:
  we are debootstrapping a full bionic distribution into a directory.
  After debootstrapping the permissions on /var/log are incorrect,
  causing rsyslog to fail because it cannot write into the directory to
  create the various files.

  Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is 
attempted to be used to create the files defined in 
/usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never 
work because of the systemd-tmpfiles manpage:
 --create
 If this option is passed, all files and directories marked with f, 
F, w, d, D, v, p, L, c, b, m in the configuration files are
 created or written to. Files and directories marked with z, Z, t, 
T, a, and A have their ownership, access mode and security
 labels set.

  Since the files are configured with type "z" only ownership, access
  mode  and security will be updated.

  # lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  # apt-cache policy rsyslog
  rsyslog:
Installed: 8.32.0-1ubuntu4
Candidate: 8.32.0-1ubuntu4
Version table:
   *** 8.32.0-1ubuntu4 100
  100 /var/lib/dpkg/status

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

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


[Touch-packages] [Bug 1881942] Re: default configuration forwards sshd failures to port 7070

2020-06-23 Thread Steve Beattie
Hi John,

I'm not sure what's happened here, but the default
/etc/rsyslog.d/50-default.conf contains no such snippet (a pristine copy
is also stored in /usr/share/rsyslog/50-default.conf) and is managed via
ucf. The contents of a pristine version are attached.

Either another package you have installed has modified this config file
(and looking at the failban package and postinstall script, I don't see
anything there that would add anything like that.

Doing a limited google search on the comment string "# Transform and
forward data" turned up this recipe: https://devconnected.com
/geolocating-ssh-hackers-in-real-time/ ; is it possible that this was
added as part of a recipe you were following?

Thanks.

** Attachment added: "50-default.conf"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1881942/+attachment/5386636/+files/50-default.conf

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

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

Title:
  default configuration forwards sshd failures to port 7070

Status in rsyslog package in Ubuntu:
  Incomplete

Bug description:
  ubuntu eoan (19.10)
  ---

  While investigating why my fail2ban client was not blocking the usual
  script-kiddie SSH attempts, I discovered that no sshd failures were
  appearing in /var/log/auth.log.  Upon opening
  /etc/rsyslog.d/50-default.conf I discovered that sshd failures are
  being transformed and forwarded to localhost:7070.  Here's the section
  of configuration:

  if $programname == 'sshd' then {
 if $msg startswith ' Failed' then {
# Transform and forward data!
action(type="omfwd" target="127.0.0.1" port="7070" protocol="tcp" 
template="ip-json")
 }
 stop
  }

  
  For me, nothing is bound to port 7070. 

  I assume you have a good reason for such a default but it seems
  suboptimal to stop processing after forwarding.  I commented out the
  stop line and restarted rsyslog and found that logs appeared in
  /var/log/auth.log and that my fail2ban is now banning IPs, as
  expected.

  I suggest changing the default configuration so that sshd failures
  reach /var/log/auth.log.

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

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


[Touch-packages] [Bug 1878108] Re: new upstream release 2020a

2020-05-20 Thread Steve Beattie
Ubuntu Security team ack for binary copying these into the security
pockets as well.

Thanks!

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

Title:
  new upstream release 2020a

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Trusty:
  In Progress
Status in tzdata source package in Xenial:
  Fix Released
Status in tzdata source package in Bionic:
  Fix Released
Status in tzdata source package in Eoan:
  Fix Released
Status in tzdata source package in Focal:
  Fix Released

Bug description:
  There is a new upstream release of tzdata, 2020, which includes the
  following:

    * New upstream release, affecting past and future timestamps:
  - Morocco springs forward on 2020-05-31, not 2020-05-24.
  - Canada's Yukon advanced to -07 year-round on 2020-03-08.
  - America/Nuuk renamed from America/Godthab.

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with "zdump -v
  $region/$timezone_that_changed" (this needed to be greped for in
  /usr/share/zoneinfo/). [For example: "zdump -v Africa/Casablanca".]
  This is compared to the same output after the updated package got
  installed. If those are different the verification is considered done.

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

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


[Touch-packages] [Bug 1865519] Re: apparmor depends on python3

2020-04-29 Thread Steve Beattie
An initial port of aa-status to C landed in
https://gitlab.com/apparmor/apparmor/-/commit/8f9046b1b179190d0003ae1beacf460ee93c5090
and will e in the upcoming AppArmor 3 release. There is a follow up
improvement in https://gitlab.com/apparmor/apparmor/-/merge_requests/487
that should also land.

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

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

** Changed in: apparmor (Ubuntu)
   Status: Fix Committed => Confirmed

** Changed in: apparmor
   Status: New => Fix Committed

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

Title:
  apparmor depends on python3

Status in AppArmor:
  Fix Committed
Status in snapd:
  Invalid
Status in apparmor package in Ubuntu:
  Confirmed
Status in snapd package in Ubuntu:
  Invalid

Bug description:
  The TL;DR;
  - AppArmor depends on python3 to support aa-status.
  - snapd depends on apparmor.
  - buildd images have no python
  - building snaps requires snapd
  - snapd does not require aa-status
  - building snaps unnecessarily installs python3 onto the system

  Proposal:
  - Split runtime requirements from apparmor into apparmor-minimal
  - have apparmor depend on apparmor-minimal
  - change snapd's dependency on apparmor to apparmor-minimal

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

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


[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2020-04-08 Thread Steve Beattie
Oh, and I have no crash files in /var/crash/.

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland 
Session.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
(session: gnome-login).

  
  X was recycleing before:
  Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11...
  ...
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (EE) 
systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/_32'.
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (II) Server 
terminated successfully (0). Closing log file.

  
  It seems like some internal service broke and everything that followed was a 
secondary issue to that:
  Apr 08 06:09:19 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel systemd[1]: wpa_supplicant.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel systemd[1]: thermald.service: Unexpected error 
response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel thermald[1256]: [WARN]Terminating ...
  Apr 08 06:09:19 Keschdeichel avahi-daemon[1204]: Got SIGTERM, quitting.
  Apr 08 06:09:19 Keschdeichel systemd[1]: udisks2.service: Unexpected error 
response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel ModemManager[1308]:   Caught signal, 
shutting down...
  Apr 08 06:09:19 Keschdeichel systemd[1]: switcheroo-control.service: 
Unexpected error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel avahi-daemon[1204]: Leaving mDNS multicast group 
on interface vnet0.IPv6 with address 

[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2020-04-08 Thread Steve Beattie
Hi, I had a similar crash this morning upgrading focal, after trying to
get unattended-upgrades to stop spinning on missing focal-security apt
list files. In this case, I don't use gnome-shell as my desktop
environment, but it still tore down my entire desktop environment and
caused gdm3 to respawn.

I've attached the journalctl log from when I started apt upgrade to when
I successfully re-logged into my i3 session.

** Attachment added: "journalctl.log"
   
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/+attachment/5349957/+files/journalctl.log

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

Title:
  dbus timeout-ed during an upgrade, taking services down including gdm

Status in accountsservice package in Ubuntu:
  Invalid
Status in dbus package in Ubuntu:
  Incomplete
Status in gnome-shell package in Ubuntu:
  Invalid

Bug description:
  This morning I found my computer on the login screen.
  But not the one of the screen log, no a new one - so something must have 
crashed.

  Logging in again confirmed that all apps were gone and the gnome shell
  was brought down what seems like triggered by a background update o
  accountsservice.

  As always things are not perfectly clear :-/
  The following goes *back* in time through my logs one by one.

  Multiple apps crashed at 06:09, but we will find later that this is a follow 
on issue of the underlying gnome/X/... recycling.
  -rw-r-  1 paelzer  whoopsie 52962868 Apr  8 06:09 
_usr_bin_konversation.1000.crash
  -rw-r-  1 paelzer  whoopsie   986433 Apr  8 06:09 
_usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash

  
  rdkit was failing fast and giving up (that will be a different bug, it just 
seems broken on my system):
  Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling 
Policy Service.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called 
chroot.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped 
privileges.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited 
resources.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: 
Resource temporarily unavailable
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time 
threads.
  Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via 
systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=>
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request 
repeated too quickly.
  Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with 
result 'exit-code'.
  Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit 
Scheduling Policy Service.
  Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53

  
  But that already was only triggered by a gnome restart that kicked of earlier:

  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on 
Wayland.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
is initialized.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland 
Session.
  Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session 
(session: gnome-login).

  
  X was recycleing before:
  Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11...
  ...
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (EE) 
systemd-logind: ReleaseControl failed: Unknown object 
'/org/freedesktop/login1/session/_32'.
  Apr 08 06:09:22 Keschdeichel /usr/lib/gdm3/gdm-x-session[10710]: (II) Server 
terminated successfully (0). Closing log file.

  
  It seems like some internal service broke and everything that followed was a 
secondary issue to that:
  Apr 08 06:09:19 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel systemd[1]: wpa_supplicant.service: Unexpected 
error response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel systemd[1]: thermald.service: Unexpected error 
response from GetNameOwner(): Connection terminated
  Apr 08 06:09:19 Keschdeichel thermald[1256]: [WARN]Terminating ...
  Apr 08 06:09:19 Keschdeichel 

[Touch-packages] [Bug 1863356] [NEW] libtool and libtool-doc 2.4.6-12 both contain /usr/share/doc/libtool/AUTHORS causing upgrade failures

2020-02-14 Thread Steve Beattie
Public bug reported:

Unpacking libtool-doc (2.4.6-12) over (2.4.6-11) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-tTUGeR/289-libtool-doc_2.4.6-12_all.deb (--unpack):
 trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in package 
libtool 2.4.6-12
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: libtool 2.4.6-12
ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
Uname: Linux 5.4.0-9-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
CurrentDesktop: i3
Date: Fri Feb 14 09:04:32 2020
InstallationDate: Installed on 2017-12-15 (790 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
ProcEnviron:
 TERM=screen.xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libtool
UpgradeStatus: Upgraded to focal on 2019-09-23 (144 days ago)

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

** Affects: libtool (Debian)
 Importance: Unknown
 Status: Unknown


** Tags: amd64 apport-bug focal

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

** Also affects: libtool (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950916
   Importance: Unknown
   Status: Unknown

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

Title:
  libtool and libtool-doc 2.4.6-12 both contain
  /usr/share/doc/libtool/AUTHORS causing upgrade failures

Status in libtool package in Ubuntu:
  New
Status in libtool package in Debian:
  Unknown

Bug description:
  Unpacking libtool-doc (2.4.6-12) over (2.4.6-11) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-tTUGeR/289-libtool-doc_2.4.6-12_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in 
package libtool 2.4.6-12
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libtool 2.4.6-12
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  CurrentDesktop: i3
  Date: Fri Feb 14 09:04:32 2020
  InstallationDate: Installed on 2017-12-15 (790 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: libtool
  UpgradeStatus: Upgraded to focal on 2019-09-23 (144 days ago)

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

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


[Touch-packages] [Bug 1858972] Re: python-apt uses MD5 for validation

2020-01-31 Thread Steve Beattie
** Summary changed:

- placeholder
+ python-apt uses MD5 for validation

** Description changed:

- Placeholder bug.
+ Only MD5 is checked (most versions)
+   
   
+ In stable releases, and unstable, they only check MD5 sums of the files they 
download. 1.9.0 was broken as it still refered to the md5 field, but the field 
went away, so it would raise an exception if you tried to use it - so that's 
safe :D
+   
   
+ experimental (1.9.1) checks all hash sums, but only if some are present - it 
would happily accept an empty list of hashes - 1.9.2 will fix this issue by 
checking that the list of hashes is "usable", as it's called in apt, completing 
the proper fix.
+   
   
+ The only versions not affected by this are the ones in Ubuntu eoan and focal, 
as they hardcoded SHA256 instead of MD5 as a workaround to code failing because 
MD5 went away.

** 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 python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1858972

Title:
  python-apt uses MD5 for validation

Status in python-apt package in Ubuntu:
  Fix Released

Bug description:
  Only MD5 is checked (most versions)

   
  In stable releases, and unstable, they only check MD5 sums of the files they 
download. 1.9.0 was broken as it still refered to the md5 field, but the field 
went away, so it would raise an exception if you tried to use it - so that's 
safe :D

   
  experimental (1.9.1) checks all hash sums, but only if some are present - it 
would happily accept an empty list of hashes - 1.9.2 will fix this issue by 
checking that the list of hashes is "usable", as it's called in apt, completing 
the proper fix.

   
  The only versions not affected by this are the ones in Ubuntu eoan and focal, 
as they hardcoded SHA256 instead of MD5 as a workaround to code failing because 
MD5 went away.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1858972/+subscriptions

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


[Touch-packages] [Bug 1858973] Re: python-apt downloads from untrusted sources where apt does not

2020-01-31 Thread Steve Beattie
** Summary changed:

- placeholder
+ python-apt downloads from untrusted sources where apt does not

** Description changed:

- Placeholder bug.
+ ptyhon-apt never checked whether the hashes it got were signed in the
+ first place. So, python-apt is happy to download files from unsigned
+ repositories when it shouldn't.
+ 
+ Making the code only fetch trusted packages means that using it on
+ untrusted packages will fail. There might be use cases broken by this.

** 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 python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1858973

Title:
  python-apt downloads from untrusted sources where apt does not

Status in aptdaemon package in Ubuntu:
  Fix Released
Status in python-apt package in Ubuntu:
  Fix Released

Bug description:
  ptyhon-apt never checked whether the hashes it got were signed in the
  first place. So, python-apt is happy to download files from unsigned
  repositories when it shouldn't.

  Making the code only fetch trusted packages means that using it on
  untrusted packages will fail. There might be use cases broken by this.

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

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


[Touch-packages] [Bug 1850551] Re: Xorg freeze

2019-11-01 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  Xorg freeze

Status in xorg package in Ubuntu:
  New

Bug description:
  I recently upgraded to ubuntu-18.04 and the screen starts to freeze
  randomly. The CPU used to gets overheated on minimal use.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-66.75-generic 4.15.18
  Uname: Linux 4.15.0-66-generic x86_64
  .tmp.unity_support_test.1:
   
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Oct 30 02:03:51 2019
  DistUpgraded: 2019-07-26 05:15:58,339 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
  DistroCodename: bionic
  DistroVariant: ubuntu
  DkmsStatus:
   bbswitch, 0.8, 4.15.0-64-generic, x86_64: installed
   bbswitch, 0.8, 4.15.0-66-generic, x86_64: installed
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GpuHangFrequency: Several times a week
  GpuHangReproducibility: Occurs more often under certain circumstances
  GpuHangStarted: Immediately after installing this version of Ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
 Subsystem: Dell HD Graphics 620 [1028:078b]
 Subsystem: Dell Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / R7 
M520] [1028:078b]
  InstallationDate: Installed on 2018-02-01 (635 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  MachineType: Dell Inc. Inspiron 15-3567
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-66-generic 
root=UUID=bf1c9a5c-ebb8-4edf-8bde-0767ec9746b0 ro nouveau.modeset=0 
drm.debug=0xe plymouth:debug
  SourcePackage: xorg
  Symptom: display
  Title: Xorg freeze
  UpgradeStatus: Upgraded to bionic on 2019-07-25 (95 days ago)
  dmi.bios.date: 03/23/2017
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 01.06.00
  dmi.board.name: 0D53F5
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr01.06.00:bd03/23/2017:svnDellInc.:pnInspiron15-3567:pvr:rvnDellInc.:rn0D53F5:rvrA00:cvnDellInc.:ct9:cvr:
  dmi.product.family: Inspiron
  dmi.product.name: Inspiron 15-3567
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.100+git1910210630.c69c9c~oibaf~b
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.3~git1909090730.ae5ac2~oibaf~b
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.3~git1909090730.ae5ac2~oibaf~b
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 
1:19.1.0+git1910151930.b9bd80~oibaf~b
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git1910071930.bff5ec~oibaf~b
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.16+git1906080730.ec2b45~oibaf~b

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

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


[Touch-packages] [Bug 1850823] Re: plz help mw

2019-11-01 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  plz help mw

Status in xorg package in Ubuntu:
  New

Bug description:
  like big and big issue

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 31 22:38:46 2019
  DistUpgraded: 2019-10-31 07:37:10,130 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process 
“./xorg_fix_proprietary.py” (No such file or directory) (8))
  DistroCodename: eoan
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) 
(prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Skylake GT2 [HD Graphics 520] 
[103c:8329]
 Subsystem: Hewlett-Packard Company Radeon R7 M520 [103c:8329]
  InstallationDate: Installed on 2019-10-29 (2 days ago)
  InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 05c8:03ac Cheng Uei Precision Industry Co., Ltd 
(Foxlink) HP TrueVision HD Camera
   Bus 001 Device 003: ID 0bda:b009 Realtek Semiconductor Corp. 802.11n WLAN 
Adapter
   Bus 001 Device 005: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless 
Adapter
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: HP HP Laptop 15-bs0xx
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-19-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: Upgraded to eoan on 2019-10-31 (0 days ago)
  dmi.bios.date: 05/10/2017
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.10
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 8329
  dmi.board.vendor: HP
  dmi.board.version: 23.27
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.10:bd05/10/2017:svnHP:pnHPLaptop15-bs0xx:pvrType1ProductConfigId:rvnHP:rn8329:rvr23.27:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP Notebook
  dmi.product.name: HP Laptop 15-bs0xx
  dmi.product.sku: 2EY79PA#ACJ
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.99-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.1-1ubuntu1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20190815-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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


[Touch-packages] [Bug 1843083] Re: tracker-store crashed with SIGSEGV

2019-09-06 Thread Steve Beattie
** Information type changed from Private Security to Public

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

Title:
  tracker-store crashed with SIGSEGV

Status in tracker package in Ubuntu:
  New

Bug description:
  I din't know about

  ProblemType: Crash
  DistroRelease: Ubuntu 19.10
  Package: tracker 2.2.99.0-1
  ProcVersionSignature: Ubuntu 5.2.0-15.16-generic 5.2.9
  Uname: Linux 5.2.0-15-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Fri Sep  6 20:15:58 2019
  ExecutablePath: /usr/lib/tracker/tracker-store
  InstallationDate: Installed on 2016-02-29 (1284 days ago)
  InstallationMedia: Xubuntu 14.04.4 LTS "Trusty Tahr" - Release amd64 
(20160217.1)
  ProcCmdline: /usr/lib/tracker/tracker-store
  ProcEnviron:
   LANG=ca_ES.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
   LANGUAGE=ca
  SegvAnalysis:
   Segfault happened at: 0x55affda50c33:cmpq   $0x0,0x8(%rdi)
   PC (0x55affda50c33) ok
   source "$0x0" ok
   destination "0x8(%rdi)" (0x0008) not located in a known VMA region 
(needed writable region)!
   Stack memory exhausted (SP below stack segment)
  SegvReason: writing NULL VMA
  Signal: 11
  SourcePackage: tracker
  StacktraceTop:
   ()
   ()
   tracker_data_commit_transaction () at 
/usr/lib/x86_64-linux-gnu/tracker-2.0/libtracker-data.so
   () at /usr/lib/x86_64-linux-gnu/tracker-2.0/libtracker-data.so
   ()
  Title: tracker-store crashed with SIGSEGV
  UpgradeStatus: Upgraded to eoan on 2019-07-30 (37 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  separator:

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

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


[Touch-packages] [Bug 1834192] Re: apparmor mult_mount regression test fails in eoan

2019-06-27 Thread Steve Beattie
Fix committed upstream:
https://gitlab.com/apparmor/apparmor/commit/7c7a4bc5311d983f2c4316252b830c52a5a0930b
and backported to apparmor-2.13.

We can work around this in qa-regression-testing or fix with an apparmor
upload.

** Changed in: apparmor (Ubuntu)
 Assignee: Steve Beattie (sbeattie) => (unassigned)

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

Title:
  apparmor mult_mount regression test fails in eoan

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  In running adt testing on 5.2-based kernels for eoan, I'm seeing
  failures from the apparmor mult_mount regression test. Running the
  test case manually with -x yields:

   + dd if=/dev/zero of=/tmp/sdtest.2210-22387-i6UxxQ/image.ext3 bs=4096 
count=20
   + mkfs.ext2 -F -m 0 -N 10 /tmp/sdtest.2210-22387-i6UxxQ/image.ext3
   ++ error_handler
   ++ fatalerror 'Unexpected shell error. Run with -x to debug'

  Running the following manually in a shell also fails in eoan with the
  5.0 kernel copied forward from disco, while it passes in disco:

   $ uname -a
   Linux ee-apparmor 5.0.0-17-generic #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
   $ dd if=/dev/zero of=test.img bs=4096 count=20
   20+0 records in
   20+0 records out
   81920 bytes (82 kB, 80 KiB) copied, 0.000406443 s, 202 MB/s
   $ mkfs.ext2 -F -m 0 -N 10 test.img
   mke2fs 1.45.2 (27-May-2019)
   test.img: Not enough space to build proposed filesystem while setting up 
superblock

  So this seems likely to be due to some change with mke2fs; not sure if
  this is a regression there or if the test was getting away with doing
  something invalid.

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

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


[Touch-packages] [Bug 1834192] Re: apparmor mult_mount regression test fails in eoan

2019-06-25 Thread Steve Beattie
The issue here is that in LP: #1817097 e2fsprogs was changed to use 4k
blocks by default regardless of the created fs size. Changing the
command to force a 1012 byte blocksize causes the mkfs.ext2 command to
succeed:

  $ dd if=/dev/zero of=/tmp/image.ext3 bs=4096 count=20
  20+0 records in
  20+0 records out
  81920 bytes (82 kB, 80 KiB) copied, 0.00136542 s, 60.0 MB/s
  $ mkfs.ext2 -F -m 0 -N 10 /tmp/image.ext3
  mke2fs 1.45.1 (12-May-2019)
  /tmp/image.ext3: Not enough space to build proposed filesystem while setting 
up superblock
  $ mkfs.ext2 -F -m 0 -N 10 -b 1024 /tmp/image.ext3
  mke2fs 1.45.1 (12-May-2019)
  Discarding device blocks: done
  Creating filesystem with 80 1k blocks and 16 inodes

  Allocating group tables: done
  Writing inode tables: done
  Writing superblocks and filesystem accounting information: done

There are two ways to solve this:

  1) change the command to force 1024 byte block sizes; the -b argument
has existed in e2fsprogs since at least the 1.42 version included in
ubuntu 12.04 LTS.

  2) the image was setup to be laughably small to ensure the testsuite
could run successfully in relatively small scale environments; we could
bump the generated image to 128 blocks (512KB), which would let mkfs
succeed while still not excessively consuming space.

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

Title:
  apparmor mult_mount regression test fails in eoan

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  In running adt testing on 5.2-based kernels for eoan, I'm seeing
  failures from the apparmor mult_mount regression test. Running the
  test case manually with -x yields:

   + dd if=/dev/zero of=/tmp/sdtest.2210-22387-i6UxxQ/image.ext3 bs=4096 
count=20
   + mkfs.ext2 -F -m 0 -N 10 /tmp/sdtest.2210-22387-i6UxxQ/image.ext3
   ++ error_handler
   ++ fatalerror 'Unexpected shell error. Run with -x to debug'

  Running the following manually in a shell also fails in eoan with the
  5.0 kernel copied forward from disco, while it passes in disco:

   $ uname -a
   Linux ee-apparmor 5.0.0-17-generic #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
   $ dd if=/dev/zero of=test.img bs=4096 count=20
   20+0 records in
   20+0 records out
   81920 bytes (82 kB, 80 KiB) copied, 0.000406443 s, 202 MB/s
   $ mkfs.ext2 -F -m 0 -N 10 test.img
   mke2fs 1.45.2 (27-May-2019)
   test.img: Not enough space to build proposed filesystem while setting up 
superblock

  So this seems likely to be due to some change with mke2fs; not sure if
  this is a regression there or if the test was getting away with doing
  something invalid.

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

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


[Touch-packages] [Bug 1834192] Re: apparmor mult_mount regression test fails in eoan

2019-06-25 Thread Steve Beattie
** Changed in: apparmor (Ubuntu)
   Status: New => Confirmed

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Steve Beattie (sbeattie)

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

Title:
  apparmor mult_mount regression test fails in eoan

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  In running adt testing on 5.2-based kernels for eoan, I'm seeing
  failures from the apparmor mult_mount regression test. Running the
  test case manually with -x yields:

   + dd if=/dev/zero of=/tmp/sdtest.2210-22387-i6UxxQ/image.ext3 bs=4096 
count=20
   + mkfs.ext2 -F -m 0 -N 10 /tmp/sdtest.2210-22387-i6UxxQ/image.ext3
   ++ error_handler
   ++ fatalerror 'Unexpected shell error. Run with -x to debug'

  Running the following manually in a shell also fails in eoan with the
  5.0 kernel copied forward from disco, while it passes in disco:

   $ uname -a
   Linux ee-apparmor 5.0.0-17-generic #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
   $ dd if=/dev/zero of=test.img bs=4096 count=20
   20+0 records in
   20+0 records out
   81920 bytes (82 kB, 80 KiB) copied, 0.000406443 s, 202 MB/s
   $ mkfs.ext2 -F -m 0 -N 10 test.img
   mke2fs 1.45.2 (27-May-2019)
   test.img: Not enough space to build proposed filesystem while setting up 
superblock

  So this seems likely to be due to some change with mke2fs; not sure if
  this is a regression there or if the test was getting away with doing
  something invalid.

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

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


[Touch-packages] [Bug 1833758] [NEW] lvm2: vgcfgbackup in postinst takes several minutes

2019-06-21 Thread Steve Beattie
Public bug reported:

The postinst for lvm2 includes a call to vgcfgbackup; in the version
included in eoan 2.03.02-2ubuntu4 (and 2.03.02-2ubuntu3 before it), this
command takes several minutes to run when invoked in an schroot  as
happens when a building a package with sbuild that ends up pulling lvm2
as part of its build dependency chain. An example package with lvm2 in
its build depends is rsnapshot, but this behavior was seen with a build
of glibc. Some notes:

  - this behavior is NOT seen with the version of lvm2 in disco.
  - this happens in bionic with a 4.15 kernel and disco with a 5.0 kernel 
(different hosts, so different sets of block devices)
  - this happens regardless of whether the host is currently using logical 
volumes or not

Here's the time difference between running the disco version and the
eoan version:

(disco-amd64)root@HOSTNAME:~# time vgcfgbackup
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.

real0m0.204s
user0m0.014s
sys 0m0.010s

(eoan-amd64)root@HOSTNAME:~# time vgcfgbackup
  WARNING: Device /dev/sda not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda2 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda3 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdc not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdc1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdd not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdd1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sde not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sde1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sde2 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda2 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sda3 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdc1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sdd1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sde1 not initialized in udev database even after waiting 
1000 microseconds.
  WARNING: Device /dev/sde2 not initialized in udev database even after waiting 
1000 microseconds.

real4m11.405s
user0m0.470s
sys 0m0.576s

/proc/mounts in the schroot:

(eoan-amd64)root@HOSTNAME:~# cat /proc/mounts
eoan-amd64 / overlay 
rw,relatime,lowerdir=/var/lib/schroot/union/underlay/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34,upperdir=/srv/devel/schroot-overlays/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34/upper,workdir=/srv/devel/schroot-overlays/eoan-amd64-29c7f791-9409-4505-9192-7c4685b8be34/work
 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=10197712k,nr_inodes=2549428,mode=755 
0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sda2 /home ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda2 /tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /run/shm tmpfs rw,relatime 0 0
/dev/sda2 /scratch ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sdc1 /srv/work ext4 rw,relatime,errors=remount-ro,data=ordered 0 0

strace of vgcfgbackup is attached

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


** Tags: eoan

** Attachment added: "strace of running vgcfgbackup in an eoan schroot"
   
https://bugs.launchpad.net/bugs/1833758/+attachment/5272220/+files/vgcfgbackup-eoan.strace

-- 
You received this 

[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only

2019-06-12 Thread Steve Beattie
Lukasz, all these packages look fine from the Ubuntu Security Team's
perspective. Thanks!

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

Title:
  New toolchain updates need to be rebuilt against -security only

Status in binutils package in Ubuntu:
  New
Status in eclipse-titan package in Ubuntu:
  New
Status in gcc-7 package in Ubuntu:
  New
Status in gcc-7-cross package in Ubuntu:
  New
Status in gcc-7-cross-ports package in Ubuntu:
  New
Status in gcc-8 package in Ubuntu:
  New
Status in gcc-8-cross package in Ubuntu:
  New
Status in gcc-8-cross-ports package in Ubuntu:
  New
Status in gcc-defaults package in Ubuntu:
  New
Status in gcc-defaults-ports package in Ubuntu:
  New
Status in ggcov package in Ubuntu:
  New
Status in binutils source package in Bionic:
  Fix Committed
Status in eclipse-titan source package in Bionic:
  Fix Committed
Status in gcc-7 source package in Bionic:
  Fix Committed
Status in gcc-7-cross source package in Bionic:
  Fix Committed
Status in gcc-7-cross-ports source package in Bionic:
  Fix Committed
Status in gcc-8 source package in Bionic:
  Fix Committed
Status in gcc-8-cross source package in Bionic:
  Fix Committed
Status in gcc-8-cross-ports source package in Bionic:
  Fix Committed
Status in gcc-defaults source package in Bionic:
  Fix Committed
Status in gcc-defaults-ports source package in Bionic:
  Fix Committed
Status in ggcov source package in Bionic:
  Fix Committed
Status in binutils source package in Cosmic:
  Fix Committed
Status in eclipse-titan source package in Cosmic:
  Fix Committed
Status in gcc-7 source package in Cosmic:
  Fix Committed
Status in gcc-7-cross source package in Cosmic:
  Fix Committed
Status in gcc-7-cross-ports source package in Cosmic:
  Fix Committed
Status in gcc-8 source package in Cosmic:
  Fix Committed
Status in gcc-8-cross source package in Cosmic:
  Fix Committed
Status in gcc-8-cross-ports source package in Cosmic:
  Fix Committed
Status in gcc-defaults source package in Cosmic:
  Fix Committed
Status in gcc-defaults-ports source package in Cosmic:
  Fix Committed
Status in ggcov source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]
  With LP: #1814369, the toolchain packages have been updated in both cosmic 
and bionic, but due to an error those packages were built in -proposed as any 
regular SRU. For toolchain updates there exists a policy that those should be 
always built against -security *only*, and then released to both -security and 
-updates.

  Since this is not the case with the current toolchain update, we need
  to no-change rebuild all of the previously released toolchain packages
  in a -security enabled devirt PPA, sync them to -proposed with
  binaries and then release into the archives.

  [Regression Potential]
  As these are toolchain packages, there is always some regression potential. 
These will be no-change rebuilds so in theory the risk should be low, but the 
current versions of the packages have not been built against -security only 
before. It is hard to say how any regressions could manifest themselves.

  [Test Case]
  Making sure there are no reported regressions in the GCC and binutils test 
suites. Hopefully this will be sufficient.

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

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


[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only

2019-05-20 Thread Steve Beattie
** Changed in: binutils (Ubuntu)
 Assignee: (unassigned) => Steve Beattie (sbeattie)

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

Title:
  New toolchain updates need to be rebuilt against -security only

Status in binutils package in Ubuntu:
  New
Status in gcc-7 package in Ubuntu:
  New
Status in gcc-7-cross package in Ubuntu:
  New
Status in gcc-7-cross-ports package in Ubuntu:
  New
Status in gcc-8 package in Ubuntu:
  New
Status in gcc-8-cross package in Ubuntu:
  New
Status in gcc-8-cross-ports package in Ubuntu:
  New
Status in gcc-defaults package in Ubuntu:
  New
Status in gcc-defaults-ports package in Ubuntu:
  New
Status in binutils source package in Bionic:
  New
Status in gcc-7 source package in Bionic:
  New
Status in gcc-7-cross source package in Bionic:
  New
Status in gcc-7-cross-ports source package in Bionic:
  New
Status in gcc-8 source package in Bionic:
  New
Status in gcc-8-cross source package in Bionic:
  New
Status in gcc-8-cross-ports source package in Bionic:
  New
Status in gcc-defaults source package in Bionic:
  New
Status in gcc-defaults-ports source package in Bionic:
  New
Status in binutils source package in Cosmic:
  New
Status in gcc-7 source package in Cosmic:
  New
Status in gcc-7-cross source package in Cosmic:
  New
Status in gcc-7-cross-ports source package in Cosmic:
  New
Status in gcc-8 source package in Cosmic:
  New
Status in gcc-8-cross source package in Cosmic:
  New
Status in gcc-8-cross-ports source package in Cosmic:
  New
Status in gcc-defaults source package in Cosmic:
  New
Status in gcc-defaults-ports source package in Cosmic:
  New

Bug description:
  [Impact]
  With LP: #1814369, the toolchain packages have been updated in both cosmic 
and bionic, but due to an error those packages were built in -proposed as any 
regular SRU. For toolchain updates there exists a policy that those should be 
always built against -security *only*, and then released to both -security and 
-updates.

  Since this is not the case with the current toolchain update, we need
  to no-change rebuild all of the previously released toolchain packages
  in a -security enabled devirt PPA, sync them to -proposed with
  binaries and then release into the archives.

  [Regression Potential]
  As these are toolchain packages, there is always some regression potential. 
These will be no-change rebuilds so in theory the risk should be low, but the 
current versions of the packages have not been built against -security only 
before. It is hard to say how any regressions could manifest themselves.

  [Test Case]
  Making sure there are no reported regressions in the GCC and binutils test 
suites. Hopefully this will be sufficient.

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

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


[Touch-packages] [Bug 1828171] Re: New toolchain updates need to be rebuilt against -security only

2019-05-20 Thread Steve Beattie
Hi Łukasz, I'll take this for the security team. Thanks.

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

Title:
  New toolchain updates need to be rebuilt against -security only

Status in binutils package in Ubuntu:
  New
Status in gcc-7 package in Ubuntu:
  New
Status in gcc-7-cross package in Ubuntu:
  New
Status in gcc-7-cross-ports package in Ubuntu:
  New
Status in gcc-8 package in Ubuntu:
  New
Status in gcc-8-cross package in Ubuntu:
  New
Status in gcc-8-cross-ports package in Ubuntu:
  New
Status in gcc-defaults package in Ubuntu:
  New
Status in gcc-defaults-ports package in Ubuntu:
  New
Status in binutils source package in Bionic:
  New
Status in gcc-7 source package in Bionic:
  New
Status in gcc-7-cross source package in Bionic:
  New
Status in gcc-7-cross-ports source package in Bionic:
  New
Status in gcc-8 source package in Bionic:
  New
Status in gcc-8-cross source package in Bionic:
  New
Status in gcc-8-cross-ports source package in Bionic:
  New
Status in gcc-defaults source package in Bionic:
  New
Status in gcc-defaults-ports source package in Bionic:
  New
Status in binutils source package in Cosmic:
  New
Status in gcc-7 source package in Cosmic:
  New
Status in gcc-7-cross source package in Cosmic:
  New
Status in gcc-7-cross-ports source package in Cosmic:
  New
Status in gcc-8 source package in Cosmic:
  New
Status in gcc-8-cross source package in Cosmic:
  New
Status in gcc-8-cross-ports source package in Cosmic:
  New
Status in gcc-defaults source package in Cosmic:
  New
Status in gcc-defaults-ports source package in Cosmic:
  New

Bug description:
  [Impact]
  With LP: #1814369, the toolchain packages have been updated in both cosmic 
and bionic, but due to an error those packages were built in -proposed as any 
regular SRU. For toolchain updates there exists a policy that those should be 
always built against -security *only*, and then released to both -security and 
-updates.

  Since this is not the case with the current toolchain update, we need
  to no-change rebuild all of the previously released toolchain packages
  in a -security enabled devirt PPA, sync them to -proposed with
  binaries and then release into the archives.

  [Regression Potential]
  As these are toolchain packages, there is always some regression potential. 
These will be no-change rebuilds so in theory the risk should be low, but the 
current versions of the packages have not been built against -security only 
before. It is hard to say how any regressions could manifest themselves.

  [Test Case]
  Making sure there are no reported regressions in the GCC and binutils test 
suites. Hopefully this will be sufficient.

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

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


[Touch-packages] [Bug 1828846] Re: ecra

2019-05-15 Thread Steve Beattie
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  ecra

Status in xorg package in Ubuntu:
  New

Bug description:
  Notebook hp elitebook 8440p com sensor de rotação da tela, ao instalar 
ubuntu19 ele reconhece a tela virada 180 graus e o ponteiro do mouse no 
sentindo certo.
  Ao tentar inverter a tela através de comandos ou configuração ela vira porem 
o mouse ainda fica invertido.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
  Uname: Linux 5.0.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon May 13 15:54:42 2019
  DistUpgraded: Fresh install
  DistroCodename: disco
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] 
(rev 02) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Core Processor Integrated Graphics 
Controller [103c:172a]
  MachineType: Hewlett-Packard HP EliteBook 8440p
  PccardctlStatus:
   Socket 0:
 3.3V
16-bit
PC Card
 Subdevice 0 (function 0) bound to driver "pata_pcmcia"
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic 
root=UUID=3a114823-2ff8-428d-8823-ecbf3fb1e030 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/02/2010
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 68CCU Ver. F.0B
  dmi.board.name: 172A
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: KBC Version 30.2C
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvr68CCUVer.F.0B:bd06/02/2010:svnHewlett-Packard:pnHPEliteBook8440p:pvr:rvnHewlett-Packard:rn172A:rvrKBCVersion30.2C:cvnHewlett-Packard:ct10:cvr:
  dmi.product.family: 103C_5336AN
  dmi.product.name: HP EliteBook 8440p
  dmi.product.sku: SJ905UP#ABA
  dmi.sys.vendor: Hewlett-Packard
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.97-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20180925-2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

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

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


[Touch-packages] [Bug 1801383] Re: the WifiSyslog apport hook (used in firefox/tb) includes SSID informations

2019-03-21 Thread Steve Beattie
The linux kernel apport hook is provided by apport directly, so needs to
be fixed there:

  $ grep -i Wifi /usr/share/apport/package-hooks/source_linux.py
apport.hookutils.attach_wifi(report)
  $ dpkg -S /usr/share/apport/package-hooks/source_linux.py
apport: /usr/share/apport/package-hooks/source_linux.py

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

Title:
  the WifiSyslog apport hook (used in firefox/tb) includes SSID
  informations

Status in apport package in Ubuntu:
  New
Status in firefox package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in thunderbird package in Ubuntu:
  New

Bug description:
  When I apport-bug certain packages such as firefox for example, it
  uploads the WifiSyslog.txt file.

  The WifiSyslog may contain a list of all system connections enumerated
  in /etc/NetworkManager/system-connections, i.e. all SSIDs the user has
  ever connected to that are found in the system-connections. This is a
  serious privacy risk and completely unnecessary information for most
  bug reports.

  Should either remove WifiSyslog as a requirement for packages that
  don't need it (should I report this to
  https://bugs.launchpad.net/ubuntu/+source/firefox/ ?), or redact
  information that may contain usernames and SSIDs from the log file.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: apport 2.20.9-0ubuntu7.4
  ProcVersionSignature: User Name 4.15.0-38.41-generic 4.15.18
  Uname: Linux 4.15.0-38-generic x86_64
  ApportLog:
   
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  CrashReports: 640:1000:117:62475:2018-11-01 19:17:29.982295751 
-0400:2018-11-01 19:17:30.982295751 
-0400:/var/crash/_usr_bin_gnome-screenshot.1000.crash
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Nov  2 11:24:20 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-09-12 (50 days ago)
  InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 
(20180731)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: Upgraded to bionic on 2018-09-28 (34 days ago)

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

-- 
Mailing list: https://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   >