Bug#1072847: fixed in lacme 0.8.3-1

[Guilhem Moulin]

Hi Sakari,

On Fri, 05 Jul 2024 at 08:23:56 +, Sakari Ailus wrote:
> The removal of the intermediate certificates (or not including the current
> ones) however is an issue as the server using the issued certificate still
> needs to provide them to the clients.

The path pointed to by ‛certificate-chain’ contains the entire chain
(excluding the root) as provided by Let's Encrypt.

> While it's certainly possible for the lacme user to obtain these
> certificates directly from Let's encrypt, it'd be quite convenient to
> continue to provide them in the lacme package itself, even if the package
> does need to be updated from time to time for that reason.

Do you have a concrete usecase?  It appears Let's Encrypt has settled on
intermediates with <2y lifetime (i.e., shorter than Debian Stable's
lifetime), and earlier rotation is at their own discretion, so I don't
see how we can reliably provide them as part of the source package.
(Updating via (o)s-pu might be an option, but that would only work if
the rotation is announced early enough ahead of the point release
freeze.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1072847: lacme: Post-issuance validation fails in the default configuration

[Guilhem Moulin]

Package: lacme
Version: 0.8.2-1
Severity: grave
Justification: renders package unusable

Let's Encrypt has recently rotated its intermediate certificates [0].
The previous intermediate certificates (lets-encrypt-r[34].pem and
lets-encrypt-e[12].pem) are concatenated along side the roots
(isrgrootx1.pem and isrg-root-x2.pem) and used as trust anchors for
validation of the issued X.509 certificate before its deployment.

The new intermediates means the validation step now fails.  A quick fix
is to add R1[0-4].pem and E[5-9].pem to the certificate bundle, however
that will cease to work once Let's Encrypt rotates its intermediates
again.

A proper fix would be to use the intermediate(s) provided during the
issuance step as -untrusted (for chain building).

-- 
Guilhem.

[0] https://letsencrypt.org/2024/03/19/new-intermediate-certificates


signature.asc
Description: PGP signature

Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Guilhem Moulin]

Hi Tomasz,

On Fri, 5 Apr 2024 at 01:11:41 +0200, Tomasz Buchert wrote:
> Looking into older versions and appropriately patching them will take
> more time.

I'm preparing an update for this issue for Buster LTS and can hand
tested debdiffs over to the Security Team for newer suites if you'd
like.  (AFAICT the fix is the same but pending feedback I haven't tested
it thoroughly yet.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

On Sat, 27 Apr 2024 at 02:07:21 +0200, Christoph Anton Mitterer wrote:
> So you say it's a glibc thingy, that this doesn't show up anymore?

Yup, that's what I wrote https://bugs.debian.org/1032235#97

| It was intentional, see the article
| 
https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
 .
| Unfortunately that change broke initramfs-tools' fix for 
https://bugs.debian.org/950254
| which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs.
| Until last week src:argon2 had never been rebuilt with the newer glibc,
| so it's just unfortunate that we missed that at the time.

On the one hand it was unfortunate to find such a severe RC bug
(unbootable system with the default config) so late in the freeze, on
the other hand it would have been even worse if src:argon2 would have
been uploaded to bookworm-security or -pu after the stable release :-)

> $ ldd /usr/bin/argon2
>   linux-vdso.so.1 (0x7ffcc67d4000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1ee48000)
>   /lib64/ld-linux-x86-64.so.2 (0x7f1a1f058000)
>
> I should use libc for determination?

Don't know if that's the best or most robust solution but that's what
I'd do as workaround at least.

> Would you recommend me to reassign #1069912 to initramfs-tools, asking
> for a more user-friendly solution?

Yup that'd make sense to me (and I see you did that already), thanks!

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

Hi,

On Sat, 27 Apr 2024 at 00:33:51 +0200, Christoph Anton Mitterer wrote:
> Now the problem is that argon2 is statically linked, so there's no
> libpthread showing up in its ldd, and thus copy_exec doesn't realise it
> needs to invoke copy_libgcc.

Even it weren't, libpthread wouldn't show up since src:argon2 from bookworm
and later is built using glibc ≥2.34.  AFAICT the “if the ldd output includes
libpthread then run copy_libgcc()” logic from initramfs-tools is mostly moot
now, see https://bugs.debian.org/1032235#97 .

We used the following workaround to manually call copy_libgcc()


https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078

for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no
longer uses libargon.  There is no stability guaranty for transitive
dependencies so I'd indeed argue the regression is not src:cryptsetup's
fault :-)  Adapting the above workarounds to your custom hookfile should
solve the issue, though.

> Did anyone of your report this issue anywhere else?

Some years ago I asked the initramfs-tools maintainers to inconditionally copy
libgcc_s to the initramfs image, but IIRC Ben argued it was too seldom used to
justify the cost in size and impemented the libpthread detection logic +
copy_libgcc() instead.

I don't know if the detection logic can be improved/fixed in initramfs-tools,
but despite what I promised elbrus in https://bugs.debian.org/1032235#87 it
looks like I didn't file a bug.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068849: marked as pending in cryptsetup

[Guilhem Moulin]

Control: tag -1 pending

Hello,

Bug #1068849 in cryptsetup reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/a7201bf6c1c76352d0bb59da24baa8dfa4eba4b8


d/crontrol: cryptsetup-initramfs: Add Breaks: libcryptsetup12 (<< 2:2.7.2-1).

cryptsetup-initramfs now assumes neither cryptsetup(8) nor
libcryptsetup.so.12 are linked with libargon2, but since no new symbols
were added since 2.7.0 cryptsetup-bin only has Depends: libcryptsetup12
(>= 2:2.7), and it's therefore possible to upgrade cryptsetup-initramfs
while keeping the old libcryptsetup12.

Upgrading from testing (2:2.6.1-6) works thanks to the Depends:
libcryptsetup12 (>= 2:2.7), but upgrading from ≥2:2.7~, <2:2.7.2-1 may
yield a broken initramfs image if libcryptsetup12 is not upgraded before
cryptsetup-initramfs.

Closes: #1068849


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068849

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

Control: reopen -1
Control: tag -1 - unreproducible moreinfo

On Sun, 14 Apr 2024 at 21:26:25 +0200, Guilhem Moulin wrote:
> At this point something triggered rebuilding a new initramfs image, but
> that's not src:cryptsetup as none of its binary packages have been
> upgraded yet.

On second thought that was likely incorrect.  The log doesn't show
anything from src:cryptsetup but likely cryptsetup-initramfs was already
upgraded at that point while libcryptsetup12 wasn't.

The package dependency constraints are indeed not strict enough.
cryptsetup-initramfs now assumes neither cryptsetup(8) nor
libcryptsetup.so.12 are linked with libargon2, but since no new symbols
were added in 2.7.2 cryptsetup-bin only has Depends: libcryptsetup12 (>=
2:2.7), and it's therefore possible to upgrade cryptsetup-initramfs
while keeping the old libcryptsetup12.

Upgrading from testing (2:2.6.1-6) works thanks to the Depends:
libcryptsetup12 (>= 2:2.7), but upgrading from ≥2:2.7~, <2:2.7.2-1 may
yield a broken initramfs image if libcryptsetup12 is not upgraded before
cryptsetup-initramfs.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068848: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

On Sat, 13 Apr 2024 at 10:06:32 -0400, Wesley Schwengle wrote:
> I had the same issue a while back, because of the t64 transitioning I chaulked
> it up to that. I fixed it as described in Ubuntu bug:
>
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594

libcryptsetup12 doesn't use libargon2 anymore, so that shouldn't be
needed.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

On Fri, 12 Apr 2024 at 14:37:16 +0200, Guilhem Moulin wrote:
> What is that “GUI” view?  src:cryptsetup doesn't provide that, I wonder
> if it might be what needs libphtread.

FWIW, I later noticed you used a splash screen (plymouth) and thought it
might be because of that, but I still cannot reproduce the issue in a
bookworm VM upgraded to sid (using d-i's “encrypted LVM” layout + a
splash screen).

>> After a ctrl-alt-del, I got to the console and there it showed an error about
>> libgcc_s.so.1 not available and aborting.

What was that error message exactly?

> If you still have the broken initramfs image, please extract it with
> `unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
> find which executable / shared library needs libphtread, for instance
> with
>
>cd /path/to/destdir
>for p in $(find -P {usr/,}lib/x86_64-linux-gnu  {usr/,}{,s}bin/ -type f); 
> do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done

Erm no, that likely won't work since pthread functions have moved from
libpthread.so.1 to libc.so.6 with glibc 2.34.  Otherwise copy_exec()
would have pulled in libgcc_s.  New attempt:

rm -rf /tmp/initramfs-destdir && \
mkdir -m0700 /tmp/initramfs-destdir && \
unmkinitramfs /path/to/broken.initrd.img /tmp/initramfs-destdir && \
for p in $(find /tmp/initramfs-destdir/main -type f | sort); do \
  objdump -T "$p" 2>&1 | grep pthread_exit && echo "^^ $p"; \
done

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

Control: tag -1 + unreproducible moreinfo

On Fri, 12 Apr 2024 at 12:45:09 +0200, Milan Broz wrote:
> Just FYI (for upstream code): if cryptsetup/libcryptsetup is linked with 
> OpenSSL >= 3.2,
> it does not need libphtread (as threads are implemented in OpenSSL for Argon2 
> internally).

Thanks for confirming!  We're now linking with OpenSSL 3.2 indeed, and
our CI confirms that unlocking works in that environment.

2:2.7.2-1 builds with OpenSSL 3.2 *and* removes the libgcc_s/libargon2
workaround from the initramfs hook:
https://tracker.debian.org/news/1517996/accepted-cryptsetup-2272-1-source-into-unstable/

>> It would also be nice if the "gui" view could show the error or at
>> least tell the user to pres ctrl-alt-del to get to a more informative
>> view, took me ages to figure out that one :-(

What is that “GUI” view?  src:cryptsetup doesn't provide that, I wonder
if it might be what needs libphtread.

Otherwise, my guess is a race where the the initramfs image was somehow
rebuilt before libcryptsetup12 was upgraded, but AFAICT the dependencies
are properly set to avoid that.  Does the broken initramfs image contain
libargon2.so, if so does its libcryptsetup12 use it?

If you still have the broken initramfs image, please extract it with
`unmkinitramfs /path/to/broken.initrd.img /path/to/destdir` and try to
find which executable / shared library needs libphtread, for instance
with

cd /path/to/destdir
for p in $(find -P {usr/,}lib/x86_64-linux-gnu  {usr/,}{,s}bin/ -type f); 
do objdump -p "$p" 2>/dev/null | grep -q pthread && echo "$p"; done

This will hopefully shed some light on this.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1066853: marked as pending in roundcube

[Guilhem Moulin]

Control: tag -1 pending

Hello,

Bug #1066853 in roundcube reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/roundcube-team/roundcube/-/commit/0a617b77808cddd3fe9142fa3273ceef14fdecc8


d/control: Remove ‘libmagic1’ from roundcube-core's Depends.

The old default ‘mime_magic’ config option (/usr/share/misc/magic) is
obsolete since Roundcube 1.0.0.

Closes: #1066853


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066853

Bug#1052547: unable to boot, no luks passwort prompt shown

[Guilhem Moulin]

Control: tag -1 + moreinfo unreproducible

Hi,

On Sun, 24 Sep 2023 at 14:42:27 +0200, Eduard Bloch wrote:
> we have a problem here. After latest upgrades, I am no longer able to
> boot into a system with LUKS-encrypted rootfs. This worked just fine a few
> weeks ago. I jumped in circles in the search for the cause, and only
> after downgrading cryptsetup-initramfs to 2:2.6.1-4 it suddenly started
> working again.

I don't see how downgrading cryptsetup-initramfs from 2:2.6.1-5 to
2:2.6.1-4 could solve this:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/compare/debian%2F2%252.6.1-4...debian%2F2%252.6.1-5?from_project_id=21364=false

Anyway, this bug is not actionable with so little information.  Please
provide a debug trace per 
https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html#debug-cryptroot-initramfs-script

cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run

[Guilhem Moulin]

On Mon, 28 Aug 2023 at 01:56:04 +0200, Guilhem Moulin wrote:
> cryptsetup-run has been a transitional package since the buster release,
> and has now been removed following #1038285.  Looks like I failed to
> properly check reverse depends; yubikey-luks should replace ‘Depends:
> cryptsetup-run’ with ‘Depends: cryptsetup’.

Uploaded the attached debdiff to DELAYED/7.

-- 
Guilhem.
diffstat for yubikey-luks-0.5.1+29.g5df2b95 yubikey-luks-0.5.1+29.g5df2b95

 changelog |8 
 control   |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 
yubikey-luks-0.5.1+29.g5df2b95/debian/changelog
--- yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2022-10-15 
12:58:53.0 +0200
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2023-08-28 
01:59:49.0 +0200
@@ -1,3 +1,11 @@
+yubikey-luks (0.5.1+29.g5df2b95-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace ‘Depends: cryptsetup-run’ with ‘Depends: cryptsetup’ as
+src:cryptsetup no longer ships the former (Closes: #1050680)
+
+ -- Guilhem Moulin   Mon, 28 Aug 2023 01:59:49 +0200
+
 yubikey-luks (0.5.1+29.g5df2b95-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/control 
yubikey-luks-0.5.1+29.g5df2b95/debian/control
--- yubikey-luks-0.5.1+29.g5df2b95/debian/control   2021-01-02 
17:38:35.0 +0100
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/control   2023-08-28 
01:59:43.0 +0200
@@ -13,7 +13,7 @@
 
 Package: yubikey-luks
 Architecture: all
-Depends: cryptsetup-run, initramfs-tools, yubikey-personalization (>= 1.5), 
${misc:Depends}
+Depends: cryptsetup, initramfs-tools, yubikey-personalization (>= 1.5), 
${misc:Depends}
 Recommends: cryptsetup-initramfs, expect
 Description: YubiKey two factor authentication for LUKS disks
  With this extension to the initramfs-tools, you can unlock a LUKS encrypted


signature.asc
Description: PGP signature

Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run

[Guilhem Moulin]

Source: yubikey-luks
Version: 0.5.1+29.g5df2b95-6.1
Severity: serious

Hi,

cryptsetup-run has been a transitional package since the buster release,
and has now been removed following #1038285.  Looks like I failed to
properly check reverse depends; yubikey-luks should replace ‘Depends:
cryptsetup-run’ with ‘Depends: cryptsetup’.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1050606: marked as pending in cryptsetup

[Guilhem Moulin]

Control: tag -1 pending

Hello,

Bug #1050606 in cryptsetup reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/2609636237a72ba204aae4ec26f6f4d15db8831c


cryptsetup-suspend-wrapper: Don't error out on missing 
/lib/systemd/system-sleep directory.

This directory was removed from the systemd package as a result of the
discussion in 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 .

Closes: #1050606


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1050606

Bug#962629: rainloop: Rainloop stores passwords in cleartext in logfile

[Guilhem Moulin]

Control: tag -1 unreproducible

On Wed, 10 Jun 2020 at 23:19:41 +0200, Marco Herrn wrote:
> When writing into a logfile, rainloop writes the passwords of all
> login attempts (successful or not) into the logfile in cleartext.

FWIW I'm not able to reproduce this with the version from Debian buster
(1.12.1-2).  Stock config, just replaced ‘enable = Off’ with ‘enable = On’
in /etc/rainloop/application.ini's ‘[logs]’ section.  (‘hide_passwords’
remains set as per default.)  I see my username in the log, but the
passphrase is replaced with (a fixed number of) asterisks in both in
succesful and failed sessions:

INFO[DATA]: 
[DATE:27.05.23][OFFSET:-00][RL:1.12.1][PHP:7.3.31-1~deb10u3][IP:127.0.0.1][PID:976085][nginx/1.14.2][fpm-fcgi]
INFO[DATA]: 
[Suhosin:off][APC:off][MB:off][PDO:~][Streams:tcp,udp,unix,udg,ssl,tls,tlsv1.0,tlsv1.1,tlsv1.2]
REQUEST[NOTE]: [POST] http://127.0.0.1/?/Ajax/[]=/0/
AJAX[NOTE]: Action: DoLogin
POST[DATA]: 
{"Email":"guil...@example.net","Login":"","Password":"***","Language":"","AdditionalCode":"","AdditionalCodeSignMe":"0","SignMe":"0","Action":"Login","XToken":"[…]"}
IMAP[NOTE]: Start connection to "ssl://imap.example.net:993"
IMAP[NOTE]: Connected (success)
IMAP[DATA]: < * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE 
IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] howdy, ready.\r\n
IMAP[DATA]: > TAG1 AUTHENTICATE PLAIN\r\n
IMAP[DATA]: < + \r\n
IMAP[SECURE]: > ***\r\n
IMAP[DATA]: < TAG1 NO [AUTHENTICATIONFAILED] Authentication failed.\r\n
IMAP[WARNING]: MailSo\Imap\Exceptions\NegativeResponseException: 
MailSo-Imap-Exceptions-NegativeResponseException (ImapClient.php ~ 1874) in 
/usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php:1874
Stack trace:
#0 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(1951): 
MailSo\Imap\ImapClient->validateResponse(Array)
#1 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(281): 
MailSo\Imap\ImapClient->parseResponseWithValidation()
#2 /usr/share/rainloop/app/libraries/MailSo/Mail/MailClient.php(92): 
MailSo\Imap\ImapClient->Login('guilhem@example', '***', '', true, false)
#3 /usr/share/rainloop/app/libraries/RainLoop/Model/Account.php(451): 
MailSo\Mail\MailClient->Login('guilhem@example', '***', '', true, false)
#4 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2078): 
RainLoop\Model\Account->IncConnectAndLoginHelper(Object(RainLoop\Plugins\Manager),
 Object(MailSo\Mail\MailClient), Object(RainLoop\Config\Application))
#5 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2329): 
RainLoop\Actions->CheckMailConnection(Object(RainLoop\Model\Account), true)
#6 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2381): 
RainLoop\Actions->LoginProcess('guilhem@example', '***', '', '', false)
#7 /usr/share/rainloop/app/libraries/RainLoop/ServiceActions.php(172): 
RainLoop\Actions->DoLogin()
#8 /usr/share/rainloop/app/libraries/RainLoop/Service.php(146): 
RainLoop\ServiceActions->ServiceAjax('')
#9 /usr/share/rainloop/app/libraries/RainLoop/Service.php(56): 
RainLoop\Service->localHandle()
#10 /usr/share/rainloop/app/libraries/RainLoop/Service.php(79): 
RainLoop\Service->__construct()
#11 /usr/share/rainloop/app/handle.php(94): RainLoop\Service::Handle()
#12 /usr/share/rainloop/include.php(228): include('/usr/share/rain...')
#13 /usr/share/rainloop/index.php(13): include('/usr/share/rain...')
#14 {main}
IMAP[NOTICE]: MailSo\Imap\Exceptions\NegativeResponseException: 
MailSo-Imap-Exceptions-NegativeResponseException (ImapClient.php ~ 1874) in 
/usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php:1874
Stack trace:
#0 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(1951): 
MailSo\Imap\ImapClient->validateResponse(Array)
#1 /usr/share/rainloop/app/libraries/MailSo/Imap/ImapClient.php(281): 
MailSo\Imap\ImapClient->parseResponseWithValidation()
#2 /usr/share/rainloop/app/libraries/MailSo/Mail/MailClient.php(92): 
MailSo\Imap\ImapClient->Login('guilhem@example', '***', '', true, false)
#3 /usr/share/rainloop/app/libraries/RainLoop/Model/Account.php(451): 
MailSo\Mail\MailClient->Login('guilhem@example', '***', '', true, false)
#4 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2078): 
RainLoop\Model\Account->IncConnectAndLoginHelper(Object(RainLoop\Plugins\Manager),
 Object(MailSo\Mail\MailClient), Object(RainLoop\Config\Application))
#5 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2329): 
RainLoop\Actions->CheckMailConnection(Object(RainLoop\Model\Account), true)
#6 /usr/share/rainloop/app/libraries/RainLoop/Actions.php(2381): 
RainLoop\Actions->LoginProcess('guilhem@example', '***', '', '', false)
#7 /usr/share/rainloop/app/libraries/RainLoop/ServiceActions.php(172): 
RainLoop\Actions->DoLogin()
#8 /usr/share/rainloop/app/libraries/RainLoop/Service.php(146): 

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Guilhem Moulin]

On Thu, 11 May 2023 at 18:12:52 +0200, Bastian Blank wrote:
> Nope, not really.  Half VG was never a real thing.  It might work in
> some cases.

And these use-cases are unbootable since 2.03.15…

> Then, degraded is the default activation mode, so overriding that would
> not be appropriate.  But forcefully enabling stuff like an incomplete
> raid will trigger rebuilds every time.  So no, this can't be the default
> option.

If that's a concern then ‘--activationmode complete’ can be used instead
(although the boot scripts used the default mode from lvm.conf).  That's
enough to fix the systems rapported here, because the required LVs are
actually complete.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Guilhem Moulin]

Control: tag -1 - unreproducible
Control: reassign -1 lvm2 2.03.15-1
Control: forcemerge 1018730 -1
Control: affects -1 cryptsetup-initramfs

Thanks for the the reproducer!  Much appreciated.  So the problem is
that your VG spans over multiple PVs, but the LVs that are required at
early boot stage (the ones holding the root FS and the resume device)
reside only on the first PV so cryptsetup-initramfs rightfully never
tries to unlock the second one (which only holds /home hence is not
needed that early).

This used to work, but it looks like lvm2's udev rules never try to
activate complete LVs residing on incomplete VGs, hence the deadlock.
This mostly affects cryptsetup-initramfs and perhaps the issue could be
mitigated there, but this is an lvm2 regression and non-luks systems can
be affected too [0] so I'm reassign the bug accordingly.  (Turns out it
was already reported, hence also merging.)

A quick fix for your particular setup is to edit crypttab(5), add the
‘initramfs’ option for the ‘4Tsolid’, and rebuild the initramfs image.
That should force the device to be considered at initramfs stage.

-- 
Guilhem.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1337220#c10


signature.asc
Description: PGP signature

Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Guilhem Moulin]

Control: tag -1 - moreinfo

On Tue, 09 May 2023 at 18:39:33 +0200, Pásztor János wrote:
> I have attached the machine definition and already sent the vm images for
> you (via filesender.hu).

Many thanks!  Will have something to put teeth into once the images have
been downloaded :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Guilhem Moulin]

Control: tag -1 + unreproducible moreinfo

On Tue, 09 May 2023 at 17:10:03 +0200, Pásztor János wrote:
> The machine and the disks are having two snapshots named 'good' and 'bad' so
> it is easy to jump between the states.
> I am willing to share with you the VM(disks + virsh dump) via a filesharing
> service. Would you be interested in it?

Yes please; I still cannot reproduce the issue.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Guilhem Moulin]

Control: tag -1 unreproducible moreinfo

What does `lsinitramfs /initrd.img | grep -e{crypt,lvm}` return (after
removing your hook and rebuilding the initramfs image)?  And also

install -m0700 -d /tmp/initramfs
unmkinitramfs /initrd.img /tmp/initramfs
cat /tmp/initramfs/cryptroot/crypttab

And also

dpkg -l | grep -e{cryptsetup,lvm}

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032235: closing 1032235

[Guilhem Moulin]

close 1032235
thanks

Closing this now, cryptsetup 2:2.6.1-2 and libargon2 0~20190702-0.1
should be able to enter testing together.

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Guilhem Moulin]

Control: tag -1 - moreinfo
Control: severity -1 important
Control: retitle -1 Argon2 memory cost is not future proof and might OOM on 
dist-upgrade on memory-constrained systems

On Sat, 11 Mar 2023 at 14:53:37 -0500, Jérôme Charaoui wrote:
>> Jérôme, what memory cost is the keyslot using?  (Paste the output of
>> `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)
>
> - 8< -
> # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
> PBKDF:  argon2i
> Time cost:  4
> Memory: 787907
> Threads:1
> - >8 -
> […]
> So, I think what's happening is that the first VM may have been created with
> a different (larger) memory configuration, and was reduced at a later point
> in time. I don't have absolute certainty of this, but it would very well
> explain the discrepancy in memory cost.

