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

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

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 cr

Bug#866869: initramfs-tools(8): please document that BOOT is exposed to boot scripts

On Sun, 02 Jul 2017 at 12:57:11 +0200, Guilhem Moulin wrote: > Knowing the boot method can be useful at init-premount and init-bottom > stages. > […] > Please document the variable if boot scripts can rely on the value of > BOOT. Otherwise, could you suggest an alternative to

Bug#900444: signing-party: gpgsigs fails to fill in checksum after gpgparticipants-prefill

Control: retitle -1 signing-party: gpgsigs(1) doesn't fill in partially filled Checksum lines Control: tag -1 wishlist Hi, On Wed, 30 May 2018 at 23:18:55 +0200, Uwe Kleine-König wrote: > uwe@taurus:~/tmp$ gpgsigs 0D2511F322BFAB1C1580266BE2DCDD9132669BD6 > uwesparty.txt | grep -A2 "SHA256 Ch" >

Bug#872529: /usr/bin/caff: caff: puts TTY into weird state when prompting to send mail

Control: tag -1 pending Hi, On Sun, 20 Aug 2017 at 21:40:44 -0400, G. Branden Robinson wrote: > I'm at a loss for what put my terminal into that state in the first > place Just got another report from Grégoire Détrez, who stumbled upon the same problem and found out how to reproduce it, namely b

Bug#898495: [pkg-cryptsetup-devel] Bug#898495: cryptsetup: [patch] make failsleep configurable

Hi Chris, On Wed, 06 Jun 2018 at 09:04:58 +0100, Chris Lamb wrote: >> Given that a major refactoring of the initramfs integration is ongoing, > > How's that getting on? :) Finishing the refactoring is on the agenda for our hackathon in about 10 days, but this part is largely done already (failsl

Bug#859953: some improvements for /lib/cryptsetup/cryptdisks.functions

Control: tag -1 pending Hi, Thanks for the review! Refactoring cryptdisks.functions has been on our TODO list for quite a while, and we finally got around to it. All the points you mentioned are addressed, AFAICT: https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/cryp

Bug#898495: [pkg-cryptsetup-devel] Bug#898495: cryptsetup: [patch] make failsleep configurable

Control: tag -1 pending On Sun, 17 Jun 2018 at 09:02:56 +0100, Chris Lamb wrote: > How did the sprint go? :) Go*es*, we still have a few hours left :-) Quite well, thanks for approving the sponsorship! The refactoring branch is now merged to master, and 'failsleep' is no longer supported. Beca

Bug#849335: Support keyfile-size, keyfile-offset in cryptroot

Control: tag -1 pending Hi, On Sun, 25 Dec 2016 at 19:13:18 +0100, schaarsc wrote: > Please consider adding keyfile-size, keyfile-offset to the supported options. Thanks for the patch. I didn't apply it as is since we just finished a major refactoring of our scripts, but nonetheless this commit

Bug#901795: cryptsetup: new version may break 3rd party keyscripts (and thus boot)

Control: tag -1 moreinfo Hi Christoph, On Mon, 18 Jun 2018 at 15:06:59 +0200, Christoph Anton Mitterer wrote: > Fritst thanks for work you've done in the recent new versions. Sooo many > nice things have been implemented/fixed :-) :-) > The problem seems that in earlier versions, the initramfs

Bug#901795: cryptsetup: new version may break 3rd party keyscripts (and thus boot)

Control: severity -1 wishlist Control: tag -1 - moreinfo Control: retitle -1 cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files On Mon, 18 Jun 2018 at 23:54:09 +0200, Christoph Anton Mitterer wrote: > So why do I need stu

Bug#879853: netcat-openbsd: support -s with -l

Control: tag -1 pending On Thu, 23 Nov 2017 at 20:33:10 +0100, Uwe Kleine-König wrote: > Hmm, regarding the above command the man page claims: > > It is an error to use [-l] in conjunction with the -p, -s, or -z > options. > > which isn't treated as an error but does the same as > >

