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

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 |

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

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

Bug#1068849: marked as pending in cryptsetup

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:

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

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.

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

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

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

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

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

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

Bug#1066853: marked as pending in roundcube

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:

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

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

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

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

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

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:

Bug#1050606: marked as pending in cryptsetup

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:

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

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

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

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

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

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

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

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.

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

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

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

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

Bug#1032235: closing 1032235

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

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

Bug#1032734: OOM when unlocking encrypted root in initramfs

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

Bug#1032734: OOM when unlocking encrypted root in initramfs

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

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

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

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

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…

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

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

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

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

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

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

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

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

Bug#1011754: interimap: autopkgtest failure with openssl 3

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

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

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

Bug#1003685: What about bullseye ?

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

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

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

Bug#1000593: Failing testsuite with PHP 8.1

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

Bug#1000642: roundcube: Failing test with PHP 8.1

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

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

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

Bug#997809: roundcube: Delay migration into testing

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

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

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

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

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'] = ''; >>

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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:

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)

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

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

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

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

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

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

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

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

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

Bug#951194: marked as pending in roundcube

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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, {t

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

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

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

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

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

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

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

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

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

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

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

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

Bug#914034: bug in Net::SSLeay?

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

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

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

Bug#905188: closing 905188

close 905188 2:2.0.4-1 thanks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

Bug#902943: cryptsetup-initramfs: Encrypted rootfs in LVM is not found after upgrade

On Fri, 06 Jul 2018 at 00:51:02 +0200, Korbinian Demmel wrote: > I played around with the 'lvm2' script. Support to get the mangled > source device (LG/LV) for an given LV UUID is quite simple to add. It's not the LV UUID that we need here, but the LUKS UUID. And the script doesn't know which

Bug#902943: cryptsetup-initramfs: Encrypted rootfs in LVM is not found after upgrade

On Tue, 03 Jul 2018 at 20:01:02 +0200, doak wrote: > After system upgrade the system is not bootable anymore due the > initramfs is unable to find the "source" for the rootfs and boot > hangs. Not forever, though. It drops to a debug shell after ‘rootdelay’ (default 180) seconds, unless you've

Bug#901884: [pkg-cryptsetup-devel] Bug#901884: (no subject)

On Wed, 20 Jun 2018 at 06:42:03 +, 901...@chiru.no wrote: > This line: > blockcipher="$(printf '%s' "$value" | cut -d':' -f1 | cut -d'-' -f1)" > should be: > blockcipher="$(printf '%s' "$value" | cut -d':' -f1 | cut -d'-' -f2)" That's indeed the regression, causing modules required for the

  1   2   >