Bug#1063919: ITP: python-pyu2f -- pure python U2F host library

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 
X-Debbugs-Cc: debian-de...@lists.debian.org, hlieber...@debian.org

* Package name: python-pyu2f
  Version : 0.1.5
  Upstream Contact: Google 
* URL : https://www.github.com/google/pyu2f
* License : Apache-2.0
  Programming Lang: Python
  Description : pure python U2F host library

pyu2f is a python based U2F host library for Linux, Windows, and MacOS. It
provides functionality for interacting with a U2F device over USB.
.
pyu2f uses ctypes to make system calls directly to interface with the USB HID
device. This means that no platform specific shared libraries need to be
compiled for pyu2f to work.

Bug#1063628: ITP: python-command-runner -- a platform-agnostic external command execution library for python with extra goodies

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 
X-Debbugs-Cc: debian-de...@lists.debian.org, an...@beanfield.com, 
hlieber...@debian.org

* Package name: python-command-runner
Version : 1.6.0
Upstream Contact: Orsiris de Jong
* URL : https://github.com/netinvent/command_runner
* License : BSD-3-clause
Programming Lang: Python 3
Description : a platform-agnostic external command execution library for 
python

command_runner's purpose is to run external commands from python, just like
subprocess on which it relies, while solving various problems a developer may
face among:
- Handling of all possible subprocess.popen / subprocess.check_output scenarios
  / python versions in one handy function without encoding / timeout hassle
- Allow stdout/stderr stream output to be redirected to callback functions /
  output queues / files so you get to handle output in your application while
  commands are running
-  Callback to optional stop check so we can stop execution from outside
  command_runner
- Callback with optional process information so we get to control the process
  from outside command_runner
- Callback once we're finished to ease thread usage
- Optional process priority and io_priority settings
- System agnostic functionality, the developer shouldn't carry the burden of 
Windows & Linux differences
- Optional Windows UAC elevation module compatible with CPython, PyInstaller & 
Nuitka
- Optional Linux sudo elevation compatible with CPython, PyInstaller & Nuitka

My plan is to maintain this package under the auspices of the Debian Python
Team. I am packaging this module in part because it is a direct dependency of
LibreNMS, though I don't currently have plans to package that.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'

[Harlan Lieberman-Berg]

tag 1061692 +patch
thanks

I've tested it, and it seems that manually adding the path to
d/install fixes the problem fine.  Patch attached.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman
From 9d9fc8e0a1b46af0c9bf13e7ff982af1b9e15c07 Mon Sep 17 00:00:00 2001
From: Harlan Lieberman-Berg 
Date: Sun, 28 Jan 2024 20:56:58 -0500
Subject: [PATCH] Ensure stock configs are installed (Closes: #1061692)

---
 debian/install | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/install b/debian/install
index d2033f8..af982ac 100644
--- a/debian/install
+++ b/debian/install
@@ -2,3 +2,4 @@ chirp/share/chirp.png /usr/share/pixmaps
 chirp/share/chirp.desktop /usr/share/applications
 chirp/share/*.png /usr/share/chirp
 chirp/locale/* /usr/lib/python3/dist-packages/chirp/locale
+chirp/stock_configs /usr/lib/python3/dist-packages/chirp
-- 
2.43.0

Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'

[Harlan Lieberman-Berg]

Package: chirp
Version: 1:20240122-1
Severity: grave
X-Debbugs-Cc: deb...@jouellet.net, hlieber...@debian.org

Hello Dave, all,

Thank you for updating chirp! Unfortunately, it seems that pybuild may have
failed to pick up one of the necessary directories that contains the stock
configurations. Running `chirpw` instantly crashes with the following error:

Traceback (most recent call last):
  File "/usr/bin/chirpw", line 33, in 
sys.exit(load_entry_point('chirp==20240122', 'console_scripts', 'chirpw')())
 ^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/__init__.py", line 178, in 
chirpmain
mainwindow = main.ChirpMain(None, title='CHIRP')
 ^^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 414, in 
__init__
self.SetMenuBar(self.make_menubar())
^^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 644, in 
make_menubar
self.OPEN_STOCK_CONFIG_MENU = self.add_stock_menu()
  ^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 573, in 
add_stock_menu
in importlib_resources.files('chirp.stock_configs').iterdir()
   
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))

  File "/usr/lib/python3.11/importlib/resources/_common.py", line 53, in 
get_package
resolved = resolve(package)
   
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 44, in resolve
return cand if isinstance(cand, types.ModuleType) else 
importlib.import_module(cand)
   
^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'chirp.stock_configs'

Hopefully this is an easy fix!  Thanks for your help maintaining this.

73,

--
Harlan Lieberman-Berg (KC1CHE)
~hlieberman

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chirp depends on:
ii  python3 [python3-supported-min]  3.11.4-5+b1
ii  python3-importlib-resources  6.0.1-1
ii  python3-requests 2.31.0+dfsg-1
ii  python3-serial   3.5-2
ii  python3-six  1.16.0-4
ii  python3-yattag   1.15.1-1
ii  wxpython-tools   4.2.1+dfsg-3

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information

Bug#1055065: doesnt find useradd

[Harlan Lieberman-Berg]

On Mon, 30 Oct 2023 17:14:57 +0100 Marc Haber
 wrote:
> debspawn create sid errors out because the tool cannot find useradd. I
> have added adduser manually to "include_pkgs" in osbase.py and this
> allows debspawn create sid to finish.

I've done a bit of digging, and I traced this problem back to a change
in the way debootstrap works when installing the buildd variant, which
is what debspawn uses.  In bug 837060, debootstrap stopped installing
packages which were Priority: Required but not essential.
Specifically, the passwd package is the cause here; failure to install
passwd means that the `useradd` command is not available.  The reason
that installing the adduser package fixed this is that adduser depends
on passwd, so it was indirectly pulled in.

It's certainly easy enough for us to fix on the debspawn side -- we
can just unilaterally add the passwd package -- but it is a bit...
strange for us to have to fix.  It seems, to me, like this is
something we should be able to rely on debootstrap for.  I've copied
the relevant bug; hopefully we can get some input from the bootstrap
folx.  (Maybe we should be using the minbase variant instead? Except
we're always building packages... should we be using a specific user?
I'm not sure!)

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1057382: would it be possible to keep certbot up-to-date?

[Harlan Lieberman-Berg]

On Mon, Dec 4, 2023 at 10:15 AM Harald Dunkel  wrote:
> Upstream provides certbot 2.7.4. Would it be possible to keep
> certbot in Sid roughly up-to-date?

Hi Harri,

Right now, I've been hesitant to update certbot because of the lack of
cryptographic signature verification.  I've been working with upstream
to try and close that gap, but we haven't gotten there yet.  Take a
peek at https://github.com/certbot/certbot/issues/9740 for reference.

Even if we don't come up with a solution long-term, I may see if I can
get one of the Let's Encrypt devs to do something as a one-off out of
band, since we are a bit out of date at this point.

It's definitely on my radar!  Hopefully we'll cross this off the list soon.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1054076: mesa: fix name collision causing Wayland SIGSEGV on i915 machines

[Harlan Lieberman-Berg]

Source: mesa
Version: 23.2.1-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: hlieber...@debian.org
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/9889
Control: affects -1 gnome-shell

Hello maintainer,

Due to a name collision in the radeonsi module, gdm under Wayland will segfault
on any machine running an Intel Iris Plus GPU. This was reported in a variety of
distro trackers (https://bugzilla.redhat.com/show_bug.cgi?id=2238711,
https://bugs.archlinux.org/task/79831, etc.).

It can be fixed trivially with the cherry-pick of a patch upstream that is
allocated to be pulled into the 23.2 release stream
(https://gitlab.freedesktop.org/mesa/mesa/-/commit/9590bce3e249a34665b2c42b20bfdbdc7f32147f).
However, due to the impact on users, it would be nice to pull it in before Mesa
makes their next release.

I've attached the patch as well for your reference.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 9590bce3e249a34665b2c42b20bfdbdc7f32147f Mon Sep 17 00:00:00 2001
From: WinLinux1028 
Date: Tue, 11 Jul 2023 18:16:01 +0900
Subject: [PATCH] radeonsi: prefix function with si_ to prevent name collision

Fixed a build error caused by multiple gfx11_init_query symbols when building 
with iris and radeonsi specified in gallium-drivers.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9238
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24045>
---
 src/gallium/drivers/radeonsi/gfx11_query.c | 4 ++--
 src/gallium/drivers/radeonsi/si_pipe.c | 4 ++--
 src/gallium/drivers/radeonsi/si_pipe.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/gfx11_query.c 
b/src/gallium/drivers/radeonsi/gfx11_query.c
index bfcd8e2511050..2a331cc3bda25 100644
--- a/src/gallium/drivers/radeonsi/gfx11_query.c
+++ b/src/gallium/drivers/radeonsi/gfx11_query.c
@@ -422,13 +422,13 @@ struct pipe_query *gfx11_sh_query_create(struct si_screen 
*screen, enum pipe_que
return (struct pipe_query *)query;
 }
 
-void gfx11_init_query(struct si_context *sctx)
+void si_gfx11_init_query(struct si_context *sctx)
 {
list_inithead(>shader_query_buffers);
sctx->atoms.s.shader_query.emit = emit_shader_query;
 }
 
-void gfx11_destroy_query(struct si_context *sctx)
+void si_gfx11_destroy_query(struct si_context *sctx)
 {
if (!sctx->shader_query_buffers.next)
   return;
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index fb5c02c473b96..2b4fceb89b198 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -192,7 +192,7 @@ static void si_destroy_context(struct pipe_context *context)
si_release_all_descriptors(sctx);
 
if (sctx->gfx_level >= GFX10 && sctx->has_graphics)
-  gfx11_destroy_query(sctx);
+  si_gfx11_destroy_query(sctx);
 
if (sctx->sqtt) {
   struct si_screen *sscreen = sctx->screen;
@@ -637,7 +637,7 @@ static struct pipe_context *si_create_context(struct 
pipe_screen *screen, unsign
/* Initialize graphics-only context functions. */
if (sctx->has_graphics) {
   if (sctx->gfx_level >= GFX10)
- gfx11_init_query(sctx);
+ si_gfx11_init_query(sctx);
   si_init_msaa_functions(sctx);
   si_init_shader_functions(sctx);
   si_init_state_functions(sctx);
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 55f1d1788f1a1..389716854f9a6 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -1616,8 +1616,8 @@ void *si_create_query_result_cs(struct si_context *sctx);
 void *gfx11_create_sh_query_result_cs(struct si_context *sctx);
 
 /* gfx11_query.c */
-void gfx11_init_query(struct si_context *sctx);
-void gfx11_destroy_query(struct si_context *sctx);
+void si_gfx11_init_query(struct si_context *sctx);
+void si_gfx11_destroy_query(struct si_context *sctx);
 
 /* si_test_image_copy_region.c */
 void si_test_image_copy_region(struct si_screen *sscreen);
-- 
GitLab

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Harlan Lieberman-Berg]

On Sun, Sep 17, 2023 at 12:13 PM Simon McVittie  wrote:
> If you run as root
>
> update-alternatives --set gdm-smartcard 
> /etc/pam.d/gdm-smartcard-sssd-or-password
>
> does that restore previous functionality?

Sort of!  It doesn't fix the changes to the UI (i.e., there is no
longer a list of users to select from; it is a username box where the
"go back" button does nothing), but you can login by putting the
username in by hand.  That part is, obviously, the most important one.

Is the issue here one of defaults (e.g., the wrong PAM profile being
set), or one of detection (are smartcards a valid choice at all)?

Potentially unrelated sidenote: setting
`/org/gnome/login-screen/enable-smartcard-authentication` to `false`
has no effect on the ability to login; it still refuses to allow
password auth.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Harlan Lieberman-Berg]

On Tue, 12 Sep 2023 10:52:16 -0400 Paul Tagliamonte  wrote:
> I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
> when I reboot, and entering my username causes it to loop back to
> username entry again (no password prompt).

Hello all,

I've gotten bitten by this one too, I'm afraid, this time in Debian testing.

Potentially interestingly, though I do have a PKCS#11 token inserted,
it has no certificates on it.  That's still enough to trigger the bug,
however, even though there is no certificate for it to even attempt to
auth against.

For example:

```
❯ pkcs11-tool -L
Available slots:
Slot 0 (0x0): Yubico YubiKey OTP+FIDO+CCID 00 00
  token label: PIV_II
  token manufacturer : piv_II
  token model: PKCS#15 emulated
  token flags: login required, rng, token initialized, PIN
initialized, user PIN locked
  hardware version   : 0.0
  firmware version   : 0.0
  serial num : 
  pin min/max: 4/8
```

However...

```
❯ pkcs11-tool --list-objects --type cert
Using slot 0 with a present token (0x0)
```

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1041562: dracut-core: dracut 059 produces broken unified kernel images with systemd 254

[Harlan Lieberman-Berg]

On Thu, 20 Jul 2023 23:16:43 +0200 Pawel Jasiak  wrote:
> Fixes are already in dracut master branch:
> - f32e95bcadbc5158843530407adc1e7b700561b1
> - 33a66ed04bdc30eccb172a0cd6dcc36d9d74f825

I confirm that these two patches fix the problem.  I've pushed up a
branch to Salsa (fix-uki) with the patch fuzzed and included, plus an
entry for d/changelog.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1038920: python3-certbot-dns-gandi: Update from Debian 11 -> 12 leaves certificate updates broken

[Harlan Lieberman-Berg]

tag 1038920 +patch
thanks

On Fri, Jun 30, 2023 at 6:35 AM Norbert Preining  wrote:
> You could still send me the code and I give it an eye ;-)

Sold!  preinst file is attached.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman


preinst
Description: Binary data

Bug#1038920: python3-certbot-dns-gandi: Update from Debian 11 -> 12 leaves certificate updates broken

[Harlan Lieberman-Berg]

On Fri, Jun 23, 2023 at 6:24 AM Norbert Preining  wrote:
> with the update of certbot and the DNS Gandi plugin, the command line
> arguments for requesting a certificate have changed.

Hello Norbert,

Thanks for letting me know.  I've spoken with upstream about this as
well, and to see what we can do in the future to ensure something like
this doesn't happen again. I've written up a draft preinst script that
should rewrite the config files to remove the problem.

Do you still have a host that's in the buggy state, or did you fix
them all with the workaround?  Because it's going to be fixed in a
preinst, I'd like more testing (and more eyes) on it than I normally
would, just for caution's sake.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1034829: 2.0 broke handling of reused keys

[Harlan Lieberman-Berg]

tag 1034829 +moreinfo
thanks

On Tue, Apr 25, 2023 at 3:42 PM Harald Dunkel  wrote:
> Would it be possible to provide new certbot 2.5.0 on experimental
> while Bookworm is frozen? 2.0 broke handling of reused keys. This
> has been fixed for 2.5, see

Hello Harri,

We actually backported the patches that fixed reused keys in 2.1.0-3.
Have you experienced this reversion behavior yourself, or is this just
based off of the changelog notes?

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1034003: certbot: Implement --no-random-sleep-on-renew on systemd timer

[Harlan Lieberman-Berg]

On Thu, Apr 6, 2023 at 9:57 AM Dan Poltawski  wrote:
> Upstream implemented a flag `--no-random-sleep-on-renew` for the use of
> packagers - see https://github.com/certbot/certbot/issues/6596