Bug#883595: [pkg-cryptsetup-devel] Bug#883595: cryptsetup: Cannot mount encrypted root using XTS on kernel 4.10 onwards

Control: retitle -1 xts module should depend on ecb Control: reassign -1 src:linux 4.10.1-1 Control: affects -1 cryptsetup On Tue, 05 Dec 2017 at 14:16:42 +, Francis Russell wrote: > Apparently from Linux 4.10 onwards, the ecb module became a dependency > of xts[1]. I am running a custom ker

Bug#883620: [Pkg-roundcube-maintainers] Bug#883620: More informations

Control: reopen -1 Didn't mean to close this, sorry. -- Guilhem. signature.asc Description: PGP signature

Bug#883677: [pkg-cryptsetup-devel] Bug#883677: upstart files not removed on upgrade

Control: tag -1 pending Hi Laurent, On Wed, 06 Dec 2017 at 12:40:33 +0100, Laurent Bigonville wrote: > I see that the upstart files are not shipped in the package anymore, but > these files are not removed from the installed system on upgrade: > > /etc/init/cryptdisks.conf e5527ceb5c020174a6464b

Bug#883620: [Pkg-roundcube-maintainers] Bug#883620: roundcube: Since the last upgrade, attachment can't be sent anymore

On Thu, 07 Dec 2017 at 13:25:07 +, Holger Levsen wrote: > On Tue, Dec 05, 2017 at 08:50:17PM +0100, Jean-Philippe Guérard wrote: >> * What was the outcome of this action? >> The attachment is not on the sent message, neither on the >> stored copy in the sent folder. > > that's a pret

Bug#901830: cryptsetup-initramfs: warning after upgrade cryptsetup-initramfs (update-initramfs -u / boot process)

Hi Antonio, On Tue, 19 Jun 2018 at 08:31:39 +0200, Antonio wrote: > $ update-initramfs -u > cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries > nor crypto modules. If that's on purpose, you may want to uninstall the > 'crypsetup-initramfs' package in order to disable the

Bug#901830: cryptsetup-initramfs: error at initramfs stage when cryptsetup is not included to the initrd

Control: severity -1 minor Control: retitle -1 On Tue, 19 Jun 2018 at 15:06:40 +0200, Antonio wrote: > The boot problem is that you include file "/lib/cryptsetup/functions" > [scripts: hooks/cryptgnupg, hooks/cryptopensc, hooks/cryptroot under > /usr/share/initramfs-tools] but when generate initr

Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep

On Tue, 19 Jun 2018 at 21:39:06 +0200, Adrien CLERC wrote: > Fortunately, the previous one has still a valid initramfs, so I can boot > my system (many thanks for that backup system). > […] > Check that kernel supports aes-xts-plain64 cipher (check syslog for > more info). Could you run the follow

Bug#901884: [pkg-cryptsetup-devel] Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep

On Tue, 19 Jun 2018 at 22:40:23 +0200, Guilhem Moulin wrote: > FWIW 2.0.3-2 was tested with MODULES=dep, too. I wonder how your system > differs from our test environments. Just noticed what looks like a regression, I wonder if that's the same problem. Does your system have AES-NI

Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep

On Tue, 19 Jun 2018 at 23:00:29 +0200, Adrien CLERC wrote: > Le 19/06/2018 à 22:40, Guilhem Moulin a écrit : >> Could you run the following on both the broken and backup initrd and >> send the diff? >> >> lsinitramfs /path/to/initrd.img | grep ^

Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep

On Tue, 19 Jun 2018 at 23:52:45 +0200, Guilhem Moulin wrote: > Sorry, I meant between your backup initrd.img (presumably also compiled > with MODULES=dep) and the new, broken one. Alternatively, if you don't have this initrd around anymore, are you able to boot if you add the ‘xts’ mo

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 cip

Bug#902123: finish-install: `update-initramfs -u` needs proc(5) and sysfs(5) resp. mounted to /proc and /sys for the cryptsetup hook

