On Sun, 29 Mar 2020 at 18:02:00 +0200, Guilhem Moulin wrote:
>> Using TCP, ^D to server nc has no visible efect. Maybe an update to your
>> patch
>> can fix this also. I will investicate over the next few days.
>
> Sorry, my bad for claiming earlier that ‘-q0’ wa
Control: tag -1 - upstream
Hi Duncan,
On Sun, 08 Mar 2020 at 14:25:50 +1100, Duncan Roe wrote:
>> The enclosed patch seems to work for me. (Untested though, so not
>> pushing just yet.)
>
> Good idea not to apply that patch. After applying, I can send server nc into a
> hard loop by entering
Control: usertag -1 bsp-2020-03-se-gothenburg
Hi,
On Thu, 18 Oct 2018 at 21:19:51 +0300, Antti Kuparinen wrote:
> Lines are sometimes drawn with one end extending to lower left.
> Rendering the same input might usually look fine, but fail randomly.
> Example input and output of 100 iterations
.
+ * 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
Control: tag -1 pending
On Wed, 25 Mar 2020 at 09:32:38 -0400, tho...@habets.se wrote:
> I have now made patches for TCP_MD5SIG that fixes both of these
> issues.
Thanks, applied:
https://salsa.debian.org/debian/netcat-openbsd/-/commit/04482d7bdaa49dfef2126683b017c1e8d5047525
.
> I have
Control: tag -1 patch
On Fri, 06 Mar 2020 at 17:50:38 +0100, Guilhem Moulin wrote:
> Also, calling exit() in fillbuf() is the wrong approach as the buffer
> might not have been drained yet.
The enclosed patch seems to work for me. (Untested though, so not
pushing just yet.) Since f
On Fri, 28 Feb 2020 at 05:40:10 +, jnq...@gmail.com wrote:
> edit: ah, so I see there were two reorganisations, one in June 2018 and
> one more in June 2019...
More precisely, one two-steps reorganisation with a Debian release in
between ;-)
> Indeed if I had performed a
On Thu, 27 Feb 2020 at 23:55:49 +, jnq...@gmail.com wrote:
> It is thus not a question of 'FrankenDebian' but of how old a sid
> installation upgrading is supported for.
The starting baseline doesn't matter, if you start from sid and don't
upgrade for longer than a full recycle, then most of
Control: retitle -1 unsupported upgrade from ```
> dpkg: error processing archive
> /var/cache/apt/archives/cryptsetup_2%3a2.2.2-3_deb (--unpack):
> trying to overwrite '/usr/sbin/luksformat', which is also in package
> cryptsetup-bin 2:1.7.0-2
> ```
That seems to be an upgrade from a package
Control: found -1 1.2.3+dfsg.1-4+deb9u3
Control: severity -1 serious
Control: tag -1 + confirmed pending
Hi,
On Wed, 12 Feb 2020 at 10:40:22 +0100, Daniel wrote:
> After an `apt upgrade` which upgrade roundcube-core, the group of
> /etc/roundcube/config.inc.php
> has changed, set to www-data,
On Mon, 03 Feb 2020 at 13:22:44 +0100, Vincent Bernat wrote:
> The hack in cryptroot hook doesn't find it anymore.
FWIW a mitigation was meanwhile uploaded as cryptsetup-initramfs 2:2.2.2-3,
cf. #950628.
--
Guilhem.
signature.asc
Description: PGP signature
On Tue, 14 Jan 2020 at 03:22:20 +0100, Guilhem Moulin wrote:
> If there is a need for a complex logic I guess this could be done once
> and for all in /usr/share/initramfs-tools/hook-functions.
Quick follow up about this: asked Ben for feedback and he agreed that it
would make sense
Control: tag -1 pending
Hi there,
I believe
https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/863e91f0e763b92a5f70d84278116a28357e74eb
should fix this, but I had to refactor a bit so would appreciate some
extra tests before releasing the fix. You can apply the above manually
Package: initramfs-tools
Version: 0.136
Severity: wishlist
Dear Maintainer,
libthread appears to load libgcc_s via dlopen, so copy_exec() won't copy
it to the initramfs image. This causes pthread_cancel to fail with
LIBGCC_S_SO must be installed for pthread_cancel to work
On Wed, 29 Jan 2020 at 21:25:02 +0100, hede wrote:
> On Wed, 29 Jan 2020 20:17:28 +0100 Guilhem Moulin wrote:
>
>> Given upstream's loud warning in cryptsetup(8) “WARNING: All support for
>> authenticated modes is experimental”, fixing this is not personally
>>
Hi,
On Sun, 26 Jan 2020 at 17:34:50 +, hede wrote:
> I've switched to Authenticated Encryption, i.e:
> […]
> Nevertheless, the initramfs doesn't get created as expected.
Given upstream's loud warning in cryptsetup(8) “WARNING: All support for
authenticated modes is experimental”, fixing
Hi Christoph,
On Mon, 27 Jan 2020 at 07:23:02 +0100, Christoph Biedl wrote:
> As far as I understand however, while such a situation _can_ happen, it
> is not very likely.
FWIW our last heavy refactoring was in spring/summer 2018. We obviously
won't change the internal interface just “for fun”,
Hi,
On Sat, 25 Jan 2020 at 02:16:01 +0100, mar...@mitzlaff.eu wrote:
> I just faced a similar problem. I tried to install the roundcube 1.4.2 from
> Sid into my Buster system.
Doesn't seem to match Marc's environment.
> I think roundcube 1.4.2 needs a dependency to libjs-bootstrap4 (>=4.4.1).
On Wed, 22 Jan 2020 at 14:37:54 -0600, Mario Limonciello wrote:
> Would you mind suggesting something upstream with the relevant changes
> that make sense?
As written earlier in this bug our public interface for this kind of
things is to use keyscripts. See crypttab(5) for the few environment
Control: found -1 2:1.7.0-1
On Wed, 22 Jan 2020 at 23:28:37 +0100, Guilhem Moulin wrote:
> If that's a regression it's older than 2:2.0.3-1, AFAICT stretch has
> the same problem.
Before 2:1.7.0-1 the completion file was copied into
/etc/bash_completion.d, which AFAICT bash traverses and s
Control: tag -1 moreinfo
Control: severity -1 minor
On Wed, 22 Jan 2020 at 23:08:32 +0100, Christoph Anton Mitterer wrote:
> in .bashrc, and that's enough for all other completions... e.g. the one
> for cryptsetup work (more or less).
~$ foo looks for /usr/share/bash-completion/completions/foo
Control: tag -1 moreinfo
On Wed, 22 Jan 2020 at 22:31:49 +0100, Christoph Anton Mitterer wrote:
> Instead of possible device target names it just completes to
> the files of the local directories.
Works fine here, also as non-root. In a sid chroot:
~$ dd if=/dev/zero of=/tmp/disk.img bs=1M
Control: tag -1 + moreinfo
On Mon, 20 Jan 2020 at 21:25:56 +0100, Milan Broz wrote:
> but I definitely need a clear reproducer (with the latest stable - 2.2.2 or
> 2.3.0-rc0) - ideally with attached debug and system log.
> (Debug log will provide all versions I need - kernel and dm targets
On Mon, 20 Jan 2020 at 07:12:37 -0600, Mario Limonciello wrote:
> FYI, the newly released version 12 has initramfs support.
Hmm. I guess I'm part of the problem since I haven't found time to help
with this unfortunately, but on a quick look it appears that my comments
from msg#27 and msg#32
Control: tag -1 upstream
Hi,
On Sun, 19 Jan 2020 at 23:41:15 +, n...@waifu.club wrote:
> clarification: I am testing it with a volume I created and used with
> cryptsetup 2:2.0. With 2:2.1 and 2:2.2 integritysetup-open seems to succeed,
> but the embedded ext4 filesystem cannot be used.
Hi Guillem!
On Tue, 14 Jan 2020 at 02:01:09 +0100, Guillem Jover wrote:
> The problem I've got is that I upgraded to gcc-10 from experimental,
> which pulled in libgcc1-s1 and libgcc1 (that I later removed), neither
> of which install libgcc_s.so.1 under /lib/$MULTIARCH anymore. The first
>
Control: retitle -1 cryptsetup-initramfs: Can't open aes-cbc-essiv:sha256
dm-crypt targets with a 5.4 kernel and an initramfs built with MODULES=dep
Control: found -1 2:1.6.6-5
Control: tag -1 pending
Hi,
On Mon, 13 Jan 2020 at 08:47:43 +0100, Didier 'OdyX' Raboud wrote:
>> Devices formatted
Hi OdyX,
On Sat, 11 Jan 2020 at 11:56:35 +, Didier 'OdyX' Raboud wrote:
> From diffing the initramfs'es, I see that kernel/arch/x86/crypto/aes-x86_64.ko
> was present in 5.3.0-3 kernels, but not present anymore in 5.4.0-1 or 5.4.0-2
> kernels.
kernel/arch/x86/crypto/aes-x86_64.ko isn't in
Control: tag -1 unreproducible moreinfo
On Thu, 09 Jan 2020 at 23:39:57 +0900, Marc Dequènes wrote:
> The new Elastic theme dependencies cannot be loaded.
Works just fine for me with the supplied apache2 and lighttpd config
files, and also on nginx. Please use reportbug(1) next time, or at
On Fri, 10 Jan 2020 at 00:15:25 +0100, Guilhem Moulin wrote:
> But I guess we could ship symlinks though in case someone wants to
> manually install libjs-less.
Didn't recall I did precisely that last summer:
https://salsa.debian.org/roundcube-team/roundcube/
Control: tag -1 moreinfo
Hi,
On Fri, 10 Jan 2020 at 01:40:56 +0900, Marc Dequènes wrote:
> libjs-less is missing for the new Elastic theme.
Are clients being served .less files? The intention is to use the .css
files (compiled from the .less sources) instead. AFAICT .less files are
only used
Control: retitle -1 roundcube-core: Needs versioned dependency on
libjs-bootstrap4: >=4.4.1+dfsg1-1.
Control: tag -1 pending
Hi,
On Fri, 03 Jan 2020 at 11:10:06 +0100, Frederik Himpe wrote:
> I installed libjs-bootstrap4=4.4.1+dfsg1-1 which also pulled in an upgrade of
>
Hi Sandro,
On Tue, 24 Dec 2019 at 17:21:40 +0100, Sandro Knauß wrote:
> An IMAP server may have temporally issues, like to much load and roundcube
> fails with
> "Empty startup gretting".
Did you try to upstream that patch? Also FWIW the code snippet seems to
be unchanged since <1.0.0, AFAICT
Control: tag -1 pending
Control: retitle -1 interimap: typo in documentation: though → through
Hi,
On Sat, 14 Dec 2019 at 21:06:14 +0100, Jonas Smedegaard wrote:
> Reads more sensible to me with word "though" replaced by "through".
Ah yeah, thanks! Removed “html” in the title: the source, in
Hi josch,
On Wed, 20 Nov 2019 at 11:21:31 +0100, Johannes Schauer wrote:
> Indeed it would not. The autopkgtest does not even test upgrades. But when I
> re-installed the system after the upgrade failed I also was unsure in many
> points of how to do it correctly. The autopkgtest does not only
Control: severity -1 minor
Control: retitle -1 gpg-key2ps should list curve names for ECC keys rather than
$ALGO$LENGTH
Hi,
On Thu, 28 Nov 2019 at 21:59:18 +0200, Mikaela Suomalainen wrote:
> my key is printed as eddsa256/BAE30723, while I believe it should be
> ed25519 as reported by `gpg
Hi Jonas,
On Sun, 17 Nov 2019 at 21:19:21 +0100, Jonas Smedegaard wrote:
> I would love something geared towards standards-compliant IMAP,
> enabled by adding one interimap config line pointing to my notmuch
> database.
Such a MUA-specific feature is most likely a won't fix I'm afraid,
because
On Sun, 17 Nov 2019 at 20:54:47 +0100, Jonas Smedegaard wrote:
> Ohh - problem seems gone indeed now:
Woo! \o/
--
Guilhem.
signature.asc
Description: PGP signature
On Sun, 17 Nov 2019 at 19:35:51 +0100, Jonas Smedegaard wrote:
> Seems you edited above quote: I had a dot between INBOX and olpc - is
> that the "typo" you are talking about then the command I ran included
> that dot (as did the email I sent).
Oh sorry for that, my finger must have ripped as I
On Sun, 17 Nov 2019 at 17:54:23 +0100, Jonas Smedegaard wrote:
> Seems the "force-repair" command didn't make any change:
Grmbl, but seems you typoed the mailbox name:
> jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk 'doveadm force-resync
> INBOXolpc'
If it still doesn't work with the right
On Sun, 17 Nov 2019 at 17:12:54 +0100, Jonas Smedegaard wrote:
> local(INBOX.olpc): WARNING: No match for 1 vanished remote UID(s) 97.
> Ignoring.
This means the remote server send a VANISHED response for a message in
the “known range” (ie with UID strictly lower than the remote's cache
UIDNEXT
Control: tag -1 pending
On Sun, 17 Nov 2019 at 16:07:38 +0100, Jonas Smedegaard wrote:
> * 3396 FETCH (UID 97 MODSEQ (1) FLAGS () INTERNALDATE "01-Jan-1970 00:00:00
> +" BODY[] NIL)
Many thanks, that's the first time I see ‘BODY[] NIL’ in an untagged
FETCH response :-) That explains the
On Sun, 17 Nov 2019 at 15:20:51 +0100, Jonas Smedegaard wrote:
> Quoting Guilhem Moulin (2019-11-16 17:26:29)
>> On Sat, 16 Nov 2019 at 15:57:16 +0100, Jonas Smedegaard wrote:
>>> Seems interimap can generate commands exceeding what Dovecot can
>>> handle.
&g
On Sun, 17 Nov 2019 at 14:38:43 +0100, Jonas Smedegaard wrote:
> doveadm is easier to run as a oneliner (please do tell if interesting
> for you to have also the output of the raw imap commands):
In this case I'd like to see the IMAP server response so I can push a
fix for the “uninitialized
Control: severity -1 minor
On Sat, 16 Nov 2019 at 23:35:31 +0100, Jonas Smedegaard wrote:
> I guess you mean this:
> […]
> * 3396 FETCH (UID 97 MODSEQ (1) FLAGS ())
> jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk 'doveadm -f flow fetch "uid
> modseq flags" mailbox INBOX.olpc' | grep -w 97
>
On Sat, 16 Nov 2019 at 20:47:53 +0100, Jonas Smedegaard wrote:
> Doesn't seem succesful (I creatively prepended "a EXAMINE INBOX.olpc",
> hope that is correct):
Yup, sorry for the incomplete commands ;-)
> a UID FETCH 97 MODSEQ
> * OK [HIGHESTMODSEQ 17] Highest
> a OK Fetch completed (0.001 +
On Sat, 16 Nov 2019 at 18:19:37 +0100, Jonas Smedegaard wrote:
> Quoting Guilhem Moulin (2019-11-16 17:50:14)
>> On Sat, 16 Nov 2019 at 16:25:15 +0100, Jonas Smedegaard wrote:
>>> jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 |
>>
On Sat, 16 Nov 2019 at 16:25:15 +0100, Jonas Smedegaard wrote:
> jonas@auryn:~$ interimap --config debian --repair --debug INBOX.olpc 2>&1 |
> grep -Fw 97
> […]
> local(INBOX.olpc): WARNING: No match for modified remote UID 97. Downloading
> again.
> remote(INBOX.olpc): C: 04 UID FETCH 97
Control: tag -1 confirmed pending
On Sat, 16 Nov 2019 at 15:57:16 +0100, Jonas Smedegaard wrote:
> Seems interimap can generate commands exceeding what Dovecot can handle.
Ack, that's a long-standing bug which breaks syncronisation in some
scenarios, such as large mailboxes with many
On Fri, 15 Nov 2019 at 19:10:56 +0100, Jonas Smedegaard wrote:
> Use of uninitialized value $length in numeric eq (==) at /usr/bin/interimap
> line 955.
> remote(INBOX.olpc): WARNING: Ignoring new 0-length message (UID 97)
>
> Wanted to let you know in case it is a bug in your code (rather than
On Thu, 14 Nov 2019 at 19:13:59 +0100, Jonas Smedegaard wrote:
> Heh. What actually happened was that at first I ran
>
> interimap --config hb --delete --target=database INBOX
> […]
> Seems to me both local and remote INBOX UIDVALIDITY is now 1571588814:
I see, that explains it. No magic with
On Thu, 14 Nov 2019 at 14:01:33 +0100, Jonas Smedegaard wrote:
> interimap --config hb --delete --target=database,local INBOX
> interimap --config hb
>
> ..which seemingly succeeded in throwing away local copy of INBOX
That confuses me even more, ‘--target=database,local’ is a no-op for
0.4-1
Control: tag -1 pending
On Mon, 21 Oct 2019 at 00:26:58 +0200, Jonas Smedegaard wrote:
>> I can certainly add an option with a simple printf-like format to
>> customize the log :-)
>
> I was thinking something along the lines of printf-like hack, yes.
I took a hammer for this, and added a new
On Wed, 06 Nov 2019 at 12:44:08 +0100, Jonas Smedegaard wrote:
> It seems that interimap would do far better in such an extreme
> scenario, as it seems to syncronize small chunks at a time which would
> make it possible to continue-where-left-off in far smaller chunks than
> possible (or rather
Hi Jonas,
On Tue, 05 Nov 2019 at 13:55:59 +0100, Jonas Smedegaard wrote:
> $ interimap --config hb INBOX
> remote: ERROR: UIDVALIDITY changed! (1571588814 != 1154884797) Need to
> invalidate the UID cache.
>
> ..and it seems the --repair option doesn't do its job:
I guess naming that command
Package: chkrootkit
Version: 0.52-3
Severity: normal
File: /etc/cron.daily/chkrootkit
Tags: patch
Dear Maintainer,
As of Buster, chkrootkit's cron.daily script contains the following line [0]
eval $CHKROOTKIT $RUN_DAILY_OPTS | egrep -v -f "${IGNORE_FILE}" >
$LOG_DIR/log.today.raw 2>&1
Control: retitle -1 ITP: dropbear-rescue -- A set of initramfs scripts to add
and run dropbear when the system boots in rescue mode
Control: tag -1 - pending
On Sat, 26 Oct 2019 at 01:50:02 +0200, Guilhem Moulin wrote:
> Control: retitle -1 race condition: init-bottom script doesn't ab
Control: retitle -1 race condition: init-bottom script doesn't abort/cleanup
configure_networking()
Control: tag -1 pending
On Fri, 25 Oct 2019 at 02:26:39 +0200, Guilhem Moulin wrote:
> Ah right, I understand the problem now. Whether configure_networking()
> is run (at premount
Control: clone -1 -2
Control: reassign -2 dropbear-initramfs 2019.78-2
Control: retitle -2 race condition: init-bottom doesn't abort/cleanup
run_networking()
Control: severity -2 normal
On Thu, 24 Oct 2019 at 18:48:12 -0400, Anton Avramov wrote:
> However I've ran into a problem where if there
On Wed, 23 Oct 2019 at 16:04:31 -0400, Anton Avramov wrote:
> On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin, wrote:
>> Given the scope of this package, I strongly believe it'd make more sense
>> to merge it with src:dropbear rather than shipping a separate source
>> package.
On Mon, 21 Oct 2019 at 00:26:58 +0200, Jonas Smedegaard wrote:
> I syncronize multiple accounts into subdirs below ~/Maildir and track
> them as a whole using a single notmuch database.
AFAIK notmuch doesn't speak IMAP so unfortunately that approach breaks
layering. I'm unsure how well IMAP
Hi Anton,
[dropbear package maintainer here.]
On Mon, 21 Oct 2019 at 16:07:11 -0400, Anton Avramov wrote:
> For a long time now I've maintained servers remotely. One problem that
> I've faced is what when there is problem booting I lose ability to login
> remotely and help the person on
Control: tag -1 moreinfo
On Sun, 20 Oct 2019 at 17:58:55 +0200, Jonas Smedegaard wrote:
> Apparently interimap treats some mailboxes specially:
It shouldn't, one can trim the output of the LIST command with the
‘list-*’ options, and perform further filtering with ‘ignore-mailbox’,
but then all
Hej Jonas!
On Sun, 20 Oct 2019 at 17:54:39 +0200, Jonas Smedegaard wrote:
> I happily use interimap with multiple configs.
\o/ I'd be interested to hear about the topology of your system. I
confess that running multiple instances in parallel haven't crossed my
mind until a few months ago when
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 -
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
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
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
On Wed, 04 Sep 2019 at 19:54:51 +0200, Guilhem Moulin wrote:
> $ qemu-system-x86_64 -display none \
> -add-fd "fd=3,set=0" \
> -drive "file=/dev/fdset/0,format=raw,media=disk" \
> 3<>/tmp/disk.img
> qemu-system-x86_64: -drive file=
Package: qemu-system-x86
Version: 1:4.1-1
Severity: normal
File: qemu-system
Dear Maintainer,
Using a pre-opened file descriptor to a disk image no longer work as
documented (and as it used to with ≤1:3.1+dfsg-8~deb10u1):
$ touch /tmp/disk.img
$ qemu-system-x86_64 -display none \
Thanks, uploaded! Hope this makes it to 10.1 :-)
And again, many thanks for your work on Buster!
--
Guilhem.
signature.asc
Description: PGP signature
<->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 (2:2
thorizations, 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, adding support
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
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
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
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
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
tps://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.
+
+ -- Guilhem
Thanks, uploaded. And sorry the wall of text in the original report ^^
--
Guilhem.
signature.asc
Description: PGP signature
lot 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 support.) The diff also inclu
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 datacenter,
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
Package: apticron-systemd
Version: 1.2.1
Severity: normal
Dear Maintainer,
‘debian/dirs’ and ‘debian/manpages’ are only installed into the first
binary package acted on, namely apticron. Hence apticron-systemd is
lacking /usr/share/man/man1/apticron.1.gz and /var/lib/apticron/.
The latter in
Package: libcryptsetup12
Version: 2:2.1.0-7
Severity: important
Tags: upstream
(Cloning upstream issue #466 so we can track it for Buster, Bullseye and sid.)
Even when all (bound) key slots were removed from a LUKS header, the header is
still salvageable given a copy of the master key.
The
Control: severity -1 minor
Control: tag -1 pending
On Wed, 07 Aug 2019 at 09:16:33 -0400, Ian Kelling wrote:
> "You can unlock your rootfs on bootup remotely, using SSH to log in to
> the booting system while it's running with the initramfs mounted.
> Consult cryptsetup's
Control: retitle -1 cryptsetup-initramfs: hook files should give hints about
missing packages to install
Control: severity -1 minor
Hi,
On Sun, 04 Aug 2019 at 10:45:33 +0200, Sebastian Mohr wrote:
> After some debugging, I found out, that this script copies the file
> "/bin/keyctl" to the
Package: signify-openbsd-keys
Version: 2018.4
Severity: wishlist
Dear Maintainer,
I noticed you prepared a release with the keys for OpenBSD 66
https://salsa.debian.org/debian/signify-openbsd-keys/commit/14edcb216bf56cbeec6cf872042350488a75b1ab
but didn't follow with an upload to sid.
tramfs` if any volume needs to be unlocked at
| initramfs stage, i.e., holding /, /usr, and/or the resume device(s).
Cheers,
--
Guilhem.
From b72b0934eb4c729d5fef462bb832aec6665513c8 Mon Sep 17 00:00:00 2001
From: Guilhem Moulin
Date: Fri, 26 Jul 2019 23:24:33 +0200
Subject: [PATCH] finish.d/crypt
Control: severity -1 normal
On Sat, 08 Jun 2019 at 22:05:42 +0200, Guilhem Moulin wrote:
> Our (cryptsetup maintaining team) plan is to rename ‘cryptsetup-run’ to
> ‘cryptsetup’ once Buster is released, hence this bug should be RC at
> this point: with `apt-install cryptsetup` the
Control: reassign -1 cryptsetup-initramfs
Control: forcemerge -1 820888
Hi,
On Wed, 24 Jul 2019 at 12:42:45 +0200, Mátyás Csere wrote:
> The symptoms are exactly as described on:
> https://bugs.launchpad.net/debian/+source/cryptsetup/+bug/1830110
> The proposed patch works on Buster too.
Please
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
On Sun, 21 Jul 2019 at 21:57:09 -0300, Guilhem Moulin wrote:
> cryptsetup <2:2.0.3-1's (≤Stretch) functionalities have been subsumed
> by the combination of cryptsetup-run and cryptsetup-initramfs between
> 2:2.0.3-1 and 2:2.0.3-5 (Buster); and the combination of
> cryptsetup-run
Control: tag -1 pending
Hi,
On Sun, 21 Jul 2019 at 12:58:28 +0100, Simon McVittie wrote:
> My understanding is that it's fine for me to remove cryptsetup-run, because
> its functionality has been subsumed by the combination of cryptsetup and
> cryptsetup-initramfs?
Yup it's safe to remove
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
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
Control: tag -1 pending
On Thu, 08 Nov 2018 at 16:03:15 +0100, 21na...@gmail.com wrote:
> An encrypted (root) filesystem containing its key file can be unlocked by
> the initramfs image if the value of the variable “KEYFILE_PATTERN”, in the
> file “/etc/cryptsetup-initramfs/conf-hook”, matches
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
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).
Control: retitle -1 `cryptroot-unlock` timeouts when Kali's
cryptsetup-nuke-password package is installed
On Mon, 15 Jul 2019 at 07:05:46 +, Luke Flinders wrote:
> This is the package;
> https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys
Oh, didn't you mean
401 - 500 of 1057 matches
Mail list logo
