[Group.of.nepali.translators] [Bug 1673247] Re: package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine
Michael, are you still actively working on this issue? ** Also affects: snapd Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1673247 Title: package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1 Status in snapd: New Status in dpkg package in Ubuntu: In Progress Status in snapd package in Ubuntu: In Progress Status in dpkg source package in Trusty: Confirmed Status in snapd source package in Trusty: In Progress Status in dpkg source package in Xenial: Confirmed Status in snapd source package in Xenial: Confirmed Status in dpkg source package in Yakkety: Invalid Status in snapd source package in Yakkety: Invalid Status in dpkg source package in Zesty: Confirmed Status in snapd source package in Zesty: Confirmed Bug description: When the ubuntu installer runs it has an option to download updates during the install. When this happens snapd/snap-confine 2.22.6 are installed on /target. The upgrade brings in snapd/snap-confine 2.23.1 which has a conffile in /etc/apparmor.d/usr.lib.snapd.snap-confine. The snapd packages declares a breaks/replaces: snapd-confine (<< 2.23) which works correctly on regular upgrades. However it does fail on upgrades with the "--root=/target" that is used by ubiquity. After a bit of debugging it turns out the reason is that src/archives.c:tarobject() has a check for obsolete conffiles in the block around "Is the file an obsolete conffile ...". There is a stat() here that checks that the conff->name and the fnamevb are the same file. This check fails to take the instdir into account and therefore the loop does not continue but falls through to the "does_replace()" checks. Snap 2.23.1 fails to upgrade from 2.21. Known facts: - reporters (and apport) indicate it fails during the install via the live-cd - not reproducible so far on an already installed system - breaks/replaces of snapd are correct - When adding "xenial-proposed" to apt-setup in ubiquity and installing Cause: - when ubiquity runs it uses "dpkg --root=/target --unpack ..." - however when doing the conffile checking dpkg does not handle the "--root" parameter correctly and checks something against "/" instead of "/target". - I really don't know what else to add... ProblemType: Package DistroRelease: Ubuntu 16.04 Package: snapd 2.23.1 ProcVersionSignature: Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-36-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CasperVersion: 1.376.2 Date: Wed Mar 15 16:03:33 2017 DuplicateSignature: package:snapd:2.23.1 Unpacking snapd (2.23.1) over (2.21) ... dpkg: error processing archive /target/var/cache/apt/archives/snapd_2.23.1_amd64.deb (--unpack): trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1 ErrorMessage: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1 LiveMediaBuild: Ubuntu-GNOME 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215) RelatedPackageVersions: dpkg 1.18.4ubuntu1.1 apt 1.2.19 SourcePackage: snapd Title: package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1673247/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1850540] [NEW] multi-zone raid0 corruption
Public bug reported: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. Users of RAID0 arrays are susceptible to a corruption issue if: - The members of the RAID array are not all the same size[*] - Data has been written to the array while running kernels < 3.14 *and* >= 3.14. This is because of an change in v3.14 that accidentally changed how data was written - as described in the upstream commit message: https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9 That change has been applied to stable, but we reverted it to fix 1849682 until we have a full solution ready. To summarize, upstream is dealing with this by adding a versioned layout in v5.4, and that is being backported to stable kernels - which is why we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2 is post 3.14. Mixing version 1 & version 2 layouts can cause corruption. However, unless a layout-version-aware kernel *created* the array, there's no way for the kernel to know which version(s) was used to write the existing data. This undefined mode is considered "Version 0", and the kernel will now refuse to start these arrays w/o user intervention. The user experience is pretty awful here. A user upgrades to the next SRU and all of a sudden their system stops at an (initramfs) prompt. A clueful user can spot something like the following in dmesg: Here's the message which , as you can see from the log in Comment #1, is hidden in a ton of other messages: [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2 [ 72.733979] md: pers->run() failed ... mdadm: failed to start array /dev/md0: Unknown error 524 What that is trying to say is that you should determine if your data - specifically the data toward the end of your array - was most likely written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with the kernel parameter raid0.default_layout=1 or raid0.default_layout=2 on the kernel command line. And note it should be *raid0.default_layout* not *raid.default_layout* as the message says - a fix for that message is now queued for stable: https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571) IMHO, we should work with upstream to create a web page that clearly walks the user through this process, and update the error message to point to that page. I'd also like to see if we can detect this problem *before* the user reboots (debconf?) and help the user fix things. e.g. "We detected that you have RAID0 arrays that maybe susceptible to a corruption problem", guide the user to choosing a layout, and update the mdadm initramfs hook to poke the answer in via sysfs before starting the array on reboot. Note that it also seems like we should investigate backporting this to < 3.14 kernels. Imagine a user switching between the trusty HWE kernel and the GA kernel. References from users of other distros: https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/ https://www.linuxquestions.org/questions/linux-general-1/raid-arrays-not-assembling-4175662774/ [*] Which surprisingly is not the case reported in this bug - the user here had a raid0 of 8 identically-sized devices. I suspect there's a bug in the detection code somewhere. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Precise) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Precise) Importance: Undecided Status: New ** Affects: linux (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Disco) Importance: Undecided Status: New ** Affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Eoan) Importance: Undecided Status: New ** Affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Affects: mdadm (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided
[Group.of.nepali.translators] [Bug 1661590] Re: GNOME Software only supports running one application from a snap
I just tried to reproduce the bug as outlined in the bug description. I
can confirm it is now fixed and working as expected. I'm marking the
snappy task as fix released.
** Changed in: snappy
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1661590
Title:
GNOME Software only supports running one application from a snap
Status in GNOME Software:
Fix Released
Status in Snappy:
Fix Released
Status in gnome-software package in Ubuntu:
Fix Released
Status in gnome-software source package in Xenial:
Fix Released
Status in gnome-software source package in Artful:
Won't Fix
Status in gnome-software source package in Bionic:
Fix Released
Bug description:
HOW TO REPRODUCE:
1. Install LibreOffice snap ('nonfree' tag) from Ubuntu Software.
2. Click on the 'Launch' button once you have it installed.
WHAT IS EXPECTED:
It should launch the LibreOffice wizard instead of any of Writer, Calc, etc.
WHAT ACTUALLY HAPPENS:
It launches LibreOffice Database.
WHY THIS HAPPENS?
Ubuntu Software probably picks the first listed command
(libreoffice.base), as shown in
$ snap info libreoffice
name: libreoffice
summary: "LibreOffice is a powerful office suite including word processing
and creation of spreadsheets, slideshows and databases"
publisher: canonical
description: |
LibreOffice is a powerful office suite – its clean interface and
feature-rich tools help you unleash your creativity and enhance your
productivity. LibreOffice includes several applications that make it the
most
powerful Free and Open Source office suite on the market: Writer (word
processing), Calc (spreadsheets), Impress (presentations), Draw (vector
graphics and flowcharts), Base (databases), and Math (formula editing).
commands:
- libreoffice.base
- libreoffice.calc
- libreoffice.draw
- libreoffice.impress
- libreoffice
- libreoffice.math
- libreoffice.writer
tracking:stable
installed: 5.3.0.3 (17) 374MB -
refreshed: 2017-02-01 20:51:51 +0200 EET
channels:
stable:5.3.0.3 (17) 374MB -
candidate: 5.3.0.3 (17) 374MB -
beta: 5.3.0.3 (17) 374MB -
edge: 5.3.0.3 (17) 374MB -
The order in snapcraft.yaml is different, so probably Snapcraft is changing
the order (it might assume that 'libreoffice' is 'libreoffice.libreoffice', so
it puts it further down.
Here is snapcraft.yaml: https://git.launchpad.net/~bjoern-michaelsen
/df-libreoffice/+git/libreoffice-snap-
playground/tree/snapcraft.yaml?h=xenial
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-software/+bug/1661590/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1659534] Re: userdel doesn't supports extrausers
I inspected snapd and noticed that we don't invoke "userdel" or "deluser" in any production code. We have some tests that do use it and we now support --extrausers there. I'm inclined to mark the snappy task as fix released, given that we inherit the relevant tools from core and core18 snaps which in turn are fed with updates from the archive. While in the past we carried this patch locally in a package override, given that it is now fixed in both Xenial and Bionic I cannot imagine anything else we'd have to do in the context of this issue. With this rationale I'm marking it as fix released. Please reopen if there's more relevant work to be done. ** Changed in: snappy Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: Fix Released Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Fix Released Status in shadow source package in Bionic: Fix Released Status in shadow source package in Cosmic: Confirmed Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1647036] Re: Client does not ACK auth/assoc responses from Cisco AP3800
Trusty release has gone end of support for this package, so marking this as such. Newer releases will have this fix though. ** Changed in: bcmwl (Ubuntu Trusty) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1647036 Title: Client does not ACK auth/assoc responses from Cisco AP3800 Status in bcmwl package in Ubuntu: Fix Released Status in bcmwl source package in Trusty: Won't Fix Status in bcmwl source package in Xenial: Fix Released Status in bcmwl source package in Yakkety: Fix Released Status in bcmwl source package in Zesty: Fix Released Bug description: This client does not ACK Assoc Responses from a Cisco 3800. Traces attached. - Model:Dell XPS13 9343 - OS Version:Ubuntu 14.04.5 LTS - WNIC:Broadcom BCM4352 rev. 03 driver version 6.30.223.248 - SSID:user.wifi (WPA2/dot1x ) - MAC address:c4:8e:8f:f5:4a:7f -Cisco AP : 3800 (wave 2) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1647036/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1721676] Re: implement errno action logging in seccomp for strict mode with snaps
This has been fixed and is available in snapd for multiple releases now. I'm marking it as fix released. ** Changed in: snappy Status: In Progress => Fix Released ** Project changed: snappy => snapd -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1721676 Title: implement errno action logging in seccomp for strict mode with snaps Status in snapd: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Zesty: Fix Released Status in linux source package in Artful: Fix Released Bug description: A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help to help catch any regressions. Note that on Artful, there's an existing test failure (20-live- basic_die%%002-1): $ sudo apt build-dep -y libseccomp $ sudo apt install -y cython $ apt source libseccomp $ cd libseccomp-* $ autoreconf -ivf && ./configure --enable-python && make check-build $ (cd tests && ./regression -T live) All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure: ... Test 20-live-basic_die%%002-1 result: FAILURE 20-live-basic_die TRAP rc=159 ... Regression Test Summary tests run: 12 tests skipped: 0 tests passed: 11 tests failed: 1 tests errored: 0 Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary: $ make -C tools/testing/selftests TARGETS=seccomp Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine and run it there. On Xenial, 54/54 tests should pass and 58/58 should pass on Zesty. Now we can run a single test to verify that SECCOMP_RET_ERRNO is logged when the application opts into it. First, verify that "errno" is listed in the actions_logged sysctl: $ cat /proc/sys/kernel/seccomp/actions_logged kill trap errno trace log Now, build and run the test program: $ gcc -o lp1721676-kernel-test lp1721676-kernel-test.c $ ./lp1721676-kernel-test SUCCESS: getpid() failed as expected: Operation not permitted It should have generated a message like this in /var/log/syslog: kernel: [79338.804966] audit: type=1326 audit(1507259221.875:27): auid=1000 uid=1000 gid=1000 ses=5 pid=3091 comm="lp1721676-kerne" exe="/home/tyhicks/lp1721676-kernel-test" sig=0 arch=c03e syscall=39 compat=0 ip=0x7fb91829c499 code=0x5 Disable errno logging in the sysctl: $ echo kill trap trace log | sudo tee /proc/sys/kernel/seccomp/actions_logged kill trap trace log Rerun the test program and ensure that nothing was logged this time. [Regression Potential] The kernel patches received a lot of review between Kees and some others interested in improved seccomp logging. I authored the patches and feel comfortable/confident with my backported versions. They do not change the behavior of seccomp logging by default but offer ways applications to opt into more logging and, on the flipside, ways for the administrator to quite any additional logging. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1721676/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe :
[Group.of.nepali.translators] [Bug 1630789] Re: normal users can't run snaps inside of LXD containers
This bug was fixed while snap-confine was a separate package. I'm marking the snappy task as fix-released. ** Changed in: snappy Status: In Progress => Fix Released ** Project changed: snappy => snapd -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1630789 Title: normal users can't run snaps inside of LXD containers Status in snap-confine: Fix Released Status in snapd: Fix Released Status in snap-confine package in Ubuntu: Fix Released Status in snapd package in Ubuntu: Fix Released Status in snap-confine source package in Xenial: Fix Committed Status in snap-confine source package in Yakkety: Fix Committed Bug description: [Impact] TBD [Test Case] Look below for a test case. [Regression Potential] TBD [Other Info] * snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates == # Pre-SRU bug description follows # == The kernel (4.8.0-19.21), apparmor (2.10.95-4ubuntu5), and lxd (2.4-0ubuntu1) needed for running snaps inside of LXD containers (bug #1611078) have all landed in Yakkety. We should be able to install squashfuse and snapd 2.16+16.10 (from yakkety-proposed) and then run snaps inside of unprivileged LXD containers. I have verified that it works well for the root user inside of the container but there are some issues when a normal user attempts to run a snap command. # Create yakkety container named "yakkety" tyhicks@host:~$ lxc launch ubuntu-daily:devel yakkety Creating yakkety Starting yakkety # Enter the container, enable yakkety-proposed, update, install the dependencies tyhicks@host:~$ lxc exec yakkety bash root@yakkety:~# echo "deb http://archive.ubuntu.com/ubuntu/ \ yakkety-proposed restricted main multiverse universe" > \ /etc/apt/sources.list.d/proposed.list root@yakkety:~# echo -e "Package: *\nPin: release a=yakkety-proposed\n\ Pin-Priority: 400" > /etc/apt/preferences.d/proposed-updates root@yakkety:~# apt-get update && apt-get dist-upgrade -y ... root@yakkety:~# apt-get install -y squashfuse snapd/yakkety-proposed ... # Rebooting the container should not be needed but is done for completeness root@yakkety:~# reboot tyhicks@host:~$ lxc exec yakkety bash # Install the hello-world snap root@yakkety:~# snap install hello-world hello-world (stable) 6.3 from 'canonical' installed # Snap commands work fine as root inside the container but not as a normal user root@yakkety:~# /snap/bin/hello-world.env SNAP_USER_COMMON=/root/snap/hello-world/common ... root@yakkety:~# su - ubuntu -c '/snap/bin/hello-world.env' internal error, please report: running "hello-world.env" failed: open /snap/hello-world/27/meta/snap.yaml: permission denied # The normal user can't access /snap/hello-world/27 because of some oddness with the # dentry root@yakkety:~# ls -al /snap/hello-world total 8 drwxr-xr-x 3 root root 4096 Oct 5 21:09 . drwxr-xr-x 5 root root 4096 Oct 5 21:09 .. drwxrwxr-x 4 root root0 Jul 11 21:20 27 lrwxrwxrwx 1 root root2 Oct 5 21:09 current -> 27 root@yakkety:~# su - ubuntu -c 'ls -al /snap/hello-world' ls: cannot access '/snap/hello-world/27': Permission denied total 8 drwxr-xr-x 3 root root 4096 Oct 5 21:09 . drwxr-xr-x 5 root root 4096 Oct 5 21:09 .. d? ? ?? ?? 27 lrwxrwxrwx 1 root root2 Oct 5 21:09 current -> 27 To manage notifications about this bug go to: https://bugs.launchpad.net/snap-confine/+bug/1630789/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1837673] Re: Certbot will be unable to create new ACME accounts
This bug was fixed in the package python-certbot - 0.27.0-1~ubuntu18.04.1 --- python-certbot (0.27.0-1~ubuntu18.04.1) bionic; urgency=medium * Backport to bionic (LP: #1837673): - d/letsencrypt.postrm: purging the transitional package shouldn't remove the logs (Closes: #921423) python-certbot (0.27.0-1) unstable; urgency=medium * New upstream version 0.27.0 * Refresh patch after upstream migration to codecov * Bump python-sphinx requirement defensively; bump S-V with no changes * Bump dep on python-acme to 0.26.0~ python-certbot (0.26.1-1) unstable; urgency=medium * New upstream release. python-certbot (0.26.0-1) unstable; urgency=medium * New upstream version 0.26.0 * Bump S-V; add R-R-R: no python-certbot (0.25.0-1) unstable; urgency=medium * New upstream version 0.25.0 * Bump python-acme dep version. python-certbot (0.24.0-2) unstable; urgency=medium * Update team email address. (Closes: #899858) python-certbot (0.24.0-1) unstable; urgency=medium * Add OR to dep on python-distutils for stretch-bpo * New upstream version 0.24.0 * Bump version dep on python3-acme -- Andreas Hasenack Thu, 10 Oct 2019 20:57:31 + ** Changed in: python-certbot (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1837673 Title: Certbot will be unable to create new ACME accounts Status in python-certbot package in Ubuntu: Fix Released Status in python-certbot source package in Xenial: Fix Released Status in python-certbot source package in Bionic: Fix Released Status in python-certbot source package in Disco: Fix Released Status in python-certbot source package in Eoan: Fix Released Bug description: [Impact] To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430. What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above. To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. [Test Case] The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions: - is reachable from the internet on port 80 - has a public IP - said public IP has a valid DNS record under a public domain name * install certbot with the apache plugin: sudo apt install python-certbot-apache certbot * run the certbot command: sudo certbot run * After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org * The new packages will use a v2 server, like this: Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used. Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages): Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org An unexpected error occurred: The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details. Please see the logfiles in /var/log/letsencrypt for more details. * To complete the test, let's test renewing the certificate, and then revoke it: sudo certbot --dry-run renew * list certificates, taking note of the certificate path: sudo
[Group.of.nepali.translators] [Bug 1837673] Re: Certbot will be unable to create new ACME accounts
This bug was fixed in the package python-certbot - 0.27.0-1~ubuntu16.04.1 --- python-certbot (0.27.0-1~ubuntu16.04.1) xenial; urgency=medium * Backport to xenial (LP: #1837673): - d/control, d/compat: go back to debhelper 9, and drop R³ - d/p/0002-revert-sphinx-1.6-requirement.patch: revert upstream change that allows build with sphinx 1.6 - d/control: drop requirement on version 1.6 or higher of sphinx - d/control, d/rules: go back to python2 - d/python-certbot-doc.doc-base: go back to the py2 package - d/python-certbot.lintian-overrides: go back to python2 - d/rules: add systemd to debhelper, since it's not automatic on this dh level - d/control: build-dep on systemd - d/rules: no need to explicitly install examples/docs - d/rules: install certbot.timer as dh-systemd in Xenial doesn't do it - d/rules: go back to dh_systemd_enable and dh_systemd_start since dh_installsystemd is only available in debhelper 11 and later - d/letsencrypt.postrm: purging the transitional package shouldn't remove the logs (Closes: #921423) python-certbot (0.27.0-1) unstable; urgency=medium * New upstream version 0.27.0 * Refresh patch after upstream migration to codecov * Bump python-sphinx requirement defensively; bump S-V with no changes * Bump dep on python-acme to 0.26.0~ python-certbot (0.26.1-1) unstable; urgency=medium * New upstream release. python-certbot (0.26.0-1) unstable; urgency=medium * New upstream version 0.26.0 * Bump S-V; add R-R-R: no python-certbot (0.25.0-1) unstable; urgency=medium * New upstream version 0.25.0 * Bump python-acme dep version. python-certbot (0.24.0-2) unstable; urgency=medium * Update team email address. (Closes: #899858) python-certbot (0.24.0-1) unstable; urgency=medium * Add OR to dep on python-distutils for stretch-bpo * New upstream version 0.24.0 * Bump version dep on python3-acme python-certbot (0.23.0-1) unstable; urgency=medium * New upstream release. * Add testdata back in to prevent test failure in RDeps. (Closes: #894025) * Bump S-V; no changes needed. -- Andreas Hasenack Thu, 17 Oct 2019 21:03:01 + ** Changed in: python-certbot (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1837673 Title: Certbot will be unable to create new ACME accounts Status in python-certbot package in Ubuntu: Fix Released Status in python-certbot source package in Xenial: Fix Released Status in python-certbot source package in Bionic: Fix Released Status in python-certbot source package in Disco: Fix Released Status in python-certbot source package in Eoan: Fix Released Bug description: [Impact] To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430. What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above. To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. [Test Case] The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions: - is reachable from the internet on port 80 - has a public IP - said public IP has a valid DNS record under a public domain name * install certbot with the apache plugin: sudo apt install python-certbot-apache certbot * run the certbot command: sudo certbot run * After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org * The new packages will use a v2 server, like this: Starting new HTTPS connection
[Group.of.nepali.translators] [Bug 1836823] Re: python-acme will break on November 1st
This bug was fixed in the package python-acme - 0.31.0-2~ubuntu18.04.1 --- python-acme (0.31.0-2~ubuntu18.04.1) bionic; urgency=medium * Backport packaging to build on Ubuntu Bionic (LP: #1836823) python-acme (0.31.0-2) unstable; urgency=medium * Backport POST-as-GET support (Closes: #928452) python-acme (0.31.0-1) unstable; urgency=medium * Bump dependency on josepy to >= 1.1.0 * Add Breaks on python-acme against certbot << 0.20 * New upstream version 0.31.0 * Add dep on python-idna required by security extra. * Bump S-V; no changes needed. python-acme (0.28.0-1) unstable; urgency=medium * New upstream version 0.28.0 python-acme (0.27.0-1) unstable; urgency=medium * New upstream release. * Bump S-V; no changes needed. python-acme (0.26.0-1) unstable; urgency=medium * New upstream version 0.26.0 * Bump S-V; add Rules-Require-Root: no python-acme (0.25.1-1) unstable; urgency=medium * New upstream version 0.25.1 python-acme (0.25.0-1) unstable; urgency=medium * New upstream version 0.25.0 * Add new dependency on requests-toolbelt * Drop unnecessary X-Python-Version fields * Add pytest as build-time dep only. python-acme (0.24.0-2) unstable; urgency=medium * Update team email address. (Closes: #895863) python-acme (0.24.0-1) unstable; urgency=medium * New upstream release. * Bump S-V; no changes needed. -- James Hebden Sat, 07 Sep 2019 16:15:04 +1000 ** Changed in: python-acme (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: python-acme (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1836823 Title: python-acme will break on November 1st Status in python-acme package in Ubuntu: Fix Released Status in python-acme source package in Xenial: Fix Released Status in python-acme source package in Bionic: Fix Released Status in python-acme source package in Cosmic: Won't Fix Status in python-acme source package in Disco: Fix Released Bug description: [Impact] This bug affects the python-acme package in all released versions of Ubuntu, with the exception of Eoan Ermine which uses a newer version of python-acme. The major change in the package is the backporting of fixes to allow the python-acme package to continue to work with Let’s Encrypt’s “ACMEv2” endpoint, which is their RFC 8555 compliant endpoint for issuing and renewing TLS certificates, after service changes are made on November 1st. See https://community.letsencrypt.org/t/acme-v2 -scheduled-deprecation-of-unauthenticated-resource-gets/74380 for more details about this change. The primary concern here is that users of the library, most commonly users of the certbot package, will no longer be able to obtain new certificates and existing certificates issued via certbot will no longer be able to renew, resulting in broken TLS configurations for many users and sites hosted on Ubuntu where certbot is used to request and renew TLS certificates. For further reference, see https://wiki.ubuntu.com/StableReleaseUpdates/Certbot [Major Changes] There are no backwards incompatible API changes being introduced by the backported changes to this library, as such interoperability with existing packages should not be impacted. All changes being introduced are either new features or fixes to ensure the library's behaviour remains compatible with the ACME protocol, which was only finalised in March of this year. These changes are required to maintain compatibility with the ACMEv2 servers operated by LetsEncrypt per the Impact section. Key changes being introduced by this backport: The changelog entries for the update from 0.31.0-1 to 0.31.0-2 are: * The acme module uses now a POST-as-GET request to retrieve the registration from an ACMEv2 server. * The acme module now avoids sending the keyAuthorization field in the JWS payload when responding to a challenge as the field is not included in the current ACME protocol. To ease the migration path for ACME CA servers, Certbot and its acme module will first try the request without the keyAuthorization field but will temporarily retry the request with the field included if a malformed error is received. * The Content-Type in the POST-as-GET request to retrieve a certificate was corrected from "application/pkix-cert" to "application/jose+json". In addition to those changes, the relevant changelog entries when updating from 0.23.0 are: * Added support for initiating (but not solving end-to-end) TLS-ALPN-01 challenges with the acme module. * Added External Account Binding support. * Use the ACMEv2 newNonce endpoint when a new nonce is needed, and newNonce is available in the directory. * Warn when using
[Group.of.nepali.translators] [Bug 1836823] Re: python-acme will break on November 1st
This bug was fixed in the package python-acme - 0.31.0-2~ubuntu19.04.1 --- python-acme (0.31.0-2~ubuntu19.04.1) disco; urgency=medium [ James Hebden ] * Backport packaging to build on Ubuntu Disco (LP: #1836823) [ Andreas Hasenack ] * d/p/series: drop unused -p1 python-acme (0.31.0-2) unstable; urgency=medium * Backport POST-as-GET support (Closes: #928452) -- James Hebden Sat, 07 Sep 2019 16:15:04 +1000 ** Changed in: python-acme (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1836823 Title: python-acme will break on November 1st Status in python-acme package in Ubuntu: Fix Released Status in python-acme source package in Xenial: Fix Released Status in python-acme source package in Bionic: Fix Released Status in python-acme source package in Cosmic: Won't Fix Status in python-acme source package in Disco: Fix Released Bug description: [Impact] This bug affects the python-acme package in all released versions of Ubuntu, with the exception of Eoan Ermine which uses a newer version of python-acme. The major change in the package is the backporting of fixes to allow the python-acme package to continue to work with Let’s Encrypt’s “ACMEv2” endpoint, which is their RFC 8555 compliant endpoint for issuing and renewing TLS certificates, after service changes are made on November 1st. See https://community.letsencrypt.org/t/acme-v2 -scheduled-deprecation-of-unauthenticated-resource-gets/74380 for more details about this change. The primary concern here is that users of the library, most commonly users of the certbot package, will no longer be able to obtain new certificates and existing certificates issued via certbot will no longer be able to renew, resulting in broken TLS configurations for many users and sites hosted on Ubuntu where certbot is used to request and renew TLS certificates. For further reference, see https://wiki.ubuntu.com/StableReleaseUpdates/Certbot [Major Changes] There are no backwards incompatible API changes being introduced by the backported changes to this library, as such interoperability with existing packages should not be impacted. All changes being introduced are either new features or fixes to ensure the library's behaviour remains compatible with the ACME protocol, which was only finalised in March of this year. These changes are required to maintain compatibility with the ACMEv2 servers operated by LetsEncrypt per the Impact section. Key changes being introduced by this backport: The changelog entries for the update from 0.31.0-1 to 0.31.0-2 are: * The acme module uses now a POST-as-GET request to retrieve the registration from an ACMEv2 server. * The acme module now avoids sending the keyAuthorization field in the JWS payload when responding to a challenge as the field is not included in the current ACME protocol. To ease the migration path for ACME CA servers, Certbot and its acme module will first try the request without the keyAuthorization field but will temporarily retry the request with the field included if a malformed error is received. * The Content-Type in the POST-as-GET request to retrieve a certificate was corrected from "application/pkix-cert" to "application/jose+json". In addition to those changes, the relevant changelog entries when updating from 0.23.0 are: * Added support for initiating (but not solving end-to-end) TLS-ALPN-01 challenges with the acme module. * Added External Account Binding support. * Use the ACMEv2 newNonce endpoint when a new nonce is needed, and newNonce is available in the directory. * Warn when using deprecated acme.challenges.TLSSNI01 * When using acme.client.ClientV2 (or acme.client.BackwardsCompatibleClientV2 with an ACME server that supports a newer version of the ACME protocol), an acme.errors.ConflictError will be raised if you try to create an ACME account with a key that has already been used. Previously, a JSON parsing error was raised in this scenario when using the library with Let's Encrypt's ACMEv2 endpoint. * You can now call query_registration without having to first call new_account on acme.client.ClientV2 objects. * Support for the ready status type was added to acme. Without this change, Certbot and acme users will begin encountering errors when using Let's Encrypt's ACMEv2 API starting on June 19th for the staging environment and July 5th for production. See https://community.letsencrypt.org/t/acmev2-order-ready-status/62866 for more information. * acme now supports specifying the source address to bind to when sending outgoing connections. * acme now parses the wildcard field included in authorisations so it can be used by users of the
[Group.of.nepali.translators] [Bug 1850454] [NEW] Xenial update: v4.4.198 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v4.4.198 upstream stable release from git://git.kernel.org/ ** Affects: linux (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Xenial) Importance: Medium Assignee: Connor Kuehl (connork) Status: In Progress ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Connor Kuehl (connork) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1850454 Title: Xenial update: v4.4.198 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: In Progress Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v4.4.198 upstream stable release from git://git.kernel.org/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850454/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