Package: finish-install Version: 2.94 Severity: important Hi there, Upgrading to cryptsetup ≥2:2.0.3-2 from d-i might yield an unbootable system if the initramfs image is updated at finish-install stage. That's because the cryptroot hook script is now relying on pseudo-filesystems proc(5) (for /

Bug#902123: finish-install: `update-initramfs -u` needs proc(5) and sysfs(5) resp. mounted to /proc and /sys for the cryptsetup hook

On Fri, 22 Jun 2018 at 17:30:43 +0200, Guilhem Moulin wrote: > Upgrading to cryptsetup ≥2:2.0.3-2 from d-i might yield an unbootable system > if the initramfs image is updated at finish-install stage. This was not the only thing need to fix the cryptsetup initramfs integration from d-i,

Bug#902183: cryptsetup-initramfs: "ERROR: Couldn't find sysfs hierarchy for /dev/sda1"

Control: tag -1 pending Control: retitle -1 cryptsetup-initramfs: "ERROR: Couldn't find sysfs hierarchy for " Hi Chris, On Sat, 23 Jun 2018 at 08:45:54 +0100, Chris Lamb wrote: > cryptsetup: ERROR: Couldn't find sysfs hierarchy for /dev/sda1 > cryptsetup: ERROR: Couldn't find sysfs hierarchy for

Bug#902183: cryptsetup-initramfs: "ERROR: Couldn't find sysfs hierarchy for /dev/sda1"

On Sat, 23 Jun 2018 at 20:41:34 +0100, Chris Lamb wrote: >> Nope, removing 'cryptsetup-initramfs' was the right thing to do since >> you don't need to unlock anything at initramfs stage. > > Out of interest, assuming I *did* actually use cryptsetup (!) would it > have resulted an unbootable system

Bug#902245: cryptsetup: Broken volume in initrd with decrypt_gnupg and plain dm-crypt

Control: retitle -1 plain dm-crypt: crypttab's 'size=' option sets the device size not the key size Control: reassign -1 cryptsetup-run Control: tag -1 pending Hi, On Sat, 23 Jun 2018 at 16:31:09 -0400, skodde wrote: > root /dev/device /path/to/key.gpg > cipher=aes-xts-plain64,size=256,hash=pla

Bug#902116: regression: keyscript=decrypt_keyctl doesn't cache passphrase anymore

Control: retitle -1 off-by-one error in CRYPTTAB_TRIED breaks decrypt_keyctl keyscript (doesn't cache anymore) Control: tag -1 pending Hi Andras, On Fri, 22 Jun 2018 at 15:36:26 +0200, Andras Korn wrote: > This had the result that I was prompted for the passphrase for sda3 during > the initramfs

Bug#901795: cryptsetup: new version may break 3rd party keyscripts (and thus boot)

On Mon, 25 Jun 2018 at 05:19:48 +0200, Christoph Anton Mitterer wrote: > On Tue, 2018-06-19 at 00:26 +0200, Guilhem Moulin wrote: >> Thus lowering the bug severity to ‘wishlist’ and retiling the bug >> accordingly. > > Well... it still broke some existing setups... it was alw

Bug#901795: cryptsetup: new version may break 3rd party keyscripts (and thus boot)

On Tue, 26 Jun 2018 at 03:28:17 +0200, Christoph Anton Mitterer wrote: > If you like I can send you the full set of scripts&hooks for review. Just open a wishlist bugs and everybody will be able to look at it? :-) >> Right now we'd like things to settle a bit, and fixing actual >> regression >> h

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

Control: severity -1 wishlist Hi, On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote: > cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian > cryptsetup: ERROR: Couldn't find sysfs directory corresponding to > rpool/ROOT/debian I guess you had a fake line for that devi

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

On Wed, 27 Jun 2018 at 13:44:23 +0200, Fabian Grünbichler wrote: > On Wed, Jun 27, 2018 at 12:56:04PM +0200, Guilhem Moulin wrote: >> On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote: >>> cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian >>

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 se

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