Well, this is embarrassing.  If you look at the upstream ticket, the
person who actually requested that feature was... me.  And then I just
never followed-up and put the flag in.

Whoops!

Pending upload now. :)

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1034325: reportbug: certbot.timer runs only monthly, rather than twice daily

[Harlan Lieberman-Berg]

tag 1034325 +moreinfo
thanks

On Thu, Apr 13, 2023 at 12:54 AM Blieque  wrote:
> The (legacy?) Cron job (`/etc/cron.d/certbot`) for Certbot runs the
> certificate renewal program every 12 hours, and starts with a random
> 0–12-hour delay. This helps to distribute load on Let's Encrypt servers
> over time.

Hi there,

Are you sure that it's not triggering twice daily? The systemd timer
with OnCalendar running twice a day has been in Debian since certbot
0.23, which went into stretch.

What version of systemd are you running on this host? Can you show me
the relevant line from `systemctl list-timers`?

Sincerely,

Bug#1028535: certbot: Please include the certbot(7) man page in the certbot package

[Harlan Lieberman-Berg]

tag 1028535 +pending
thanks

On Fri, Jan 13, 2023 at 12:28 PM Karl O. Pinc  wrote:
> What motivated me was interest in documenting this:
>
> ${webroot-path}/.well-known/acme-challenge
>
> I did just pester the certbot people into including that
> in certbot(1).  But it has been helpful in the past
> to know more about the protocol and details about choices,
> whether for validation or whatever.
> [snip]
> It can be helpful to have prose to look at and disk is
> cheap.

Fair point!  I committed the patch to my repo; it'll go out in the next upload.

Cheers!

Bug#1028535: certbot: Please include the certbot(7) man page in the certbot package

[Harlan Lieberman-Berg]

On Thu, Jan 12, 2023 at 1:06 PM Karl O. Pinc  wrote:
> The certbot upstream includes a certbot(7) man page.  At present this
> is not included in the Debian package.  It would be helpful to have it
> included.

Hi Karl,

I'm interested in what you're looking for that's in the certbot.7
manpage.  Most of that information is either duplicated in the
certbot.1 manpage, or is really for plugin developers rather than
actual users.

Sincerely,

Bug#1026537: python-certbot: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Harlan Lieberman-Berg]

reassign 1026537 python-cryptography 38.0.4-1
retitle 1026537 python-cryptography fails to depend on python3-cffi
affects 1026537 python-certbot
thanks

On Tue, Dec 20, 2022 at 12:12 Lucas Nussbaum  wrote:

> > I: pybuild base:240: cd
> /<>/.pybuild/cpython3_3.10_certbot/build; python3.10 -m pytest
> tests
> > = test session starts
> ==
> > platform linux -- Python 3.10.9, pytest-7.2.0, pluggy-1.0.0+repack
> > rootdir: /<>
> > collected 967 items / 1 error
> >
> >  ERRORS
> 
> > ___ ERROR collecting
> .pybuild/cpython3_3.10_certbot/build/tests/cli_test.py 
> > tests/cli_test.py:21: in 
> > PLUGINS = disco.PluginsRegistry.find_all()
> > certbot/_internal/plugins/disco.py:192: in find_all
> > cls._load_entry_point(entry_point, plugins)
> > certbot/_internal/plugins/disco.py:199: in _load_entry_point
> > plugin_ep = PluginEntryPoint(entry_point)
> > certbot/_internal/plugins/disco.py:40: in __init__
> > self.plugin_cls: Type[interfaces.Plugin] = entry_point.load()
> > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2470: in load
> > self.require(*args, **kwargs)
> > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2493: in require
> > items = working_set.resolve(reqs, env, installer, extras=self.extras)
> > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:795: in resolve
> > raise DistributionNotFound(req, requirers)
> > E   pkg_resources.DistributionNotFound: The 'cffi>=1.12' distribution
> was not found and is required by cryptography
> > === short test summary info
> 
> > ERROR tests/cli_test.py - pkg_resources.DistributionNotFound: The
> 'cffi>=1.12...
> >  Interrupted: 1 error during collection
> 
> > === 1 error in 1.43s
> ===


This error stems from the .egg-info file being shipped as part of
python3-cffi, but the python3-cryptography lib only having Depends on the
cffi backend lib.

Morph, can you take a peek at this?

Thanks!

Sincerely,

—
Harlan Lieberman-Berg
~hlieberman

> --
Harlan Lieberman-Berg
~hlieberman

Bug#1025891: python3-acme: Sets invalid CSR version in bullseye

[Harlan Lieberman-Berg]

tags 1025891 +pending,+confirmed
thanks
On Sun, Dec 11, 2022 at 1:03 PM Mathias Ertl  wrote:
> The PR from the certbot repo[1] gives the (trivial) fix. Several other
> affected clients also link to the PR. I have verified that applying the patch
> solves the issue.

Hello Mathias,