I'm very sure it's the case: buster, bullseye, bookworm (and everything
in between) never set the memory cost to more than half the physical
memory.  So it's just not possible to end up with such a high memory
cost on a machine with only 1GiB RAM.  Memory-hard KDF parameters are
non portable and this is a feature not a bug :-)  Upon hardware change
one needs to run the benchmark again via cryptsetup-luksChangeKey(8) or
similar to tune the parameters to the new system; and downgrading
hardware needs to be done with care as folks who bootstrap images for
RPI-like boards are surely aware.

It's a coincidence that you triggered the OOM-killer only after the post
dist-upgrade reboot, you were already likely close to memory exhaustion
after reducing memory.

> I there any way we could make the cryptsetup-initramfs hook aware of this,
> and emit a warning if it finds that the encrypted root lacks a keyslot with
> appropriate (low-enough) memory cost?

I don't think the hook is the place for that: 1/ it might not have
access to the header where this information resides, 2/ it doesn't know
beforehand which keyslot will be used, and 3/ the issue is not specific
to cryptsetup-initramfs.  There is an upstream commit on the main branch
that adds a warning to libcryptsetup, might cherry-pick that to bookworm
instead.

Anyway, lowering this to sub-RC now that it's demystified.  In your case
the root issue (KDF parameter portability) is wontfix/notabug, but I'm
hijacking this to point out that KDF parameters are not future proof.
(This is what the forwarded upstream bug points to, and what I initially
thought you might be experiencing.)  Things work fine out of the box on
minimal systems (also with <1GiB RAM), but several releases down the
road we might ship a kernel or early boot daemons requiring a lot more
memory, and the KDF *will* exhaust memory at that point.  The upstream
fix in !490 (neither in bookworm nor sid yet) improves things a bit but
really is only buying time.  Milan suggested that systems with little
RAM are probably better off using a non-memory-hard KDF.  Perhaps
upstream could be convinced to have different defaults depending on the
amount of physical memory, if not then perhaps it could be done in
partman-crypto (I personally wouldn't feel comfortable carrying such a
patch in src:cryptsetup or have defaults that are unaligned with
upstream or other distros).  Won't help with existing keyslots though.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Guilhem Moulin]

Control: found -1 2:2.1.0-5+deb10u2
Control: tag -1 moreinfo

Hi kibi,

On Sat, 11 Mar 2023 at 15:16:01 +0100, Cyril Brulebois wrote:
> Guilhem Moulin  (2023-03-11):
>> On Sat, 11 Mar 2023 at 08:26:27 -0500, Jérôme Charaoui wrote:
>>> Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of
>>> RAM to bookworm, and was very surprised to be confronted with an OOM
>>> immediately upon entering my LUKS password in the initramfs prompt:
>>> […]
>>> The problem appears to be perhaps related to #924560, but in this instance,
>>> the issue causing an unbootable system post-upgrade.
>>
>> No, this is related to #1028250 and 
>> https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 .
>> Don't think we can do anything in src:cryptsetup for existing volumes
>> unfortunately.  You might need to manually lower the parameters of your
>> PBKDF.
>
> Existing systems failing to boot after an upgrade doesn't seem to be
> “only” important to me…

I fail to see how that's different from an existing resource-constrained
system (sarge recommends for 64MiB RAM for desktop i386) being unusable
after dist-upgrading to a more recent Debian release.  Granted I haven't
tried it, but I very much doubt GNOME would still work with that little
memory :-)

Anyway, while it definitely isn't ideal (not very future proof) that the
key slots were created with a memory cost close to the whole available
memory, there is actually not that much difference in resident set size
before and after the upgrade.  The test environment is a VM with 1024M
RAM, and initialized with d-i's debian-10.12.0-amd64-netinst.iso and
“Encrypted LVM” partition scheme.  In my case the PBKDF benchmark chose
the following parameters (close to half the amount of physical memory
indeed):

~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 504962
Threads:2

## buster (cryptsetup 2:2.1.0-5+deb10u2, linux 4.19+105+deb10u18)
~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<> Lowering the severity, because this shouldn't block the transition of -2
>> into bookworm (which fixes an unrelated and arguably much more severe RC
>> bug).
>
> That's not really how RC bugs work: bugs aren't less RC because it makes
> sense for a specific version to migrate…
>
> Either the bug appeared specifically in the version it was filed against,
> and it makes sense to block the migration since that's a new RC bug in
> that particular version, and the RC-ness stays.
>
> Or the bug was already there in the version currently in testing, and that
> means that's not a regression, and the RC-ness stays. You only need to
> record the bug as also being found in the previous version (possibly
> plural) to make sure britney knows it's not a regression.

Ah cool didn't know that, thanks for the information.  Marking this as
found all the way back to buster then.  I'm indeed able to trigger the
OOM-killer on a buster system when I artificially fill the memory so the
memory cost exceeds what remains.  Furthermore I don't see what can be
done about existing keyslots, and that includes everything created since
buster.

> Sure, we can discuss the severity of the bug I filed. But #1032734 really
> can't be “just” important.

Tagging ‘moreinfo’ then.  I can definitely see how one can reproduce
this theoretically (and possibly in the future when the kernel's memory
requirement increase high enough), and mentioned that in the upstream
bug, but I'm unable to find a reproducer after dist-upgrading bullseye
systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso,
and “Encrypted LVM” partition scheme, on VMs with 1024M RAM).

Jérôme, what memory cost is the keyslot using?  (Paste the output of
`cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)  Would also be
interested to see by how much the amount of memory available to
cryptsetup has changed before and after the uprade.  Please edit
/usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at
the begining of the setup_mapping() function (patch attached).  My own
findings are as follows (again on a minimal netinst system without
changing any default).  cryptsetup isn't even close to memory
exhaustion.

## bullseye (cryptsetup 2:2.3.7-1+deb11u1, linux 5.10.162-1)
~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
PBKDF:  argon2i
Time cost:  4
Memory: 499892
Threads:2
~# systemctl reboot
Loading Linux 5.10.0-21-amd64 ...
Loading initial ramdisk ...
  totalusedfree  shared  buff/cache   
available
Mem: 9997

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Guilhem Moulin]

Control: reassign -1 cryptsetup-bin 2:2.6.1-2
Control: severity -1 important
Control: tag -1 upstream
Control: forwarded -1 
https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872

Hi,

On Sat, 11 Mar 2023 at 08:26:27 -0500, Jérôme Charaoui wrote:
> Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of
> RAM to bookworm, and was very surprised to be confronted with an OOM
> immediately upon entering my LUKS password in the initramfs prompt:
> […]
> The problem appears to be perhaps related to #924560, but in this instance,
> the issue causing an unbootable system post-upgrade.

No, this is related to #1028250 and 
https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 .
Don't think we can do anything in src:cryptsetup for existing volumes
unfortunately.  You might need to manually lower the parameters of your
PBKDF.

Lowering the severity, because this shouldn't block the transition of -2
into bookworm (which fixes an unrelated and arguably much more severe RC
bug).  See also the d-i errata for Bookworm Alpha 2.  I'm also not
certain that #-1 is RC, after all Debian's memory requirements have
consistently increased since the start of the project, so IMHO one has
to accept that hardware might need to be dusted up on upgrade.  Compare

https://www.debian.org/releases/potato/i386/ch-hardware-req.en.html §2.3 
with
https://www.debian.org/releases/bullseye/amd64/ch03s04.en.html §3.4

Either way the issue definitely needs to be mentioned in Bookworm's
release notes.

cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Guilhem Moulin]

On Wed, 08 Mar 2023 at 14:11:05 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2023-03-08 at 14:04 +0100, Guilhem Moulin wrote:
>> No please don't, #-1 is RC so that would block transitioning into
>> Bookworm which only supports merged-usr…  Will fix that later during
>> the
>> freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
>> further delay the transition.
>
> Well but at least right now people without merged /usr will still end
> up in a broken system?

Yes.  Been the case for a week (since the argon2=0~20190702-0.1 upload).
However the TC has ruled that these systems are no longer supported, so
the issue isn't RC.  Not saying we should shove it under the carpet,
only that it shouldn't delay transition.

> And there is no guarantee that /usr has already been merged at that
> point... I mean it should, when the upgrade to bookwork completes...
> but can it happen that it's interrupted? Or that people do it in
> several steps? Then they could upgrade argon2, reboot and have the
> missing libgcc.

Correct, but AFAICT that's would be a FrankenDebian so not something
supported either.  Either way that's not something src:cryptsetup can
fix.  One could upload src:argon2 again adding “Break: cryptsetup-initramfs
(<< 2:2.6.1-2)” to libargon2-1, though I'm not sure it's worth doing
given the freeze and the fact that covered that supported systems are
covered.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Guilhem Moulin]

Control: clone -1 -2
Control: severity -2 important
Control: done -1 2:2.6.1-2

On Wed, 08 Mar 2023 at 13:42:53 +0100, Christoph Anton Mitterer wrote:
> @Guilhem, I'm reopening this for now.

No please don't, #-1 is RC so that would block transitioning into
Bookworm which only supports merged-usr…  Will fix that later during the
freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
further delay the transition.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032221: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs

[Guilhem Moulin]

Control: clone -1 -2
Control: reassign -1 cryptsetup-initramfs 2:2.6.1-1

On Thu, 02 Mar 2023 at 02:57:20 +0100, Guilhem Moulin wrote:
> On Wed, 01 Mar 2023 at 12:04:04 +, Debian FTP Masters wrote:
>> Changes:
>> argon2 (0~20190702-0.1) unstable; urgency=medium
>> .
>> […]
>>  * Only build udeb without threads (Closes: #1014110)
> 
> AFAICT #1014110 says nothing about udeb, but that change actually builds
> libargon2 (.deb) without pthread support (which AFAICT isn't what
> #1014110 is about either).  This badly breaks cryptsetup-initramfs, see
> #1032221.  Given 1/ we're soft freeze already, 2/ 0~20190702-0.1 was
> NMU'ed, and 3/ the breakage it causes, I'll revert the change shortly.

Ah no my bad, the changelog entry is probably incorrect and the
cryptsetup-initramfs breakage is caused by the recent libargon2 upload
indeed, but AFAICT not by anything particular in the upload.  It's just
that the recent upload is built with glibc ≥2.34 hence no longer links
libpthread.  That in turns means that initramfs-tool's copy_exec() is no
longer able to detect pthread_*() need and thus doesn't copy libgcc_s.so
anymore…

I'll fix that in cryptsetup-initramfs 2:2.6.1-2 but am temporarily
leaving a clone open against libargon2-1 due to the severity of the
breakage.  That'll hopefully warn folks to wait a bit before updating
libargon2-1.  Will close or merge back #-2 later once the newer
src:cryptsetup has entered the archive.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1026528: [Pkg-roundcube-maintainers] Bug#1026528: roundcube: FTBFS: make[1]: *** [debian/rules:105: override_dh_auto_test] Error 1

[Guilhem Moulin]

Control: tag -1 pending

Hi,

On Tue, 20 Dec 2022 at 17:54:56 +0100, Lucas Nussbaum wrote:
>> There was 1 failure:
>> 
>> 1) Rcmail_Rcmail::test_format_date
>> Failed asserting that two strings are identical.
>> --- Expected
>> +++ Actual
>> @@ @@
>> -'6/1/20, 12:20 PM'
>> +'6/1/20, 12:20 PM'
>> 
>> /<>/tests/Rcmail/Rcmail.php:270
>> /usr/bin/phpunit:73

Good timing, fixed in 
https://salsa.debian.org/roundcube-team/roundcube/-/commit/fab4ddc0a83b3040fb8b84a9b9e9c697bafbfea6
which I pushed seconds ago :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1020714: [pkg-cryptsetup-devel] Bug#1020714: cryptsetup: cryptroot-* autopkgtests fall-back to shell and hang on errors

[Guilhem Moulin]

Hi elbrus,

On Fri, 30 Sep 2022 at 21:38:50 +0200, Paul Gevers wrote:
> On Mon, 26 Sep 2022 19:35:44 +0200 Paul Gevers  wrote:
>> Assuming it works as intended, that's exactly what I was looking for, yes.
> 
> Seems it doesn't always work.

Haven't uploaded 2:2.5.0-4 yet as I was traveling this week; will do
that early next week.  Thanks for the reminder :-)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1020714: cryptsetup: cryptroot-* autopkgtests fall-back to shell and hang on errors

[Guilhem Moulin]

Control: tag -1 pending

Hi Paul,

On Sun, 25 Sep 2022 at 20:09:09 +0200, Paul Gevers wrote:
> However, the reason for that long run was not the failure itself, but
> the fact that your tests drop to shell on error and apparently waits
> for user input. One failure with 2:2.5.0-3 in unstable has the same
> problem.
>
> This is pretty bad for our infrastructure as normally your test is
> much faster and it shouldn't wait for the time out. Can you please fix
> that?

Very sorry for that!  That specific error was caused by a race condition
after partitioning (the test was trying to use the partition before the
block device was created) and is fixed in
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/39e9cb8baf69f1b126a636026883569317adf7fb
 .

At 
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/cc175feed03319b2544382699e812fe7c67fd0ee
I also added a timeout on each qemu command so failed setups won't wait
for the global debci timeout.  Hope this is an acceptable fix from your
perspective :-)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1011754: interimap: autopkgtest failure with openssl 3

[Guilhem Moulin]

On Thu, 26 May 2022 at 12:39:51 +0200, Sebastian Ramacher wrote:
> interimap's autopkgtests fail with openssl 3:

I believe this is due to #1011038 and/or #1011051.  AFAICT nothing needs
doing on the interimap side while these are open.  Leaving -1 open
though so no one files a duplicate.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1006028: php-crypt-gpg: FTBFS: PHPUnit\Framework\Exception: PHP Fatal error: Uncaught Crypt_GPG_BadPassphraseException: Cannot export private key. Incorrect passphrase provided for keys: "First Ke

[Guilhem Moulin]

Control: tag -1 moreinfo

On Sat, 19 Feb 2022 at 07:38:04 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Seems like a false-positive to me.  It does build here, and also did
build on the buildds [0] (and Salsa CI too).  Perhaps that test is
unreliable though, in which case we should mark it as such or skip it.

> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

Attached diff for a local build (in minimal up to date sid chroot).

cheers
-- 
Guilhem.

[0] 
https://buildd.debian.org/status/fetch.php?pkg=php-crypt-gpg=all=1.6.7-1=1645097644=0
--- a/php-crypt-gpg_1.6.7-1_unstable.log
+++ b/php-crypt-gpg_1.6.7-1_amd64.build
@@ -1,10 +1,7 @@
-DC-Build-Header: php-crypt-gpg 1.6.7-1 / 2022-02-18 20:43:39 +
-DC-Task: type:rebuild-full source:php-crypt-gpg version:1.6.7-1 chroot:unstable esttime:127 logfile:/tmp/php-crypt-gpg_1.6.7-1_unstable.log modes:
-DC-Sbuild-call: su user42 -c 'sbuild -n -A -s --force-orig-source --apt-update -d unstable -v --no-run-lintian php-crypt-gpg_1.6.7-1'
-sbuild (Debian sbuild) 0.81.2 (31 January 2021) on ip-10-84-234-189.eu-central-1.compute.internal
+sbuild (Debian sbuild) 0.83.0 (05 February 2022) on odin.guilhem.org
 
 +==+
-| php-crypt-gpg 1.6.7-1 (amd64)Fri, 18 Feb 2022 20:43:39 + |
+| php-crypt-gpg 1.6.7-1 (amd64)Sat, 19 Feb 2022 09:58:33 + |
 +==+
 
 Package: php-crypt-gpg
@@ -16,17 +13,17 @@
 Build Architecture: amd64
 Build Type: full
 
-I: NOTICE: Log filtering will replace 'var/run/schroot/mount/sid-amd64-sbuild-95c36d99-de34-45d8-b2a5-0d1225712452' with '<>'
-I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-pcurml/resolver-oJHJ6s' with '<>'
+I: 06ccache-tmpfs: Set cache size limit to 4.0 GB
+I: NOTICE: Log filtering will replace 'var/run/schroot/mount/sid-amd64-sbuild-c5e0e4c5-4fd3-4b24-b403-023f18c87b99' with '<>'
+I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-ToTA24/resolver-tqhfbu' with '<>'
 
 +--+
 | Update chroot|
 +--+
 
-Hit:1 http://127.0.0.1:12990/debian sid InRelease
-Reading package lists...
 Reading package lists...
 Building dependency tree...
+Reading state information...
 Calculating upgrade...
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 
@@ -35,28 +32,12 @@
 +--+
 
 
-Check APT
--
-
-Checking available source versions...
-
-Download source files with APT
---
+Local sources
+-
 
-Reading package lists...
-NOTICE: 'php-crypt-gpg' packaging is maintained in the 'Git' version control system at:
-https://salsa.debian.org/php-team/pear/php-crypt-gpg.git -b debian/latest
-Please use:
-git clone https://salsa.debian.org/php-team/pear/php-crypt-gpg.git -b debian/latest
-to retrieve the latest (possibly unreleased) updates to the package.
-Need to get 353 kB of source archives.
-Get:1 http://127.0.0.1:12990/debian sid/main php-crypt-gpg 1.6.7-1 (dsc) [2244 B]
-Get:2 http://127.0.0.1:12990/debian sid/main php-crypt-gpg 1.6.7-1 (tar) [344 kB]
-Get:3 http://127.0.0.1:12990/debian sid/main php-crypt-gpg 1.6.7-1 (diff) [6580 B]
-Fetched 353 kB in 0s (6614 kB/s)
-Download complete and in download only mode
-I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-pcurml/php-crypt-gpg-1.6.7' with '<>'
-I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-pcurml' with '<>'
+/tmp/php-crypt-gpg_1.6.7-1.dsc exists in /tmp; copying to chroot
+I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-ToTA24/php-crypt-gpg-1.6.7' with '<>'
+I: NOTICE: Log filtering will replace 'build/php-crypt-gpg-ToTA24' with '<>'
 
 +--+
 | Install package build dependencies   |
@@ -74,7 +55,7 @@
 Ign:3 copy:/<>/apt_archive ./ Release.gpg
 Get:4 copy:/<>/apt_archive ./ Sources [441 B]
 Get:5 copy:/<>/apt_archive ./ Packages [510 B]
-Fetched 1908 B in 0s (141 kB/s)
+Fetched 1908 B in 0s (0 B/s)
 Reading package lists...
 Reading package lists...
 
@@ -84,494 +65,481 @@
 Installing build dependencies
 Reading package lists...
 Building dependency tree...
+Reading state information...
 The following additional packages will be installed:
   autoconf automake autopoint autotools-dev bsdextrautils debhelper
   dh-autoreconf dh-strip-nondeterminism dwz file gettext gettext-base gpg
   gpg-agent gpgconf groff-base intltool-debian 

Bug#1003685: What about bullseye ?

[Guilhem Moulin]

Hi,

On Sun, 30 Jan 2022 at 21:23:55 +0100, Rogier wrote:
> I am a bit surprised that this bug has been closed, even 
> though it has not yet been fixed in bullseye.

That's how the BTS works.  It's marked as fixed cryptsetup/2:2.4.3-1
(bookworm, unstable), but still marked as found in cryptsetup/2:2.3.5-1
(bullseye).

> Is a security update for bullseye still in the making ?

Yes, see https://bugs.debian.org/1003686#5 and
https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2022-January/009292.html
 .

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1003686: CVE-2021-4122: cryptsetup 2.x: decryption through LUKS2 reencryption crash recovery

[Guilhem Moulin]

Source: cryptsetup
Severity: grave
Tags: security upstream
Justification: root security hole
Control: found -1 2:2.3.5-1
Control: found -1 2:2.4.2-1
X-Debbugs-Cc: Debian Security Team 

Quoting :

| CVE-2021-4122 describes a possible attack against data confidentiality
| through LUKS2 online reencryption extension crash recovery.
| 
| An attacker can modify on-disk metadata to simulate decryption in
| progress with crashed (unfinished) reencryption step and persistently
| decrypt part of the LUKS device.
| 
| This attack requires repeated physical access to the LUKS device but
| no knowledge of user passphrases.
| 
| The decryption step is performed after a valid user activates
| the device with a correct passphrase and modified metadata.
| There are no visible warnings for the user that such recovery happened
| (except using the luksDump command). The attack can also be reversed
| afterward (simulating crashed encryption from a plaintext) with
| possible modification of revealed plaintext.
| […]
| The issue was found by Milan Broz as cryptsetup maintainer.

Upstream fixes:

  2.3 branch: 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/60addcffa6794c29dccf33d8db5347f24b75f2fc
  2.4 branch: 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/de98f011418c62e7b825a8ce3256e8fcdc84756e

Buster and earlier are not affected since their respective
(lib)cryptsetup don't support LUKS2 online reencryption.  I'll provide a
debdiff for bullseye-security.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1000593: Failing testsuite with PHP 8.1

[Guilhem Moulin]

Hi taffit,

On Thu, 25 Nov 2021 at 11:50:24 -0400, David Prévot wrote:
> There is a new upstream version (1.2.4), but I quickly checked that
> two failures (first and last) still happen. (It’s also not a PEAR
> package anymore, so need some work to convert the packaging to its
> Composer source).

I plan to work on this during the next few days if no one beats me to
it.  AFAICT php-console-commandline's only reverse depends is php-crypt-
gpg which in turns is currently only used for Roundcube.  (I currently
co-maintain these packages already.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1000642: roundcube: Failing test with PHP 8.1

[Guilhem Moulin]

On Thu, 02 Dec 2021 at 17:22:09 +, debian-bts-link wrote
> # remote status report for #1000642 (http://bugs.debian.org/1000642)
> # Bug title: roundcube: Failing test with PHP 8.1
> #  * https://github.com/roundcube/roundcubemail/issues/8151
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 1000642 + fixed-upstream
> usertags 1000642 + status-closed

Just a quick follow-up on this: while the upstream issue is closed and
1.5.[12] were recently released, upstream's 1.5 branch is officially not
compatible with PHP 8.1.  I think it's best to refrain from further 1.5
uploads and instead wait for 1.6.0.  Even if that means the roundcube
package will be removed from testing.  (Hopefully only briefly as
upstream is currently planning to release 1.6 in January or February.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#999815: cryptsetup - build-depends on removed package.

[Guilhem Moulin]

On Thu, 18 Nov 2021 at 23:13:59 +0100, Christian Göttsche wrote:
> A quick test build without those two build-dependencies resulted in
> identical binary packages.

They are currently pulled transitively by libdevmapper-dev, so removing
them from the explicit Build-Depends doesn't yield a different build
environment.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#997809: roundcube: Delay migration into testing

[Guilhem Moulin]

Source: roundcube
Version: 1.5.0+dfsg.1-2
Severity: serious

Given the large changelog it's probably best to let 1.5 mature in
unstable and delay its entry into testing by a week or so.

With the DEP8 tests urgency=medium means migration after only 2 days
which is definitely too short here.  Meant to upload -2 with
urgency=low, my bad for not changing the default.  

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#994446: roundcube-core: SMTP error message 'SMTP auth failed (250)'

[Guilhem Moulin]

Control: tag -1 - moreinfo

On Thu, 16 Sep 2021 at 15:42:16 +0200, Olaf Zaplinski wrote:
> Yes, I added
> 
> $config['smtp_user'] = '';
> $config['smtp_pass'] = '';
> 
> to config.inc-php, now it is working. Thank you!

Great, thanks for the follow-up!  The new default took effect a while
back but it might still make sense to retroactively add it to the NEWS
file, so I'm leaving this bug open meanwhile.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#994446: roundcube-core: SMTP error message 'SMTP auth failed (250)'

[Guilhem Moulin]

On Thu, 16 Sep 2021 at 14:46:34 +0200, Olaf Zaplinski wrote:
> Roundcube does authenticate to IMAP, but not to SMTP because it is not
> needed on localhost. 

The default is to use SMTP AUTH on localhost:587.  This is not an RC
bug.
 
>>   Does adding 
>>  
>>     $config['smtp_user'] = ''; 
>>  
>>     $config['smtp_pass'] = ''; 
>>  
>> to the configuration fixes the problem? 
> 
> I added it to my /etc/dovecot/local.conf => no.

I mean to the *Roundcube* configuration (/etc/roundcube/config.inc.php)…
I'm able to send mail to [::1]:25 without SMTP AUTH with the above and

$config['smtp_port'] = 25;

> So I need a way to disable SMTP AUTH

That's what setting $config['smtp_user'] and/or $config['smtp_pass'] to
the empty string does.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#994446: roundcube-core: SMTP error message 'SMTP auth failed (250)'

[Guilhem Moulin]

Hi,

Control: severity -1 important
Control: tag -1 moreinfo

On Thu, 16 Sep 2021 at 09:29:49 +0200, Olaf Zaplinski via 
Pkg-roundcube-maintainers wrote:
> Severity: grave
> Justification: renders package unusable

I disagree with that: I believe a typical Roundcube installation uses
IMAP credentials to authenticate to the submission server.  Downgrading
the severity accordingly.

> on Debian 10, Roundcube worked as configured and could send emails to 
> [::1]:25 without authentication as intended.
> Now on Debian 11, it says that 'SMTP error (250) authentication failed' or so 
> (my system is set to German).
> 
> The error message makes no sense. SMTP 250 reply code is 'ok'.

It's not an SMTP error code; Roundcube refuses to proceed because
smtp_{user,pass} are set while the SMTPd doesn't offer authentication.
Does adding

$config['smtp_user'] = '';
$config['smtp_pass'] = '';

to the configuration fixes the problem?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#980792: Cannot decrypt encrypted root at boot with cryptsetup-initramfs 2:2.3.4-2~bpo10+1 (buster-backports)

[Guilhem Moulin]

> apt upgrade installed cryptsetup-initramfs 2:2.3.4-2~bpo10+1 over
> 2:2.3.4-1~bpo10+1

Next time please use the backports mailing list to report bugs for
-backports: https://backports.debian.org/Instructions/#index6h2

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#979156: Useless in Debian

[Guilhem Moulin]

Control: severity -1 important

On Sun, 10 Jan 2021 at 20:35:45 -0400, David Prévot wrote:
> Guilhem, I did not spot that with ”build-rdeps php-net-idna2”, so I assume
> your need is a work in progress (please, do correct me If I’m wrong).

Yup you're right, once this is ready php-net-idna2 should show up in
Roundcube's (Build-)Depends.  I hope to finalize that before the freeze,
so lowering the bug severity for now to remove its RC status :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian

[Guilhem Moulin]

Hi all,

On Sun, 03 Jan 2021 at 16:54:41 -0800, Sunil Mohan Adapa wrote:
> I will be filing an RM: bug on the package on Jan 10, 2021. I will
> wait to see if the other uploaders think it is still needed.

Roundcube's test suite which I'm working on now has some tests making
use of Net_IDNA2 so I'd like to keep the package around if possible :-)
I can give a hand and help bringing it up to shape for Bullseye.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#975862: lacme: Upcoming changes in the Let's Encrypt chain of trust break lacme

[Guilhem Moulin]

Package: lacme
Version: 0.6.1-1
Severity: grave
Justification: renders package unusable

Two upcoming changes in the Let's Encrypt chain of trust severely impact
lacme and will break new issuance when they're rolled out in December /
January.

 1. The existing issuer, namely “Let's Encrypt Authority X3”, which
expires on 2021-03-17, will be phased out in December and
progressively replaced with “Let's Encrypt Authority R3”.
https://community.letsencrypt.org/t/beginning-issuance-from-r3/139018
 2. The existing trust root, namely “IdenTrust DST Root CA X3”, which
expires on 2021-09-30, will be replaced with ”ISRG Root X1” on
January 11 next year.
https://letsencrypt.org/2020/11/06/own-two-feet.html

Unfortunately lacme uses a configurable ‘CAfile’ (pointing to “Let's
Encrypt Authority X3” by default) as intermediate CA in the certificate
chain.  This made sense for ACME v1, but for ACME v2 the issuing
certificate is provided as part of the response and gives more
flexibility for rotation, so we should definitely use that instead.
(ACME v2 is supported since lacme 0.5.)

In addition, the configurable ‘CAfile’ is used for client-side
validation after the issuance.  Defaulting to a bundle containing all
known active Let's Encrypt certificates would give some flexibility
compared to hard coded key material and avoid having a period during
which issuance no longer works out of the box.  Otherwise the cheap fix
is to download https://letsencrypt.org/certs/lets-encrypt-r3.pem and set
‘CAfile’ to its path once Let's Encrypt has finalized the transition in
mid January (and avoid making new certificate requests/renewals
meanwhile).

[Setting this RC already now since it's not clear exactly when this will
break; but at most 2 weeks.]

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#969226: [pkg-cryptsetup-devel] Bug#969226: cryptsetup-suspend: missing dependency on /bin/openvt (kbd)

[Guilhem Moulin]

Control: -1 severity -1 serious

Hi Jochen,

On Sat, 29 Aug 2020 at 18:24:44 +0200, Jochen Sprickerhof wrote:
> Severity: grave
> Justification: renders package unusable
> […r
> /lib/systemd/system/systemd-suspend.service.d/systemd_cryptsetup-suspend.conf
> tries to call /bin/openvt which is in the optional package kbd.

cryptsetup-initramfs has ‘Recommends: kbd’ so while the missing
dependency in cryptsetup-suspend is a policy violation, in practice
it'll work just fine on systems without --no-install-recommends (the
default). :-P

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#968383: Info received and FILED only (Bug#968383: marked as done (interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF)))

[Guilhem Moulin]

On Fri, 14 Aug 2020 at 19:54:31 +0200, Jonas Smedegaard wrote:
> Arrgh - I _know_ who you are, and that there are both a Guillem and a 
> Guilhem in Debian - I know you both.
> 
> ...but yes, indeed, I flipped around who is spelled how.  And indeed, I 
> just shouted at and later had a nice conversation with Guillem - without 
> realizing throughout our conversation that I was talking to the other 
> one...

Aha :-D

> (I imagine you experience that from time to time...)

Indeed!  And folks get confused with username auto-completion when we
both show up in the same room ;-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#968383: marked as done (interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF))

[Guilhem Moulin]

On Fri, 14 Aug 2020 at 13:57:32 +0200, Jonas Smedegaard wrote:
> and shouting out to you on irc,

Oh, if that was recently I'm afraid I missed it.

> Now it works, after aplying this patch:
> 
> --- /etc/dovecot/conf.d/10-ssl.conf.orig
> +++ /etc/dovecot/conf.d/10-ssl.conf
> @@ -9,8 +9,8 @@
> # dropping root privileges, so keep the key file unreadable by anyone but
> # root. Included doc/mkcert.sh can be used to easily generate self-signed
> # certificate, just make sure to update the domains in dovecot-openssl.cnf
> -ssl_cert =  -ssl_key =  +#ssl_cert =  +#ssl_key =  .
> # If key file is password protected, give the password here. Alternatively
> # give it when starting dovecot with -p parameter. Since this file is often

I see, thanks.  Seems a regression from Dovecot upstream, which was also
reported at https://dovecot.org/pipermail/dovecot/2020-August/119642.html .

The test suite didn't catch this since we don't run the IMAPd with the
stock configuration (intentionally — don't want to depend too much on a
specific server), and instead run `doveadm -c /path/to/dovecot.conf exec
imap` as tunnel command.  That's also the workflow advertised at
/usr/share/doc/interimap/getting-started.md.gz.

I'll see if upstream fixes the regression, and add a note to the
aforementioned document otherwise.  (Explicitly setting ‘ssl=no’ doesn't
seem to have an effect anymore, so that document should probably be
revisited anyway.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#968383: marked as done (interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF))

[Guilhem Moulin]

On Fri, 14 Aug 2020 at 09:33:03 +, Debian Bug Tracking System wrote:
>> All my 5 interimap profiles stopped working when security fix was applied
>> for my local Dovecot install was applied.
> 
> False alarm: Turned out to be a change in dovecot configuration files 
> incompatible with my accessing it via tunnel.
> 
> Revealed by manually running the underlying doveadm command.

Thanks for the update, Jonas!  Mind sharing what you had to change in
Dovecot?  1:2.3.11.3+dfsg1-1 doesn't break the test suite, so maybe you
have a setup it'd be worth having test covering for.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963010: roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php

[Guilhem Moulin]

Hi,

On Thu, 09 Jul 2020 at 16:53:03 +0200, Mirko Vogt wrote:
> Can I do anything to push this being fixed or workaround this myself
> without weakening my setup security wise? Thanks!

The bug metadata say:

  Found in versions roundcube-core/1.2.3+dfsg.1-4+deb9u3, 
roundcube-core/1.3.13+dfsg.1-1~deb10u1, roundcube-core/1.3.10+dfsg.1-1~deb10u1
  Fixed in versions roundcube-core/1.4.3+dfsg.1-1

So right now versions in testing, sid, and buster-backports are
unaffected, while those in buster, buster-security and stretch and
stretch-security (or anything earlier) are affected.

Some work has been done in the postinst script in 1.4 so the fix doesn't
apply to 1.3.14+dfsg.1-1~deb10u1.  It might be possible to write a
targeted patch and convince the release team to accept it as a
stable-proposed-updates, but I personally don't plan to work on that.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

[Guilhem Moulin]

Control: reassign -1 libmount1
Control: found -1 2.35.2-6
Control: retitle -1 libmount1 pulls in libssl 1.1 and breaks software 
statically linked against libcrypto 1.0

On Sat, 27 Jun 2020 at 01:08:49 -0400, Christian Weeks wrote:
>> Unless there is a reproducer involving a targeted libcryptsetup12
>> upgrade I don't think this belong here :-P  Aside from documentation
>> files, the only thing libcryptsetup12 (2:2.1.0-5+deb10u2 and 2:2.3.3-1)
>> ships is libcryptsetup.so.12*.  It doesn't touch libssl.
> 
> It seems that libcryptsetup + the new libmount1 dependency on same are
> the root cause somehow. Sorry for the confusion.

To the util-linux maintainers: the following link from #message26 appears
relevant: 
https://github.com/ValveSoftware/steam-for-linux/issues/6861#issuecomment-584379611

Starting with 2.1 cryptsetup upstream started using libssl as
cryptographic backend for LUKS header processing; this is already the
case in Buster and while other backends are supported I'm very reluctant
to diverge from upstream's sane defaults here.

So software dynamically linked against libmount ≥2.35.2-5 will
transitively pull in libssl.so.1.1, which due to symbol clashes appears
to crash software statically linked against libssl1.0.  Unfortunately
I've not been able to find a standalone reproducer using a PoC
executable and I didn't look further.

I'm not sure this bug should be RC, or if it's even valid in the first
place (it's arguably a steam bug).  Reassigning to libmount1 anyway as
the regression follows #951048.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

[Guilhem Moulin]

On Fri, 26 Jun 2020 at 20:39:32 -0400, Christian Weeks wrote:
> After some more googling, it seems that the REAL culprit might be
> libmount1.

Should this be reassigned to util-linux/2.35.2-5 then?
 
> This seems like a really messy tangled web of nastiness. Good luck
> figuring it out.

Unless there is a reproducer involving a targeted libcryptsetup12
upgrade I don't think this belong here :-P  Aside from documentation
files, the only thing libcryptsetup12 (2:2.1.0-5+deb10u2 and 2:2.3.3-1)
ships is libcryptsetup.so.12*.  It doesn't touch libssl.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

[Guilhem Moulin]

On Fri, 26 Jun 2020 at 11:40:31 -0400, Christian Weeks wrote:
> Attached is the output of the various console commands, as well
> as the backtrace from the broken launcher with the new lib.

Thanks, however I fail to see how libcryptsetup12 is involved.  (Also I
think we can rule out i386 since the crash happens with x86_64.)  Is
that the entire reproducer?

  - launcher works with libcryptsetup12:amd64 2:2.1.0-5+deb10u2
  - `apt upgrade libcryptsetup12:amd64` (from 2:2.1.0-5+deb10u2
to 2:2.3.3-1, and *only* this package)
  - launcher no longer works

Do you confirm that the backtrace you shared previously was part of this
reproducer, and not something saved from a previous environment?  I see
no mention of libcryptsetup there, so I don't see how it comes to the
picture.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi Christian,

On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote:
> I installed the newest version of libcryptsetup12.

Unfortunately you appeared to file this bug using Buster's
libcryptsetup12 so the metada doesn't describe the buggy environment
(Version: 2:2.1.0-5+deb10u2).  Please show the output of `apt upgrade
libcryptsetup12` that yields the buggy environment.  (I.e., you don't
encounter the bug before the command but do after the upgrade.)  The
output of

ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup

and

dpkg-query -l "*cryptsetup*"

before *and* after the upgrade might be helpful too.

> Suddenly, minecraft would not run! 
> Backtraces in gdb indicate that something is broken in SSL.

Care to share said backtrace also?

cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963010: [Pkg-roundcube-maintainers] Bug#963010: Acknowledgement (roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php)

[Guilhem Moulin]

On Wed, 17 Jun 2020 at 17:09:01 +0200, Mirko Vogt wrote:
> However above report was closed in Feb 2020 with a comment that bug was
> believed to be fixed. If that's the case, the fix apparently didn't make
> it back to stable/buster, though.

Right, as written on the list:

| I believe is a duplicate of https://bugs.debian.org/951194 (RC) and
| fixed 1.4.3+dfsg.1-1.  I'm not sure the fix is suitable for buster-pu
| though.

(FWIW my “please use the Debian BTS” wasn't an invitation to file a bug
in this case, but to query the BTS to check if the issue was already
reported and/or fixed.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Guilhem Moulin]

Hi Salvatore,

On Thu, 07 May 2020 at 08:18:34 +0200, Salvatore Bonaccorso wrote:
> I would like to get some testing feedback on the stretch packages, if
> you have such instance
> https://people.debian.org/~carnil/tmp/salt/stretch/ contains testing
> packages.

Unfortunately I don't, would have been able to help with Buster (you
were faster though ;-)) but I currently don't have a running stretch
instance and won't find time to deploy one before the week-end.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Guilhem Moulin]

Control: notfixed -1 2016.11.2+ds-1+deb9u3

On Wed, 6 May 2020 at 10:36:42 +0200, Elimar Riesebieter wrote:
> please notice the attached note from saltstack! I assume this is not
> integrated into DSA 4676-1, isn't it?

Ooops yes, 2016.11.2+ds-1+deb9u3 appears to still be vulnerable to
CVE-2020-11652:

| If you have already applied the patch for Salt 2017.x or earlier, there
| is a follow-up patch to apply. You can download the patch and
| instructions below. **This applies to 2017.x, 2016.x, and 2015.x. This
| does NOT apply to 2018.x, 2019.x, or 3000.x.** 
| […]
|   - 2016.x 
| […] 
| The original patch for versions 2017.x and earlier secured against
| arbitrary commands running on Salt minions and eliminated the exposure
| (CVE-2020-11651). This additional patch is required to completely
| resolve arbitrary directory access to authenticated users
| (CVE-2020-11652).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959684: salt: CVE-2020-11651 and CVE-2020-11652

[Guilhem Moulin]

Source: salt
Version: 2018.3.4+dfsg1-6
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 2018.3.4+dfsg1-6
Control: found -1 2016.11.2+ds-1+deb9u2
Control: found -1 2014.1.13+ds-3
Control: notfound -1 3000.2+dfsg1-1

Dear Maintainer,

These CVEs were assigned last Wednesday but I'm filing this as it seems
they're not tracked in the BTS yet.

  CVE-2020-11651
  --

  An issue was discovered in SaltStack Salt before 2019.2.4 and 3000
  before 3000.2. The salt-master process ClearFuncs class does not
  properly validate method calls. This allows a remote user to access
  some methods without authentication. These methods can be used to
  retrieve user tokens from the salt master and/or _run arbitrary
  commands on salt minions_. [emphasis mine]

  CVE-2020-11652
  --

  An issue was discovered in SaltStack Salt before 2019.2.4 and 3000
  before 3000.2. The salt-master process ClearFuncs class allows access
  to some methods that improperly sanitize paths. These methods allow
  arbitrary directory access to authenticated users.

As seen for instance at https://github.com/saltstack/salt/issues/57057
the vulnerabilities are being exploited in wild already; compromised
salt masters do allow attackers to run arbitrary commands on the minions
as root.

See also https://labs.f-secure.com/advisories/saltstack-authorization-bypass .

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#880778: ploticus build depends on removed libgd2*-dev provides

[Guilhem Moulin]

Control: tag -1 pending
Control: usertags -1 bsp-2020-03-se-gothenburg

Hi there, about to NMU with the attached debdiff.

-- 
Guilhem.
diffstat for ploticus-2.42 ploticus-2.42

 changelog |8 
 control   |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -Nru ploticus-2.42/debian/changelog ploticus-2.42/debian/changelog
--- ploticus-2.42/debian/changelog  2017-07-25 10:58:08.0 +0200
+++ ploticus-2.42/debian/changelog  2020-03-29 11:06:52.0 +0200
@@ -1,3 +1,11 @@
+ploticus (2.42-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control: Replace removed libgd2-noxpm-dev build-deb with libgd-dev to
+fix FTBS (closes: #880778)
+
+ -- Guilhem Moulin   Sun, 29 Mar 2020 11:06:52 +0200
+
 ploticus (2.42-4) unstable; urgency=medium
 
   * Fix debian/watch - thanks to Iain Learmonth
diff -Nru ploticus-2.42/debian/control ploticus-2.42/debian/control
--- ploticus-2.42/debian/control2017-07-25 10:57:12.0 +0200
+++ ploticus-2.42/debian/control2020-03-29 11:04:16.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Colin Tuckley 
 Homepage: http://ploticus.sourceforge.net
-Build-Depends: debhelper (>= 9), zlib1g-dev, libgd2-noxpm-dev, libjpeg-dev, 
libfreetype6-dev, libx11-dev, x11proto-core-dev, libpng-dev, dpkg-dev (>= 
1.16.1~)
+Build-Depends: debhelper (>= 9), zlib1g-dev, libgd-dev, libjpeg-dev, 
libfreetype6-dev, libx11-dev, x11proto-core-dev, libpng-dev, dpkg-dev (>= 
1.16.1~)
 Standards-Version: 4.0.0
 
 Package: ploticus


signature.asc
Description: PGP signature

Bug#951194: marked as pending in roundcube

[Guilhem Moulin]

Control: tag -1 pending

Hello,

Bug #951194 in roundcube reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/roundcube-team/roundcube/commit/fd57a4fbc7b8d5262815978f448fe526db9ce79c


d/roundcube-core.postinst: Avoid overriding ownership/mode.

A new config file /etc/roundcube/config.inc.php is (atomically) created
with owner root:www-data and mode 0640 (like before), but we're now
preserving ownership/mode of existing files.

Also, honor dpkg-statoverride(1) rules on /var/lib/roundcube/temp and
/var/log/roundcube: don't chown/chmod these directories if the local
admin has defined overrides.

Closes: #951194


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/951194

Bug#935702: [pkg-cryptsetup-devel] Bug#935702: Wrong DM device size due to integer truncation

[Guilhem Moulin]

Control: tag -1 fixed-upstream

On Mon, 26 Aug 2019 at 11:08:35 +0200, Milan Broz wrote:
> Fixed here 
> https://gitlab.com/cryptsetup/cryptsetup/commit/8f8f0b3258152a260c6a40be89b485f943f81484

Thanks, Milan!

> I'll do minor release soon, but perhaps it would be better to
> cherrypick the patch directly.

We'll likely have to backport your patch to 2.2.0-3 since we're a bit in
a rush if we want the bugfix in the upcoming point release (10.1 is
scheduled on Sep 07 after a freeze of one week): bug fixes should land
to unstable first per Release Team policy.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#935702: [pkg-cryptsetup-devel] Bug#935702: Wrong DM device size due to integer truncation

[Guilhem Moulin]

Control: retitle -1 DM device size ≥2³² 512-bits sectors is truncated on 
32-bits platforms
Control: tag -1 + upstream

Hi,

On Sun, 25 Aug 2019 at 12:43:26 +, n...@waifu.club wrote:
> Not only the access to protected data is lost, the integritysetup's "open"
> operation actually succeeds. All reads on the incorrectly created DM device
> will of course fail with I/O errors due to bad integrity tags, but all
> writes will happily write wrong tags at wrong places! This makes it very
> easy for the administrator to destroy the data while trying to recover with
> --integrity-recovery-mode.

Would you mind sharing your test vector, either here or the upstream bug
tracker at https://gitlab.com/cryptsetup/cryptsetup/issues ?  While it's
clear there is a bug, I was unable to reproduce your observations in the
arguably most common cases, namely block devices formatted as LUKS1 or
LUKS2 with the default parameters (and a payload size exceeding ≥2³²
512-bits sectors).  The only function of the dm_*_target_set() family
called is dm_crypt_target_set(), and always with 0 as segment offset and
size.

`cryptsetup plainOpen -b $LARGE_NUMBER` does yield a call to 
dm_crypt_target_set()
with a truncated dmd.size, but the proper size is used before opening
the device thanks to device_block_adjust().

Or does the bug only applies to integrity targets?  I'm indeed able to
reproduce for these targets:

$ uname -r
4.19.0-5-686
$ truncate -s3T /tmp/disk.img
$ losetup /dev/loop0 /tmp/disk.img

$ integritysetup format -s 512 --no-wipe -q /dev/loop0
$ integritysetup dump /dev/loop0 | grep provided_data_sectors
provided_data_sectors 6392379512
$ integritysetup open /dev/loop0 integrity_test
$ echo $?
0
$ dmsetup table integrity_test
0 2097412216 integrity …

syslog contains (checksum errors are due to no-wipe):
[…] device-mapper: integrity: Checksum failed at sector 0x7d03f780
[…] device-mapper: integrity: Checksum failed at sector 0x7d03f780
[…] Buffer I/O error on dev dm-2, logical block 262176496, async page read


## experimental --integrity extension
$ cryptsetup luksFormat -q --integrity hmac-sha256 --integrity-no-wipe \
--pbkdf-force-iterations 4 --pbkdf-memory 32 /dev/loop0 <<

signature.asc
Description: PGP signature

Bug#932643: [pkg-cryptsetup-devel] Bug#932643: cryptsetup upgrade causes cryptsetup-initramfs autoremoval and boot failure

[Guilhem Moulin]

On Mon, 22 Jul 2019 at 11:37:24 +1200, Ben Caradoc-Davies wrote:
> cryptsetup 2:2.1.0-6 has no dependency on cryptsetup-initramfs so the
> latter will be autoremoved if only cryptsetup was marked manual by the
> installer.

Ooops.  We don't want ‘cryptsetup’ to hard-depend on ‘cryptsetup-initramfs’,
as that would make the 2:2.0.3-1 package split moot.  I just uploaded
2:2.1.0-7 where ‘cryptsetup’ *Recommends* ‘cryptsetup-initramfs’, which
is enough to convince APT not to auto-remove the latter upon `apt
upgrade --autoremove`.

In addition, I added a NEWS entry (forgot to do it for 2:2.1.0-6…) and
the prerm script now triggers a loud warning upon package removal if
there are mapped crypt devices.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

On Sun, 21 Jul 2019 at 22:40:38 +0200, Michael Biebl wrote:
> I already uploaded 2.20-7+deb10u1 with this changelog, so it's not
> really possible anymore to undo this other then making a 2.20-7+deb10u2
> upload, which seems like overkill to me.
> I don't think the changelog is that misleading that we need another
> upload fixing it.

Ack, agreed

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

Hi,

On Sun, 21 Jul 2019 at 13:36:06 +0200, Michael Biebl wrote:
> Agreed. I've just uploaded a libblockdev with that cherry-pick to buster
> and this change was acked by the SRMs, so should be in 10.1.

Awesome! :-)

> Regarding the LUKS2/udisks2/LimitMEMLOCK issue, would you prefer to
> track this as a udisks2 issue or cryptsetup issue?  Is there already a
> bug report for this or should we clone/reassign this one?

I filed https://gitlab.com/cryptsetup/cryptsetup/issues/465 “Argon2i/d
benchmark doesn't honor `getrlimit(RLIMIT_MEMLOCK,)`”, but on second
thought I don' think udisks2 is affected.  As I wrote in Message #59,

| Apologies for incorrectly pointing to getrlimits(2) earlier: I'm
| personally not familiar with udisks/libblockdev myself and hadn't
| realized `getrlimit(RLIMIT_MEMLOCK,)` was bypassed since the Argon2d/i
| benchmark process is privileged.

Now that libblockdev uses crypt_keyslot_change_by_passphrase() there is
AFAICT nothing more to be done on the libblockdev or udisks2 side with
respect to that bug.  But maybe the Changelog entry for libblockdev
2.20-7+deb10u1 should be changed to remove the references to MEMLOCK.
As I wrote in https://gitlab.com/cryptsetup/cryptsetup/issues/466 I
believe the problem with LUKSv2 is elsewhere (crypt_get_volume_key_size()
fails because there is no bound keyslot object to retrieve the key size
from).  Maybe changing it to

  * Use existing cryptsetup API for changing keyslot passphrase.
Cherry-pick upstream fix to use existing cryptsetup API for atomically
changing a keyslot passphrase, instead of deleting the old keyslot
before adding the new one. This avoids data loss when attempting to
change the passphrase of a LUKS2 device via udisks2, e.g. from GNOME
Disks.
Deleting a keyslot and then adding one is risky: if anything goes wrong
before the new keyslot is successfully added, no usable keyslot is left
and the device cannot be unlocked anymore.  There's little chances this
causes actual problems with LUKS1, but as of 2.1.0 libcrypsetup
fails to add a new keyslot to a LUKS2 header without any
pre-existing keyslot.
(Closes: #928893)

Or maybe remoing the last sentence alltogether, ending with “[…] cannot
be unlocked anymore.”

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

On Sat, 20 Jul 2019 at 06:01:35 -0300, Guilhem Moulin wrote:
> LUKS2_get_volume_key_size() fails because the key size is specified in
> the ‘keyslots’ object of LUKSv2's JSON header [0], and that object is
> the empty array at that point.

Forgot to add another data point which supports my claim: with a LUKSv2
device with two active key slots (#0 unlocked by passphrase “test” and
#1 unlocked by a random passphrase), LUKS2_get_volume_key_size()
succeeds and so does crypt_keyslot_add_by_volume_key().

$ cryptsetup luksFormat --pbkdf-force-iterations 4 --pbkdf-memory 32 \
--type luks2 -q /tmp/disk.img <<https://gitlab.com/cryptsetup/cryptsetup/issues/466

However as far as libblockdev is concerned, FWIW I fully support
intrigeri's cherry-pick of upstream's 34ed7be.  Adding a key slot
*after* having removed it can have very nasty consequences (entire
device lost), and that not just for LUKSv2.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

Hi there,

On Fri, 19 Jul 2019 at 22:14:49 -0300, intrigeri wrote:
> it turns out this is caused by a bug in libblockdev, which is fixed in
> sid already (although it seems like upstream applied the fix for
> unrelated reasons and it's not clear whether they realized this bug
> was a possibility).

AFAICT there were two bugs in 
src/plugins/crypto.c:bd_crypto_luks_change_key_blob()


https://sources.debian.org/src/libblockdev/2.20-7/src/plugins/crypto.c/#L1359

The API calls to libcryptsetup roughly goes as follows:

keyslot = crypt_volume_key_get(cd, …, volume_key, old_passphrase);
crypt_keyslot_destroy(cd, keyslot);
crypt_keyslot_add_by_volume_key(cd, 0, volume_key, new_passphrase);

The first call uses the old passphrase to unlock a keyslot and set the
volume key.   (In LUKS2 the volume key of open devices isn't accessible
to userspace, but of course it's no problem here since the passphrase is
used to unlock a keyslot, which yields the volume key.)

The second call removes the keyslot used to get the volume key in the
first call.

The third call adds a new key slot with the new passphrase.


There are IMHO two issues with these calls (regardless of the LUKS
format version):

  1. It only adds the new slot *after* deleting the old one, so there is
 moment where the LUKS header might have no active key slot left.
 Worse, if crypt_keyslot_add_by_volume_key() fails for whichever
 reason, then the header is left in a broken state; if the user
 doesn't notice and closes the mapped device (or simply reboots)
 then the entire content of the device is lost.

  2. The second argument of crypt_keyslot_add_by_volume_key() is always 0,
 while the user might want to change another key slot.

I'm unfortunately not familiar with libblockdev, but the attached
program, to be linked against libcryptsetup, shows these problems
AFAICT.


Format a device as LUKSv1 (although the same happens with v2), with a
random passphrase for key slot 0, and passphrase “test” for key slot
1.  (The extra PBKDF argument are there just so the test doesn't take
too long.)

$ dd if=/dev/zero of=/tmp/disk.img bs=1M count=64
$ head -c 32 /dev/urandom >/tmp/keyslot0
$ cryptsetup luksFormat --pbkdf-force-iterations 1000 --type luks1 \
-q --key-file=/tmp/keyslot0 /tmp/disk.img
$ cryptsetup luksAddKey --pbkdf-force-iterations 1000 \
--key-file=/tmp/keyslot0 -q /tmp/disk.img <

Bug#927165: [pkg-cryptsetup-devel] Bug#927165: debian-installer: improve support for LUKS

[Guilhem Moulin]

On Mon, 01 Jul 2019 at 04:45:47 +0200, Guilhem Moulin wrote:
> Sure, I even planned to do that when I heard about your post-mini-DebConf
> “hiccup” ;-)  I remained on the road for another 3 weeks and unfortunately
> didn't find time since the mini Debconf.  Thanks for the poke, I'll try to
> tend to it this week.

It was less difficult than I imagined ;-)  Sorry for delaying it, I
could have done that immediately after writing the document.

https://salsa.debian.org/installer-team/installation-guide/merge_requests/9

Do you still think it'd be a good idea to add a boot parameter ‘luks-version=’
or so (defaulting to ‘2’) so users can easily format to LUKS1, or do you agree
documenting the “downgrade path” is enough?  (I guess it's too late for
Buster anyway, but maybe a later point release?)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#927165: debian-installer: improve support for LUKS

[Guilhem Moulin]

Hi there,

On Mon, 01 Jul 2019 at 04:21:46 +0200, Cyril Brulebois wrote:
> Roger Shimizu  (2019-06-30):
>> Thank for the above doc, which is quite easy understanding and 
>> straightforward!
>> […]
>> I confirmed with /boot set up in LUKS1, everything works fine.
>> It‘d configure non encrypted /boot when in D-I, then after finishing
>> D-I, and reboot to system, manually make LUKS1 for /boot partition.
> 
> Thanks for letting us know you appreciate it.

+1 :-)
 
> Guilhem, any chance I could trick you into adding a pointer from the
> installation-guide to your documentation? It would be an extra string
> for translators to deal with, but that might be added to unstable and
> then backported at a later point to buster once translators have had a
> chance to catch up.

Sure, I even planned to do that when I heard about your post-mini-DebConf
“hiccup” ;-)  I remained on the road for another 3 weeks and unfortunately
didn't find time since the mini Debconf.  Thanks for the poke, I'll try to
tend to it this week.

>> However, I found adding: GRUB_PRELOAD_MODULES="luks cryptodisk" to
>>  /etc/default/grub is not necessary.  GRUB_ENABLE_CRYPTODISK=y is the
>>  only setting need to append manually.
>
> From my limited tests, it seemed that GRUB_ENABLE_CRYPTODISK=y was
> indeed sufficient.

Thanks Roger for the info, and to Cyril for confirming.  Interestingly
my 6 years old notes suggest otherwise, but I don't remember the details
and it's of course possible that I messed up the tests back then.  I'll
try to test again with older GRUB to find an inflexion point, and modify
the document accordingly.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#927165: debian-installer: improve support for LUKS

[Guilhem Moulin]

Hi there,

On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote:
>>> One could argue that cryptodisk support has never been supported by
>>> d-i anyway,
>>
>> Yup, and I suppose that's why I overlooked this in my mail to
>> debian-boot :-P  Jonathan Carter had a similar report last week
>>
>> https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-April/008196.html
>
> While I'm usually fine to dismiss some bug reports as “it's unsupported,
> sorry”, making users' life harder doesn't seem really reasonable… :/

During last week's gathering at MiniDebConf Hamburg we (cryptsetup package
maintainer + KiBi) talked and came up with the following guide/notes:

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

I believe it covers the easiest way to set up GRUB unlocking, i.e., starting
from d-i's "encrypted LVM" partitioning method.  Tested with Debian
Installer Buster RC1, but should™ be relevant with:

  - Any d-i supporting the "encrypted LVM" partitioning method where
encrypted have LUKS headers.  (Since Lenny?  Or perhaps even Etch, don't
remember if Etch had support for LUKS already, or only plain dm-crypt
and loop-AES.)
  - Any GRUB2 ≥2.00-1, so very early in Jessie's release cycle.
  - Any cryptsetup version, whether the default LUKS format version is 1
(pre-Buster) or 2 (since 2:2.1.0-1, now in Buster).

The aim of our document is to describe how to setup GRUB unlocking from an
existing “standard” installation (thus subject to partman-partitioning's
limitations).  We aim to follow future d-i versions; should native support
for encrypted /boot (which — as of GRUB 2.02 — requires the underlying
device to be formatted as LUKS1) be implemented at some point, that'll be
documented there.

We also propose to add a link to this document from the release notes:
https://salsa.debian.org/ddp-team/release-notes/merge_requests/29 .

Cheers,
-- 
Guilhem.

PS. I've used GRUB unlocking on several devices (sometimes bypassing
partman, sometimes not) since before Wheezy was released, and should
have written that guide & shipped it to the cryptsetup package years ago
(the closest form that comes to mind is my talk at DebConf18 which was
not so detailed)… apologies for not doing so earlier.  I'm also a bit
sad to have missed 
https://lists.debian.org/debian-boot/2019/01/msg00035.html .


signature.asc
Description: PGP signature

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Guilhem Moulin]

On Wed, 22 May 2019 at 07:34:06 +0200, Xavier wrote:
> It seems that Clément has fixed something related to that feature.
> Could you try 
> https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/commit/deff50f072c64898d1204daa28c01fdcc7275ea4
>  ?

That solves the issue indeed, thanks for the pointer!  I ended up
amending the patch as attached though:

 * Not setting the ‘Access-Control-Allow-Origin: *’ header is upstream
   issue #1519, fixed in e6c034a38aa0e7dadcf0ce87809193b327fbc0e5.

 * The second to last hunk from deff50f072c64898d1204daa28c01fdcc7275ea4
   (-2134,8 +2137,10) doesn't apply, and as it's only cosmetic
   (whitespace change) I just skipped it.

Cheers,
-- 
Guilhem.
--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Simple.pm
+++ b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Simple.pm
@@ -1049,7 +1049,7 @@ sub updatePersistentSession {
 
 }
 
-## @method void updateSession(hashRef infos, string id)
+## @method void updateSession(hashRef infos, string id, string kind)
 # Update session stored.
 # If no id is given, try to get it from cookie.
 # If the session is available, update datas with $info.
@@ -1057,9 +1057,10 @@ sub updatePersistentSession {
 # server local cache, if there are several LL::NG servers.
 # @param infos hash reference of information to update
 # @param id Session ID
+# @param kind Session kind
 # @return nothing
 sub updateSession {
-my ( $self, $infos, $id ) = @_;
+my ( $self, $infos, $id, $kind ) = @_;
 
 # Return if no infos to update
 return () unless ( ref $infos eq 'HASH' and %$infos );
@@ -1084,7 +1085,9 @@ sub updateSession {
 }
 
 # Update session in global storage
-if ( my $apacheSession = $self->getApacheSession( $id, 1 ) ) {
+if ( my $apacheSession =
+$self->getApacheSession( $id, 1, undef, $kind ) )
+{
 
 # Store updateTime
 $infos->{updateTime} = strftime( "%Y%m%d%H%M%S", localtime() );
@@ -1567,9 +1570,8 @@ sub process {
 {
 if ( ( my $code = $self->{error} ) > 0 ) {
 print $self->header(
--status=> '401 Unauthorizated',
-'-WWW-Authenticate'=> "SSO $self->{portal}",
-'-Access-Control-Allow-Origin' => '*',
+-status => '401 Unauthorizated',
+'-WWW-Authenticate' => "SSO $self->{portal}",
 );
 $self->quit;
 }
@@ -2744,7 +2746,7 @@ sub autoRedirect {
 $cdaInfos->{cookie_name} = $self->{cookieName} . "http";
 }
 
-$self->updateSession( $cdaInfos, $cdaSession->id );
+$self->updateSession( $cdaInfos, $cdaSession->id, "CDA" );
 
 $self->{urldc} .=
 ( $self->{urldc} =~ /\?/ ? '&' : '?' )


signature.asc
Description: PGP signature

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Guilhem Moulin]

Hi Xavier,

 # Load session data into object
 if ($data) {
+if ( $self->kind ) {
+unless ( $data->{_session_kind} eq $self->kind ) {
+$self->error("Session kind mistmatch");
+return undef;
+}
+}

Doesn't that break CDA in 1.9.7-3+deb9u1?  At least I'm no longer able
to access a protected application under domains other than the portal.

Error output shows occurrences of “Session kind mistmatch” instead, and
further debugging suggests that $data->{_session_kind} is "CDA" while
$self->kind is "SSO" in the execution flow that yields access denial.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 14 May 2019 at 03:57:46 +0200, Steffen Ullrich wrote:
>> Ah I see, thanks for the clarification.  I thought you meant it could
>> yield a deadlock.  Aren't temporary failures also possible on plain
>> sockets (though of course the extra SSL layer make it strictly more
>> likely to happen)?  IIRC if the checksum of the incoming packet
>> mismatches, which causes the read() call to block until the packet is
>> retransmitted.
> 
> select only shows an fd ready  if data are available for read in the socket
> buffer. Data with wrong checksum are discarded by the kernel before they are
> put into the socket buffer and thus don't cause select to show it ready for
> read.
> 
> select(2) explicitly says:
> 
> A file descriptor is considered ready if it is possible to perform a
> corresponding I/O operation (e.g., read(2)  without blocking ...

Hmm, however in the “Bugs” sections, it says it's in fact not the case, and
that non-blocking I/O should be used to avoid temporary failures:

Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks.  This could for
example happen when data has arrived but upon examination has wrong
checksum and is discarded.  There may be other circumstances in which a
file descriptor is spuriously reported as ready.  Thus it may be safer to
use O_NONBLOCK on sockets that should not block.
 
>>> And while using blocking I/O with polling sockets might be fine with plain
>>> sockets where each byte is part of application data it is not fine with SSL
>>> since the unit in SSL is not a byte but a record and some records might
>>> contain application data and some not.
>>
>> Why is that not fine, if the SSL_read() caller is ready for that (documented)
>> outcome, and doesn't assume that the call will always block until some
>> application data is received?
> 
> IO::Socket::SSL is intended as abstraction which behaves as much as possible
> as other IO::Socket classes. It is not intended that the developer has to be
> familiar with the exact semantics of SSL_read (which also changed over
> time, especially with OpenSSL 1.1.0 and again with OpenSSL 1.1.1). While it
> is impossible to behave in exactly all cases sysread is usually not expect
> to return a temporary error on a blocking socket.
> […]
> Yes, the intention was to reflect as much as possible what is expected from
> IO::Socket::sysread and not what the SSL_read documentation says.

Fair enough.  Then it sounds like you'd want to set SSL_MODE_AUTO_RETRY
explicitly and not rely on the OpenSSL old or new defaults :-)  (Or loop in
Perl if support for OpenSSL that are two decades old is desired.)

For what it's worth, I interpreted

Also, calls to sysread might fail, because it must first finish an SSL
handshake.
To understand these behaviors is essential, if you write applications
which use event loops and/or non-blocking sockets.

from the sysread() documentation as an invitation to read the low-level
documentation and see what SSL_read() may return, also with blocking I/O :-)
(After all since sysread() will never block if there is some unprocessed data
left in the current SSL frame, that's already a hint that this sysread() has
some peculiarities that are not found in the version with plain sockets.)  The
new documentation clarifies a bit the expectation, thanks!  But I guess it
would be clearer if the paragraphs I quoted above were explicitly said
to only apply to non-blocking I/O.

Also isn't the workaround you implemented earlier

“deal with OpenSSL 1.1.1 switching on SSL_AUTO_RETRY by default by 
disabling it when non-blocking”

https://github.com/noxxi/p5-io-socket-ssl/commit/09bc6a3203bc7bc89078317da42a3e96cdbf94fc

a no-op?  AFAICT setting SSL_MODE_AUTO_RETRY avoids SSL_read() returning
SSL_ERROR_WANT_READ when a non-application data record is received, and
instead makes it block until application data is received.  For non-blocking
I/O however, SSL_read() will of course never block and may — regardless of
whether SSL_MODE_AUTO_RETRY is set — return SSL_ERROR_WANT_{READ,WRITE}.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 22:24:55 +0200, Steffen Ullrich wrote:
> On Mon, May 13, 2019 at 03:18:14PM +0200, Guilhem Moulin  
> wrote:
>> Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
>> default flags?  libssl mentions no such thing beside the new default
>> mode.  And in fact the s_client() program, *from OpenSSL upstream
>> itself*, does precisely that: a select loop in blocking I/O mode (unless
>> the ‘-nbio’ flag is set).
> 
> "Before" meaning already with previous OpenSSL versions. But the effect was
> likely hard to notice: an incomplete SSL record would not cause a permanent
> hang but only a blocking read until the rest of the data was received, i.e.
> only some slow down in some situations.

Ah I see, thanks for the clarification.  I thought you meant it could
yield a deadlock.  Aren't temporary failures also possible on plain
sockets (though of course the extra SSL layer make it strictly more
likely to happen)?  IIRC if the checksum of the incoming packet
mismatches, which causes the read() call to block until the packet is
retransmitted.

> And while using blocking I/O with polling sockets might be fine with plain
> sockets where each byte is part of application data it is not fine with SSL
> since the unit in SSL is not a byte but a record and some records might
> contain application data and some not.

Why is that not fine, if the SSL_read() caller is ready for that (documented)
outcome, and doesn't assume that the call will always block until some
application data is received?

>> The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
>> as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
>> SSL socket has a different behavior than usual read(2) system calls, in
>> that read failures should be treated with care, as there are both
>> retryable (eg. when no application data was received) and non-retryable
>> errors.
> 
> As I was the one who wrote the documentation for IO::Socket::SSL: the part
> about sysread failing was supposed to be about non-blocking sockets. A
> blocking socket was not expected to return nothing just because the
> handshake was not done.

Then I don't get it.  AFAICT the current documentation reflects what
happens with blocking sockets and OpenSSL <1.1.1a, namely that
IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
renegotiated.  Are you saying that the intention was to keep retrying
(either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
OpenSSL ≥0.9.6) until application data is received or a fatal error is
encountered?
 
> Do you know a relevant module or actually used application which has
> problems because of the default mode of SSL_MODE_AUTO_RETRY the ability to
> change it would fix the related problems and not introduce new ones, i.e.
> where such a fix would be the right thing to do?

Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
particular, a quick codesearch returns a few prominent programs that
reverted the new OpenSSL default.

  Apache2's mod_ssl:
Bug:https://github.com/openssl/openssl/issues/7178
Commit: 
https://github.com/apache/httpd/commit/6ee9d597e01281f2ef2e146586129af6aed7854d#diff-b70bd458eb699e70c322ee797a3e0991

  Neon:
File:   
http://svn.webdav.org/repos/projects/neon/tags/0.30.2/src/ne_socket.c
Change: 
http://lists.manyfish.co.uk/pipermail/neon-commits/2018-September/001077.html
  
  YottaDB
Bug: 
https://github.com/YottaDB/YDB/commit/1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87

> Another option might be to have an option SSL_mode_auto_retry which by
> default is not set but might be set to either 0 or 1 to get a consistent
> behavior across different OpenSSL versions.

I quite like this approach :-)

Anyway this bug can probably be closed now, maybe we should follow up
elsewhere.  Thanks for the discussion & analysis!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> Additionally switching off SSL_MODE_AUTO_RETRY would actually just add
> a different unexpected behavior: that sysread might return with EAGAIN
> on a blocking socket.

FWIW as shown below that's always been the case, until OpenSSL 1.1.1a
where SSL_MODE_AUTO_RETRY was switched on by default, so I'd say it's
wrong to expect that it won't :-P  Also I'm not arguing that the default
should be toggled back in IO::Socket::SSL, but that it should have a
flag to optionally revert to the old OpenSSL default.

Please consider the following code, which uses blocking I/O and merely
echoes what's being received from the SSL/TLS server.

perl -I. -MIO::Socket::SSL -e '
my $sock = IO::Socket::SSL->new(
PeerAddr => "127.0.0.1:4433",
SSL_ca_file => "/tmp/cert.pem"
) // die;
while(1) {
my $buf = "";
$sock->sysread($buf, 4096) //
die "errno=\"$!\", SSL_ERROR=\"$SSL_ERROR\"\n";
print $buf;
}'

Running in a Stretch chroot (libssl1.1 1.1.0j-1~deb9u1, libnet-ssleay-perl
1.80-1, and IO::Socket::SSL upstream 2.066), it dies with the following
message when the server renegotiates the TLSv1.2 session (“r\n” command
in the `s_server` input):

errno="Resource temporarily unavailable", SSL_ERROR="SSL wants a read first"

That's expected because SSL_read() fails and SSL_get_error() returns
SSL_ERROR_WANT_READ.  That code is broken as it doesn't inspect
$SSL_ERROR on sysread failure, and treats retryable errors as fatal.
With TLSv1.3 (but ensuring SSL_MODE_AUTO_RETRY is still unset) it's way
worse because it dies immediately after the handshake, not “just” when
the session is renegotiated.  In that light it makes sense that the
OpenSSL developers have switched SSL_MODE_AUTO_RETRY on by default.

Now with an OpenSSL version where SSL_MODE_AUTO_RETRY is set by default,
SSL_read() automatically retries and blocks until application data is
received, so the above program keeps looping as expected.  Automatic
retrying in lower-level functions is a fine default, but unfortunately
breaks applications that *were* relying on SSL_read() *not* blocking
when only non-application data was received.  That's why there needs to
be a way to optionally switch it back off.  Changing these programs to
use non-blocking I/O is clearly much more invasive.

> I've added more information regarding this to the IO::Socket::SSL
> documentation:
> https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

| A sysread on the IO::Socket::SSL socket will not return any data
| though since it is an abstraction which only returns application data.
| This causes the sysread to hang in case the socket was blocking

As shown above this is incorrect for OpenSSL <1.1.1a's (or any later
OpenSSL version where SSL_MODE_AUTO_RETRY was switched off).  There
IO::Socket::SSL::sysread() doesn't hang, but instead fails immediately
and sets $SSL_ERROR to SSL_ERROR_WANT_READ (and $! to EAGAIN).  While
setting errno to EAGAIN is specific to IO::Socket::SSL (and AFAICT
undocumented for blocking I/O), the manpage for SSL_read() and its higher
level bindings & wrappers, incl. IO::Socket::SSL, explicitly says that
upon failure one should first check SSL_get_error() for SSL-specific
errors, i.e., not rely on the errno value unless the SSL error code is
SSL_ERROR_SYSCALL.  That also applies to blocking I/O.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> Applications which relied on blocking I/O in connection with select could
> also hang before,

Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
default flags?  libssl mentions no such thing beside the new default
mode.  And in fact the s_client() program, *from OpenSSL upstream
itself*, does precisely that: a select loop in blocking I/O mode (unless
the ‘-nbio’ flag is set).

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1/apps/s_client.c#L2817

s_client() is roughly speaking a C version the ‘netcat.pl’ prototype I
attached earlier.  Unsurprisingly, since 1.1.1a the code clears
SSL_MODE_AUTO_RETRY from the bitmask mode of the newly created SSL_CTX
object.  That change was even done in the very same commit that enabled
SSL_MODE_AUTO_RETRY by default :-)


https://github.com/openssl/openssl/commit/693cf80c6ff54ae276a44d305d4ad07168ec6895#diff-7f3b79983f6d53c047c90a62813cc11f

IMHO using polling sockets in blocking I/O is fairly common.  Granted,
that itself itself doesn't say much about code quality, but the fact that
the OpenSSL project *does* use it (and explicitly mentions it in the
docs) gives me confidence that it's a fine use which should still be
supported.

> only this problem is worse now. Before TLS 1.3 these applications
> could hang if the peer initiated a renegotiation since this were TCP
> level data without any SSL application payload, i.e. select was
> triggered but sysread would not return with data.

I feel that we're talking past each other :-/  select() being triggered
means indeed that a subsequent read() system call *won't block*;
however read() is not called directly, but through SSL_read().  Whether
SSL_read() will block until application data is received, or not, is
controlled with the SSL_MODE_AUTO_RETRY flag.  If that flag is unset,
then SSL_read() returns immediately with failure and sets SSL_ERROR.
For an IO::Socket::SSL object, $sock->sysread() is AFAICT a mere wrapper
for SSL_read():


https://github.com/noxxi/p5-io-socket-ssl/blob/2.066/lib/IO/Socket/SSL.pm#L1187

So if select() is triggered because the TLS session is renegotiated, but
no application data was received, sysread will block iff. SSL_MODE_AUTO_RETRY
is set.  As I showed in the traces enclosed in my previous message.

> Additionally switching off SSL_MODE_AUTO_RETRY would actually just add a
> different unexpected behavior: that sysread might return with EAGAIN on a
> blocking socket. This is not the behavior one expects from a blocking
> socket, i.e. it should block until it returns data, should return no data
> only on connection shutdown or should fail permanently.

The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
SSL socket has a different behavior than usual read(2) system calls, in
that read failures should be treated with care, as there are both
retryable (eg. when no application data was received) and non-retryable
errors.

So from my perspective, the expectation that IO::Socket::SSL::sysread()
behaves like a “normal” sysread doesn't hold, and never did.  (There is
even an entry for “Expecting exactly the same behavior as plain
sockets” in the “Common errors” section of IO::Socket::SSL's manpage!)
For what it's worth I think it's a shame that SSL_MODE_AUTO_RETRY was
not the default earlier, as it's convenient to be able to write

$sock->sysread($buf, $len) // die;

and not bother about inspecting $SSL_ERROR.  But programs have been
written with the old default in mind, and the fact that SSL_read()
doesn't behave like a normal read() system call.  For these programs to
keep working, there needs to be a way to switch SSL_MODE_AUTO_RETRY off.
libssl provides SSL_CTX_clear_mode(), Net::SSLeay has
CTX_ctrl(,78,SSL_CTRL_CLEAR_MODE,0), and I'd like to have something
similar in IO::Socket::SSL, too.

> It was just a coincidence that LWP::protocol::http could deal with
> this situation. And this coincidence came from the fact, that this
> code was actually designed for non-blocking sockets and only the
> Debian patch caused it to use a blocking socket instead.

Yup, I now agree with you as far as LWP is concerned.
 
> I've added more information regarding this to the IO::Socket::SSL
> documentation:
> https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

| A sysread on the IO::Socket::SSL socket will not return any data
| though since it is an abstraction which only returns application data.
| This causes the sysread to hang in case the socket was blocking

I believe that statement is incorrect for OpenSSL <1.1.1a's (or if
SSL_MODE_AUTO_RETRY was toggled via some other means).  If you try
netcat.pl with an older OpenSSL release, you won't be able to reproduce
the TLSv1.2 trace I pasted yesterday; the client doesn't end up stuck in
a blocking read :-)  If no application data is 

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

Thanks for your analysis, Steffen.  Dropping the Debian-specific patch
is definitely the way to go for libwww/LWP.  However I still believe
IO::Socket::SSL should provide a way to clear SSL_MODE_AUTO_RETRY in
order to fix applications relying on the former OpenSSL defaults, as
suggested in the OpenSSL changelog:

“SSL_MODE_AUTO_RETRY is enabled by default. Applications that use
blocking I/O in combination with something like select() or poll()
will hang. This can be turned off again using SSL_CTX_clear_mode().”

Otherwise the “usual” way to write event loops in blocking I/O won't be
possible with IO::Socket::SSL.

On Sat, 11 May 2019 at 21:56:01 +0200, Steffen Ullrich wrote:
> As far as I can see it has nothing to do with SSL_MODE_AUTO_RETRY but
> instead is caused by expectations on the behavior of select which are
> wrong with TLS 1.3.

Please consider the enclosed netcat-like program.  I don't think I'm
relying on any particular behavior of a specific TLS version, and
follow the practices for polling blocking sockets, as documented in
libssl, Net::SSLeay, and IO::Socket::SSL, namely:

  - If SSL_pending() > 0, skip the (blocking) select() call and instead
call SSL_read() to process remaining bytes in the current SSL frame.
  - If SSL_read() fails and sets SSL_ERROR_WANT_READ, don't treat it as
a read error.

The last point however relies on SSL_MODE_AUTO_RETRY being *unset*, like
it used to be with OpenSSL <1.1.1a.  With SSL_MODE_AUTO_RETRY being set,
the program doesn't work properly.  (*Not only for TLSv1.3, but also for
TLSv1.2*).  This is expected with the new default:

“If the underlying BIO is blocking, a read function will only return
once the read operation has been finished or an error occurred,
except when a non-application data record has been processed and
SSL_MODE_AUTO_RETRY is not set. Note that if SSL_MODE_AUTO_RETRY is
set and only non-application data is available the call will hang.”
— https://www.openssl.org/docs/manmaster/man3/SSL_read.html

As seen below, this also breaks with ≤TLSv1.2; but only when the TLS
session is renegotiated, not during the initial handshake.

Generate a self-signed certificate:

$ openssl req -x509 -keyout /tmp/key.pem -out /tmp/cert.pem -subj 
/CN=127.0.0.1 -nodes

Start a TLSv1.2 server on [127.0.0.1]:4433:

$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert 
/tmp/cert.pem -tls1_2

Now start the enclosed program in another terminal.  What's being
written in the s_server(1ssl) TTY is echoed on the netcat.pl side, and
vice versa.  All good.  Now trigger renegotiate the TLS session by
pressing ‘r\n’.  The server prints

SSL_do_handshake -> 1
Read BLOCK

and netcat ends up being stuck in a blocking read().  So what's being
written client-side won't show up anymore in the server window, until
data is being sent from the server to the client and makes read()
return.

openssl s_server … -tls1_2  netcat.pl
--- -
S: Using default temp DH parameters  
S: ACCEPT 
S: -BEGIN SSL SESSION PARAMETERS-
S: […]
S: ---
S: No server certificate CA names sent
S: CIPHER is ECDHE-RSA-AES128-GCM-SHA256
S: Secure Renegotiation IS supported
S: Entering loop...
C: can you hear me now?
S: can you hear me now?
C: yes
S: yes 
C: good
S: good
C: starving you now
S: starving you now
C: r
S: SSL_do_handshake -> 1
S: Read BLOCK
C: meh, I'm muted
C: unstarving
S: meh, I'm muted
S: unstarving

(The ‘C: ’ prefix indicates a line written to the standard input, and
the ‘S: ’ prefix a line written to the standard output or error output.)

After renegotiation, the client is stuck in a blocking read() until the
server sends some data.  Same thing with TLSv1.3, but of course without
the renegotiation part: this happens right at the begining.

openssl s_server … -tls1_3  netcat.pl
--- -
S: Using default temp DH parameters  
S: ACCEPT 
S: -BEGIN SSL SESSION PARAMETERS-
S: […]
S: ---
S: No server certificate CA names sent
S: CIPHER is TLS_AES_256_GCM_SHA384
S: Secure Renegotiation IS supported
S: Entering loop...
C: can you hear me now?
C: I guess no...
C: unstarving
S: can you hear me now?
S: I guess no...
 

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

Hi Dimitri,

On Tue, 07 May 2019 at 15:46:25 +0100, Dimitri John Ledkov wrote:
> On Tue, 7 May 2019 14:16:43 +0100 Dimitri John Ledkov  wrote:
>> This issue concerns me a lot at the moment. I am currently trying to
>> upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And
>> as far as I understand all the comment on this debian bug report,
>> current application are potentially broken and brokeness happens more
>> often with TLSv1.3 and the new OpenSSL 1.1.1 defaults
>> (SSL_MODE_AUTO_RETRY).
>>
>> As far as I understand we do not have a fixed LWP that works correctly
>> in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing
>> existing users further, does it make sense for me to make updates in
>> bionic that:
>>
>> 1) limit SSL_new and SSL_CTX_new to TLS v1.2 max
>> and
>> 2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections?
>>
>> My goal is to keep existing breakages as is, without introducing new
>> ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not
>> get TLS v1.3 enabled for perl server/clients without code changes, but
>> oh well. Those who want it, will be able to force / start using it.

It's IMHO unfortunate to change the default in Net::SSLeay, as TLSv1.3
brings quite a few improvements (in terms of security as well as
performance).  OpenSSL 1.1.1 was released on 11 Sep 2018 and uploaded to
sid the day after, breaking programs using select()/poll() with blocking
I/O; this is not specific to Perl bindings — other languages are also
affected — yet no one is suggesting to disable TLSv1.3 globally in
libssl :-)

If TLSv1.3 should be disabled (and the SSL_MODE_AUTO_RETRY flag cleared)
then IMHO I think it should be done as close at possible to the leaf
application (LWP in this case), not in the library itself.  After all we
have only one RC bug about this, so I guess other programs (in any
language) 1/ have workarounds; 2/ aren't using select()/poll() with
blocking I/O; or 3/ aren't affected because they never used SSL_read()
as documented.  IHMO the libssl change shouldn't be reason to penalize
all applications, given most seems unaffected.

I still think the right fix is to make SSL_MODE_AUTO_RETRY (or even the
whole mode bitmask mode?) configurable in IO::Socket::SSL, and clear it
in programs and libraries using select()/poll() with blocking I/O, such
as LWP in this case.  AFAICT that follows the intention of OpenSSL's
development team, unlike global library changes.  AFAICT the attached
patch (to sid's IO::Socket::SSL and LWP::Protocol::https, respectively
2.060-3 and 6.36-1) fixes the problem for me, while preserving TLSv1.3
support and default.
 
> I proposed the following patch upstream / request for comments
> https://github.com/radiator-software/p5-net-ssleay/pull/139

I personally don't like this change as I hope Buster's Net::SSLeay and
other SSL libraries will default to TLSv1.3 on capable servers :-)  2
comments anyway:

  * OpenSSL <1.1.0 has no SSL_CTX_set_max_proto_version(), so an OpenSSL
version test is lacking (nothing more as <1.1.0 has no TLSv1.3
support and SSL_MODE_AUTO_RETRY is unset by default).
 
  * Disabling TLSv1.3 won't always prevent hangs, you also need to clear
SSL_MODE_AUTO_RETRY to revert to the pre-1.1.1 defaults.  With
TLSv1.2, SSL_read() returns SSL_ERROR_WANT_READ upon renegotiation,
causing applications using select()/poll() with blocking I/O to hang
if SSL_MODE_AUTO_RETRY is set.

Cheers,
-- 
Guilhem, who isn't not in the Debian Perl team, but who would be quite
sad to have to wait one full release cycle for out-of-the-box TLSv1.3
support.
--- a/IO/Socket/SSL.pm
+++ b/IO/Socket/SSL.pm
@@ -260,6 +260,14 @@
 	INIT { init() }
 	init();
 }
+
+if (!defined ::SSLeay::CTX_clear_mode) {
+	# assume SSL_CTRL_CLEAR_MODE being 78 since it was always this way
+	*Net::SSLeay::CTX_clear_mode = sub {
+	my ($ctx,$opt) = @_;
+	Net::SSLeay::CTX_ctrl($ctx,78,$opt,0);
+	};
+}
 }
 
 # global defaults which can be changed using set_defaults
@@ -2433,6 +2441,11 @@
 	# cannot guarantee, that the location of the buffer stays constant
 	Net::SSLeay::CTX_set_mode( $ctx,
 	SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER|SSL_MODE_ENABLE_PARTIAL_WRITE);
+	# Clear SSL_MODE_AUTO_RETRY on request; useful for applications using select/poll
+	# with blocking I/O. (Since OpenSSL 1.1.1 SSL_MODE_AUTO_RETRY is enabled by
+	# default, making such applications hang.)
+	Net::SSLeay::CTX_clear_mode( $ctx, Net::SSLeay::MODE_AUTO_RETRY() )
+		if $arg_hash->{SSL_mode_auto_no_retry};
 
 	if ( my $proto_list = $arg_hash->{SSL_npn_protocols} ) {
 	return IO::Socket::SSL->_internal_error("NPN not supported in Net::SSLeay",9)
--- a/LWP/Protocol/https.pm
+++ b/LWP/Protocol/https.pm
@@ -32,6 +32,11 @@
 $ssl_opts{SSL_ca_file} = '/etc/ssl/certs/ca-certificates.crt';
 	}
 }
+# Clear SSL_MODE_AUTO_RETRY as LWP uses select with blocking I/O.
+# (Since OpenSSL 1.1.1 SSL_MODE_AUTO_RETRY is enabled 

Bug#927165: debian-installer: improve support for LUKS

[Guilhem Moulin]

Hi kibi,

On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote:
> I'm also immensely grateful for all the security-related work Matthew
> Garrett puts everywhere he goes, but I'm not sure that MR qualifies as
> “requested by d-i [0]” as you mentioned in [2].

Just to state that publicly: now that you point that out, I agree with
you and I'm unsure how I convinced myself otherwise through 2018.  The
only other related message I found is your ack of the libcryptsetup
transition [0], which doesn't count either.  I might have wrongly
assumed that someone involved in the early discussion was a member of
d-i, I dunno.  Anyway in this new light the communication was indeed on
the weak side from our (cryptsetup packaging team) side, apologies for
the late rush and extra work.

Cheers,
-- 
Guilhem.

[0] https://lists.debian.org/debian-boot/2017/12/msg00231.html


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 09 Apr 2019 at 23:39:31 +0200, Guilhem Moulin wrote:
> AFAICT this worked this time because the socket was *only* marked as
> ready for writing after the first select() call.  Only during the second
> call was there some data to be read:
> 
>> select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 1 (out [3], left 
>> {tv_sec=179, tv_usec=96})
>> select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
>> {tv_sec=179, tv_usec=977469})
> 
> I'm unable to reproduce this with v1.3, probably due to race conditions.

Forgot to add this, sorry: perhaps the reproducibility of this issue is
improved when one connects to the loopback interface rather than to a
remote TLS termination proxy?  (Even though I suppose it doesn't
completely eliminate the race.)

In a clean sid chroot, after `apt install --no-install-recommends strace
liblwp-protocol-https-perl libio-socket-ssl-perl libnet-ssleay-perl`:

## Start a loopback-bound TLS (v1.3 only) server in a terminal
$ openssl req -x509 -keyout /tmp/key.pem -out /tmp/cert.pem -subj 
/CN=127.0.0.1 -nodes
$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert 
/tmp/cert.pem -tls1_3

## Connect to it from another terminal and send an HTTP POST request
$ patch -p2 
new(ssl_opts => {SSL_ca_file => "/tmp/cert.pem"})->
post("https://127.0.0.1:4433;, {data => "foo"})'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 234)   = 234
read(3, "…", 5) = 5
read(3, "…", 250)   = 250
read(3,

This does hang *anyway* but it should hang *after* sending the request
out to the server (ie when waiting for the HTTP reply), not *before* any
application data was sent, unlike the above.  AFAICT the local server
never receives “POST / HTTP/1.1\r\n” when select(2) marks the socket as
ready both for reads and writes client-side, whether the patch is
applied or not.

Not setting the SSL_MODE_AUTO_RETRY flag back after removing O_NONBLOCK
(ie commenting out `Net::SSLeay::set_mode($ssl, $mode_auto_retry);` in
the patch) solves the problem with blocking I/O and select/poll, but
breaks programs expecting SSL_read() to block until application data
comes in.  (That is, programs not conforming to SSL_read()'s documented
behavior — hence which would break on renegotiation with TLS <1.3; or
programs relying on SSL_MODE_AUTO_RETRY being set, as in OpenSSL ≥1.1.1's
default context flags.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 09 Apr 2019 at 17:26:22 +0200, gregor herrmann wrote:
> On Tue, 09 Apr 2019 17:14:32 +0200, Guilhem Moulin wrote:
>> With TLS 1.3?  (You can pass ‘SSL_version => "TLSv1_3"’ to ssl_opts to
>> force this.)  Doesn't work here, still hangs on read():
> 
> Yes, also with using TLSv1_3 explicitly:
> […]
> (trace attached in case it helps)

AFAICT this worked this time because the socket was *only* marked as
ready for writing after the first select() call.  Only during the second
call was there some data to be read:

> select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 1 (out [3], left 
> {tv_sec=179, tv_usec=96})
> select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
> {tv_sec=179, tv_usec=977469})

I'm unable to reproduce this with v1.3, probably due to race conditions.
Anyway I fail to see how the patch can help, because as I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#101 the socket
is in blocking mode (hence SSL_MODE_AUTO_RETRY is set) by the time LWP
starts its select loop, and SSL_MODE_AUTO_RETRY is set.  This is visible
by adding fcntl(2) to the traced set of system calls:

$ strace -etrace=fcntl,select,read perl -MLWP::UserAgent -MIO::Socket::SSL 
-e \
'$IO::Socket::SSL::DEBUG = 3;
 LWP::UserAgent->new(ssl_opts => {SSL_version => 
"TLSv1_3"})->post("https://facebook.com;, { data => "" })'
[…]
fcntl(3, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce 
timeout=180
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
read(3, 0x5628bec16923, 5)  = -1 EAGAIN (Resource temporarily 
unavailable)
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:857: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:867: waiting for fd to become ready: SSL wants 
a read first
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
{tv_sec=179, tv_usec=988296})
DEBUG: .../IO/Socket/SSL.pm:887: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:844: call Net::SSLeay::connect
[…]
DEBUG: .../IO/Socket/SSL.pm:847: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:902: ssl handshake done
fcntl(3, F_GETFL)   = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDWR)   = 0
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5)   = 5
read(3, "…", 156) = 156
read(3,

When the non-application record comes in, the socket is marked as ready
for reading, but SSL_read() transparently processes the non-application
data record, and blocks on trying to read an application data record.

If one is lucky and the socket is *only* marked as ready for writing (ie
not for reading as well, like in your trace) when select() returns then
the problem doesn't trigger (at least not right after the handshake —
OTOH it might occur later on renegotiation), but AFAICT it's orthogonal
to whether the patch is applied or not: we use blocking I/O, so
SSL_MODE_AUTO_RETRY is set just like before (`Net::SSLeay::set_mode($ssl,
$mode_auto_retry)` is called just before clearing O_NONBLOCK).

If the (blocking) socket is marked for reading when select() returns,
then the application assumes that SSL_read() won't block, and setting
SSL_MODE_AUTO_RETRY breaks that assumption, as written in the OpenSSL
changelog.  Instead of a blocking SSL_read() the application expects it
to return SSL_ERROR_WANT_READ.  And proceeds with SSL_write() if the
socket is also ready for writing, like in the trace above.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 09 Apr 2019 at 16:59:20 +0200, gregor herrmann wrote:
> When I install the package with the patch and run our test case
> again, I don't get any hangs anymore:
> 
> % time perl -MLWP::UserAgent -e 
> 'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
> perl -MLWP::UserAgent -e   0.18s user 0.02s system 22% cpu 0.867 total 

With TLS 1.3?  (You can pass ‘SSL_version => "TLSv1_3"’ to ssl_opts to
force this.)  Doesn't work here, still hangs on read():

$ strace -etrace=select,read perl -MLWP::UserAgent -e 'LWP::UserAgent->new( 
ssl_opts =>
{SSL_version => "TLSv1_3"})->post("https://facebook.com;, { data => "foo" 
})'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left 
{tv_sec=179, tv_usec=98})
read(3, "…", 5)  = 5
read(3, "…" 156) = 156
read(3,

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#101 and the
OpenSSL changelog: “Applications that use blocking I/O in combination
with something like select() or poll() will hang”

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Tue, 09 Apr 2019 at 07:48:45 +0200, Steffen Ullrich wrote:
> Simply clearing SSL_MODE_AUTO_RETRY will cause problems with blocking
> connections in TLS 1.3.

AFAICT not when SSL_read() is used as documented.  Also while the issue is
triggered more often for TLS 1.3 than for earlier TLS protocol versions, it's
not specific to TLS 1.3:

“TLSv1.3 sends more non-application data records after the handshake is
finished. At least the session ticket and possibly a key update is send
after the finished message. With TLSv1.2 it happened in case of
renegotiation. SSL_read() has always documented that it can return
SSL_ERROR_WANT_READ after processing non-application data, even when there
is still data that can be read. When SSL_MODE_AUTO_RETRY is set using
SSL_CTX_set_mode() OpenSSL will try to process the next record, and so not
return SSL_ERROR_WANT_READ while it still has data available. Because many
applications did not handle this properly, SSL_MODE_AUTO_RETRY has been
made the default.  If the application is using blocking sockets and
SSL_MODE_AUTO_RETRY is enabled, and select() is used to check if a socket
is readable this results in SSL_read() processing the non-application data
records, but then try to read an application data record which might not
be available and hang.”
— https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records

FWIW OpenSSL 1.1.1a's changelog does mention that the new default causes
regressions:

“SSL_MODE_AUTO_RETRY is enabled by default. Applications that use blocking
I/O in combination with something like select() or poll() will hang. This
can be turned off again using SSL_CTX_clear_mode().  Many applications do
not properly handle non-application data records, and TLS 1.3 sends more
of such records. Setting SSL_MODE_AUTO_RETRY works around the problems in
those applications, but can also break some.  It's recommended to read the
manpages about SSL_read(), SSL_write(), SSL_get_error(), SSL_shutdown(),
SSL_CTX_set_mode() and SSL_CTX_set_read_ahead() again.”
— https://github.com/openssl/openssl/blob/OpenSSL_1_1_1a/CHANGES#L153

Programs that *were* broken (would have choked on renegotation with TLS <1.3,
or on key update / session ticket with TLS 1.3) might work better now, but
it's *really* unfortunate that programs like LWP::Protocol::http, with a
properly written select(2) loop (ie able to work around 
SSL_ERROR_WANT_{READ,WRITE}),
are now broken.

> Please check if
> https://github.com/noxxi/p5-io-socket-ssl/commit/09bc6a3203bc7bc89078317da42a3e96cdbf94fc
> fixes the problems you see.

It doesn't, as the socket is in blocking mode when it enters the select loop.
As the OpenSSL's changelog puts it, “Applications that use blocking I/O in
combination with something like select() or poll() will hang”.

I guess a better fix is to not to change the OpenSSL default in IO::Socket::SSL
but make it configurable with a new option ‘SSL_auto_retry’; and set that
option to 0 in applications with select loops.  AFAICT the alternative would
be to refactor all these loops, so clearly a much bigger task.  This is not
specific to IO::Socket::SSL, also.  Any program with such select/poll loops,
written in any language, needs either refactoring or SSL_MODE_AUTO_RETRY be
cleared.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#926689: [pkg-cryptsetup-devel] Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing

[Guilhem Moulin]

Control: reassign -1 grub2-common
Control: merge-1 924151

Hi,

On Mon, 08 Apr 2019 at 20:19:47 -0400, Gabriel Filion wrote:
> Package: cryptsetup
> Version: 2:2.1.0-2
> […]
> I found out that some configuration lines are missing in all options that get
> generated inside grub.cfg.
> 
> Here's a diff between the grub configuration that was generated while in 
> rescue
> mode (in a chroot inside the device that gets used for / ) vs. generated while
> the system is running:
> 
> -8<8<8<---
> $ diff -burN ~/grub.cfg /boot/grub/grub.cfg
> --- /home/gabster/grub.cfg2019-04-08 19:20:24.000726392 -0400
> +++ /boot/grub/grub.cfg   2019-04-08 19:37:00.360714287 -0400

/boot/grub/grub.cfg is not generated by src:cryptsetup.  Reassigning
accordingly, and merging with #924151.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Sun, 07 Apr 2019 at 20:56:41 +0200, gregor herrmann wrote:
> Alright, after purging libssl1.0.2 (and the outdated packages which
> depended on it *cough*) I get the hang as well:
> […]
> Thanks for the push in the right direction!

You're welcome :-)  Does clearing the SSL_MODE_AUTO_RETRY context flag
(i.e., reverting the default from OpenSSL <1.1.1) solves this for you
too?  If so, what do you think about my proposed paths forwards from

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#71

If there is consensus that libssl's SSL_CTRL_CLEAR_MODE and/or
SSL_CTX_clear_mode should be exposed to Net::SSLeay I'd be happy to
propose a patch there.  That leaves the question about which defaults
context flags should IO::Socket::SSL (or LWP) have, though.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Sun, 07 Apr 2019 at 18:12:45 +0200, gregor herrmann wrote:
> On Sun, 18 Nov 2018 19:41:05 +0200, Niko Tyni wrote:
> 
>> Reiterating a bit: the underlying issue with TLSv1.3 seems to be related
>> to handling of 'non-application_data_records'.
>> 
>> The client tries to POST but gets an 'SSL wants a read first' error,
>> then waits until timeout for the socket to become writable.
>> 
>> A simple way to reproduce it here is
>> 
>> perl -MLWP::UserAgent -e 'LWP::UserAgent->new->post("https://facebook.com;, 
>> { data => "foo" }) or die'
>> 
>> which deadlocks for me.
> 
> I can't reproduce this problem:

Interesting, are you talking TLS 1.3?

$ dpkg-query -l "libssl*" "libnet-ssleay-perl" "liblwp-protocol-https-perl" 
"libio-socket-ssl-perl"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  libio-socket-ssl-perl  2.060-3  all  Perl module 
implementing object oriented interface to SSL sockets
ii  liblwp-protocol-https-perl 6.07-2   all  HTTPS driver for 
LWP::UserAgent
ii  libnet-ssleay-perl 1.85-2+b1amd64Perl module for Secure 
Sockets Layer (SSL)
ii  libssl-dev:amd64   1.1.1b-1 amd64Secure Sockets Layer 
toolkit - development files
un  libssl-doc   (no description 
available)
un  libssl0.9.8  (no description 
available)
un  libssl1.0-dev(no description 
available)
ii  libssl1.1:amd641.1.1b-1 amd64Secure Sockets Layer 
toolkit - shared libraries

$ openssl req -x509 -newkey rsa:4096 -keyout /tmp/key.pem -out /tmp/cert.pem 
-subj /CN=example.net -nodes
$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert /tmp/cert.pem 
-tls1_3
[…]

Then on a separate terminal, with SSL_MODE_AUTO_RETRY set (the default),
it blocks on read(2):

$ strace -eselect,read,write perl -MLWP::UserAgent -e 
'LWP::UserAgent->new(ssl_opts =>
{verify_hostname => 0, SSL_ca_file => 
"/tmp/cert.pem"})->post("https://127.0.0.1:4433;, { data => "foo" })'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left 
{tv_sec=179, tv_usec=98})
read(3, "…", 5)   = 5
read(3, "…", 250) = 250
read(3, "…", 5)   = 5
read(3, "…", 250) = 250
read(3,

With SSL_MODE_AUTO_RETRY cleared, the handshake terminates and it waits
for the reply from the server:

$ strace -eselect,read,write perl -MLWP::UserAgent -e 
'LWP::UserAgent->new(ssl_opts =>
{verify_hostname => 0, SSL_ca_file => 
"/tmp/cert.pem"})->post("https://127.0.0.1:4433;, { data => "foo" })'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left 
{tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 250) = 250
write(3, "…", 216) = 216
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
{tv_sec=179, tv_usec=99})
read(3, "…", 5) = 5
read(3, "…", 250) = 250
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}

(and the connection closes gracefuly when I write “HTTP/1.1
200\r\nContent-Length: 0\r\n\r\n” from the server)

> % time perl -MLWP::UserAgent -e 
> 'LWP::UserAgent->new->post("https://twitter.com;, { data => "foo" }) or die'
> perl -MLWP::UserAgent -e   0.13s user 0.02s system 36% cpu 0.415 total

twitter.com doesn't support TLS 1.3 though, right?

$ openssl s_client -4 -connect twitter.com:443 -servername twitter.com -tls1_3
CONNECTED(0003)
139682444989504:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:../ssl/record/rec_layer_s3.c:1536:SSL alert number 40

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914034: bug in Net::SSLeay?

[Guilhem Moulin]

Control: usertag -1 bsp-2019-04-se-gothenburg

Hi there,

strace(1) shows a select(2) syscall indicating that the socket is ready for
both read and write, but is later blocking on a read(2) without any
write(2) taking place.

select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5)   = 5
read(3, "…", 156) = 156
read(3, 

Net::SSLeay warns:

If you need to select(2) on the socket, go right ahead, but be warned that
OpenSSL does some internal buffering so SSL_read does not always return
data even if the socket selected for reading (just keep on selecting and
trying to read). "Net::SSLeay" is no different from the C language OpenSSL
in this respect.

And indeed LWP::Protocol::http's use of select(2) on SSL sockets *does*
assume that read/write readiness won't block.  (If Net::SSLeay::read()
returns -1, then the loop will retry later with SSL_ERROR_WANT_READ/WRITE.)
However since OpenSSL 1.1.1 the SSL_MODE_AUTO_RETRY flag is on by
default, which breaks that assumption: ssl_read(3) might block, even
when select(2) claimed the socket had data to be read.

SSL_MODE_AUTO_RETRY

During normal operations, non-application data records might need to be
sent or received that the application is not aware of. If a
non-application data record was processed, SSL_read_ex(3) and SSL_read(3)
can return with a failure and indicate the need to retry with
SSL_ERROR_WANT_READ. If such a non-application data record was processed,
the flag SSL_MODE_AUTO_RETRY causes it to try to process the next record
instead of returning.

[…]

In a blocking environment, applications are not always prepared to deal
with the functions returning intermediate reports such as retry requests,
and setting the SSL_MODE_AUTO_RETRY flag will cause the functions to only
return after successfully processing an application data record or a
failure.

[…]

All modes are off by default except for SSL_MODE_AUTO_RETRY which is on by
default since 1.1.1.

— https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_mode.html

See also https://github.com/openssl/openssl/issues/6234 .

I see several paths forward here:

  - Refactor LWP::Protocol::http's select loop to solve the assumption
that's now broken with OpenSSL ≥1.1.1; or
  - Unset SSL_MODE_AUTO_RETRY in IO::Socket::SSL; or
  - Make context flags configurable in IO::Socket::SSL, and unset
SSL_MODE_AUTO_RETRY from LWP.

IMHO the first option is not ideal so late in the release cycle.  The
second option is the easiest to implement, and should™ be regression-free,
but might confuse people who became used to OpenSSL ≥1.1.1's new context
default flags.

SSL_CTX_clear_mode(3) and SSL_CTRL_CLEAR_MODE macros are unfortunately
not exposed to Net::SSLeay 1.85-2.  The proper fix would be to expose
these and release a new version of Net::SSLeay, of course, but for tests
the macros can be taken from /usr/include/openssl/ssl.h:

# define SSL_CTRL_CLEAR_MODE 78
[…]
# define SSL_CTX_clear_mode(ctx,op) \
SSL_CTX_ctrl((ctx),SSL_CTRL_CLEAR_MODE,(op),NULL)

and used as is in IO::Socket::SSL.pm.  With the following patch I'm
again able to POST to HTTPS servers using TLS 1.3.

--8<--->8--
--- a/IO/Socket/SSL.pm
+++ b/IO/Socket/SSL.pm
@@ -2433,6 +2433,7 @@
# cannot guarantee, that the location of the buffer stays constant
Net::SSLeay::CTX_set_mode( $ctx,
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER|SSL_MODE_ENABLE_PARTIAL_WRITE);
+   Net::SSLeay::CTX_ctrl($ctx, 78, Net::SSLeay::MODE_AUTO_RETRY(), undef);
 
if ( my $proto_list = $arg_hash->{SSL_npn_protocols} ) {
return IO::Socket::SSL->_internal_error("NPN not supported in 
Net::SSLeay",9)
--8<--->8--

(Again, I'm not proposing to patch IO::Socket::SSL as above :-)  With
MODE_AUTO_RETRY set — the default for OpenSSL ≥1.1.1 — one gets:

$ strace -e trace=read,write,select perl -MLWP::UserAgent -e 
'LWP::UserAgent->new(ssl_opts =>
{SSL_version => "TLSv1_3"})->post("https://facebook.com;, { data => 
"plonc" })';
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5)   = 5
read(3, "…", 156) = 156
read(3, 

And now with the MODE_AUTO_RETRY flag unset:

$ select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], 
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 156)   = 156
write(3, "…", 217)  = 217
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left 
{tv_sec=179, tv_usec=870931})
read(3, "…", 5) = 5
read(3, "…", 361)   = 361

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Guilhem Moulin]

On Mon, 06 Aug 2018 at 21:15:10 +0800, Ben Hutchings wrote:
> Sometimes driver modules have been reorganised and this has resulted
> in missing modules.  But this wouldn't explain other files being
> missing.

cryptsetup's initramfs boot scripts should be present either way, but
inclusion of the cryptsetup binaries (and crypto modules) depend on
whether the hook detected that some device has to be unlocked at
initramfs stage.  (Unless /etc/cryptsetup-initramfs/conf-hook contains
"CRYPTSETUP=y", which indeed forces initramfs integration.)

Dirk, which “cryptsetup related parts” are missing from the 4.17 bpo
initramfs with cryptsetup 2:1.7.3-4?  Does `update-initramfs -u` print
any warning about unknown module and/or root FS?  Can you confirm that
adding "CRYPTSETUP=y" to /etc/cryptsetup-initramfs/conf-hook (and
compiling your initramfs image with MODULES="most" — the default) fixes
the issue?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#905188: closing 905188

[Guilhem Moulin]

close 905188 2:2.0.4-1
thanks

Bug#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Guilhem Moulin]

Control: unmerge -1
Control: done -1 2:2.0.4-1

On Mon, 06 Aug 2018 at 04:19:15 +0200, Andreas Beckmann wrote:
> right now the package fails to install in sid.

This is not the same bug, though.  #905188 is about the upgrade path
from stretch, which works since 2:2.0.4-1.  The regression bug is
#905514.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Guilhem Moulin]

Control: tag   -1 pending
Control: found -1 2:2.0.3-1

On Wed, 01 Aug 2018 at 20:29:50 +0200, Andreas Beckmann wrote:
> On 2018-08-01 19:01, Guilhem Moulin wrote:
>> On Wed, 01 Aug 2018 at 13:20:37 +0200, Andreas Beckmann wrote:
>>> Configuration file '/etc/cryptsetup-initramfs/conf-hook'
>>> ==> Deleted (by you or by a script) since installation.
>>> ==> Package distributor has shipped an updated version.
>>> What would you like to do about it ?  Your options are:
>>> Y or I  : install the package maintainer's version
>>> N or O  : keep your currently-installed version
>>>  D : show the differences between the versions
>>>  Z : start a shell to examine the situation
>>> The default action is to keep your current version.
>>> *** conf-hook (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
>>> cryptsetup-initramfs (--configure):
>>> end of file on stdin at conffile prompt
>>> dpkg: dependency problems prevent configuration of cryptsetup:
>>> cryptsetup depends on cryptsetup-initramfs (>= 2:2.0.3-1); however:
>>> Package cryptsetup-initramfs is not configured yet.
>> 
>> I wonder if it's a false positive?  Following the same upgrade path in a
>
> No, already asking the question about the conffile that was *not*
> modified by the user is a policy violation.

I see, thanks for the pointers.  Fixed at
https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/b7abb5d06e46f3704c4edeb55d033b6283ae8777
 .

(Interesting, I seem to recall we threw piuparts at 2:2.0.3-1, but
possibly didn't test that same upgrade path.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#905188: [pkg-cryptsetup-devel] Bug#905188: cryptsetup-initramfs: fails to install, remove, distupgrade, and install again

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi Andreas,

On Wed, 01 Aug 2018 at 13:20:37 +0200, Andreas Beckmann wrote:
> Configuration file '/etc/cryptsetup-initramfs/conf-hook'
>  ==> Deleted (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** conf-hook (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
> cryptsetup-initramfs (--configure):
>  end of file on stdin at conffile prompt
> dpkg: dependency problems prevent configuration of cryptsetup:
>  cryptsetup depends on cryptsetup-initramfs (>= 2:2.0.3-1); however:
>   Package cryptsetup-initramfs is not configured yet.

I wonder if it's a false positive?  Following the same upgrade path in a
stretch chroot:

$ apt install cryptsetup
$ apt remove cryptsetup
$ sed -i s/stretch/buster/g /etc/apt/sources.list.d/debian.sources 
$ apt update
$ apt dist-upgrade
$ apt install cryptsetup

The log differs as follows:

Configuration file '/etc/cryptsetup-initramfs/conf-hook'
 ==> Deleted (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** conf-hook (Y/I/N/O/D/Z) [default=N] ? 
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
update-initramfs: deferring update (trigger activated)
Setting up cryptsetup (2:2.0.3-6) ...
Processing triggers for initramfs-tools (0.132) ...

And the upgrade path is successful.  AFICT piuparts's dpkg processes
fail because there is no working standard input.  But normal systems
have a working standard input, and the upgrade path is function there. 
AFAIK automatic configuration tools install with

DEBIAN_FRONTEND=noninteractive apt-get install -o 
"Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold" -y

which also works.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#904926: [pkg-cryptsetup-devel] Bug#904926: cryptroot-unlock: timeout waiting for askpass

[Guilhem Moulin]

On Mon, 30 Jul 2018 at 02:47:39 +0800, Guilhem Moulin wrote:
> On Sun, 29 Jul 2018 at 20:28:02 +0200, C. Dominik Bódi wrote:
>> Am Sonntag, 29. Juli 2018, 18:46:20 CEST schrieb Guilhem Moulin:
>>> readlink -f /lib/cryptsetup/askpass
>> readlink returns:
>> /lib/cryptsetup/askpass
> 
> Hmm.  In the initramfs too?  No need to reboot to the broken initrd to
> test it out, you can run
> 
>lsinitramfs /path/to/broken/initrd | grep cryptsetup

I think I know the answer to that actually, cf.
https://bugs.debian.org/874523 .  You wrote “after installing updates
today” and although you didn't specify which (package name &
before/after version) I guess you also upgraded ‘initramfs-tools-core’
to 0.132, so your initramfs image *is* using usrmerge.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#904926: cryptroot-unlock: timeout waiting for askpass

[Guilhem Moulin]

On Sun, 29 Jul 2018 at 20:28:02 +0200, C. Dominik Bódi wrote:
> Am Sonntag, 29. Juli 2018, 18:46:20 CEST schrieb Guilhem Moulin:
>> readlink -f /lib/cryptsetup/askpass
> readlink returns:
> /lib/cryptsetup/askpass

Hmm.  In the initramfs too?  No need to reboot to the broken initrd to
test it out, you can run

lsinitramfs /path/to/broken/initrd | grep cryptsetup

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#904926: cryptroot-unlock: timeout waiting for askpass

[Guilhem Moulin]

Do you have a usrmerge setup?  What does `readlink -f /lib/cryptsetup/askpass` 
return?

I noticed a problem with usrmerge setups earlier today.  The following
commit fixes the issue AFAICT:
https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/f1c56c19fea6dc988c1f29fb8a510c05286c2900

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#904899: mandos: initramfs boot script assumes internal cryptsetup implementation details and is now broken

[Guilhem Moulin]

Source: mandos
Version: 1.7.19-1
Severity: serious

Hi,

mandos' initramfs boot script reads and parses /conf/conf.d/cryptroot.
Since cryptsetup 2:2.0.3-2 this file no longer exists; we cryptsetup
package maintainers replaced and it changed its format (without notice
as it was undocumented and thus internal to src:cryptsetup).

Packages outside of src:cryptsetup must stick to the documented
interface; and in use cases where it's not enough, ask us to extend it
rather than using internal details that are subject to change without
notice.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#902972: libargon2-0 install a symlink pointin to libargon2.so.1

[Guilhem Moulin]

Hi,

Could you please upload src:argon2 without the compatibility package?
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

This RC bug prevents packages depending on libargon2-*, such as
cryptsetup, from migrating to testing.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903246: [pkg-cryptsetup-devel] Bug#903246:

[Guilhem Moulin]

Control: retitle -1 crypttab source specifications shouldn't be converted to 
/dev/block/$maj:$min
Control: severity -1 important
Control: tag -1 pending

On Sun, 08 Jul 2018 at 18:53:07 +1000, Ian Tester wrote:
> Upon further exploration, it appears the problem is that /dev/block is not
> being created and populated on this system. I'll have to figure out why
> that is. This report may be closed or at least knocked down in severity.

With a running udev daemon `udevadm trigger --type=devices --action=add`
creates and populates that directory.  This is done at early boot stage
and I'm not able to create a bootable environment where this is not the
case, so I'm lowering the severity to non-RC.

That being said there is no reason to convert the crypttab source
specifications to /dev/block/$maj:$min.  (We do want to do the
conversion when traversing the sysfs hierarchy, but for the crypttab
it's unnecessary.)  This commit should do it:


https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/0d03f850113b3e5bd0d8211f0bc0161455e09368

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903246: [pkg-cryptsetup-devel] Bug#903246:

[Guilhem Moulin]

Control: tag -1 moreinfo

On Sun, 08 Jul 2018 at 18:53:07 +1000, Ian Tester wrote:
> Upon further exploration, it appears the problem is that /dev/block is not
> being created and populated on this system. I'll have to figure out why
> that is.

Do you have udev installed and running?  It should take care of creating
/dev/block/$major:$minor, cf.

https://sources.debian.org/src/systemd/239-5/src/udev/udev-node.c/#L337

That being said, ‘cryptsetup-run’ is missing a dependency on the ‘udev’
package.  (OTOH ‘cryptsetup-initramfs’ pulls it in as ‘initramfs-tools’
depends on it.)  Also instead of using hardcoded ‘/dev/block/$major:$minor’
for source devices we should probably query

udevadm info -rq name /sys/dev/block/$major:$minor

(On your system, does the above command return the path to the source
device?)

-- 
Guilhem.


signature.asc
Description: PGP signature