Hi Michal, On Tue, 03 Jul 2018 at 18:23:12 +0200, Michal Humpula wrote: > Entry in /proc/mounts for ZFS is different as it refers to the actual ZFS > filesystem not to the devices of the underlying zpool. Which, from my point > of > view, makes more sense. Do you see a way to export all the req

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

On Thu, 05 Jul 2018 at 11:05:08 +0200, Michal Humpula wrote: >> Since ZFS doesn't expose a block device one would need another >> documented way to resolve /sys/fs/zfs/$FS. Hopefully ‘tank/my/fs’ is >> unique and can't be aliased to something else, can it? > >> Do the slash characters in ‘tank/my

Bug#885905: [Pkg-roundcube-maintainers] Bug#885905: roundcube: Update backports?

Hi, On Sun, 31 Dec 2017 at 18:36:05 +1100, Dean Hamstead wrote: > It would be amazing if you could update the backport of jessie. Upload of 1.1.5+dfsg.1-1~bpo8+6 was rejected, the backport folks asked us to backport and upload 1.2.3+dfsg.1-4~bpo8+1 instead. Unfortunately the 1.2 branch adds more

Bug#923513: [pkg-cryptsetup-devel] Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

Control: found -1 2:2.1.0-1 Hi Christoph, On Fri, 01 Mar 2019 at 11:09:53 +0100, Christoph Biedl wrote: > Declare usage of format 1 like in > > $ echo -n foo | cryptsetup luksFormat --type luks1 /tmp/blob - > > and possibly some other ways. FWIW the regression isn't directly tied to the new

Bug#926573: cryptsetup-{initramfs,run}: decrypt_opensc regressions

Package: cryptsetup-run Version: 2:2.0.3-2 Severity: important Since 2.0.3-7 the ‘opensc’ keyscript breaks if `opensc-tool -n` writes to the standard out. Since 2.0.3-2 the initramfs hook fails to copy ‘libpcsclite.so’ to the initramfs. https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_

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

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 contex

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

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 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#927165: debian-installer: improve support for LUKS

Hi Cyril, [crytsetup team member here] On Mon, 15 Apr 2019 at 21:40:35 +0200, Cyril Brulebois wrote: > There are also some other highlights in this changelog entry, regarding > key sizes, and some update to partman-crypto might be needed… GRUB stuff aside? AFAICT not, but FWIW we poked debian-b

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

On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote: > Guilhem Moulin (2019-04-15): >> On Mon, 15 Apr 2019 at 21:40:35 +0200, Cyril Brulebois wrote: >>> There are also some other highlights in this changelog entry, regarding >>> key sizes, and some update

Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

Hi Jonas! On Mon, 07 Jun 2021 at 21:54:50 +0200, Jonas Meurer wrote: >> I'm not sure how what the best way to proceed for Bullseye. Jonas, >> what's your take about this? > > First sorry for not responding earlier. I simply missed this mail in my > backlog :-/ No worries! > I would suggest to

Bug#981405: [pkg-cryptsetup-devel] Bug#981405: man crypttab file conflict with systemd

Hi Michael, On Sat, 30 Jan 2021 at 18:05:23 +0100, Michael Biebl wrote: > This is unfortunate though. Since systemd is our default init system, > the man page for /etc/crypttab should reflect what's supported. In my view it's more nuanced than this: our default initramfs is initramfs-tools, and A

Bug#981716: roundcube-core: /usr/share/roundcube/bin/cleandb.sh aborts with php 7.4

Control: tag -1 unreproducible moreinfo On Wed, 03 Feb 2021 at 18:53:27 +1100, Russell Coker via Pkg-roundcube-maintainers wrote: > # /usr/bin/php7.4 /usr/share/roundcube/bin/cleandb.sh > PHP Fatal error: Uncaught Error: Call to undefined function > mb_internal_encoding() in > /usr/share/round

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

Control: tag -1 moreinfo Hi, On Sun, 05 Sep 2021 at 16:37:00 +0200, Lukas Schwaighofer wrote: > I noticed that LV activation done as part of the provided initramfs > scripts disregards the activation/auto_activation_volume_list setting > in /etc/lvm/lvm.conf. > > To fix the issue please consider

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

Control: tag -1 - moreinfo Control: severity -1 minor On Sun, 05 Sep 2021 at 20:13:03 +0200, Lukas Schwaighofer wrote: > On Sun, 5 Sep 2021 17:04:06 +0200 Guilhem Moulin wrote: > Without the suggested patch it's impossible to prevent some LVs that > share the same volume group as

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

Hi, On Thu, 09 Sep 2021 at 00:54:51 +0200, Christoph Anton Mitterer wrote: > I've just wondered whether the way you've mentioned above is still > valid respectively considered "stable" now (as it: for use by > keyscripts)? :-) Well we've never received any follow-up regarding a stable interface a

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

On Sat, 11 Sep 2021 at 01:31:31 +0200, Christoph Anton Mitterer wrote: > I mean in a keyscript, CRYPTTAB_* are anyway already set for the > "current" target, right? > And in a initramfs hook, I anyway need to loop over all of them... or > at least I wouldn't have a particular (target) name to searc

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

On Sat, 11 Sep 2021 at 17:12:17 +0200, Christoph Anton Mitterer wrote: >>> For which fields are the octal escapes handled? The manpage only >>> mentions them for them for the key/3rd field. >> >> My bad, it's supported in all fields. > > Are you going to correct it or shall I provide a patch for

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

On Sat, 11 Sep 2021 at 17:12:17 +0200, Christoph Anton Mitterer wrote: > VALUE="$(printf '%b' "$VALUE")" > ###=> is this the place where you unescape? > ### then the documentation is wrong, casue %b doesn't only unescape octal > sequences, right? Not wrong in my view, but incomplete a

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

On Sat, 11 Sep 2021 at 18:31:33 +0200, Christoph Anton Mitterer wrote: > On Sat, 2021-09-11 at 18:06 +0200, Guilhem Moulin wrote: >> Not wrong in my view, but incomplete and using undocumented escape >> sequences yields unspecified behavior. > > Well the problem is simply th

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

On Sat, 11 Sep 2021 at 20:26:57 +0200, Christoph Anton Mitterer wrote: > On Sat, 2021-09-11 at 20:06 +0200, Guilhem Moulin wrote: >>   So either I misremembered testing >> this at the time, or something changed meanwhile :-)  I'd argue that >> ‘\’ >> is a special c

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

On Sat, 11 Sep 2021 at 22:01:52 +0200, Christoph Anton Mitterer wrote: > Well then best is probably to e.g. document the \0xxx and mention that > any other use of \ needs to have that quoted or it may have a special > meaning? Right, that's what I was hinting at in https://bugs.debian.org/901795#1

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

Control: tag -1 moreinfo Hi, On Sun, 12 Sep 2021 at 08:19:10 -0400, Steve Dondley via Pkg-roundcube-maintainers wrote: > I set the $config['search_scope'] to a value of 'all' in the configuration > file so that the "Scope" field should default to "All folders." This feature > is broken. When swi

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

On Sun, 12 Sep 2021 at 09:57:06 -0400, Steve Dondley via Pkg-roundcube-maintainers wrote: > So it doesn't appear the a minified version of the code is the problem. It > just looks to me like app.min.js is using bad code and app.js is using good > code. app.min.js is generated at built time from a

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

On Sun, 12 Sep 2021 at 13:02:41 -0400, Steve Dondley via Pkg-roundcube-maintainers wrote: > That said, there must still be a bug because roundcube is supposed to > remember the search scope feature from the $_SESSION variable and it's not > doing that. Looking at the PHP code, roundcube is most ce

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

On Sun, 12 Sep 2021 at 14:16:58 -0400, Steve Dondley via Pkg-roundcube-maintainers wrote: > What's the easiest way to get my hands on the original file from the > package? We don't have Debian-specific modification, so you can simply take it from upstream. $ curl -Ls https://github.com/roun

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