Thank you for reporting the issue!  I've prepared a stable upload and
have sent a request for approval to the stable release team
(#1025925).

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1025925: bullseye-pu: package python-acme/1.12.0-2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: python-a...@packages.debian.org, hlieber...@debian.org
Control: affects -1 + src:python-acme

Hello SRMs!

A bug, #1025891, was recently reported about the certbot package failing to
produce certificates when run against certain strictly-RFC-complying instances
of the ACME API. A fix is present upstream in later versions, however, stable is
still affected.

This is a simple backport, changing only the version number (and its associated
test), taken from upstream.

I have tested the updated version of certbot against the Let's Encrypt test
instances directly, and through the apache and nginx plugins. All were
successful. Note: the Let's Encrypt API is not strictly-RFC-complying in this
regard, so this proves only that the package is not broken further. However,
considering the simplicity of the patch, I'm not concerned about testing against
a stricter endpoint.

A source debdiff is attached.  I await your thumbs-up before uploading.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman
diff -Nru python-acme-1.12.0/debian/changelog 
python-acme-1.12.0/debian/changelog
--- python-acme-1.12.0/debian/changelog 2021-02-02 16:37:28.0 -0500
+++ python-acme-1.12.0/debian/changelog 2022-12-11 16:44:00.0 -0500
@@ -1,3 +1,10 @@
+python-acme (1.12.0-2+deb11u1) bullseye; urgency=medium
+
+  * Fix CSR version to prevent problems with strictly RFC-complying
+implementations of the ACME API (Closes: #1025891)
+
+ -- Harlan Lieberman-Berg   Sun, 11 Dec 2022 16:44:00 
-0500
+
 python-acme (1.12.0-2) unstable; urgency=medium
 
   * Commit missed changes to control file.
diff -Nru python-acme-1.12.0/debian/control python-acme-1.12.0/debian/control
--- python-acme-1.12.0/debian/control   2021-02-02 16:37:28.0 -0500
+++ python-acme-1.12.0/debian/control   2022-12-11 16:26:05.0 -0500
@@ -7,7 +7,6 @@
 Build-Depends: debhelper-compat (= 13),
dh-python,
python3,
-   python3-chardet,
python3-cryptography (>= 2.1.4),
python3-docutils,
python3-josepy,
@@ -18,6 +17,7 @@
python3-requests-toolbelt,
python3-rfc3339,
python3-setuptools (>= 11.3),
+   python3-six (>= 1.9),
python3-sphinx (>= 1.3.1-1~),
python3-sphinx-rtd-theme,
python3-tz
diff -Nru python-acme-1.12.0/debian/patches/fix-csr-version.patch 
python-acme-1.12.0/debian/patches/fix-csr-version.patch
--- python-acme-1.12.0/debian/patches/fix-csr-version.patch 1969-12-31 
19:00:00.0 -0500
+++ python-acme-1.12.0/debian/patches/fix-csr-version.patch 2022-12-11 
16:42:50.0 -0500
@@ -0,0 +1,40 @@
+Description: Fix incorrect CSR version
+  Certain strict implementations of the ACME API deny all version numbers 
except
+  that defined in the RFC (version 0). To accommodate, unilaterally set it to 
0.
+Author: Amir Omidi
+Origin: https://github.com/certbot/certbot/pull/9334/
+Bug-Debian: https://bugs.debian.org/1025891
+Acked-By: Harlan Lieberman-Berg 
+Index: python-acme/acme/crypto_util.py
+===
+--- python-acme.orig/acme/crypto_util.py
 python-acme/acme/crypto_util.py
+@@ -213,7 +213,8 @@ def make_csr(private_key_pem, domains, m
+ value=b"DER:30:03:02:01:05"))
+ csr.add_extensions(extensions)
+ csr.set_pubkey(private_key)
+-csr.set_version(2)
++# RFC 2986 Section 4.1 only defines version 0
++csr.set_version(0)
+ csr.sign(private_key, 'sha256')
+ return crypto.dump_certificate_request(
+ crypto.FILETYPE_PEM, csr)
+Index: python-acme/tests/crypto_util_test.py
+===
+--- python-acme.orig/tests/crypto_util_test.py
 python-acme/tests/crypto_util_test.py
+@@ -244,6 +244,14 @@ class MakeCSRTest(unittest.TestCase):
+ self.assertEqual(len(must_staple_exts), 1,
+ "Expected exactly one Must Staple extension")
+ 
++def test_make_csr_correct_version(self):
++csr_pem = self._call_with_key(["a.example"])
++csr = OpenSSL.crypto.load_certificate_request(
++OpenSSL.crypto.FILETYPE_PEM, csr_pem)
++
++self.assertEqual(csr.get_version(), 0,
++ "Expected CSR version to be v1 (encoded as 0), per 
RFC 2986, section 4")
++
+ 
+ class DumpPyopensslChainTest(unittest.TestCase):
+ """Test for dump_pyopenssl_chain."""
diff -Nru python-acme-1.12.0/debian/patches/series 
python-acme-1.12.0/debian/patches/series
--- python-acme-1.12.0/debian/patches/series2021-01-10 14:56:16.0 
-0500
+++ python-acme-1.12.0/debian/patches/series2022-12-11 16:38:15.0 
-0500
@@ -1 +1,2 @@
 disable-tls-alpn-test.patch
+fix-csr-version.patch

Bug#1023276: evdi: diff for NMU version 1.12.0+dfsg-0.1

[Harlan Lieberman-Berg]

Package: evdi
Version: 1.9.0+dfsg-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for evdi (versioned as 1.12.0+dfsg-0.1) and uploaded it to
DELAYED/0 as there has been no activity for some time and it has been dropped
from testing.

Regards.

diff -Nru evdi-1.9.0+dfsg/debian/changelog evdi-1.12.0+dfsg/debian/changelog
--- evdi-1.9.0+dfsg/debian/changelog2021-01-26 10:32:36.0 -0500
+++ evdi-1.12.0+dfsg/debian/changelog   2022-11-01 11:56:26.0 -0400
@@ -1,3 +1,12 @@
+evdi (1.12.0+dfsg-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release (Closes: #994892, #1017058)
+  * Import patch to fix FTBFS in Linux >= 6.0 from upstream
+  * Add dh-dkms to build-depends
+
+ -- Harlan Lieberman-Berg   Tue, 01 Nov 2022 11:56:26 
-0400
+
 evdi (1.9.0+dfsg-1) unstable; urgency=medium
 
   * new upstream release 1.9.0
diff -Nru evdi-1.9.0+dfsg/debian/control evdi-1.12.0+dfsg/debian/control
--- evdi-1.9.0+dfsg/debian/control  2021-01-26 10:32:36.0 -0500
+++ evdi-1.12.0+dfsg/debian/control 2022-11-01 11:56:26.0 -0400
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Hanno Stock 
-Build-Depends: debhelper-compat (= 13), dkms, dh-exec, libdrm-dev
+Build-Depends: debhelper-compat (= 13), dh-dkms, dkms, dh-exec, libdrm-dev
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://github.com/DisplayLink/evdi
diff -Nru evdi-1.9.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch 
evdi-1.12.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch
--- evdi-1.9.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch 1969-12-31 
19:00:00.0 -0500
+++ evdi-1.12.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch2022-11-01 
11:56:26.0 -0400
@@ -0,0 +1,53 @@
+From bdc258b25df4d00f222fde0e3c5003bf88ef17b5 Mon Sep 17 00:00:00 2001
+From: Adam Tazul <71192298+simpilotad...@users.noreply.github.com>
+Date: Thu, 13 Oct 2022 10:50:00 +0100
+Subject: [PATCH] Add support for kernel 6.0 + a minor fix (#381)
+
+* Add support for kernel 6.0
+
+Fixes #376 by implementing @Crashdummyy's fix as posted 
[here](https://github.com/DisplayLink/evdi/issues/376#issuecomment-1237450695)
+
+* Fixing the style used in evdi_painter.c
+
+* Update evdi_painter.c
+
+* drm_framebuffer is only included on 5.15 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 5.15.0 and later
+---
+ module/evdi_drm_drv.h | 2 +-
+ module/evdi_painter.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+Index: evdi/module/evdi_drm_drv.h
+===
+--- evdi.orig/module/evdi_drm_drv.h
 evdi/module/evdi_drm_drv.h
+@@ -26,7 +26,7 @@
+ #include 
+ #endif
+ #if KERNEL_VERSION(5, 15, 0) <= LINUX_VERSION_CODE
+-#include 
++#include 
+ #else
+ #include 
+ #endif
+Index: evdi/module/evdi_painter.c
+===
+--- evdi.orig/module/evdi_painter.c
 evdi/module/evdi_painter.c
+@@ -885,7 +885,7 @@ evdi_painter_connect(struct evdi_device
+ 
+   painter_lock(painter);
+ 
+-evdi->pixel_area_limit = pixel_area_limit;
++  evdi->pixel_area_limit = pixel_area_limit;
+   evdi->pixel_per_second_limit = pixel_per_second_limit;
+   painter->drm_filp = file;
+   kfree(painter->edid);
diff -Nru evdi-1.9.0+dfsg/debian/patches/series 
evdi-1.12.0+dfsg/debian/patches/series
--- evdi-1.9.0+dfsg/debian/patches/series   1969-12-31 19:00:00.0 
-0500
+++ evdi-1.12.0+dfsg/debian/patches/series  2022-11-01 11:56:26.0 
-0400
@@ -0,0 +1 @@
+0001-fix-6.0-ftbfs.patch
diff -Nru evdi-1.9.0+dfsg/library/evdi_lib.c evdi-1.12.0+dfsg/library/evdi_lib.c
--- evdi-1.9.0+dfsg/library/evdi_lib.c  2021-01-26 09:31:59.0 -0500
+++ evdi-1.12.0+dfsg/library/evdi_lib.c 2022-07-13 09:58:06.0 -0400
@@ -29,7 +29,7 @@
 #define EVDI_INVALID_DEVICE_INDEX -1
 
 #define EVDI_MODULE_COMPATIBILITY_VERSION_MAJOR 1
-#define EVDI_MODULE_COMPATIBILITY_VERSION_MINOR 8
+#define EVDI_MODULE_COMPATIBILITY_VERSION_MINOR 9
 #define EVDI_MODULE_COMPATIBILITY_VERSION_PATCH 0
 
 #define evdi_log(...) do { \
@@ -468,15 +468,45 @@
return dev_index;
 }
 
-static int find_unused_card_for(const char *sysfs_parent_device_path)
+static bool is_correct_parent_device(const char *dirname, const char 
*parent_device)
 {
+   char link_path[PATH_MAX];
+
+   snprintf(link_path, PATH_MAX - 7, "%s/device", dirname);
+
+   if (parent_device == NULL)
+   return access(link_path, F_OK) != 0;
+
+   char link_resolution[PATH_MAX];
+   const ssize_t link_resolution_len = readlink(link_path, 
link_resolution, PATH_MAX);
+
+   if (link_resolution_len == 

Bug#1017749: certbot: /usr/share/doc/certbot/README.rst.gz is not useful for Debian users

[Harlan Lieberman-Berg]

On Fri, Aug 19, 2022 at 7:51 PM Borden  wrote:
> The file /usr/share/doc/certbot/README.rst.gz provides a generic overview of 
> certbot and advice to refer to the official documentation at 
> https://certbot.eff.org/instructions?ws=apache=debiantesting . However, 
> will be confusing for new users because the instructions direct them to 
> install certbot from snap and _uninstall_ this package.
>
> Either encourage the eff.org to provide instructions that don't involve 
> removing this package or the README needs to provide specific instructions 
> for Debian users (for example: ignore steps 1 to 6 in the official 
> documentation and start where it says "Choose how you'd like to run Certbot")

Hello,

This is something that I've spoken to the EFF about before.  At the
time, they weren't willing to officially sign off on the distros'
packages because they were worried about the additional support
burden.  That being said, I think things have been stable for a long
period of time now and the overall velocity of feature releases has
slowed down, so I will approach them again.

Thank you for the prompt!

Sincerely,

Bug#1008992: xwayland: all X clients hang indefinitely waiting for /tmp/.X11-unix/X0

[Harlan Lieberman-Berg]

Package: xwayland
Version: 2:22.1.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: hlieber...@debian.org

After upgrade to 2:22.1.1-1, all X applications refuse to start.  strace shows 
that they hang on connect(2), waiting for the /tmp/.X11-unix/X0 socket.

XWayland on my system is being started by Gnome/mutter, with the following 
command line showing in ps:

/usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth 
/run/user/1000/.mutter-Xwaylandauth.A4B0J1 -listen 4 -listen 5 -displayfd 6 
-initfd 7

A full strace of an xeyes session (up through ^C) is attached.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xwayland depends on:
ii  libc6   2.33-7
ii  libdrm2 2.4.110-1
ii  libepoxy0   1.5.10-1
ii  libgbm1 21.3.7-1
ii  libgcrypt20 1.10.1-2
ii  libgl1  1.4.0-1
ii  libpixman-1-0   0.40.0-1
ii  libtirpc3   1.3.2-2
ii  libwayland-client0  1.20.0-1
ii  libxau6 1:1.0.9-1
ii  libxcvt00.1.1-3
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.5-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:21.1.3-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information


xeyes.log.13007.gz
Description: application/gzip

Bug#1005977: fwupd-signed

[Harlan Lieberman-Berg]

It looks like this is due to the migration of the efi capsule out to the
virtual packages fwupd-signed and fwupd-unsigned. Installing one should fix
the problem, but this bug should remain open to fix the underlying
Recommends’ bug.--
Harlan Lieberman-Berg
~hlieberman

Bug#1005854: pudb contains LGPL code, potentially changing the copyright status

[Harlan Lieberman-Berg]

Source: pudb
Version: 2020.1-1
Severity: serious
Tags: upstream
Justification: Policy 2.3
X-Debbugs-Cc: hlieber...@debian.org

In debugging pudb recently, I found a notice in pudb/settings.py (L35-63) where
the author has pointed out a section of code that was copied from pyxdg.

Looking in pyxdg, the substantially same code is in xdg/BaseDirectory.py, dating
back several years.

I see three paths to fix this:

1, Simply declare the entire package licensed under LGPL. That requires no code
changes and updates potential downstream users about a conflict.

2. Trace the lines of code to an author inside pyxdg and attempt to get them to
agree to license that segment under MIT.

3. Replace the code with an equivalent clean-room implementation.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#1004140: [certbot-apache] Bad SSLHonorCipherOrder

[Harlan Lieberman-Berg]

tag 1004140 +upstream
forwarded 1004140 https://github.com/certbot/certbot/issues/9180
severity 1004140 wishlist
thanks

On Fri, Jan 21, 2022 at 11:18 AM Jean-Michel Vourgère
 wrote:
> Please enable SSLHonorCipherOrder
> Or at the very least stop resetting it!

Hello Jean-Michel,

Thank you for your report.  I've forwarded this upstream for their
consideration.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#999503: python-acme: upstream changing signing keys

[Harlan Lieberman-Berg]

On Thu, Nov 11, 2021 at 10:12 PM Harlan Lieberman-Berg
 wrote:
> I received a notification from the Certbot team that they were updating the 
> PGP
> keys used to sign the next release to a new key, rsa3072/0xB6029E8500F7DB16,
> fingerprint BF6B CFC8 9E90 747B 9A68 0FD7 B602 9E85 00F7 DB16. I have verified
> that the new key has been signed by the old one.

Re-reading their email, it seems there are three possible keys, all
cross-signed:

rsa3072/0xB6029E8500F7DB16, EFF Certbot Team ,
fingerprint BF6B CFC8 9E90 747B 9A68  0FD7 B602 9E85 00F7 DB16
rsa3072/0x3402831161D1D280, EFF Certbot Team ,
fingerprint 8637 9B4F 0AF3 71B5 0CD9  E5FF 3402 8311 61D1 D280
rsa3072/0x780CC99432A28621, EFF Certbot Team ,
fingerprint 20F2 0134 6BF8 F3F4 55A7  3F9A 780C C994 32A2 8621

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#999503: python-acme: upstream changing signing keys

[Harlan Lieberman-Berg]

Source: python-acme
Version: 1.18.0-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: hlieber...@debian.org

I received a notification from the Certbot team that they were updating the PGP
keys used to sign the next release to a new key, rsa3072/0xB6029E8500F7DB16,
fingerprint BF6B CFC8 9E90 747B 9A68 0FD7 B602 9E85 00F7 DB16. I have verified
that the new key has been signed by the old one.

This bug is to track why the upstream signing key has been altered.

Sincerely,

--

Bug#995645: Joining the Debian Let's Encrypt Team

[Harlan Lieberman-Berg]

On Tue, Oct 12, 2021 at 12:44 PM Linus Vanas  wrote:
> I'm now hoping for the package and myself to be accepted into the
> Debian Let's Encrypt Team.

Hello Linus -- welcome to the team!

We'd love to have you maintain the dns-standalone plugin as part of
the Let's Encrypt team.  I've forked your packaging into the team repo
so it has a formal place to live
(https://salsa.debian.org/letsencrypt-team/certbot/certbot-dns-standalone)
and granted you maintainer permissions on the repo.

Jeroen has helped get your package up to snuff (thanks jcfp!), but
there are a couple of things specific to the way we've been packaging
modules for certbot that would be good to bring into alignment.

First, take a peek at the way we manage dependencies in some of the
other DNS plugins (certbot-dns-cloudflare is a good example,
https://salsa.debian.org/letsencrypt-team/certbot/certbot-dns-cloudflare/-/blob/master/debian/control).
We switched to using a virtual package ABI structure to help deal with
breaking version changes around the time of the 1.0 release.
dh-python can get a bit confused about install-time dependencies if
there's not also a dep on the python3 library, so we put the abi
packages as both build-dependencies and actual dependencies of the
package. (You don't need to have a dependency on the acme ABI if your
certbot dependency requires the same version).

It looks like upstream's tests are bogus, so no sense in supporting
those -- you did the right thing there.

The only other thing is that we've been using pristine-tar.  All you
need to do for that is pass the `--pristine-tar` flag to
gbp-import-orig when you import the new versions.  Because reimporting
it can be annoying, and git and pristine-tar can be... fiddly when you
didn't start with it, so I took care of this version for you already.

jcfp, do you want to close the loop and do the upload, since you've
been working with Linus so far? Happy either way!

Sincerely,




-- 
Harlan Lieberman-Berg
~hlieberman

Bug#993641: linux: enable 64-bit tmpfs inode allocation

[Harlan Lieberman-Berg]

On Sat, Sep 4, 2021 at 12:00 AM Harlan Lieberman-Berg
 wrote:
> I will be making an MR in Gitlab to this effect.

This has been done as
https://salsa.debian.org/kernel-team/linux/-/merge_requests/389.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#993641: linux: enable 64-bit tmpfs inode allocation

[Harlan Lieberman-Berg]

Source: linux
Version: 5.10.46-4
Severity: normal
Tags: patch
X-Debbugs-Cc: hlieber...@debian.org

Hello Kernel maintainers,

Due to a bug in tmpfs handling of inodes, it's possible to run into inode
collisions on heavily loaded tmpfs filesystems. This problem is described in
detail in
https://chrisdown.name/2021/07/02/tmpfs-inode-corruption-introducing-inode64.html
and has been applied by default in Arch.

Considering the potential for extremely hard to track failures and the fact that
this has been widely deployed already, I suggest that we enable
CONFIG_TMPFS_INODE64 by default.

I will be making an MR in Gitlab to this effect.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#988483: certbot: add preconfigured renewal flag

[Harlan Lieberman-Berg]

Package: certbot
Severity: wishlist
X-Debbugs-Cc: hlieber...@debian.org

As of the upcoming v1.16 release of certbot, upstream is requesting that we add
--preconfigured-renewal to either the command line flags or to the cli.ini file
so they can appropriately let the user know that automatic renewal has been
configured on their behalf.

This flag has been permitted since v1.9, however, it has no effect prior to 
v1.16.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#984143: 2.4.0

[Harlan Lieberman-Berg]

A simple update to 2.4.0 fixes this FTBFS (though note, it depends on
libportal which is only available in experimental).

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Harlan Lieberman-Berg]

On Sun, Mar 21, 2021 at 7:04 PM Don Armstrong  wrote:
> Hrm.  It was maintained by you, but there's a non-zero chance I installed it 
> directly from source. If it's never been uploaded, that's probably what 
> happened.

Iiiinteresting.  The plover repo that I've been working out of has
3.1.1 as the earliest version (Mon Nov 18 23:01:12 2019 -0500), but I
do remember vaguely trying to decide if I was going to split the
common out into its own repo.

I think the 3.0.0 might be dated back to when we were waiting on the
relicensing to solve the fact that it was undistributable (GPLv2 only
/ GPLv3 only) and I was trying to figure out the packaging in
preparation.

Sorry about that!
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1

[Harlan Lieberman-Berg]

tag 985675 +moreinfo
thanks

On Sun, Mar 21, 2021 at 3:39 PM Don Armstrong  wrote:
> plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship
> /usr/share/plover/assets/american_english_words.txt, but the latter is
> missing the appropriate Conflicts/Replaces.

Hi Don,

Where have you installed plover-common from?  That's not a package I
recognize in the archive.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#982292: certbot package upgrade hangs apt for 5 minutes

[Harlan Lieberman-Berg]

tag 982292 +confirmed
thanks

On Mon, Feb 8, 2021 at 6:36 AM Vincas Dargis  wrote:
> Just upgraded one Debian Buster VM, and during it `apt full-upgrade` stopped 
> on
> the `Setting up certbot` line.

Hi Vincas,

This definitely shouldn't be happening.  This bug is an edge case that
occurs in the following circumstance:

1. You are upgrading certbot, not installing it,
2. you have existing certs due for renewal on the machine, and
3. you trigger the install in the 0-12 hour period between the last
certbot run and when the certificate came due for renewal.

I'm putting a patch in to fix this in the next certbot release, but
I'm not sure it will be backported to stable.  I'll speak with some
folks to get their opinions on whether it needs a backport or not
because it's such an edge-case.

Thanks for your report!


-- 
Harlan Lieberman-Berg
~hlieberman

Bug#980006: pulseaudio: fails to prompt Gnome for headphone/headset selection (regression in 14.x)

[Harlan Lieberman-Berg]

Package: pulseaudio
Version: 14.0-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: hlieber...@debian.org, 
pkg-gnome-maintain...@lists.alioth.debian.org

Hello maintainers,

Not entirely sure whether this is a GNOME issue or a pulseaudio issue, but since
the breakage occured due to a change in the pulseaudio API, I'm putting it here
for now. Feel free to move it if appropriate.

Since upgrading from the 13.x branch, GNOME no longer prompts whether a device
is a headphone or headset on plug insertion. After talking with i-garrison on
freenode/#pulseaudio, our guess is that this is related to the creation of
availability groups in 13.99.2 and the changes made to module
switch-on-port-available.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1028 is related,
though not specifically covering the breakage between GNOME and PA, but rather
mistakes in the way PA did selection from g-s-d.

Sincerely,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-6
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.1-3
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-14
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.0-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-8
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-3
ii  libsystemd0  247.2-4
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.2-4
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.6.12-1
ii  libxcb1  1.14-2.1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.0-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-1
ii  libpam-systemd [logind]  247.2-4
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.2-4

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; 

Bug#976432: buster-pu: package python-certbot/0.31.0-1

[Harlan Lieberman-Berg]

On Sun, Jan 3, 2021 at 1:51 PM Adam D. Barratt  wrote:
> Thanks. Please feel free to upload.

Uploaded!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#978962: certbot: Certbot needs python-cryptography to work

[Harlan Lieberman-Berg]

Hi Nicolas,

Your installation of python3-cryptography is very broken.  You appear
to be missing about half of the files for some reason.  Try
reinstalling python3-cryptography and see if that fixes the problem:

apt reinstall python3-cryptography

On Sat, Jan 2, 2021 at 3:09 AM Nicolas Grandjean  wrote:
>
>
>
> Le 01/01/2021 à 22:16, Harlan Lieberman-Berg a écrit :
> > […]
> > Can you also attach the output of this new script?
>
> You can find it in the attached files.
>
> $ ./import2.py > import2.out1 2> import2.out2
>
>
> --
> Nicolas



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#976432: buster-pu: package python-certbot/0.31.0-1

[Harlan Lieberman-Berg]

On Fri, Jan 1, 2021 at 12:14 PM Adam D. Barratt
 wrote:
> That version number is lower than the package currently in buster. You
> want 0.31.0-1+deb10u1.

Indeed I do!  New debdiff attached.

> +  * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: 
> #971045)
>
> The metadata for that bug implies that it affects the package in
> unstable. I'm assuming that's simply an oversight? If so, please add an
> appropriate fixed version. (I'm not entirely sure why it was cloned
> from #969126 either, but that's not directly relevant here.)

Correct.  I cloned the bug so I could track the fix in oldstable and
the fix in stable separately, just to make sure I didn't miss one when
the autoclose happened.  I've updated the version numbers to show the
fix in unstable (and to remove the reference to oldstable in the
stable issue).

> The next point release is likely to be in early February. Assuming the
> plan outlined at
> https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
> is still current, it sounds like there will be one brown-out for v1 before 
> that point, possibly two if we're unlikely with timing. Are we anticipating 
> that being enough of an issue to warrant pushing the update via 
> stable-updates before the point release?

It's not great, but I also don't think it's necessarily worth fixing
through s-u.  I'll reach out to the ISRG folks and see what their
specific timing is like for doing the brownouts.  I may be able to
encourage them to nudge it backwards into February.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman
diff -Nru python-certbot-0.31.0/debian/changelog python-certbot-0.31.0/debian/changelog
--- python-certbot-0.31.0/debian/changelog	2019-02-09 19:39:59.0 -0500
+++ python-certbot-0.31.0/debian/changelog	2020-12-04 21:33:11.0 -0500
@@ -1,3 +1,15 @@
+python-certbot (0.31.0-1+deb10u1) buster; urgency=high
+
+  * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045)
+
+Let's Encrypt's ACMEv1 API is deprecated and in the process of being
+shut down. Beginning with brownouts in January 2021, and ending with a
+total shutdown in June 2021, the Let's Encrypt APIs will become
+unavailable. To prevent users having disruptions to their certificate
+renewals, this update backports the switch over to the ACMEv2 API.
+
+ -- Harlan Lieberman-Berg   Fri, 04 Dec 2020 21:33:11 -0500
+
 python-certbot (0.31.0-1) unstable; urgency=medium
 
   * New upstream version 0.31.0
diff -Nru python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
--- python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch	1969-12-31 19:00:00.0 -0500
+++ python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch	2020-12-04 21:33:11.0 -0500
@@ -0,0 +1,88 @@
+From 8a15bd7927e2b8956bb1f4d062423e471e473ccf Mon Sep 17 00:00:00 2001
+From: Alex Zorin 
+Date: Thu, 21 May 2020 22:58:40 +1000
+Subject: [PATCH 1/2] renewal: disregard acme-v01 in renewal configs
+
+Fixes #7979
+---
+ certbot/_internal/constants.py |  2 ++
+ certbot/_internal/renewal.py   | 17 +++--
+ certbot/tests/renewal_test.py  |  8 
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+Index: python-certbot/certbot/constants.py
+===
+--- python-certbot.orig/certbot/constants.py
 python-certbot/certbot/constants.py
+@@ -120,6 +120,8 @@ CLI_DEFAULTS = dict(
+ )
+ STAGING_URI = "https://acme-staging-v02.api.letsencrypt.org/directory;
+ 
++V1_URI = "https://acme-v01.api.letsencrypt.org/directory;
++
+ # The set of reasons for revoking a certificate is defined in RFC 5280 in
+ # section 5.3.1. The reasons that users are allowed to submit are restricted to
+ # those accepted by the ACME server implementation. They are listed in
+Index: python-certbot/certbot/renewal.py
+===
+--- python-certbot.orig/certbot/renewal.py
 python-certbot/certbot/renewal.py
+@@ -17,6 +17,7 @@ import OpenSSL
+ from acme.magic_typing import List  # pylint: disable=unused-import, no-name-in-module
+ 
+ from certbot import cli
++from certbot import constants
+ from certbot import crypto_util
+ from certbot import errors
+ from certbot import interfaces
+@@ -247,16 +248,28 @@ def _restore_int(name, value):
+ raise errors.Error("Expected a numeric value for {0}".format(name))
+ 
+ 
+-def _restore_str(unused_name, value):
++def _restore_str(name, value):
+ """Restores an string key-value pair from a renewal config file.
+ 
+-:param str unused_name: option name
++:param str name: option name
+ :param str value: option value
+ 
+ :returns: converted option value to be stored in the runtime config
+ :rtype: str or None
+ 
+ """
++# Previous to 

Bug#978962: certbot: Certbot needs python-cryptography to work

[Harlan Lieberman-Berg]

On Fri, Jan 1, 2021 at 6:24 AM Nicolas Grandjean  wrote:
> nicolas@krypton:/tmp$ ./import.py
> /usr/lib/python3/dist-packages/cryptography/__init__.py
> 2.6.1
> /usr/lib/python3/dist-packages/cryptography/hazmat/__init__.py
> None
> Traceback (most recent call last):
>   File "./import.py", line 10, in 
> import cryptography.hazmat.primitives.asymmetric
> ModuleNotFoundError: No module named
> 'cryptography.hazmat.primitives.asymmetric'

Curiouser and curiouser!  The version of the module you have installed
clearly has the module that it's complaining it can't find.  And the
'None' there is strange; that means it successfully loaded
cryptography.hazmat.primitives (otherwise the ModuleNotFoundError
would have been for cryptography.hazmat.primitives, instead of
cryptography.hazmat.primitives.asymmetric), but that the module didn't
have a path.

A couple more things to try so we can get some more info:

find /usr/lib/python3/dist-packages/cryptography/hazmat -name __init__.py -ls

Can you also attach the output of this new script?
-- 
Harlan Lieberman-Berg
~hlieberman
#!/usr/bin/python3 -vvv

import os, sys
import pkgutil

def print_submodules(module):
for loader, module_name, is_pkg in pkgutil.walk_packages(module.__path__, module.__name__+'.'):
print(module_name)
module_name = __import__(module_name, fromlist='dummylist')
if is_pkg:
print_submodules(module_name)

import cryptography
print_submodules(cryptography)

Bug#978962: certbot: Certbot needs python-cryptography to work

[Harlan Lieberman-Berg]

On Fri, Jan 1, 2021 at 4:57 AM Nicolas Grandjean  wrote:
> Dec 31 19:03:18 krypton certbot[4849]: ModuleNotFoundError: No module named 
> 'cryptography.hazmat.primitives.asymmetric'

Hi Nicolas,

That's a strange error.  certbot depends on python3-certbot, which I
see you have installed.  That package depends on python3-cryptography,
which should have the python module that it's erroring about.

A couple of things to get some more intel.  First, what's the output
of the following: dpkg -s python3-cryptography python3-certbot certbot

Second, can you run the attached script and give me the output?

-- 
Harlan Lieberman-Berg
~hlieberman
#!/usr/bin/python3

import cryptography
print(cryptography.__file__)
print(cryptography.__version__)
import cryptography.hazmat
print(cryptography.hazmat.__file__)
import cryptography.hazmat.primitives
print(cryptography.hazmat.primitives.__file__)
import cryptography.hazmat.primitives.asymmetric
print(cryptography.hazmat.primitives.asymmetric.__file__)

Bug#977350: certbot: Version in Debian Stable gets certificates by R3 issuer which might fail to validate

[Harlan Lieberman-Berg]

fixed 977350 1.10.1-1
thanks

On Mon, Dec 14, 2020 at 5:06 AM Frederik  wrote:
> The new certificate is now issued by C=US, O=Let's Encrypt, CN=R3, while
> the previous one was issued by C=US, O=Let's Encrypt, CN=Let's Encrypt 
> Authority X3
> This change is documented here: 
> https://community.letsencrypt.org/t/beginning-issuance-from-r3/139018

Hi Frederik!

Hm.  We wouldn't expect the R3 change to affect anything; certbot
doesn't ignore the intermediary like the post is warning about.  How
do you renew the certificates? (Are you using certonly?)

Would it be possible for you to upload the log of the renewal that
occurred with the old version and the new version?  The certbot client
version will be one of the first lines in the file.

Thanks for your help!

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#976432: buster-pu: package python-certbot/0.31.0-1

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hlieber...@debian.org, team+letsencr...@tracker.debian.org

Hello Release Team!

As part of the deprecation of the Let's Encrypt v1 endpoint beginning in
January, they are going to begin causing intermittant failures increasing to a
complete shutdown June 2021.

To prevent users from being affected by this transition, I've prepared a
backport of the piece of code that switches renewals automatically to v2. In
this version of the code, new certificates were already being issued through the
v2 URL.

A debdiff is attached.

Sincerely,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-certbot-0.31.0/debian/changelog 
python-certbot-0.31.0/debian/changelog
--- python-certbot-0.31.0/debian/changelog  2019-02-09 19:39:59.0 
-0500
+++ python-certbot-0.31.0/debian/changelog  2020-12-04 21:33:11.0 
-0500
@@ -1,3 +1,15 @@
+python-certbot (0.31.0-1~deb10u1) buster; urgency=high
+
+  * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045)
+
+Let's Encrypt's ACMEv1 API is deprecated and in the process of being
+shut down. Beginning with brownouts in January 2021, and ending with a
+total shutdown in June 2021, the Let's Encrypt APIs will become
+unavailable. To prevent users having disruptions to their certificate
+renewals, this update backports the switch over to the ACMEv2 API.
+
+ -- Harlan Lieberman-Berg   Fri, 04 Dec 2020 21:33:11 
-0500
+
 python-certbot (0.31.0-1) unstable; urgency=medium
 
   * New upstream version 0.31.0
diff -Nru python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 
python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
--- python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch  1969-12-31 
19:00:00.0 -0500
+++ python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch  2020-12-04 
21:30:36.0 -0500
@@ -0,0 +1,88 @@
+From 8a15bd7927e2b8956bb1f4d062423e471e473ccf Mon Sep 17 00:00:00 2001
+From: Alex Zorin 
+Date: Thu, 21 May 2020 22:58:40 +1000
+Subject: [PATCH 1/2] renewal: disregard acme-v01 in renewal configs
+
+Fixes #7979
+---
+ certbot/_internal/constants.py |  2 ++
+ certbot/_internal/renewal.py   | 17 +++--
+ certbot/tests/renewal_test.py  |  8 
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+Index: python-certbot/certbot/constants.py
+===
+--- python-certbot.orig/certbot/constants.py
 python-certbot/certbot/constants.py
+@@ -120,6 +120,8 @@ CLI_DEFAULTS = dict(
+ )
+ STAGING_URI = "https://acme-staging-v02.api.letsencrypt.org/directory;
+ 
++V1_URI = "https://acme-v01.api.letsencrypt.org/directory;
++
+ # The set of reasons for revoking a certificate is defined in RFC 5280 in
+ # section 5.3.1. The reasons that users are allowed to submit are restricted 
to
+ # those accepted by the ACME server implementation. They are listed in
+Index: python-certbot/certbot/renewal.py
+===
+--- python-certbot.orig/certbot/renewal.py
 python-certbot/certbot/renewal.py
+@@ -17,6 +17,7 @@ import OpenSSL
+ from acme.magic_typing import List  # pylint: disable=unused-import, 
no-name-in-module
+ 
+ from certbot import cli
++from certbot import constants
+ from certbot import crypto_util
+ from certbot import errors
+ from certbot import interfaces
+@@ -247,16 +248,28 @@ def _restore_int(name, value):
+ raise errors.Error("Expected a numeric value for {0}".format(name))
+ 
+ 
+-def _restore_str(unused_name, value):
++def _restore_str(name, value):
+ """Restores an string key-value pair from a renewal config file.
+ 
+-:param str unused_name: option name
++:param str name: option name
+ :param str value: option value
+ 
+ :returns: converted option value to be stored in the runtime config
+ :rtype: str or None
+ 
+ """
++# Previous to v0.5.0, Certbot always stored the `server` URL in the 
renewal config,
++# resulting in configs which explicitly use the deprecated ACMEv1 URL, 
today
++# preventing an automatic transition to the default modern ACME URL.
++# (https://github.com/certbot/certbot/issues/7978#issuecomment-625442870)
++# As a mitigation, this function reinterprets the value of the `server` 
parameter if
++# necessary, replacing the ACMEv1 URL with the default ACME URL. It 

Bug#973837: evdi module fails to compile on Linux 5.9.0

[Harlan Lieberman-Berg]

Package: evdi-dkms
Version: 1.7.0+dfsg-1
Severity: grave

Hello maintainer,

Looking at #960391, it looks like we've seen another kernel regression for evdi.
Even on the evdi-dkms from experimental, the module FTBFS with 5.9.0.

The compile log is attached.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evdi-dkms depends on:
ii  dkms  2.8.3-4

Versions of packages evdi-dkms recommends:
ii  libevdi0  1.7.0+dfsg-1

evdi-dkms suggests no packages.

-- no debconf information
DKMS make.log for evdi-1.7.0+dfsg for kernel 5.9.0-1-amd64 (x86_64)
Thu 05 Nov 2020 03:49:36 PM EST
make: Entering directory '/usr/src/linux-headers-5.9.0-1-amd64'
  AR  /var/lib/dkms/evdi/1.7.0+dfsg/build/built-in.a
  CC [M]  /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.o
  CC [M]  /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.o
  CC [M]  /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_connector.o
  CC [M]  /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_encoder.o
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:3: error: ‘struct drm_driver’ 
has no member named ‘gem_free_object’; did you mean ‘gem_open_object’?
   92 |  .gem_free_object = evdi_gem_free_object,
  |   ^~~
  |   gem_open_object
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:21: error: initialization of 
‘void (*)(struct drm_device *)’ from incompatible pointer type ‘void (*)(struct 
drm_gem_object *)’ [-Werror=incompatible-pointer-types]
   92 |  .gem_free_object = evdi_gem_free_object,
  | ^~~~
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:21: note: (near 
initialization for ‘driver.lastclose’)
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c: In function 
‘evdi_platform_probe’:
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:173:20: error: ‘struct 
dev_archdata’ has no member named ‘iommu’
  173 |  pdev->dev.archdata.iommu = INTEL_IOMMU_DUMMY_DOMAIN;
  |^
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.c: In function 
‘evdi_crtc_cursor_set’:
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.c:133:2: error: implicit 
declaration of function ‘drm_gem_object_put_unlocked’; did you mean 
‘drm_gem_object_put_locked’? [-Werror=implicit-function-declaration]
  133 |  drm_gem_object_put_unlocked(obj);
  |  ^~~
  |  drm_gem_object_put_locked
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: 
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.o] Error 1
make[2]: *** Waiting for unfinished jobs
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: 
/var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.o] Error 1
make[1]: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:1796: 
/var/lib/dkms/evdi/1.7.0+dfsg/build] Error 2
make: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:185: __sub-make] 
Error 2
make: Leaving directory '/usr/src/linux-headers-5.9.0-1-amd64'

Bug#966085: gitlab contains git bundles with non-free code, unlisted code

[Harlan Lieberman-Berg]

Source: gitlab
Severity: serious

Hello maintainer,

The source package contains copies of various project templates
(vendor/project_templates) that contain copyleft code which needs to
be mentioned in d/copyright.

For example, the git bundle ("./project.bundle") inside
vendor/project_templates/hexo.tar.gz contains the FontAwesome
webfonts, licensed under SIL OFL 1.1.

Additionally, some code contained in these bundles is non-DFSG free.
For example, in the same bundle as previously mentioned, in
landscape/source/fancybox there are files which are licensed under CC
BY-NC 3.0.

Please search the contents of the project templates git bundles for
files and incorporate it into the d/copyright file, or ensure they are
excluded from all distributed binaires.

Sincerely,

Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils

[Harlan Lieberman-Berg]

affects 964242 debootstrap
thanks

On Sun, 5 Jul 2020 12:52:54 +0200 Michael Meskes  wrote:
> On Sat, Jul 04, 2020 at 10:52:04AM +0200, Rene Engelhard wrote:
> > But that bsdextrautils (>= 2.35.2-7) doesn't exist:
>
> Yes, as already communicated we had to wait with the next util-linux upload
> until bsdmainutils made it out of NEW. Now that it has, Chris will upload as
> soon as he finds the time.

Because debootstrap follows Recommends and bsdmainutils is Recommended
by bsdutils in Priority: required, this bug means debootstrap can't
currently create sid bases.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#963583: sysdig: sysdig segfaults on start

[Harlan Lieberman-Berg]

On Tue, 23 Jun 2020 18:59:25 -0700 Dima Kogan
 wrote:
>   $ sudo sysdig ...
>   sysdig: symbol lookup error: sysdig: undefined symbol: 
> _ZN9grpc_impl23CreateCustomChannelImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt10shared_ptrINS_18ChannelCredentialsEERKNS_16ChannelArgumentsE
>
> This sounds like #955279, but even if it is, there should be a
> Conflicts, or something, to prevent me from getting into that state. In
> any case, I just

Updating the gprc library was probably the thing that fixed it; there
was a bad libgrpc version.  AFAIK you shouldn't need the libgrpc++-dev
package to run sysdig.

> And now it segfaults again:
>
>   $ sudo sysdig
>   zsh: segmentation fault  sudo sysdig

Hm, this is strange.  I've tested this a couple of different ways,
including on a clean sid box and a sid box with libc downgraded to the
same version as on your machine, but I can't recreate the error.

Would it be possible for you to use rr to capture a dump of the segfault for me?

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#962811: calibre: ebook-viewer crash on start

[Harlan Lieberman-Berg]

severity grave
tags 962811 +confirmed
clone 962811 -1 -2
reassign -1 pyqt5webengine 5.14.0-2+b1
retitle -1 pyqt5webengine: fails to block pyqt5 update
reassign -2 pyqt5 5.15.0+dfsg-1
retitle -2 pyqt5: update breaks pyqt5webengine and deps
affects -1 calibre
thanks

On Sun, 14 Jun 2020 15:31:47 +0200 Davide Prina  wrote:
> in this bug report the prolem is a python2 library, I have see that the
> corresponding python3 library has been updated today:
> python3-pyqt5
>
> but I cant try to install the previews version, elsewhere it will remove
> calibre and so I cannot test if this is the problem.

I've done a bit of digging, and this problem is solved by manually
updating pyqt5webengine to 5.15 from unstable.  The root cause is that
there is an unstated strict version dependency between these two
packages, and/or some symbols were changed without being handled
properly.

Reassigning the bug to the correct packages.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#962508: switch libcurl to openssl by default

[Harlan Lieberman-Berg]

Package: cargo
Version: 0.43.1-3
Severity: wishlist

Hello fellow Rustaceans!

Because cargo has a direct dependency on OpenSSL, it seems logical that we
should switch the priority of openssl and gnutls so Cargo, at least by default,
isn't building against two different TLS implementations.

This is especially important considering GnuTLS has had some painful security
incidents recently: CVE-2020-13777 in particular.

Should just require switching the order of the libcurl dep in d/control.

Sincerely,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cargo depends on:
ii  binutils2.34-8
ii  gcc [c-compiler]4:9.2.1-3.1
ii  gcc-8 [c-compiler]  8.4.0-4
ii  gcc-9 [c-compiler]  9.3.0-13
ii  libc6   2.30-8
ii  libcurl3-gnutls 7.68.0-1
ii  libgcc-s1   10.1.0-1
ii  libgit2-28  0.28.5+dfsg.1-1
ii  libssh2-1   1.8.0-2.1
ii  libssl1.1   1.1.1g-1
ii  rustc   1.42.0+dfsg1-1
ii  zlib1g  1:1.2.11.dfsg-2

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  
ii  python33.8.2-3

-- no debconf information

Bug#950964: anki: Anki won't play sound, claims mpv is too old

[Harlan Lieberman-Berg]

tag 950964 +patch
thanks

On Sun, May 3, 2020 at 4:56 PM Julian Gilbey  wrote:
> I'm slowly working on packaging the newer versions, but it is proving
> to be quite difficult.

Hi Julian,

Totally understand; I know anki had some major architectural changes
recently that I'm sure are making your life all sorts of fun.

I've backported the patch from upstream to fix the issue in the older
version, so if you want to fix this issue separately from the upstream
version bump, you should be able to do that easily.  I've tested and
confirmed this patch fixes the problem, and applies cleanly to the
version of anki you have in master in salsa right now.

Sincerely,


-- 
Harlan Lieberman-Berg
~hlieberman
Description: Fix mpv arguments to prevent failures
 In mpv 0.31.0, it started interpreting its arguments strictly, such
 that you must pass the option value after an equals sign.  As a
 result of this, anki started incorrectly calling mpv and crashing
 with a warning about the version of mpv being too old.  This patch,
 backported from a newer version of anki, corrects this problem.
Author: Harlan Lieberman-Berg 
Origin: https://github.com/ankitects/anki/commit/ccd715013609133c55e83924734efa78abc03326
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950964
Index: anki/anki/mpv.py
===
--- anki.orig/anki/mpv.py
+++ anki/anki/mpv.py
@@ -104,9 +104,9 @@ class MPVBase:
 """
 self.argv = [self.executable]
 self.argv += self.default_argv
-self.argv += ["--input-ipc-server", self._sock_filename]
+self.argv += ["--input-ipc-server=" + self._sock_filename]
 if self.window_id is not None:
-self.argv += ["--wid", str(self.window_id)]
+self.argv += ["--wid=" + str(self.window_id)]
 
 def _start_process(self):
 """Start the mpv process.
@@ -568,4 +568,3 @@ class MPV(MPVBase):
 """Set the value of property `name`.
 """
 return self.command("set_property", name, value)
-

Bug#950964: anki: Anki won't play sound, claims mpv is too old

[Harlan Lieberman-Berg]

On Sun, 9 Feb 2020 10:56:36 + Julian Gilbey  wrote:
> At the moment, I'm trying to find time to package the latest version
> of anki, which is a major undertaking (huge changes to the software
> architecture).  If that fixes this problem, great, if not, we can
> certainly add a hard dependency for the time being.

Hi Julian,

Confirmed; this is fixed in the upstream version 2.1.20.

Sincerely,

-- 
Harlan Lieberman-Berg

Bug#951696: certbot: Incompatibility with python3-urllib3=1.25.8-1

[Harlan Lieberman-Berg]

reassign 951696 requests
retitle 951696 requests: incompatibility between requests == 2.22.0-2
and urllib3 == 1.25.8-1
tag 951696 +unreproducible
affects 951696 certbot python3-urllib3
thanks

I've looked over this several times over the last few months, and I
can't reproduce the problem on any of my test systems.  However,
looking at the code, if this bug exists, it's definitely between
requests and urllib3, not in certbot itself.

Sending it over to the requests folks, in the hopes that they've seen
this somewhere else and can reproduce it.

Sincerely,

On Fri, Feb 21, 2020 at 4:10 AM Alexandre Beelen
 wrote:
>
> Hi,
>
> I was simply trying to renew my certificate with
>
> certbot renew
>
> Also try to obtain new certificate after ditching /etc/letsencrypt to
> make sure it was not a configuration problem, with the same outcome
>
> it works with :
>
> python3-requests   2.22.0-2
> python3-urllib31.24.1-1
>
> it fails with :
>
> python3-requests   2.22.0-2
> python3-urllib3    1.25.8-1
>
> a.
>
> On 21/02/2020 05:29, Harlan Lieberman-Berg wrote:
> > Hello Alexandre,
> >
> > Can you please tell me exactly what command you're running when
> > certbot gives you that stacktrace?  Can you also let me know what
> > version of python3-requests you have? That looks like a
> > requests/urllib3 incompatibility, but I can't reproduce it by hand or
> > inside certbot.
> >
> > Sincerely,
> >
> > On Thu, Feb 20, 2020 at 4:27 AM abeelen  wrote:
> >>
> >> Package: certbot
> >> Version: 1.1.0-1
> >> Severity: important
> >>
> >> Dear Maintainer,
> >>
> >> When run with python3-urllib3=1.25-8-1, certbot fails to run with a 
> >> traceback :
> >>
> >> Traceback (most recent call last):
> >>File "/usr/lib/python3/dist-packages/requests/models.py", line 379, in 
> >> prepare_url
> >>  scheme, auth, host, port, path, query, fragment = parse_url(url)
> >>File "/usr/lib/python3/dist-packages/urllib3/util/url.py", line 392, in 
> >> parse_url
> >>  return six.raise_from(LocationParseError(source_url), None)
> >>File "", line 3, in raise_from
> >> urllib3.exceptions.LocationParseError: Failed to parse: 
> >> https://acme-v02.api.letsencrypt.org/directory
> >>
> >> downgrading to python3-urllib3=1.24.1-1 solve this issue.
> >>
> >>
> >> -- System Information:
> >> Debian Release: bullseye/sid
> >>APT prefers unstable
> >>APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> >> 'oldstable'), (1, 'experimental')
> >> Architecture: amd64 (x86_64)
> >>
> >> Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
> >> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> >> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> >> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> >> Shell: /bin/sh linked to /bin/dash
> >> Init: systemd (via /run/systemd/system)
> >> LSM: AppArmor: enabled
> >>
> >> Versions of packages certbot depends on:
> >> ii  python3  3.7.5-3
> >> ii  python3-certbot  1.1.0-1
> >>
> >> certbot recommends no packages.
> >>
> >> Versions of packages certbot suggests:
> >> pn  python-certbot-doc  
> >> ii  python3-certbot-apache  1.1.0-1
> >> pn  python3-certbot-nginx   
> >>
> >> -- no debconf information
> >>
> >
> >



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#954650: AttributeError: module 'certbot.plugins.common' has no attribute 'TLSSNI01'

[Harlan Lieberman-Berg]

On Sun, Mar 22, 2020 at 5:51 AM Damien Couroussé
 wrote:
> I could fix the issue by upgrading python3-certbot-apache to version
> 1.1.0-1.

Hi Damien,

Yes, these two versions are not fully compatible.  I didn't put in a
version restriction because mixing packages from testing into a stable
installation can result in breakage (such as you've ran into).  If you
really want to do so, make sure that you pull not only the package
from testing, but all the things that reverse-depend on it.  For
certbot, the easiest way to do that is to specify that you want to
install the leaf package from testing (python3-certbot-apache), rather
than the middle package (certbot, or python3-certbot).  That should
reliably upgrade certbot itself, if it's necessary to do so.

That said, I'll talk with upstream and see if I can add some level of
version protection to keep it from happening in the future.

Thanks for your report!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#953135: ITP: golang-github-letsencrypt-challtestsrv -- ACME challenge mock server

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: golang-github-letsencrypt-challtestsrv
  Version : 1.2.0
  Upstream Author : Let's Encrypt (Internet Security Research Group)
* URL : https://github.com/letsencrypt/challtestsrv
* License : MPL-2.0
  Programming Lang: Go
  Description : ACME challenge mock server

challtestsrv is a library for testing code to respond to HTTP-01,
DNS-01, and TLS-ALPN-01 ACME challenges.  It can also be used as a
mock DNS server letting developers mock `A`, ``, `CNAME`, and
`CAA` DNS data for specific hostnames.
.
Important note: The `challtestsrv` library is for TEST USAGE ONLY.  It
is trivially insecure, offering no authentication whatsoever.  Only
use this library in a controlled test environment.

This library is being packaged as a dependency for pebble, which is
itself an ACME test server to be used by the Debian Let's Encrypt team
for end-to-end CI testing of ACME clients.

Bug#953130: ITP: pebble -- ACME (RFC 8555) compliance testing server

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: pebble
  Version : 2.3.0
  Upstream Author : Let's Encrypt (Internet Security Research Group)
* URL : https://github.com/letsencrypt/pebble
* License : MPL-2.0
  Programming Lang: Go
  Description : ACME (RFC 8555) test-only server

Pebble is a miniature version of Boulder
(https://github.com/letsencrypt/boulder) that can assist in the
development and testing of ACME clients against the standard without
having to setup a full production-capable ACME server.
.
Pebble is NOT designed for production use and is for testing only.  By
design, it will drop all of its state between invocations and will
randomize keys and certificates used for issuance!
.
Pebble has several top level goals:
.
1. Provide a simplified ACME testing front end
2. Provide a test-bed for new and compatibility breaking ACME features
3. Encourage ACME client best-practices
4. Aggressively build in guardrails against non-testing usage

Pebble is being packaged for Debian in order to provide a test harness
for the certbot client, as well as other ACME clients in Debian, with
the goal to be able to provide evidence that as-installed clients are
fully functional through the Debian CI system.  It will be maintained
under the auspices of the Debian Let's Encrypt team.

Bug#951696: certbot: Incompatibility with python3-urllib3=1.25.8-1

[Harlan Lieberman-Berg]

Hello Alexandre,

Can you please tell me exactly what command you're running when
certbot gives you that stacktrace?  Can you also let me know what
version of python3-requests you have? That looks like a
requests/urllib3 incompatibility, but I can't reproduce it by hand or
inside certbot.

Sincerely,

On Thu, Feb 20, 2020 at 4:27 AM abeelen  wrote:
>
> Package: certbot
> Version: 1.1.0-1
> Severity: important
>
> Dear Maintainer,
>
> When run with python3-urllib3=1.25-8-1, certbot fails to run with a traceback 
> :
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/requests/models.py", line 379, in 
> prepare_url
> scheme, auth, host, port, path, query, fragment = parse_url(url)
>   File "/usr/lib/python3/dist-packages/urllib3/util/url.py", line 392, in 
> parse_url
> return six.raise_from(LocationParseError(source_url), None)
>   File "", line 3, in raise_from
> urllib3.exceptions.LocationParseError: Failed to parse: 
> https://acme-v02.api.letsencrypt.org/directory
>
> downgrading to python3-urllib3=1.24.1-1 solve this issue.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages certbot depends on:
> ii  python3  3.7.5-3
> ii  python3-certbot  1.1.0-1
>
> certbot recommends no packages.
>
> Versions of packages certbot suggests:
> pn  python-certbot-doc  
> ii  python3-certbot-apache  1.1.0-1
> pn  python3-certbot-nginx   
>
> -- no debconf information
>


-- 
Harlan Lieberman-Berg
~hlieberman

Bug#947816: GeoLite2 databases are now non-free

[Harlan Lieberman-Berg]

Nope; that’s what I get for filing bugs while sleep deprived.

Sorry for the spam!

On Tue, Dec 31, 2019 at 04:10 Faidon Liambotis  wrote:

> On Mon, Dec 30, 2019 at 11:37:52PM -0500, Harlan Lieberman-Berg wrote:
> > 
> >
> > Based on this license change, it seems to me that geoipupdate can no
> > longer be in main.  Contrib may be a suitable home, however?
>
> geoipupdate is already in contrib (it has always been that way). Did you
> perhaps miss that, or did I misunderstood your question?
>
> Regards,
> Faidon
>
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#947816: GeoLite2 databases are now non-free

[Harlan Lieberman-Berg]

Package: geoipupdate
Severity: serious

Hello maintainer,

Unfortunately, it seems that MaxMind have changed their policies on GeoLite2 
databases such that they now require a license key.  In addition (and more 
critically), they are no longer licensed under a Creative Commons BY-SA 
license, and now are under a custom EULA.

I reviewed the EULA (https://www.maxmind.com/en/geolite2/eula) and, while I am 
neither an attorney nor a debian-legal faux-counsel, the agreement seems to 
violate the DFSG in several regards.

First, it places restrictions on fields of endeavor -- specifically, that you 
may not use the data for Fair Credit Reporting Act purposes, including 
determining whether a person may be granted credit, eligible for insurance, for 
employment purposes, or any other purpose governed by the FCRA.

Second, you are no longer permitted to redistribute the data except by binding 
them to the EULA.

Third, you are required to check in with MaxMind regularly and destroy old 
versions of the dataset within 30 days.  This seems to violate several 
long-standing interpretations of the DFSG including the desert island test and 
the tentacles of evil test.

Based on this license change, it seems to me that geoipupdate can no longer be 
in main.  Contrib may be a suitable home, however?

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#654659: ITP: plover

[Harlan Lieberman-Berg]

retitle 654659 ITP: plover -- stenotype input method
owner 654659 !
thanks

Sorry for letting this lie for so long.  I've redone the packaging of
the latest weekly at the advice of upstream, and it seems to be in a
good state.  I'm holding off on uploading it until a more experienced
plover user tests my debs, but that should be happening in the next
week.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#934843: parsedatetime: FTBFS in stretch

[Harlan Lieberman-Berg]

tag 934843 +unreproducible
thanks

On Thu, 15 Aug 2019 19:12:49 + Santiago Vila  wrote:
> I tried to build this package in stretch but it failed:

Hello!

This is quite strange.  I've tried rebuilding it several times in my
stretch sbuild, and it worked every time without error.  I also
re-triggered the build on reproducible-builds, and it's now clean
there as well.

One possibility that comes to mind is locales -- what locales are you
compiling under? It's possible there's a bug in one of the
locale-specific parsers that's not getting exercised on my sbuild,
through, I admit to not being sure how reproducible-builds could have
been affected by the same thing.  Otherwise, maybe a difference in one
of the deps that was fixed in the last... day?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

On Sat, Oct 26, 2019 at 10:44 AM Adam D. Barratt
 wrote:
> I've included a draft for an SUA below; comments welcome.

The draft looks good.  I've included a couple of minor tweaks, just to
help indicate to users that there may be an operational impact, not
just broken tests in a CI system somewhere.

Other than that, +1, it's ready to ship!


-- 
Harlan Lieberman-Berg
~hlieberman
--- old.txt	2019-10-27 11:50:56.226063124 -0400
+++ new.txt	2019-10-27 11:53:02.668777460 -0400
@@ -11,12 +11,12 @@
 python-acme is part of an implementation of the ACME protocol, as used
 by the Let's Encrypt certification authority to issue TLS certificates.
 
-The ACME protocol has deprecated support for the use of unauthenicated
+The ACME protocol has deprecated support for the use of unauthenticated
 GET requests in favour of authenticated POST requests. On November 1st,
 Let's Encrypt's staging ACME v2 endpoint will stop supporting the older
 protocol, with the production endpoint following at a later point. The
 staging endpoint is used by applications such as certbot in order to
-perform tests before issuing a certificate.
+perform tests, including when testing renewals with `--dry-run`.
 
 This update moves python-acme to use the newer protocol.
 

Bug#941719: certbot: certbot purge my certs at /etc/letsencrypt/

[Harlan Lieberman-Berg]

package certbot
retitle 941719 certbot: warn users when purging valid certificates
severity 941719 wishlist
thanks

On Fri, Oct 4, 2019 at 4:21 AM Yangfl  wrote:
> This can be disastrous as someone might forget to backup his certs and
> occasionally purge all reomved but unpurged packages.

Hello,

This behavior seems to me to be the proper one given that Debian
Policy requires the removal of conffiles when a package is purged
(§6.8.5).  The dpkg(1) manpage also seems to indicate that this
behavior is correct: "The package is selected to be purged (i.e. we
want to remove  everything from system directories, even configuration
files)."

I could, however, see it being useful to give the user an additional
warning when removing certificates that are still valid. " 'm not sure
when I'll be able to tackle this, but I'll change the ticket over to a
wishlist item to reflect that so I hopefully don't forget.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

On Sun, Oct 13, 2019 at 06:53 Adam D. Barratt 
wrote:

> Apologies for the delay. Please go ahead.


Uploaded!

> --
Harlan Lieberman-Berg
~hlieberman

Bug#935211: python-acme: Please port to Python 3 and/or drop Python 2 package

[Harlan Lieberman-Berg]

Yup; I’m targeting it for tomorrow evening when I have some time to do
Debian work.

On Tue, Oct 1, 2019 at 14:29 Sunil Mohan Adapa  wrote:

> Hello,
>
> The python-acme package and consequently, all of certbot and FreedomBox,
> are set to be autoremoved from Debian testing in just a few days from
> now on Sunday, the 6th of October, 2019. Since the fix seems to be
> straight forward, can some please look into this and upload the package
> without Python2 and python3-ndg-httpsclient?
>
> Gianfranco Costamagna, the patch you have attached seems to be incorrect
> and meant for another unrelated package.
>
> Thank you,
>
> --
> Sunil
>
> --
Harlan Lieberman-Berg
~hlieberman

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello release managers,

We have a proposed update for acme in stretch (oldstable).  This is
necessary to prevent the package, and all its dependencies, stopping
to work due to changes to the web service that the acme module is
primarily used for.  (Let's Encrypt)

We've backported the minimal set of patches, and upstream has
validated that the set is correct.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-acme-0.28.0/debian/changelog 
python-acme-0.28.0/debian/changelog
--- python-acme-0.28.0/debian/changelog 2018-12-02 16:24:15.0 -0500
+++ python-acme-0.28.0/debian/changelog 2019-07-31 22:26:45.0 -0400
@@ -1,3 +1,11 @@
+python-acme (0.28.0-1~deb9u2) stretch; urgency=medium
+
+  * This stretch update is to switch to using a POST-as-GET protocol
+before the November 1, 2019 deadline when Let's Encrypt will begin
+refusing requests using the (old) GET protocol. (Closes: #932248)
+
+ -- Harlan Lieberman-Berg   Wed, 31 Jul 2019 22:26:45 
-0400
+
 python-acme (0.28.0-1~deb9u1) stretch; urgency=medium
 
   * This stretch update is to cure the problem caused by the deprecation
diff -Nru python-acme-0.28.0/debian/patches/-post-as-get.patch 
python-acme-0.28.0/debian/patches/-post-as-get.patch
--- python-acme-0.28.0/debian/patches/-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.28.0/debian/patches/-post-as-get.patch2019-07-31 
18:40:59.0 -0400
@@ -0,0 +1,317 @@
+From 0b5468e992ab57fa028ddf33ca2351cb37c8e1ee Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand 
+Date: Fri, 30 Nov 2018 01:42:06 +0100
+Subject: [PATCH] Implement POST-as-GET requests (#6522)
+
+* Setup an integration tests env against Pebble, that enforce post-as-get
+
+* Implement POST-as-GET requests, with fallback to GET.
+
+* Fix unit tests
+
+* Fix coverage.
+
+* Fix or ignore lint errors
+
+* Corrections after review
+
+* Correct test
+
+* Try a simple delegate approach
+
+* Add a test
+
+* Simplify test mocking
+
+* Clean comment
+---
+Index: python-acme/acme/client.py
+===
+--- python-acme.orig/acme/client.py
 python-acme/acme/client.py
+@@ -199,22 +199,6 @@ class ClientBase(object):  # pylint: dis
+ 
+ return datetime.datetime.now() + datetime.timedelta(seconds=seconds)
+ 
+-def poll(self, authzr):
+-"""Poll Authorization Resource for status.
+-
+-:param authzr: Authorization Resource
+-:type authzr: `.AuthorizationResource`
+-
+-:returns: Updated Authorization Resource and HTTP response.
+-
+-:rtype: (`.AuthorizationResource`, `requests.Response`)
+-
+-"""
+-response = self.net.get(authzr.uri)
+-updated_authzr = self._authzr_from_response(
+-response, authzr.body.identifier, authzr.uri)
+-return updated_authzr, response
+-
+ def _revoke(self, cert, rsn, url):
+ """Revoke certificate.
+ 
+@@ -236,6 +220,7 @@ class ClientBase(object):  # pylint: dis
+ raise errors.ClientError(
+ 'Successful revocation must return HTTP OK status')
+ 
++
+ class Client(ClientBase):
+ """ACME client for a v1 API.
+ 
+@@ -388,6 +373,22 @@ class Client(ClientBase):
+ body=jose.ComparableX509(OpenSSL.crypto.load_certificate(
+ OpenSSL.crypto.FILETYPE_ASN1, response.content)))
+ 
++def poll(self, authzr):
++"""Poll Authorization Resource for status.
++
++:param authzr: Authorization Resource
++:type authzr: `.AuthorizationResource`
++
++:returns: Updated Authorization Resource and HTTP response.
++
++:rtype: (`.AuthorizationResource`, `requests.Response`)
++
++"""
++response = self.net.get(authzr.uri)
++updated_authzr = self._authzr_from_response(
++response, authzr.body.identifier, authzr.uri)
++return updated_authzr, response
++
+ def poll_and_request_issuance(
+ self, csr, authzrs, mintime=5, max_attempts=10):
+ """Poll and request issuance.
+@@ -651,13 +652,29 @@ class ClientV2(ClientBase):
+ body = messages.Order.from_json(response.json())
+ authorizations = []
+ for url in body.authorizations:
+-
authorizations.append(self._authzr_from_response(self.net.get(url), uri=url))
++
authorizations.app

Bug#932444: closed by Harlan Lieberman-Berg (Re: Bug#932444: certbot: package certbot should require python-certbot-apache)

[Harlan Lieberman-Berg]

That's a good idea.  I'll open an issue upstream to have them consider this.

On Sun, Jul 21, 2019 at 4:03 PM Martin Monperrus
 wrote:
>
> Thanks for your answer.
>
> Then, one solution might be to give the name of the missing package in the 
> error message, ie replacing
>
> "The requested apache plugin does not appear to be installed."
>
> by
>
> "Plugin python-certbot-apache is missing, it must be installed"



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#928453: unblock: python-acme/0.31.0-2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-acme to fix RC bug #928452.

Because of changes to the ACME v2 standard, unauthenticated GET
requests to ACME compatible APIs must be performed as special
POST-as-GET requests to be valid.  The primary ACME API, Let's
Encrypt, has deprecated support for unauthenticated GET requests as of
October 2018, and plans on removing support for them entirely on
November 1, 2019.

To prevent the version being frozen into buster from becoming RC-buggy
on November 1, a backport is being prepared to add this functionality
before buster is released in coordination with upstream.

Debdiff is attached.

unblock python-acme/0.31.0-2

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-acme-0.31.0/debian/changelog 
python-acme-0.31.0/debian/changelog
--- python-acme-0.31.0/debian/changelog 2019-02-09 19:07:59.0 -0500
+++ python-acme-0.31.0/debian/changelog 2019-05-04 21:32:00.0 -0400
@@ -1,3 +1,9 @@
+python-acme (0.31.0-2) unstable; urgency=medium
+
+  * Backport POST-as-GET support (Closes: #928452)
+
+ -- Harlan Lieberman-Berg   Sat, 04 May 2019 21:32:00 
-0400
+
 python-acme (0.31.0-1) unstable; urgency=medium
 
   * Bump dependency on josepy to >= 1.1.0
diff -Nru python-acme-0.31.0/debian/patches/0001-post-as-get.patch 
python-acme-0.31.0/debian/patches/0001-post-as-get.patch
--- python-acme-0.31.0/debian/patches/0001-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.31.0/debian/patches/0001-post-as-get.patch2019-05-04 
21:32:00.0 -0400
@@ -0,0 +1,66 @@
+From b0d960f102c998d8231c0ee48952b488f10864ac Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand 
+Date: Wed, 1 May 2019 00:37:23 +0200
+Subject: [PATCH] Send a POST-as-GET request to query registration in ACME v2
+ (#6993)
+
+* Send a post-as-get request to query registration
+
+* Add comments. Add again a line.
+
+* Prepare code for future PR about post-as-get
+---
+diff --git a/acme/client.py b/acme/client.py
+index a41787756f..5a8fd88ae9 100644
+--- a/acme/client.py
 b/acme/client.py
+@@ -123,15 +123,6 @@ def deactivate_registration(self, regr):
+ """
+ return self.update_registration(regr, update={'status': 
'deactivated'})
+
+-def query_registration(self, regr):
+-"""Query server about registration.
+-
+-:param messages.RegistrationResource: Existing Registration
+-Resource.
+-
+-"""
+-return self._send_recv_regr(regr, messages.UpdateRegistration())
+-
+ def _authzr_from_response(self, response, identifier=None, uri=None):
+ authzr = messages.AuthorizationResource(
+ body=messages.Authorization.from_json(response.json()),
+@@ -276,6 +267,15 @@ def register(self, new_reg=None):
+ # pylint: disable=no-member
+ return self._regr_from_response(response)
+
++def query_registration(self, regr):
++"""Query server about registration.
++
++:param messages.RegistrationResource: Existing Registration
++Resource.
++
++"""
++return self._send_recv_regr(regr, messages.UpdateRegistration())
++
+ def agree_to_tos(self, regr):
+ """Agree to the terms-of-service.
+
+@@ -603,10 +603,13 @@ def query_registration(self, regr):
+ Resource.
+
+ """
+-self.net.account = regr
+-updated_regr = super(ClientV2, self).query_registration(regr)
+-self.net.account = updated_regr
+-return updated_regr
++self.net.account = regr  # See certbot/certbot#6258
++# ACME v2 requires to use a POST-as-GET request (POST an empty JWS) 
here.
++# This is done by passing None instead of an empty UpdateRegistration 
to _post().
++response = self._post(regr.uri, None)
++self.net.account = self._regr_from_response(response, uri=regr.uri,
++
terms_of_service=regr.terms_of_service)
++return self.net.account
+
+ def update_registration(self, regr, update=None):
+ """Update registration.
diff -Nru python-acme-0.31.0/debian/patches/0002-post-as-get.patch 
python-acme-0.31.0/debian/patches/0002-post-as-get.patch
--- python-acme-0.31.0/debian/patches/0002-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.31.0/debian/patches/0002-post-as-get.patch2019-05-04 
21:3

Bug#928452: POST-as-GET support needed in Buster

[Harlan Lieberman-Berg]

Source: python-certbot
Version: 0.31.0-1
Severity: serious
Tags: upstream

Because of changes to the ACME v2 standard, unauthenticated GET
requests to ACME compatible APIs must be performed as special
POST-as-GET requests to be valid.  The primary ACME API, Let's
Encrypt, has deprecated support for unauthenticated GET requests as of
October 2018, and plans on removing support for them entirely on
November 1, 2019.

To prevent the version being frozen into buster from becoming RC-buggy
on November 1, a backport is being prepared to add this functionality
before buster is released in coordination with upstream.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#927326: use temp filesystem for signing operation

[Harlan Lieberman-Berg]

Package: sicherboot
Version: 0.1.5
Severity: wishlist
Tags: upstream

Hallo Julian!

Recently, I've started running into a problem where my efi partition
is so small that there isn't room to have two copies of the kernel
living in the efi partition to do the signing operation.  Looking at
l111 of sicherboot, I don't see any reason off the top of my head why
the sign_image operation needs to have the .jak-bak file stored in
/boot/efi.

We could switch to a file generated with mktemp to do the signing
operation and then copy it back over.

Obviously, this is a low priority -- I have a workaround for right
now, and I really should just suck it up and expand my EFI partition.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sicherboot depends on:
ii  binutils  2.31.1-15
ii  efitools  1.8.1-1
ii  systemd   241-3
ii  uuid-runtime  2.33.1-0.1

sicherboot recommends no packages.

sicherboot suggests no packages.

-- no debconf information

Bug#905929: marked as done (sysdig FTBFS on arm64/mips*/alpha/riscv64: syscall_table.c fails to compile)

[Harlan Lieberman-Berg]

reopen 905929
notfixed 905929 0.24.1-2
thanks

Unfortunately, the patch was missing an #ifdef.  Correcting with -3

Bug#926685: unblock: python3-lexicon/3.0.8-2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello release team,

I was recently made aware of a bug in python3-lexicon that causes the
certbot dnsimple plugin to be completely broken.  I've spoken to the
upstreams of both certbot and lexicon, and we've worked out a plan
forward.

A single backported patch for python3-lexicon will fix the issue for
certbot and anything else that's using the DNSimple API.  The
functional change is a single line, though the patch is slightly
bigger to correct the tests as well.

Could I get it unblocked for migration into buster?  A debdiff is
attached.

Thanks!

unblock python3-lexicon/3.0.8-2

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lexicon-3.0.8/debian/changelog lexicon-3.0.8/debian/changelog
--- lexicon-3.0.8/debian/changelog  2019-01-06 09:24:20.0 -0500
+++ lexicon-3.0.8/debian/changelog  2019-04-08 18:07:45.0 -0400
@@ -1,3 +1,10 @@
+lexicon (3.0.8-2) unstable; urgency=high
+
+  * Team upload.
+  * Import dnsimple create fix from upstream (Closes: #926682)
+
+ -- Harlan Lieberman-Berg   Mon, 08 Apr 2019 18:07:45 
-0400
+
 lexicon (3.0.8-1) unstable; urgency=medium
 
   [ Ana Custura ]
diff -Nru lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch 
lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
--- lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
1969-12-31 19:00:00.0 -0500
+++ lexicon-3.0.8/debian/patches/0004-fix-dnsimple-creates.patch
2019-04-08 18:02:42.0 -0400
@@ -0,0 +1,143 @@
+From d0bf4939d49c63026411a306615b6fb13ed0cc22 Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand 
+Date: Wed, 3 Apr 2019 23:43:24 +0200
+Subject: [PATCH] Fix create record on dnsimple (#389)
+
+---
+ lexicon/providers/dnsimple.py | 2 +-
+ ..._calling_delete_record_by_filter_should_remove_record.yaml | 2 +-
+ ..._record_by_filter_with_fqdn_name_should_remove_record.yaml | 2 +-
+ ..._record_by_filter_with_full_name_should_remove_record.yaml | 2 +-
+ ...ling_delete_record_by_identifier_should_remove_record.yaml | 2 +-
+ ...h_record_set_by_content_should_leave_others_untouched.yaml | 2 +-
+ ...calling_delete_record_with_record_set_name_remove_all.yaml | 4 ++--
+ ...ing_update_record_with_fqdn_name_should_modify_record.yaml | 2 +-
+ ...ing_update_record_with_full_name_should_modify_record.yaml | 2 +-
+ 9 files changed, 10 insertions(+), 10 deletions(-)
+
+Index: python-lexicon/lexicon/providers/dnsimple.py
+===
+--- python-lexicon.orig/lexicon/providers/dnsimple.py
 python-lexicon/lexicon/providers/dnsimple.py
+@@ -69,7 +69,7 @@ class Provider(BaseProvider):
+ record['regions'] = self._get_provider_option('regions')
+ 
+ payload = self._post(
+-'{0}/zones/{1}/records'.format(self.account_id, self.domain), 
record)
++'/{0}/zones/{1}/records'.format(self.account_id, self.domain), 
record)
+ 
+ LOGGER.debug('create_record: %s', 'id' in payload)
+ return 'id' in payload
+Index: 
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
+===
+--- 
python-lexicon.orig/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
 
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_record_by_filter_should_remove_record.yaml
+@@ -112,7 +112,7 @@ interactions:
+   Content-Type: [application/json]
+   User-Agent: [python-requests/2.19.1]
+ method: POST
+-uri: https://api.sandbox.dnsimple.com/v2731/zones/lexicontest.us/records
++uri: https://api.sandbox.dnsimple.com/v2/731/zones/lexicontest.us/records
+   response:
+ body: {string: 
'{"data":{"id":502887,"zone_id":"lexicontest.us","parent_id":null,"name":"delete.testfilt","content":"challengetoken","ttl":3600,"priority":null,"type":"TXT","regions":["global"],"system_record":false,"created_at":"2018-07-09T05:38:19Z","updated_at":"2018-07-09T05:38:19Z"}}'}
+ headers:
+Index: 
python-lexicon/tests/fixtures/cassettes/dnsimple/IntegrationTests/test_Provider_when_calling_delete_rec

Bug#926682: lexicon cannot create records through DNSimple

[Harlan Lieberman-Berg]

Package: python3-lexicon
Version: 3.0.8-1
Severity: important
Tags: upstream

An update to the DNSimple API caused a bug in lexicon to go from
technically-wrong-but-working to straight-up-broke.  A minor patch
ported from upstream will fix this problem, and unbreak the certbot
plugin that depends on lexicon for its dnsimple support.

I've verified with the upstream developers that there's no problem in
cherry-picking just the patch back onto the version we have in buster.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-lexicon depends on:
ii  python3   3.7.2-1
ii  python3-cryptography  2.6.1-3
ii  python3-future0.16.0-1
ii  python3-requests  2.21.0-1
pn  python3-tldextract
ii  python3-yaml  3.13-2

Versions of packages python3-lexicon recommends:
pn  python3-boto3  
pn  python3-softlayer  

python3-lexicon suggests no packages.

Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed

[Harlan Lieberman-Berg]

On Mon, 8 Apr 2019 16:50:31 +0100 ana  wrote:
> Thanks for the update on this. It would be a shame to drop the package
> entirely from Debian. Have had a look at the packaging on salsa and I'm
> happy to take over. I would need DM permissions on it to make uploads.

Hi Ana!

Happy to sponsor you for uploading  on it if you'll take it over.
Ping me on the original removal bug when you have the upload prepared
that names you as a maintainer and closes the O.

-Harlan

Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

On Sat, Mar 23, 2019 at 18:21 Adam D. Barratt 
wrote:

> It looks like there was an issue with the upload:


Indeed. My new key hasn’t reached the keyring package yet, it seems. I’ll
reach out to some of the other pkg-letsencrypt folks and see if I can get
one of them to sponsor it in.

> --
Harlan Lieberman-Berg
~hlieberman

Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

Control: tags -1 + pending

On Sat, Mar 23, 2019 at 1:17 PM Adam D. Barratt
 wrote:
> Welcome to why we get paranoid about changes in stable updates. :-)

Tell me about it!  I'm always chewing my fingernails off every time I
do an upload there... and yet.

Thanks much for your help!
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

After talking to kibi and jrtc27 on IRC, pushing up a new proposed
diff with some tweaks to the control file and changelog.

For more background about how this happened and why the move to v9
fixes it (with many, many thanks to Michael Biebl who walked me
through this earlier when I sent up a flare for help):

In the unstable branch, we switched to using dh_installsystemd instead
of dh_systemd_enable in between the version that was in stable and the
version in unstable.  When preparing the SRU for the update, I undid
those changes and reduced the compat level down to match the version
that was in stretch (v10) to reduce the diff that would occur in
stable.  Unbeknownst to me, there was a change to the behavior of
dh_systemd_enable between v9 and v10 that causes problems on upgrade.

In v9, dh_systemd_enable would stop timers in prerm and then start
them in postinst.  In v10, however, dh_systemd_enable switches to
using try-restart, which will noop on stopped timers.  This means when
the SRU was installed, the timer was stopped (in the old v9 prerm) and
never started (in the new v10 postinst).  Changing back to use v9 will
mean that the package will invoke the start on the timer regardless of
its current status, fixing broken systems and preventing new problems.

This problem doesn't occur on fresh installs because the postinst is
called differently, and although I tested certbot extensively (and had
upstream do the same), none of us were looking closely at the timer
functionality because "it wasn't supposed to change" (because that's
never caused bugs before, god knows.)

Sincerely,
--
Harlan Lieberman-Berg
~hlieberman


certbot-src.debdiff
Description: Binary data

Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

On Sun, Mar 10, 2019 at 2:48 PM Adam D. Barratt
 wrote:
> The source debdiff is clearly *not* empty. Your diffoscope output shows
>  changes to debian/changelog, debian/control, debian/compat, ... those
> are all in the source package and thus would appear in a source
> debdiff.

Derp, was diffing the changes file instead of the .dsc.  Attached.

-- 
Harlan Lieberman-Berg
~hlieberman


certbot-src.debdiff
Description: Binary data

Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello SRMs,

Due to an error in the certbot 0.28.0-1~deb9u1 upload, users are
having their systemd timers disabled and not correctly reactivated by
the upload.  After consulting with the pkg-systemd folx, we have come
up with a solution for the problem, but it will require an upload.

There's some amount of time-sensitivity here, as certbot certificates
will automatically expire ninety days after they're issued, and if the
systemd timer is not running, people's TLS certificates will expire.
This could happen as soon as the package is installed depending on
when the certificates were issued, but it will defintely happen for
everyone using certbot if this update doesn't hit their machine by
April.

The update will be relatively trivial; dropping the compat level one
notch is all that's needed.

What are your thoughts about using the security upload process to fix
this in a more aggressive timeline?

Apologies for the trouble. :(

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

Bug#922031: Timer Disabling on Package Update? (is: #922031)

[Harlan Lieberman-Berg]

On Sun, Mar 10, 2019 at 1:19 PM Michael Biebl  wrote:
> Let's bump this to serious. I think you should consider making another
> stable upload for this.
> As users have pointed out, systems which aren't rebooted regularly are
> otherwise up for a nasty experience.
> You might consider asking the security team to distribute the update
> with stable-security more quickly and not wait for the next stable upload.

I agree; this needs an update.  I'll open a ticket with the SRMs and
see what they think about it going to -security.

> You have a couple of options to fix this:
> 1/ Switch the compat level back to what 0.10 was using

I think this is the most reasonable approach, since newer versions
aren't using dh_installsystemd anyway.

The bigger question for me is... what do we do about users who have
already upgraded? If my understanding is correct, if we switch back to
compat level 9, they'll all be forcibly started again by the postinst,
correct?  Or do we need to explicitly start it again?

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#922031: Timer Disabling on Package Update? (is: #922031)

[Harlan Lieberman-Berg]

On Sun, Mar 10, 2019 at 12:29 PM Michael Biebl  wrote:
> Can you provide the output of
> systemctl status certbot.timer
> journalctl -u certbot.timer

The output of `systemctl show certbot.timer` is at
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=922031;filename=systemctl-show-certbot.timer.txt;msg=20
.  One of the reporters will have to follow up with the output of
journalctl -u certbot.timer, as I can't replicate the problem.

> Is certbot.timer restarted as part of the package update?

Not unless dh_installsystemd is doing it automagically, no.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#922031: Timer Disabling on Package Update? (is: #922031)

[Harlan Lieberman-Berg]

Hello pkg-systemd!

There's a strange bug being reported in the stable-updated version of
certbot about the systemd timer that I'm having trouble reproducing or
understanding how it could happen.

According to the users reporting the issue, between the update from
0.10~ to 0.28.0.1~deb9u1, the systemd timer stops functioning.  In the
list-timers output, both NEXT and LAST are listed as "n/a".  Rebooting
the machine fixes the problem (potentially temporarily?).

Looking back at the changes that were made to the debian/ directory, I
don't see anything that could have caused this.  We did change the
timer file during the upgrade, but just to change the value of
RandomizedDelaySec -- and we didn't change from dh_installsystemd to
dh_systemd_{enable,start}.  I'm not sure how/why this could have
happened, but I'm clearly out of my depth on the systemd stuff and
need some help.

I'm not subscribed to pkg-systemd-maintainers, so please keep me (and
the bug!) CCed.

Thanks much!

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#922031: certbot: Debian 9 systemd timer inactive after upgrade to 0.28.0-1~deb9u1

[Harlan Lieberman-Berg]

On Mon, Feb 11, 2019 at 8:12 AM Václav Ovsík  wrote:
> there is no periodic certificate renew task. LE sent me a first email
> about a first certificate expiration.

Hello Václav,

Hm, that's strange.  I went back and checked, and the timer file was
present in the 0.10 version as well.  The timer used to work, and now
no longer does, correct?

Can you send the output of `systemctl show certbot.timer`?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#921423: /var/log/letsencrypt gets wiped on transitional package purge

[Harlan Lieberman-Berg]

On Tue, Feb 5, 2019 at 10:57 PM Mattia Rizzolo  wrote:
> Sure, of course that's the cause, but your suggested fix would instead
> introduce the other bug that "purge does not delete related logs", which
> is what everybody is expecting "purge" to do.

Hi Mattia,

The bug here is that the transitional dummy package purges the
directory that the main package which provides it uses.  Both certbot
and letsencrypt use `/var/log/letsencrypt` for their log storage, but
the letsencrypt package has been hollowed out and made into a dummy.
The directory will still be deleted if you purge certbot, which is the
new and correct owner of that path.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#882395: still seeing this in buster

[Harlan Lieberman-Berg]

tag 882395 +wontfix
thanks

On Thu, 24 Jan 2019 20:48:01 +0100 Hans-Christoph Steiner  wrote:
> I'm still seeing this in buster

Hello!

Yes, this is expected behavior.  Because certbot is intended for
administrators to be relatively hands-off, and especially for
administrators who are not very experienced, certbot will install its
own ciphersuites.  If this is not desired, you can avoid it by not
using the apache plugin for installation, and only using it for
authentication.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920360: certbot: does not work if python is set to python3 in update-alternatives

[Harlan Lieberman-Berg]

tag 920360 +moreinfo -d-i
thanks

On Thu, Jan 24, 2019 at 1:06 PM Pascal Grafe  wrote:
> Package does not install/work if python is set to python3 in update-
> alternatives.

Hello!  Can you please provide the error that you're experiencing?
/usr/bin/certbot directly invokes /usr/bin/python3 with the shebang,
so what /usr/bin/python is set to shouldn't matter.  (Additionally,
I've tested it and it appears to still work even if it is set that
way.)

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920565: certbot modifies /etc/letsencrypt everytime certbot is executed.

[Harlan Lieberman-Berg]

tag 920565 +upstream
severity 920565 minor
forwarded 920565 https://github.com/certbot/certbot/issues/6726
thanks

On Sat, Jan 26, 2019 at 8:57 PM Jim Popovitch  wrote:
> It is recommended (citation needed!) to not modify files/dirs in /etc/
> every time a cmd is executed, rather only when config files are
> modified.

Sent this one upstream!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#920895: certbot: post-hook command: service apache2 stop

[Harlan Lieberman-Berg]

On Wed, Jan 30, 2019 at 6:24 AM Xavier Bestel  wrote:
> Certbot says it will stop apache after renewing certificates (although 
> apparently it doesn't).

Hello!

Very strange.  What is in your /etc/letsencrypt/renewal-hooks
sub-directories?  Does `grep hook
/etc/letsencrypt/renewal/awak.mobi.conf` return any rows?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

Indeed -- sorry about that, everyone!  I intended for that to go out
before I went on vacation (and didn't have email access), but it looks
like I didn't quite manage it.

I'm doing the uploads again now.

On Mon, Jan 21, 2019 at 6:05 AM Julien Cristau  wrote:
>
> On Thu, Jan 17, 2019 at 01:48:24PM -0800, Brad Warren wrote:
> > I just wanted to make sure this was still on everyone’s radar. The
> > change server side where tens of thousands of Debian users will begin
> > being unable to renew their certificates is in less than a month.
> >
> It is, but the initial uploads used the wrong version numbers and had to
> be rejected.  AIUI Harlan should be back this week, hopefully he can get
> to this.
>
> Cheers,
> Julien
>
> > > On Jan 8, 2019, at 4:24 PM, Harlan Lieberman-Berg  
> > > wrote:
> > >
> > > Hello Julien, everyone,
> > >
> > > I've uploaded the relevant packages for your examination.  The
> > > packages uploaded are:
> > >
> > > - python-acme_0.28.0-1+deb9u1
> > > - python-certbot_0.28.0-1+deb9u1
> > > - python-certbot-nginx_0.28.0-1+deb9u1
> > > - python-certbot-apache_0.28.0-1+deb9u1
> > > - python-josepy_1.1.0-2+deb9u1
> > > - parsedatetime_2.1-3+deb9u1
> > >
> > > On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
> > >  wrote:
> > >>
> > >> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  
> > >> wrote:
> > >>> OK, let's do that then.  Sorry for not getting back to this sooner.
> > >>
> > >> Sounds good.  I'm preparing the uploads now.
> > >>
> > >> It looks like I will need to rebuild the version of
> > >> python-parsedatetime in stable to also build the python3 version.  I
> > >> could also backport a newer version that builds python3.  Let me know.
> > >>
> > >> Sincerely,
> > >> --
> > >> Harlan Lieberman-Berg
> > >> ~hlieberman
> > >
> > >
> > >
> > > --
> > > Harlan Lieberman-Berg
> > > ~hlieberman
> > >
> > > --
> > > To unsubscribe, send mail to 887399-unsubscr...@bugs.debian.org.
> > >



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#918914: add -fstack-clash-protection to default buildflags

[Harlan Lieberman-Berg]

Package: dpkg-dev
Version: 1.19.2
Severity: wishlist
Tags: security

Hello GCC Maintainers!

It would be Really Awesome (TM) if we could add the
-fstack-clash-protection flag to our default hardening posture.  This
would have provided protection against the recent System Down
vulnerability (CVE-2018-16864, CVE-2018-16865, CVE-2018-16866, aka
#918841 and #918848).

I'd reay love it if it would make it into buster, but I know
that's an awfully aggressive timeline considering the upcoming freeze.
Still, there are an awfully high number of vulnerabilities that are
lurking that this might be able to help patch up.

Happy to discuss more, and if we need to do a test archive-rebuild
with that change made, I can probably do that in the upcoming weekend.

Sincerely,

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg-dev depends on:
ii  binutils  2.31.1-11
ii  bzip2 1.0.6-9
ii  libdpkg-perl  1.19.2
ii  make  4.2.1-1.2
ii  patch 2.7.6-3
ii  perl  5.28.1-3
ii  tar   1.30+dfsg-3
ii  xz-utils  5.2.2-1.3

Versions of packages dpkg-dev recommends:
ii  build-essential  12.5
ii  fakeroot 1.23-1
ii  gcc  4:8.2.0-2
ii  gcc-7 [c-compiler]   7.3.0-29
ii  gcc-8 [c-compiler]   8.2.0-13
ii  gnupg2.2.12-1
ii  gnupg2   2.2.12-1
ii  gpgv 2.2.12-1
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2018.11.25

-- no debconf information

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

Hello Julien, everyone,

I've uploaded the relevant packages for your examination.  The
packages uploaded are:

- python-acme_0.28.0-1+deb9u1
- python-certbot_0.28.0-1+deb9u1
- python-certbot-nginx_0.28.0-1+deb9u1
- python-certbot-apache_0.28.0-1+deb9u1
- python-josepy_1.1.0-2+deb9u1
- parsedatetime_2.1-3+deb9u1

On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
 wrote:
>
> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> > OK, let's do that then.  Sorry for not getting back to this sooner.
>
> Sounds good.  I'm preparing the uploads now.
>
> It looks like I will need to rebuild the version of
> python-parsedatetime in stable to also build the python3 version.  I
> could also backport a newer version that builds python3.  Let me know.
>
> Sincerely,
> --
> Harlan Lieberman-Berg
> ~hlieberman



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#913930: Confirmed for sbuild only

[Harlan Lieberman-Berg]

found 913930 2.5.118
thanks

On Mon, 19 Nov 2018 13:19:38 -0800 Felix Lechner
 wrote:
> Hi, I can reproduce the issue only when using sbuild. I am looking
> into the possibility that a dependency is missing inside sbuild.
> Meanwhile, I marked the bug as confirmed. Thank you!

Hello Felix!

Just as one more datapoint for you, I see the same thing with
certbot-dns-ovh with lintian 2.5.118 and sbuild 0.77.1-2.

I don't know if it will help, but I've copy/pasted the list of files
that sbuild downloaded in the repo against the lastest sid minimal
chroot to install and run lintian.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman
Get:1 copy:/<>/apt_archive ./ sbuild-build-depends-lintian-dummy 
0.invalid.0 [852 B]
Get:2 http://deb.debian.org/debian unstable/main amd64 liblocale-gettext-perl 
amd64 1.07-3+b4 [18.9 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 netbase all 5.5 [19.3 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 ucf all 3.0038+nmu1 
[69.0 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 diffstat amd64 1.62-1 
[33.4 kB]
Get:6 http://deb.debian.org/debian unstable/main amd64 libapt-pkg-perl amd64 
0.1.34+b1 [71.2 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 libhtml-tagset-perl all 
3.20-3 [12.7 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 liburi-perl all 1.74-1 
[89.4 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 libhtml-parser-perl 
amd64 3.72-3+b3 [105 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 libcgi-pm-perl all 
4.40-1 [222 kB]
Get:11 http://deb.debian.org/debian unstable/main amd64 libsub-name-perl amd64 
0.21-1+b3 [13.6 kB]
Get:12 http://deb.debian.org/debian unstable/main amd64 libclass-accessor-perl 
all 0.51-1 [23.2 kB]
Get:13 http://deb.debian.org/debian unstable/main amd64 libclone-perl amd64 
0.41-1+b1 [14.6 kB]
Get:14 http://deb.debian.org/debian unstable/main amd64 libdigest-hmac-perl all 
1.03+dfsg-2 [10.6 kB]
Get:15 http://deb.debian.org/debian unstable/main amd64 libtimedate-perl all 
2.3000-2 [42.2 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 perl-openssl-defaults 
amd64 3 [6782 B]
Get:17 http://deb.debian.org/debian unstable/main amd64 libnet-ssleay-perl 
amd64 1.85-2+b1 [308 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 libio-socket-ssl-perl 
all 2.060-3 [207 kB]
Get:19 http://deb.debian.org/debian unstable/main amd64 libnet-smtp-ssl-perl 
all 1.04-1 [6184 B]
Get:20 http://deb.debian.org/debian unstable/main amd64 libmailtools-perl all 
2.18-1 [88.5 kB]
Get:21 http://deb.debian.org/debian unstable/main amd64 libnet-ip-perl all 
1.26-2 [29.0 kB]
Get:22 http://deb.debian.org/debian unstable/main amd64 libnet-dns-perl all 
1.19-1 [372 kB]
Get:23 http://deb.debian.org/debian unstable/main amd64 libnet-domain-tld-perl 
all 1.75-1 [33.3 kB]
Get:24 http://deb.debian.org/debian unstable/main amd64 libemail-valid-perl all 
1.202-1 [23.0 kB]
Get:25 http://deb.debian.org/debian unstable/main amd64 libexporter-tiny-perl 
all 1.002001-1 [36.9 kB]
Get:26 http://deb.debian.org/debian unstable/main amd64 
libipc-system-simple-perl all 1.25-4 [26.5 kB]
Get:27 http://deb.debian.org/debian unstable/main amd64 libfile-basedir-perl 
all 0.08-1 [17.7 kB]
Get:28 http://deb.debian.org/debian unstable/main amd64 libio-pty-perl amd64 
1:1.08-1.1+b5 [33.7 kB]
Get:29 http://deb.debian.org/debian unstable/main amd64 libio-string-perl all 
1.08-3 [12.3 kB]
Get:30 http://deb.debian.org/debian unstable/main amd64 libipc-run-perl all 
20180523.0-1 [101 kB]
Get:31 http://deb.debian.org/debian unstable/main amd64 liblist-moreutils-perl 
amd64 0.416-1+b4 [64.2 kB]
Get:32 http://deb.debian.org/debian unstable/main amd64 
libparse-debianchangelog-perl all 1.2.0-13 [59.5 kB]
Get:33 http://deb.debian.org/debian unstable/main amd64 
libtext-levenshtein-perl all 0.13-1 [11.1 kB]
Get:34 http://deb.debian.org/debian unstable/main amd64 
libxml-namespacesupport-perl all 1.12-1 [14.8 kB]
Get:35 http://deb.debian.org/debian unstable/main amd64 libxml-sax-base-perl 
all 1.09-1 [20.4 kB]
Get:36 http://deb.debian.org/debian unstable/main amd64 libxml-sax-perl all 
1.00+dfsg-1 [58.6 kB]
Get:37 http://deb.debian.org/debian unstable/main amd64 libxml-libxml-perl 
amd64 2.0132+dfsg-2+b1 [344 kB]
Get:38 http://deb.debian.org/debian unstable/main amd64 libxml-simple-perl all 
2.25-1 [72.0 kB]
Get:39 http://deb.debian.org/debian unstable/main amd64 libyaml-libyaml-perl 
amd64 0.75+repack-1 [32.9 kB]
Get:40 http://deb.debian.org/debian unstable/main amd64 patchutils amd64 
0.3.4-2 [90.4 kB]
Get:41 http://deb.debian.org/debian unstable/main amd64 t1utils amd64 1.41-3 
[62.3 kB]
Get:42 http://deb.debian.org/debian unstable/main amd64 lintian all 2.5.118 
[1172 kB]

Bug#917114: ansible: crashes when trying to read vault variables

[Harlan Lieberman-Berg]

retitle 917114 ansible: crashes when running playbook in non-ascii path
tag 917114 +confirmed +upstream
thanks

On Mon, Dec 24, 2018 at 12:31 PM Yvan Masson
 wrote:
> The isdir() function gave me a hint: my playbook and other files are in
> a path that contains character "é". I moved it to a path with only ASCII
> chars and it fixed the issue. I am very surprised this type of issue
> still exist in popular software like Ansible!

Bingo!

Yes, please -- when you do, please shoot a link over to this ticket so
we can track it on this side.

It's quite possible that ansible upstream may be uninterested in
fixing this as it will get fixed "automatically" when we switch to
using python3.  We're working on that now, and we hope to have it
finished in time to get into buster before the freeze.  They still
advertise py2 support, though, so I consider it still a bug.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#917114: ansible: crashes when trying to read vault variables

[Harlan Lieberman-Berg]

On Sat, Dec 22, 2018 at 4:06 PM Yvan Masson  wrote:
> Using testing, Ansible crashes when trying to read vault variables. I
> see this issue since Ansible 2.6 at least.

Interesting!  Can you try to reproduce this with `LC_ALL=C LANG=C` ?

Also, do you get the same error when you run the command without the
verbosity flags? That error appears to be a unicode string problem
related to some debug output.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#568897: [debhelper-devel] Bug#568897: Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

[Harlan Lieberman-Berg]

Hello all!

Just pinging this again for reconsideration.  I ran into this
recently, and copy/pasting bits of makefile throughout various
packages' debian/rules seems like the wrong solution to me.

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> OK, let's do that then.  Sorry for not getting back to this sooner.

Sounds good.  I'm preparing the uploads now.

It looks like I will need to rebuild the version of
python-parsedatetime in stable to also build the python3 version.  I
could also backport a newer version that builds python3.  Let me know.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

Hello Jeremy, release team,

Yes, the minimal set of involved source packages is python-acme,
python-certbot, python-certbot-nginx, and python-certbot-apache.  This
would also require the new package python-josepy, which is also
maintained by the LE team.

They should be able to be taken directly out of backports without
breaking anything.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#912103: python-certbot-dns-route53 FTBFS: ConnectionRefusedError: [Errno 111] Connection refused

[Harlan Lieberman-Berg]

", line 152, in 
> _send_output
> self.send(msg)
>   File "/usr/lib/python3/dist-packages/botocore/awsrequest.py", line 236, in 
> send
> return super(AWSConnection, self).send(str)
>   File "/usr/lib/python3.6/http/client.py", line 964, in send
> self.connect()
>   File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 166, in 
> connect
> conn = self._new_conn()
>   File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 150, in 
> _new_conn
> self, "Failed to establish a new connection: %s" % e)
> urllib3.exceptions.ProxyError: ('Cannot connect to proxy.', 
> NewConnectionError(' 0x7fe256361358>: Failed to establish a new connection: [Errno 111] Connection 
> refused',))
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File 
> "/build/1st/python-certbot-dns-route53-0.23.0/certbot_dns_route53/dns_route53_test.py",
>  line 23, in setUp
> self.auth = Authenticator(self.config, "route53")
>   File 
> "/build/1st/python-certbot-dns-route53-0.23.0/certbot_dns_route53/dns_route53.py",
>  line 36, in __init__
> self.r53 = boto3.client("route53")
>   File "/usr/lib/python3/dist-packages/boto3/__init__.py", line 91, in client
> return _get_default_session().client(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/boto3/session.py", line 263, in client
> aws_session_token=aws_session_token, config=config)
>   File "/usr/lib/python3/dist-packages/botocore/session.py", line 878, in 
> create_client
> credentials = self.get_credentials()
>   File "/usr/lib/python3/dist-packages/botocore/session.py", line 479, in 
> get_credentials
> 'credential_provider').load_credentials()
>   File "/usr/lib/python3/dist-packages/botocore/credentials.py", line 1663, 
> in load_credentials
> creds = provider.load()
>   File "/usr/lib/python3/dist-packages/botocore/credentials.py", line 842, in 
> load
> metadata = fetcher.retrieve_iam_role_credentials()
>   File "/usr/lib/python3/dist-packages/botocore/utils.py", line 291, in 
> retrieve_iam_role_credentials
> r = self._get_request(url, timeout, num_attempts)
>   File "/usr/lib/python3/dist-packages/botocore/utils.py", line 276, in 
> _get_request
> response = self._session.send(request.prepare())
>   File "/usr/lib/python3/dist-packages/botocore/httpsession.py", line 264, in 
> send
> raise ProxyConnectionError(proxy_url=proxy_url, error=e)
> botocore.exceptions.ProxyConnectionError: Failed to connect to proxy URL: 
> "http://127.0.0.1:9/;
> ...
> Ran 17 tests in 0.061s
>
> FAILED (errors=17)
> Test failed: 
> error: Test failed:  failures=0>
> E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: 
> python3.6 setup.py test
> dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
> make: *** [debian/rules:6: build] Error 25
>


-- 
Harlan Lieberman-Berg
~hlieberman

Bug#908841: add description on systemd timer to cronjob

[Harlan Lieberman-Berg]

Package: certbot
Severity: wishlist

As requested by jmorahan in 
https://community.letsencrypt.org/t/certbot-dovecot-postfix-certificate-renewal-issue/72226/11,
we should add descriptive text to the cronjob reminding users that the
systemd timer is controlling if installed.

Bug#907527: RM: couchapp -- RoQA; RC-buggy for 9 months, RoQA requested for dependency

[Harlan Lieberman-Berg]

Package: ftp.debian.org
Severity: normal

Hello ftp-masters,

In association with the removal request for python-restkit, I am requesting the 
removal of couchapp.  Though couchapp has a minimally active upstream, it is 
fatally poisoned by the security vulnerabilities in its dependencies and should 
not be used.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman