Bug#939357: [pkg-cryptsetup-devel] Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

Control: retitle -1 `decrypt_keyctl` fails when the user-keyring(7) isn't attached to the calling process Hi Sebastian, Thanks for the detailed report! I was able to reproduce this in a fresh Buster netinstall, taking SSH sessions and sudo(8)'s ‘-i’ flag out of the picture. This is what I get

Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

Control: reassign -1 sudo 1.8.27-1 Control: affects -1 cryptsetup Control: merge -1 906752 On Thu, 05 Sep 2019 at 02:03:34 +0200, Guilhem Moulin wrote: > Perhaps keyctl(1) could provide a wrapper using thread-keyring(7) as > temporary keyring, like the attached PoC. Of course I forg

Bug#939766: [pkg-cryptsetup-devel] Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

Control: tag -1 moreinfo Hi, On Mon, 09 Sep 2019 at 00:53:44 +0200, Alexander Brock wrote: > but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in > /usr/lib/x86_64-linux-gnu. (I assume you meant ‘/lib.*/libc\.so\.[0-9.-]+’.) How did you end up with a system where /lib/*-linux-gn

Bug#939766: [pkg-cryptsetup-devel] Bug#939766: Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

Control: retitle -1 cryptsetup-initramfs: Missing libgcc_s on linux-image-5.2.0-2-amd64 On Mon, 09 Sep 2019 at 02:55:06 +0200, Guilhem Moulin wrote: > This on a sid system upgraded from buster with a ‘usrmerge’ layout: > > root@kvm-10487:~# ldd /sbin/cryptsetup | grep -

Bug#920611: netcat-openbsd: Report the listening port correctly in verbose mode

Control: tag -1 pending Control: notfound -1 1.105-1 Control: found -1 1.195-1 Hi Peter, On Sun, 27 Jan 2019 at 12:38:54 +0200, Peter Pentchev wrote: > I submitted a merge request on Salsa; what do you think about these > changes to the Debian-specific patches that report the listening port in >

Bug#916374: cryptsetup-initramfs: keyscript=decrypt_gnupg-sc yields a debug shell if the first smartcard can't unlock the key

Package: cryptsetup-initramfs Version: 2:2.0.6-1 Severity: wishlist If the wrong card is plugged at boot time, then our loop tries again and again with the following message: gpg: encrypted with 2048-bit RSA key, ID DEADBEEFDEADBEEF, created 2018-12-13 "test test" gpg: decryption

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

Control: retitle -1 `/etc/init.d/cryptdisks stop` should ignore devices holding / and /usr Control: severity -1 wishlist Hi, On Sun, 16 Dec 2018 at 13:28:37 -0800, r...@riseup.net wrote: > When shuting down my Devuan LVM + LUKS install, it hangs just at the end > of the shutdown sequence presen

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

On Wed, 19 Dec 2018 at 04:59:47 -0800, r...@riseup.net wrote: > When I manually applied the patch from #5, my shutdown sequence worked > just fine (without hanging). Dunno what Devuan ships, but that patch simply doesn't apply to the debian/cryptdisks.functions from cryptsetup 2:1.7.3-4: htt

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote: > I see. What would you suggest as a proper solution to this situation? How about what's now the title of this bug? :-) -- Guilhem. signature.asc Description: PGP signature

Bug#916649: [pkg-cryptsetup-devel] Bug#916649: crytpsetup:

On Thu, 20 Dec 2018 at 05:38:50 -0800, r...@riseup.net wrote: > On 2018-12-19 22:14, Guilhem Moulin wrote: >> On Wed, 19 Dec 2018 at 12:13:25 -0800, r...@riseup.net wrote: >>> I see. What would you suggest as a proper solution to this situation? >> >> How about wh

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

Hi, On Sat, 22 Dec 2018 at 04:09:02 +0100, Mikhail Morfikov wrote: > All of the containers should be opened at boot time, but only the first two > are. Presumably because /dev/mapper/some_img is not required at initramfs stage, ie, it's not holding /, /usr or the resume device(s). > When I add

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

Control: reassign -1 cryptsetup-initramfs Control: retitle -1 Open a disk image file not residing on the root filesystem Control: severity -1 wishlist On Sat, 22 Dec 2018 at 15:47:58 +0100, Mikhail Morfikov wrote: >> If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to >> unlock the

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

On Sat, 22 Dec 2018 at 16:35:59 +0100, Mikhail Morfikov wrote: > Anyways I think crypttab should have such functionality built it (if > possible), > so everything could be set up in the /etc/crypttab file. Disk images, key files, and detached headers can reside on arbitrarily complicated file sys

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote: > On 22/12/2018 16:48, Guilhem Moulin wrote: >> Disk images, key files, and detached headers can reside on arbitrarily >> complicated file systems and block device stack, and setting up these >> stacks to make the

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote: > I don't get it -- I didn't post it as an initramfs issue, only as > cryptsetup one. I'm not sure, but isn't the /etc/crypttab file a > debian specific? If not, I can ask about this problem upstream, but I > thought it is debian specif

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

On Sun, 23 Dec 2018 at 04:19:45 +0100, Guilhem Moulin wrote: > If your encrypted disk image is in LUKS2 format (otherwise upgrade from > LUKS1 possible) you can also get away without workaround if you don't > mind re-enabling systemd-cryptsetup-generator(8). First you need to a

Bug#850756: [pkg-cryptsetup-devel] Bug#850756: cryptsetup: Please save password to kernel keyring

Hi Laurent, On Tue, 10 Jan 2017 at 01:07:00 +0100, Laurent Bigonville wrote: > Looking at systemd, I see that they are doing something similar: > > serial = add_key("user", keyname, p, n, KEY_SPEC_USER_KEYRING); > > with keyname="cryptsetup" I just had a look at this and as I wrote in #917067's

Bug#934753: dropbear-initramfs: please add an autopkgtest

On Wed, 14 Aug 2019 at 14:54:08 +0200, Johannes 'josch' Schauer wrote: > when I upgraded my Squeeze box to Jessie, remote unlocking via dropbear > in my initramfs stopped working. This is a remote host in a datacenter, > so I cannot directly investigate the issue. Interesting, once you manage to b

Bug#934753: dropbear-initramfs: please add an autopkgtest

On Fri, 16 Aug 2019 at 14:45:17 +0200, Guilhem Moulin wrote: > On Wed, 14 Aug 2019 at 14:54:08 +0200, Johannes 'josch' Schauer wrote: >> when I upgraded my Squeeze box to Jessie, remote unlocking via dropbear >> in my initramfs stopped working. This is a remote host in a d

Bug#934956: buster-pu: package cryptsetup/2:2.1.0-5+deb10u1

e were no bound keyslot on the header. (Closes: #934715) -- Guilhem Moulin Fri, 16 Aug 2019 19:18:10 +0200 The 3 cherry-picked patches are all backported from 2.2.0 [1,2], and the version in sid is not affected. (The one in Stretch is not affected either as it doesn't have LUKS2 suppo

Bug#934956: buster-pu: package cryptsetup/2:2.1.0-5+deb10u1

Thanks, uploaded. And sorry the wall of text in the original report ^^ -- Guilhem. signature.asc Description: PGP signature

Bug#935370: buster-pu: package lacme/0.5-1+deb10u1

555 <https://tools.ietf.org/html/rfc8555> instead of the +ACME I-D URL. + * Issue GET and POST-as-GET requests (RFC 8555 sec. 6.3) for the +authorizations, order and certificate URLs. Let's Encrypt will remove +support of unauthenticated GETs from the V2 API on 01 Nov 2019.

Bug#935650: netcat-openbsd: valid arguments disallowed

Control: retitle -1 netcat-openbsd: Unable to specify client socket for UNIX-domain datagram sockets Control: found -1 1.187-1 Control: found -1 1.195-2 Hi, On Sat, 24 Aug 2019 at 20:25:00 +, astian wrote: > Looking at the patch I don't trust this is the only behaviour change. I > don't und

Bug#935727: [gpg-key2ps] Print the long keyID instead of the short ID

Control: severity -1 wishlist Hi, On Sun, 25 Aug 2019 at 19:11:10 +0200, Jörg Frings-Fürst wrote: > please print the long keyID instead of the short keyID. We were matching the output of `gpg --fingerprint --list-key`. They now only show the fingerprint and I guess it makes sense to do the same

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

Bug#935799: lacme: `client` uses unauthenticated GETs instead of POST-as-GETs

Source: lacme Version: 0.5-1 Severity: important Per RFC 8555 sec 6.3 the Let's Encrypt folks are deprecating unauthenticated GETs from their v2 API. Support for these requests will be removed on *Nov 01 2019* [0]. lacme uses the v2 API since 0.5, and removing support for unauthenticated GETs me

Bug#935370: buster-pu: package lacme/0.5-1+deb10u1

he +authorizations, order and certificate URLs. Let's Encrypt will remove +support of unauthenticated GETs from the V2 API on 01 Nov 2019. + Closes: #935799. + + -- Guilhem Moulin Thu, 22 Aug 2019 00:14:42 +0200 + lacme (0.5-1) unstable; urgency=medium * New upstream release,

Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

--8<->8-- cryptsetup (2:2.1.0-5+deb10u2) buster; urgency=medium * Cherry pick upstream commit 8f8f0b32: Fix mapped segments overflow on 32bit architectures. Regression since 2:2.1.0-1. (Closes: #935702) -- Guilhem Moulin Mon, 26 Aug 2019 14:54:10 +0200 cryptsetup

Bug#1003951: DROPBEAR_OPTIONS is silently ignored when missing quotes

Hi Lee, On Wed, 19 Jan 2022 at 14:45:47 +0100, Lee Garrett wrote: > Ah, I wasn't aware that it was directly sourced by a shell. This makes > much more sense now. I see, then I guess it needs to be clarified indeed. Made an attempt at https://salsa.debian.org/debian/dropbear/-/commit/06b27a9abfb5

Bug#1005921: CVE-2022-24953: Crypt_GPG <1.6.7 does not prevent additional options in GPG calls

Source: php-crypt-gpg Version: 1.6.6-1 Severity: important Tags: security upstream Control: found -1 1.6.4-2 Control: found -1 1.6.6-1 Crypt_GPG upstream recently published for CVE-2022-24953: “The Crypt_GPG extension before 1.6.7 for PHP does not prevent additional options in GPG calls, which pre

Bug#1006010: bullseye-pu: package php-crypt-gpg/1.6.4-2+deb11u1

, d/salsa-ci.yml: Target Bullseye release. + + -- Guilhem Moulin Fri, 18 Feb 2022 22:17:29 +0100 + php-crypt-gpg (1.6.4-2) unstable; urgency=medium * Require phpunit ≥8 in Build-Depends. diff -Nru php-crypt-gpg-1.6.4/debian/gbp.conf php-crypt-gpg-1.6.4/debian/gbp.conf --- php-crypt-gpg-1.6.4

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 that

Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net

Hi, On Thu, 30 Dec 2021 at 17:05:39 -0500, Aaron M. Ucko wrote: > caff has historically defaulted to looking keys up on > pool.sks-keyservers.net $CONFIG{'keyserver'} is deprecated since 2.3-1, and the default is to use the keyserver in ~/.caff/gnupghome/gpg.conf, falling back to the option value

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

Package: roundcube Severity: important Tags: security Control: found -1 1.3.17+dfsg.1-1~deb10u1 Control: found -1 1.4.12+dfsg.1-1~deb11u1 Control: fixed -1 1.5.1+dfsg-1 In a recent post roundcube webmail upstream has announced a fix for a cross-site scripting (XSS) vulnerability via HTML messages

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

Control: notfixed -1 1.5.1+dfsg-1 Control: found -1 1.5.1+dfsg-1 Hi Salvatore! On Mon, 03 Jan 2022 at 09:47:28 +0100, Salvatore Bonaccorso wrote: > On Sun, Jan 02, 2022 at 10:50:25PM +0100, Guilhem Moulin wrote: >> Package: roundcube >> Severity: important >> Tags: security

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

Hi carnil, On Wed, 05 Jan 2022 at 20:49:35 +0100, Salvatore Bonaccorso wrote: > FTR, have not yet heard back on the assignment. We can wait a bit > longer, but just wanted to say we do not necessarily need to block on > the missing assignment if we want to release the DSA earlier. The > issue is n

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

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#1003615: ITP: php-bacon-bacon-qr-code -- QR code generator for PHP

Package: wnpp Severity: wishlist Owner: Guilhem Moulin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: php-bacon-bacon-qr-code Version : 2.0.4 Upstream Author : Ben Scholzen 'DASPRiD' * URL : https://github.com/Bacon/BaconQrCode * License

Bug#1003615: ITP: php-bacon-bacon-qr-code -- QR code generator for PHP

On Wed, 12 Jan 2022 at 18:10:18 +0100, Guilhem Moulin wrote: > * Package name: php-bacon-bacon-qr-code > Version : 2.0.4 > Upstream Author : Ben Scholzen 'DASPRiD' > * URL : https://github.com/Bacon/BaconQrCode > * License : BSD-2-Clause

Bug#1003633: ITP: php-roundcube-rtf-html-php -- RTF to HTML converter in PHP

Package: wnpp Severity: wishlist Owner: Guilhem Moulin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: php-roundcube-rtf-html-php Version : 2.1 Upstream Author : Alexander van Oostenrijk , Aleksander Machniak * URL : https

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 conf

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

On Mon, 27 Sep 2021 at 02:56:26 +0200, Christoph Anton Mitterer wrote: > Thus I cannot implement my own unescaping. Why not? _CRYTTAB_* is useful to copy a crypttab snippet to another location, but as said before you don't need it to produce your own parsing logic. You can use another character

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

On Mon, 27 Sep 2021 at 18:21:47 +0200, Christoph Anton Mitterer wrote: > But why on earth should one want to do any of that? Because the field is opaque, and the key=value list format might not make sense for keyscripts. -- Guilhem. signature.asc Description: PGP signature

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

On Mon, 27 Sep 2021 at 19:21:45 +0200, Christoph Anton Mitterer wrote: > On Mon, 2021-09-27 at 18:37 +0200, Guilhem Moulin wrote: >> Because the field is opaque, and the key=value list format might not >> make sense for keyscripts. > > Well sure you can define it that way..

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

Hi, On Thu, 16 Sep 2021 at 17:41:17 +0200, Christoph Anton Mitterer wrote: > I think it would be nice if askpass was only included when actually > needed. What does “would be nice” means concretely, is there anything else than the slightly smaller initramfs image? Personally I'm not against doin

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

On Sun, 03 Oct 2021 at 00:03:17 +0200, Christoph Anton Mitterer wrote: > It's like you say in the other bugs... people cannot rely on non- > documented features, and you're right there - otherwise you could > barely make any changes. We could also rename internal functions, variables, and paths to

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

On Thu, 16 Sep 2021 at 17:41:17 +0200, Christoph Anton Mitterer wrote: > I think it would be nice if askpass was only included when actually > needed. > > That seems to be the case, when no keyscript is set, and the KEY field is > none, > cause: > […] > Does the attached patch seem reasonable (ha

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

Control: tag -1 moreinfo On Tue, 31 Aug 2021 at 16:05:27 +0200, Christoph Anton Mitterer wrote: > The cryptdisks_* completion scripts seems to depend on mawk. > > Would it be possible to make this compatible with the other awk > implementations > in Debian (gawk/original-awk)? mawk has ‘Priorit

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

Control: tag -1 = pending On Mon, 04 Oct 2021 at 00:09:41 +0200, Christoph Anton Mitterer wrote: > On Sun, 2021-10-03 at 22:14 +0200, Guilhem Moulin wrote: >> mawk has ‘Priority: required’ and is expressive enough for this >> use-case.  Why should we use something else? > >

Bug#993374: cryptsetup: cryptdisks_* completion scripts depend on mawk

On Mon, 04 Oct 2021 at 01:17:36 +0200, Christoph Anton Mitterer wrote: > And as you said, since we only use the POSIX subset, I thought it would > be an improvement to use awk, and not fail in even the above situation. I don't recall why I used mawk in b0b8e3e88fecf2f8f5f5a3ad39b68e56a9e53427, but

Bug#995725: dropbear-initramfs: connection between ssh client and dropbear times out

Control: tag -1 moreinfo On Mon, 04 Oct 2021 at 10:32:49 -0700, Arnout Boelens wrote: > I can ping my server on port . Not sure what you mean here, there is no port in ICMP. Do you see the dropbear greeting when you connect to your server on /tcp? -- Guilhem. signature.asc Descriptio

Bug#995725: dropbear-initramfs: connection between ssh client and dropbear times out

On Mon, 04 Oct 2021 at 13:28:12 -0700, Arnout Boelens wrote: > My bad. I meant to say I can ping the server. But I cannot connect to port > . You probably have a firewall on the way blocking the connection. Assuming 22/tcp is open you can tell dropbear to use that instead. -- Guilhem. sign

Bug#1000156: roundcube: XSS vulnerability in handling attachment filename extension in MIME type mismatch warnings

Source: roundcube Severity: important Tags: security Control: found -1 1.3.16+dfsg.1-1~deb10u1 Control: found -1 1.4.11+dfsg.1-4 Control: fixed -1 1.5.0+dfsg.1-1 In a recent post roundcube webmail upstream has announced the following security fixes: * Fix XSS issue in handling attachment filenam

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 different

Bug#1000642: roundcube: Failing test with PHP 8.1

Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/8151 Control: tag -1 upstream Hi taffit! On Fri, 26 Nov 2021 at 06:41:47 -0400, David Prévot wrote: > PHP 8.1 is now the default in experimental (soon in testing), and the > command1 autopkgtest is failing in this environment

Bug#1003951: DROPBEAR_OPTIONS is silently ignored when missing quotes

Control: severity -1 minor Hi, On Tue, 18 Jan 2022 at 15:58:43 +0100, Lee Garrett wrote: > A low-effort fix would be to change the shipped config to > # DROPBEAR_OPTIONS="" > to indicate that they're required. Ideally the initramfs hook should either > fail > when unquoted, or accept the full pa

Bug#1004203: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian)

Package: ftp.debian.org Severity: normal I mixed things up when filing https://bugs.debian.org/1003615 , and unfortunately didn't notice before the upload entered NEW. Per : | Please ignore my upload: turns out the package is already in Debian, my | bad… Sorry for the trouble! So please remove

Bug#1004203: closed by Scott Kitterman (Re: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian))

Control: reopen -1 On Mon, 24 Jan 2022 at 14:39:11 +, Debian Bug Tracking System wrote: >> I mixed things up when filing https://bugs.debian.org/1003615 , and >> unfortunately didn't notice before the upload entered NEW. Per >> : >> >> | Please ignore my upload: turns out the package is alre

Bug#1004203: closed by Scott Kitterman (Re: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian))

Control: retitle -1 src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian) On Sat, 29 Jan 2022 at 18:25:42 +, Adam D. Barratt wrote: > On Sat, 2022-01-29 at 18:41 +0100, Guilhem Moulin wrote: >>> Appears it was already removed. >> >> Was it? 5 days la

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 cryptsetup/2

Bug#994056: cryptsetup: blkid check fails to take offset option into account

On Fri, 08 Oct 2021 at 15:12:58 +, Thorsten Glaser wrote: >>, so I completed your patch with 2373709bb461a71a7af46e7e9c59355fce63e52e. > > -blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$offset"} -- "$dev")" > +blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$((offset*512))"} -

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

ysql >/dev/null;` causes roundcube-core.postinst to spew /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead. Here is a trivial patch following the suggested workaround from the debianutils maintainer. Thanks Cheers, -- Guilhem. commit e

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

Hi elbrus! On Sun, 10 Oct 2021 at 20:52:51 +0200, Paul Gevers wrote: > Thanks for the report. I had committed nearly the same change locally. > Can you elaborate why you removed some "2>&1" strings on top of that? AFAIK with some `which` implementations one wants to silence the standard error to

Bug#996181: cryptsetup-initramfs: Unable to use keyfile to decrypt rootfs

Control: severity -1 wishlist Hi, On Mon, 11 Oct 2021 at 22:28:31 +0200, Mateusz Jończyk wrote: > Currently, it is not possible to use a keyfile to decrypt the root > file system. I would like to use such a setup, so I'm attaching a > short patch for crypttab to make this work. IMHO this is too

Bug#996177: cryptsetup: please report fatal errors without having to use -v

Control: tag -1 moreinfo Hi, On Mon, 11 Oct 2021 at 22:09:07 +0200, Marc Lehmann wrote: > Specifically, the machine didn't have enough ram, probably because the > default algorithm (argon) requires more ram than the machine had. Could you please share the memory cost of the PBKDF, and also the o

Bug#996177: cryptsetup: please report fatal errors without having to use -v

Control: found -1 2:2.1.0-5+deb10u2 On Tue, 12 Oct 2021 at 00:33:32 +0200, Guilhem Moulin wrote: > On Mon, 11 Oct 2021 at 22:09:07 +0200, Marc Lehmann wrote: >> Specifically, the machine didn't have enough ram, probably because the >> default algorithm (argon) requires more

Bug#996177: cryptsetup: please report fatal errors without having to use -v

On Thu, 14 Oct 2021 at 19:53:14 +0200, Marc Lehmann wrote: > On Tue, Oct 12, 2021 at 12:33:32AM +0200, Guilhem Moulin > wrote: >> Could you please share the memory cost of the PBKDF, > > I wouldn't know how to do that. `cryptsetup luksDump` >> of `free` just bef

Bug#996177: cryptsetup: please report fatal errors without having to use -v

On Thu, 14 Oct 2021 at 20:48:51 +0200, Marc Lehmann wrote: > I reported this from another system, but both were recently upgraded to > bullseye. > > I know because I use kvm to see if the machine will actually boot (Cthus > the different memory setup) and the kvm in bullseye has a bug that makes >

Bug#996505: cryptsetup: set CRYPTTAB_OPTION_tries for keyscripts when not explicitly set

On Thu, 14 Oct 2021 at 23:43:32 +0200, Christoph Anton Mitterer wrote: > I've noted that when there is no explicit tries=n in crypttab, that > CRYPTTAB_OPTION_tries isn't set either for the keyscripts. There is a 1:1 mapping between CRYPTTAB_OPTION_* and known options in crypttab's 4th column, and

Bug#996655: Processed: forcibly merging 996613 996655

Control: unmerge -1 Control: severity -1 normal On Sat, 16 Oct 2021 at 18:42:11 -0400, David Mandelberg wrote: > Why were these two merged? Read too fast. Sorry. -- Guilhem. signature.asc Description: PGP signature

Bug#996655: updating database with dbconfig-no-thanks doesn't seem to work

On Sat, 16 Oct 2021 at 17:45:42 -0400, David Mandelberg via Pkg-roundcube-maintainers wrote: > $ sudo -u www-data /usr/share/roundcube/bin/update.sh > ERROR: Configuration error. Unsupported database driver: I suppose the command doesn't have RCUBE_CONFIG_PATH=/etc/roundcube in its environment.

Bug#987769: [pkg-cryptsetup-devel] Bug#987769: cryptsetup Recommends cryptsetup-run which is a transitional package

Control: severity -1 low Hi Laurent, On Thu, 29 Apr 2021 at 10:53:11 +0200, Laurent Bigonville wrote: > cryptsetup recommends cryptsetup-run which is a transitiona package > pulling cryptsetup. > > That creates a "soft" dependency loop. > > cryptsetup should probably stop recommending cryptsetu

Bug#988032: lacme: Files owned by _lacme-client might be left on disk when 'challenge-directory' is set

Package: lacme Version: 0.8.0-1 Severity: important Since lacme 0.8.0-1 the internal ACME client runs as a dedicated system user _lacme-client, which is deleted on purge. This is fine as far as the default configuration goes because no non-temporary files are created with that owner, however if t

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#906283: initramfs script expects file system on crypto device

Control: severity -1 wishlist Hi Marc, On Thu, 16 Aug 2018 at 16:50:55 +0200, Marc Haber wrote: > Severity: normal Lowering to ‘wishlist’ since AFAIK it's not the a regression; the check is already place in 2:1.4.3-4 (stretch), 2:1.6.6-5 (jessie) and 2:1.7.3-4 (wheezy): https://sources.deb

Bug#874364: Keyboard layout set in GNOME or with localectl does not apply to initramfs LUKS prompt immediately

Control: reassign -1 gnome-control-center,systemd,initramfs-tools Hi, On Fri, 17 Aug 2018 at 10:44:55 +0100, Simon McVittie wrote: > Control: reassign -1 gnome-control-center,systemd,cryptsetup-initramfs cryptsetup-initramfs doesn't mess around with the keyboard layout. Installing custom layouts

Bug#874364: [pkg-cryptsetup-devel] Bug#874364: Keyboard layout set in GNOME or with localectl does not apply to initramfs LUKS prompt immediately

On Fri, 17 Aug 2018 at 10:44:55 +0100, Simon McVittie wrote: > having systemd-localed regenerate the initramfs whenever the > system-wide default keyboard layout is set seems disproportionate? This is only needed on systems where initramfs.conf(5) sets KEYMAP="y", but maybe it's not so easy to de

Bug#906890: dropbear: CVE-2018-15599

Control: found -1 2014.65-1+deb8u2 Hi Salvatore, Wow, you're fast :-) I read the the discussion in the upstream list but wasn't aware a CVE had been assigned yet. Upstream replied “I should have a patch in the next couple of days”, and I'll propose an upload to stretch-security after that. (Ho

Bug#906890: dropbear: CVE-2018-15599

On Wed, 22 Aug 2018 at 06:21:27 +0200, Salvatore Bonaccorso wrote: > Would you agree and could you instead update dropbear for the next > point release? Makes sense indeed, I'll do that instead. Cheers, -- Guilhem. signature.asc Description: PGP signature

Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype

On Wed, 22 Aug 2018 at 21:22:19 +0100, Ben Hutchings wrote: > Looking at the local-top script from cryptsetup-initramfs, it seems to > depend rather too closely on details of both initramfs-tools and lvm2. > > - Why does it try to activate a volume group directly? lvm2's scripts > should do that.

Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype

On Thu, 23 Aug 2018 at 12:16:35 +0200, Jonas Meurer wrote: > Mh. When using LUKS, the cryptsetup scripts should not do any post > checks by default. Can you send a detailed log of the script execution? > Maybe indeed our initramfs rewrite introduced a regression here. > Guildhem, could you look int

Bug#907124: stretch-pu: package dropbear/2016.74-5

est +function in svr-auth.c in Dropbear through 2018.76 is prone to a user +enumeration vulnerability because username validity affects how fields in +SSH_MSG_USERAUTH messages are handled. (Closes: #906890.) +Adapted from https://secure.ucc.asn.au/hg/dropbear/rev/5d2d1021ca00 . +

Bug#906890: dropbear: CVE-2018-15599

On Wed, 22 Aug 2018 at 11:19:37 +0200, Guilhem Moulin wrote: > On Wed, 22 Aug 2018 at 06:21:27 +0200, Salvatore Bonaccorso wrote: >> Would you agree and could you instead update dropbear for the next >> point release? > > Makes sense indeed, I'll do that instead. Jus

Bug#907082: orphaning packages

Control: tag -1 pending Hi, On Fri, 24 Aug 2018 at 06:55:23 +, Gerrit Pape wrote: > On Thu, Aug 23, 2018 at 10:27:12PM +0200, Tobias Frost wrote: >> The current maintainer of [packages], Gerrit Pape , >> is apparently not active anymore. Therefore, I orphan this package now. > > Indeed, I'm

Bug#907201: [pkg-cryptsetup-devel] Bug#907201: cryptsetup-initramfs: Asks for disk password twice unless 'debug' is passed to kernel command line

Hi, On Fri, 24 Aug 2018 at 18:49:10 +0200, Matthias Klumpp wrote: > This issue is really annoying, and I would be glad for any pointers on > how to investigate the issue further, as I am no expert on cryptsetup. See https://wiki.debian.org/CryptsetupDebug to trace /scripts/local-top/cryptroot, pl

Bug#907201: [pkg-cryptsetup-devel] Bug#907201: cryptsetup-initramfs: Asks for disk password twice unless 'debug' is passed to kernel command line

Control: tag -1 moreinfo On Fri, 24 Aug 2018 at 22:45:40 +0200, Matthias Klumpp wrote: > Obviously no Plymouth was shown here. The log looks normal to me. Ah right, plymouthd isn't started yet when you're dropped into the initramfs shell, so you'll need to start it manually: `/scripts/init-premou

Bug#907124: stretch-pu: package dropbear/2016.74-5

On Sun, 26 Aug 2018 at 14:52:06 +0100, Adam D. Barratt wrote: > +dropbear (2016.74-5+deb9u1) stable; urgency=medium > > Please make the distribution "stretch", and feel free to upload. Oops yes sorry, uploaded with the correct distribution now. -- Guilhem. signature.asc Description: PGP signa

Bug#888916: Bug#903163: Adding OpenPGP smartcard support to LUKS

Hi Chris, On Sat, 01 Sep 2018 at 11:50:47 +0100, Chris Lamb wrote: >>> So, whilst I will be at DebCamp too (yay) I unfortunately won't have >>> any hardware to test with and for various reasons I should keep >>> commitments low at this point. >> >> Sure thing! I was planning to do some triaging

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

Control: severity -1 wishlist Control: tag -1 moreinfo Hi Raphaël, On Fri, 07 Sep 2018 at 15:41:26 +0200, Raphaël Hertzog wrote: > However that no longer works... when the live image is created, there's > no encrypted device detected and you see that in the build log: > > update-initramfs: Gen

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

Control: tag -1 - moreinfo On Fri, 07 Sep 2018 at 23:22:45 +0200, Raphael Hertzog wrote: > On Fri, 07 Sep 2018, Guilhem Moulin wrote: >>> update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64 >>> cryptsetup: WARNING: Couldn't determine root device >&

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

Control: retitle -1 cryptsetup-initramfs: Please silence the warning when the hook config contains CRYPTSETUP="y" On Sat, 08 Sep 2018 at 09:39:27 +0200, Raphael Hertzog wrote: > On Sat, 08 Sep 2018, Guilhem Moulin wrote: >> Hmm, so you don't really need the integration p

Bug#907243: [pkg-cryptsetup-devel] Bug#907243: cryptsetup-initramfs recursive resolution broken

Control: tag -1 pending On Sat, 25 Aug 2018 at 09:33:46 +0100, Nathaniel Filardo wrote: > https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/cb5985935713deb6bd4fd45c77d1f54cc28b204b#a630d04e2df57150e6a092fc23f955c6ea0ce412_214_193 > is subtly wrong: while 'name' and friends were local vari

Bug#908220: [pkg-cryptsetup-devel] Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

On Sun, 09 Sep 2018 at 11:08:46 +0200, Raphael Hertzog wrote: > On Sat, 08 Sep 2018, Guilhem Moulin wrote: >>> The persistence feature does not allow to update the kernel/initrd. It can >>> be updated in the overlay file system but the kernel/initrd are booted >>> be

Bug#903163: Adding OpenPGP smartcard support to LUKS

Hi, On Wed, 21 Nov 2018 at 11:12:08 -0500, Chris Lamb wrote: > Guilhem Moulin wrote: >>> GnuPG upstream was asked about a documented API to retrieve the stubs >>> but hasn't answered yet AFAIK. > > Did they get back to you yet out of interest, Guilhem? Peter

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

Control: tag -1 moreinfo Control: severity -1 wishlist Hi Mikhail, On Fri, 23 Nov 2018 at 16:03:32 +0100, Mikhail Morfikov wrote: > I have to type the same password two times (one for each drive) when > the system boots. Does ‘keyscript=decrypt_keyctl’ cover your needs? Cf. /usr/share/doc/crypt

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

On Fri, 23 Nov 2018 at 17:09:24 +0100, Mikhail Morfikov wrote: > Should the script be used when systemd takes care of opening the > encrypted containers? Because it doesn't support those scripts. Indeed, but systemd isn't involved at initramfs stage. At this stage unlocking is done by our own scr

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

On Fri, 23 Nov 2018 at 17:27:11 +0100, Mikhail Morfikov wrote: > On 23/11/2018 17:20, Guilhem Moulin wrote: >> On Fri, 23 Nov 2018 at 17:09:24 +0100, Mikhail Morfikov wrote: >>> Should the script be used when systemd takes care of opening the >>> encrypted containers?

Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

Control: retitle -1 cryptsetup-initramfs: user is prompted for password even when the detached header is missing On Fri, 23 Nov 2018 at 17:05:13 +0100, Mikhail Morfikov wrote: > So, to open my laptop, I have to connect the USB device (my phone) > first. In order to make this work, I had to write

<    4   5   6   7   8   9   10   11   >