On Sun, 12 Sep 2021 at 15:10:18 -0400, Steve Dondley via Pkg-roundcube-maintainers wrote: > On 2021-09-12 02:58 PM, Steve Dondley wrote: >>> Here is my version of app.js: >>> https://gist.github.com/sdondley/9db6dbffb8fb751c4afcd1092ab24fd0 >> >> Alright, so all confusion is from the fact that I

Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

Hi, On Tue, 14 Sep 2021 at 03:39:29 +0200, Christoph Anton Mitterer wrote: > AFAIK, keyscripts are always loaded from /lib/cryptsetup/scripts/, right? > > Likey the check= option, keyscript= should either support to specify a full > path and/or cryptsetup should support alternative location(s).

Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

On Tue, 14 Sep 2021 at 15:06:22 +0200, Christoph Anton Mitterer wrote: > On Tue, 2021-09-14 at 12:50 +0200, Guilhem Moulin wrote: >> It ought to be documented though. > > Tell me when it helps you if I provide a patch for the manpage. That would have been welcome but I tweaked t

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 credentia

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

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#994610: cryptsetup: creation/cleanup of /etc/crypttab

On Sat, 18 Sep 2021 at 16:30:38 +0200, Christoph Anton Mitterer wrote: > On Sat, 2021-09-18 at 16:04 +0200, Guilhem Moulin wrote: >> src:cryptsetup isn't the only consumer of /etc/crypttab, so this is a >> wontfix. > > Who else uses it that can work without cryptsetup? S

Bug#994610: cryptsetup: creation/cleanup of /etc/crypttab

On Sat, 18 Sep 2021 at 17:04:41 +0200, Guilhem Moulin wrote: > I don't see why it makes more sense to og-rwx /etc/crypttab by default > compared to /etc/fstab or /etc/systemd/system. If that makes sense in > YOUR environment, then YOU are free to do it manually Note however that

Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

On Sun, 19 Sep 2021 at 02:12:18 +0200, Christoph Anton Mitterer wrote: > Did I observe correctly, and cryptroot places *any* keyscript into: > /lib/cryptsetup/scripts/ > ? No. How did you test this? -- Guilhem. signature.asc Description: PGP signature

Bug#988216: unblock: lacme/0.8.0-2

Don't delete system users on purge. There might be files +on disk owned by _lacme-client when 'challenge-directory' is set in the +configuration (closes: #988032). + + -- Guilhem Moulin Tue, 04 May 2021 01:37:13 +0200 + lacme (0.8.0-1) unstable; urgency=low * New upst

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

Control: tag -1 moreinfo On Sun, 09 May 2021 at 01:48:16 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote: > If you manually run dpkg-reconfigure roundcube-core, then the full > installation > script is run and you are asked to specify the connection method. The default > method purports

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

On Sun, 09 May 2021 at 11:39:16 -0300, Kurt Fitzner wrote: > After running dpkg-reconfigure roundcube-core I find that > /etc/dbconfig-common/roundcube.conf remains unchanged, with the relevant > bits as follows: > > # dbc_dbserver: database host. > #leave unset to use localhost (or a more eff

Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active

Control: reassign -1 roundcube-core 1.4.11+dfsg.1-3 On Sat, 08 May 2021 at 09:07:26 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote: > On systems with lighttpd, the installer should detect if fastcgi-php-fpm is > already active and if so, should not subsequently activate fastcgi-php. Tha

Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active

On Sun, 09 May 2021 at 17:48:28 +0200, Guilhem Moulin wrote: > That said I'm not sure to how to fix this. I'm not really familiar with > lighttpd but I don't see a way to list enabled modules other than > looking in /etc/lighttpd/conf-enabled which I'm not really

Bug#988236: Likely the best solution

On Mon, 10 May 2021 at 23:19:51 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote: > I think you've lighted (hah) upon the best solution here. I don't really like it as it makes assumptions about another namespace/ interface. There is also no guaranty that fastcgi handlers for .php match t

Bug#988452: Can't unlock keys with passphrase during boot after upgrade to kernel 5.10.0

Control: tag -1 + unreproducible moreinfo On Thu, 13 May 2021 at 11:51:14 +0200, Grzegorz Bizon wrote: > I will be happy to provide more information if needed. Yes please :-) And please also use reportbug(1) so we get a list of installed dependencies along with their version. Note that if your

Bug#949336: integritysetup: volume formatted with 2.0.4 might not open with ≥2.0.5 (different key truncation)

Control: forwarded -1 https://gitlab.com/cryptsetup/cryptsetup/-/issues/648 Control: retitle -1 integritysetup: volume formatted with 2.0.4 might not open with ≥2.0.5 (different key truncation) Control: found -1 2:2.0.5-1 Control: severity -1 normal On Wed, 12 May 2021 at 18:25:20 +, n...@wai

Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active

On Mon, 10 May 2021 at 20:30:42 +0200, Guilhem Moulin wrote: > On Sun, 09 May 2021 at 17:48:28 +0200, Guilhem Moulin wrote: >> That said I'm not sure to how to fix this. I'm not really familiar with >> lighttpd but I don't see a way to list enabled modules other th

Bug#949336: integritysetup: volume formatted with 2.0.4 might not open with ≥2.0.5 (different key truncation)

Control: retitle -1 integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode Control: severity -1 important On Thu, 13 May 2021 at 17:46:26 +0200, Guilhem Moulin wrote: > Fortunately there are no Debian releases with integritysetup ≤2.0.4 so > as far as Debian is con

Bug#988282: [Pkg-roundcube-maintainers] Bug#988282: Testing

On Mon, 17 May 2021 at 20:54:00 -0300, kurt--- via Pkg-roundcube-maintainers wrote: > Will this make it into bullseye/testing? See https://bugs.debian.org/988236#12 . I'll file an unblock request for 1.4.11+dfsg.1-4. Whether it'll make it into Bullseye is up to the Release Team. -- Guilhem.

Bug#988701: unblock: roundcube/1.4.11+dfsg.1-4

closes: #988282). + * d/roundcube-core.postinst: lighttpd: Don't enable fastcgi-php if there is +already an enabled fastcgi .php handler (closes: #988236). + * d/uupdate: Fix comment. + + -- Guilhem Moulin Mon, 17 May 2021 20:45:48 +0200 + roundcube (1.4.11+dfsg.1-3) unstable; urgency=

Bug#988704: piuparts.debian.org: scripts/pre_install_database-server fails to start MariaDB/MySQL

Package: piuparts.debian.org Severity: normal Dear Maintainer, I believe https://piuparts.debian.org/sid2experimental/fail/roundcube-core_1.5~beta+dfsg.1-3.log is a false positive: scripts/pre_install_database-server installs default-mysql-server but fails to start it: 0m8.1s DEBUG: Starti

Bug#989140: roundcube-core: Error displayed during upgrade if manually installed plugins are in use in /var/lib/roundcube

On Wed, 26 May 2021 at 13:25:21 -0300, Kurt Fitzner wrote: > During an upgrade of roundcube-core, if there are any manually installed > plugins in /var, then an error is shown: Thanks for the report! > It may be a disply-only error with no actual ramifications. AFAICT that's correct, load_plugi

Bug#884992: roundcube-plugins: No documentation to enable plugins

On Wed, 26 May 2021 at 12:16:14 -0500, Jonathan Hutchins wrote: > Thank you for pointing me to the correct information. I'm not sure it was > there when I originally installed the package. 1.2.3+dfsg.1-4+deb9u1 has this information as well. Note that /usr/share/doc/$PACKAGE/README.Debian is the

Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

Hi and thanks Milan for releasing the fix! I'm not sure how what the best way to proceed for Bullseye. Jonas, what's your take about this? I tried to summarize the regression at https://gitlab.com/cryptsetup/cryptsetup/-/issues/648#note_575895772 . (Note that the truncation doesn't affect LUKS o

Bug#970800: lacme: allow direct use challenge-directory .well-known/acme-challenge

Control: tag -1 pending Hi, On Wed, 23 Sep 2020 at 17:22:32 +0200, Benjamin Tietz wrote: > in our setup multiple http-servers can be used to serve a random file. > For the static files, the storage is syncronized filesystem replication. > > When lacme creates a challenge-response for a new certi

Bug#985581: cryptsetup-bin: Interactive passphrases over 64-bytes long are not read correctly under kernel 5.10.20/5.11.3

Package: cryptsetup-bin Version: 2:2.3.4-2 Severity: important Tags: upstream fixed-upstream Control: fixed -1 2:2.3.5-1+exp1 Control: forwarded -1 https://gitlab.com/cryptsetup/cryptsetup/-/issues/627 From 2.3.5 release notes and :

Bug#983708: passdev and systemd use conflicting syntax for keyfile

Control: reassign -1 systemd 247.3-1 Control: retitle -1 systemd-cryptsetup@.service should ignore targets that are already mapped Hi, On Sun, 28 Feb 2021 at 19:11:56 +0100, schaa...@gmx.de wrote: > Package: cryptsetup-initramfs > Version: 2:2.3.4-2~bpo10+2 > > systemd 247.2-5~bpo10+1 > > I r

Bug#981405: man crypttab file conflict with systemd

Hi Michael, On Sat, 30 Jan 2021 at 19:34:46 +0100, Michael Biebl wrote: > Do I take it, that you do not consider renaming the Debian specific crypttab > man page an option? Correct: as written earlier I believe the current manual is more likely to be useful for our users (given initramfs-tools is

Bug#985866: roundcube-core: broken symlink: /usr/share/roundcube/skins/elastic/deps/less.min.js -> ../../../../javascript/less/less.min.js

Hi, On Thu, 25 Mar 2021 at 08:56:22 +0100, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > […] > 1m6.0s ERROR: FAIL: Broken symlinks: > /usr/share/roundcube/skins/elastic/deps/less.min.js -> > ../../../../javascript/less/less.m

Bug#985629: Bug#981405: unblock (pre-approval): cryptsetup/2:2.3.5-1

Control: tag -1 - moreinfo Hi Paul, On Fri, 02 Apr 2021 at 22:33:05 +0200, Paul Gevers wrote: > I'm not overly enthusiastic about the size of the diff, but indeed this > seems like something we'd want. > > Please go ahead and remove the moreinfo tag once the upload has happened. Done, many than

Bug#970208: mhonarc: -gzipfiles flag yields partially broken archives when the temporary filename ends with '_z'

Package: mhonarc Version: 2.6.19-2 Severity: normal Tags: patch upstream Dear Maintainer, When ‘-gzipfiles’ [0] is set, MHonArc generates a temporary file on which to call gzip(1) afterwards. The template doesn't include a suffix so there is no guaranty that the filename won't end with ‘.gz’, ‘-

Bug#970209: mhonarc: -conlen mbox parsing breaks on messages with last line starting with "From " (despite Content-Length)

Package: mhonarc Version: 2.6.19-2 Severity: normal Tags: patch upstream Dear Maintainer, Consider the attached UUCP-style mbox, where for each message the byte-length of its body is indicated with a Content-Length: header. The ‘-conlen’ [0] flag is meant to make MHonArc read the correct body len

Bug#970394: Content-Length: headers of excluded messages are ignored (yielding bogus archives)

Package: mhonarc Version: 2.6.19-2 Severity: normal Tags: patch upstream Dear Maintainer, Consider the attached UUCP-style mbox, where for each message the byte-length of its body is indicated with a Content-Length: header. The ‘-conlen’ [0] flag is meant to make MHonArc read the correct body le

<    1   2   3   4   5   6   7   8   9   10   >