Bug#1081133: fortunes: Offensive fortune in kids file

Package: fortunes Version: 1:1.99.1-7.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I was just presented with a fortune I found offensive. I hesitate a bit because I don't want to whine, but I'd really rather see it go. The kids file contains: > Beat your

Bug#978712: libneon27-gnutls: Should not treat missing OCSP stapling as error

Package: libneon27-gnutls Version: 0.30.2-3 Severity: normal Tags: patch Hello maintainers! Since a little while ago, I could no longer synchronize my laptop with my Radicale server: What happens: --8<---cut here---start->8--- $ syncevolution radicale [WARNIN

Bug#923880: ssh: IPQoS defaults change interacts badly with iptables -m tos

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > We can make it more concrete. Let's create an iptables rule with > numerical values that matches DSCP CS6, which corresponds to IP > Precendence 6, numerical value 0xC0, where in the terms of RFC 1349 bits > 0 and 1 are set in the PRECEDENCE portio

Bug#923880: ssh: IPQoS defaults change interacts badly with iptables -m tos

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 6 Mar 2019 18:15:41 +0100 Helmut Grohne wrote: > This suggests that iptables' ECN mask is wrong. It should be using > 0xfc rather than 0x3f. Yes, I'm convinced the mask is wrong. However, fixing that would change the behaviour of already de

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

Hello Adam, On 15/03/2019 07:44, Adam D. Barratt wrote: > Feedback would be appreciated I used the following two files to construct an installer SD card: http://ftp.nl.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/20170615+deb9u5+b3/images/netboot/SD-card-images/firmware.

Bug#924129: debian-installer: Kernel for armhf for stretch unbootable

Package: debian-installer Version: 20170615+deb9u5+b2 Severity: grave Justification: renders package unusable Dear maintainers, Debian kernel bug #922478 renders armhf systems unbootable. This bug was fixed, but the debian-installer images still use (I presume) kernel version 4.9.144-3, the unboo

Bug#890408: dirvish: last character gobbled when tree alias is used

On 23/01/2019 13:32, Paul Slootman wrote: > This can be solved with a "zero-width negative lookbehind assertion" > (yes I needed the perlre manpage to look that up...). Of course! I didn't know the name by heart either :-), but I knew the concept. It must have slipped my mind at the time. > I'll

Bug#903163: Adding OpenPGP smartcard support to LUKS

Hi, On 21/11/2018 17:46, Guilhem Moulin wrote: > Peter last poked Werner on Nov 09 but there wasn't any reply from him. > (At least not on the gnupg-users list.) Nope, no reply, unfortunately. > Hmm on second thought the offer is tempting; if you're also attending > 35c3 then shipping won't even

Bug#903163: Adding OpenPGP smartcard support to LUKS

On 08/11/2018 02:07, Guilhem Moulin wrote: > However that doesn't happen currently because I'm really worried about > copying real private key material to the initramfs along with the stubs; > GnuPG upstream was asked about a documented API to retrieve the stubs > but hasn't answered yet AFAIK. I'

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 25/09/2018 02:10, Guilhem Moulin wrote: > Then shouldn't the following be enough, and > save a temporary file? > > `| gpg --no-default-keyring --keyring … --trust-model=always --import` I thought so but was wrong. Without relocating trustdb.gpg to somewhere else, it will lose all informat

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 24/09/2018 11:42, Guilhem Moulin wrote: > Sure, me too :-) But I'm afraid of ending up in a situation similar to > caff(1)'s, where in order to avoid maintaining two sets of conf files > some users end up symlinking them (or blindly copying them). I hadn't > thought of scdaemon.conf, but at le

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 23/09/2018 17:02, Guilhem Moulin wrote: > I was thinking about something like that, and that's why I was referring > to by “the complexity is not worth it IMHO”. `--list-secret-keys` > implicitly launches gpg-agent(1) for that homedir, which will need to be > shut down afterwards (unless it was

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 23/09/2018 13:32, Peter Lebbing wrote: > How about copying the whole homedir without > random_seed, but first checking to make sure there are only smartcard > keys as private keys? O dear, this might not be enough. The agent can also hold non-OpenPGP keys. SSH keys are an example of

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 23/09/2018 13:32, Peter Lebbing wrote: > How about copying the whole homedir without random_seed, but first > checking to make sure there are only smartcard keys as private keys? However, we should specifically exclude openpgp-revocs.d as well. The whole "is the homedi

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

On 23/09/2018 05:58, Guilhem Moulin wrote: > Agreed, and implemented :-) This is awesome! :-) Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

can only manage daemons started with a default homedir. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> From 7957c591fc

Bug#903163: ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

By the way, I think it would be much cooler if GnuPG used pinentry-curses or pinentry-tty, rather than the current /lib/cryptsetup/askpass and --pinentry-mode loopback. That would also gracefully ask for the smartcard to be inserted if it were forgotten or the wrong one was inserted, and prompt the

Bug#903163: ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

Hi Guilhem and others, On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin wrote: > * Copying not only the (encrypted) key file and the public keyring, >but also the private-keys-v1.d directory, sounds very odd to me. >What is the rationale for doing so? First, a new GnuPG --homedir /etc/

Bug#890408: dirvish: last character gobbled when tree alias is used

Package: dirvish Version: 1.2.1-1.3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear maintainer, The "tree" configuration option accepts an "alias" which causes the index of all files in a vault to have a different path. There is a bug in an old bugfix which causes misparsin

Bug#877074: u-boot-exynos: Default environment for Odroid XU3 has wrong console var

On 28/09/17 20:17, Vagrant Cascadian wrote: > Will apply it to the next upload. Ah, great, thanks! Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at

Bug#877074: u-boot-exynos: Default environment for Odroid XU3 has wrong console var

Package: u-boot-exynos Version: 2017.09+dfsg1-1 Severity: normal Tags: patch The odroid-xu3 platform passes a wrong "console" argument on the kernel commandline: console=console=ttySAC2,115200n8 >From the source, it's clear where this comes from: include/configs/odroid_xu3.h: #define CONFIG_DEF

Bug#852318: lightning: Fake mtime in packaged files

On 28/01/17 20:42, Carsten Schoenert wrote: > then I don't understand your first email. Do I need to clarify more or did my follow-up mail already do that? > So I have currently no clue where the timestamps with *.0 are > coming from. Maybe I'm nitpicking, maybe I'm pointing out somethin

Bug#852318: lightning: Fake mtime in packaged files

Hello Carsten, On 28/01/17 17:15, Carsten Schoenert wrote: > we didn't ever have done some patching here. I did a quick search on the > upstream sources and found mozilla bug 1277976 which introduces this > change. While this sure is the change that made the mtime problem manifest with user-visib

Bug#852318: lightning: Fake mtime in packaged files

Package: lightning Version: 1:45.6.0-3 Severity: normal Dear maintainer, Some packaged files have fake, constant modification times, as can for instance be seen here: ll --full-time usr/lib/lightning/ total 40 -rw-r--r-- 1 peter peter 563 2010-01-01 01:00:00.0 +0100 app.ini drwxr-xr-x 2

Bug#844631: Ahh it's a Disaster

On 13/12/16 12:36, bob wrote: > What else can we who no-longer have a Windows partition do? Isn't it enough to install 55.0.2883.75-1~deb8u1 from jessie-security? >From the Debian changelog: > chromium-browser (55.0.2883.75-1~deb8u1) jessie-security; urgency=medium > > [...] > - Certificate

Bug#844631: Seem like Chromium issue 664177

I presume this is Chromium issue 664177 [1], which in Ubuntu is tracked as bug 1641380. It would appear a simple rebuild of the package is a stop-gap measure that helps, since it is a 10 week timebomb that start ticking on build time. HTH, Peter. [1] https://bugs.chromium.org/p/chromium/issues/

Bug#788704: gnutls28: VIA PadLock accelerated AES-CBC segfaults

Hello Andreas, On 20/06/15 14:07, Andreas Metzler wrote: > Would you mind testing the code I intend to try to get into stable? I tested the binaries (gnutls-bin, libgnutls-deb0-28) and they work in all AES modes, 128 or 256 bits, CBC and GCM. I used gnutls-cli to connect both to the SMTP server o

Bug#788704: gnutls28: VIA PadLock accelerated AES-CBC segfaults

As indicated by Nikos Mavrogiannopoulos on the gnutls-devel mailing list[1], this problem had been fixed upstream in 3.3.12. I had completely forgotten to check upstream for fixes. My suggested patch is almost exactly the same as commit 023156a from the GnuTLS Git[2]. I'd like to suggest backpor

Bug#788704: gnutls28: VIA PadLock accelerated AES-CBC segfaults

Source: gnutls28 Version: 3.3.8-6+deb8u1 Severity: normal Tags: patch Dear Maintainer, After upgrading a server with a VIA C3 (Nehemiah) processor to jessie, exim4 started to crash on pretty much every connection that negotiated AES-128-CBC or AES-256-CBC on TLS: > 2015-05-31T16:06:43.641909+02:

Bug#782505: libxrender1: dist-upgrade breaks on multiarch due to conflict on

Package: libxrender1 Version: 1:0.9.7-1+deb7u1+b1 Followup-For: Bug #782505 I reported the bug in parallel with this bug report, and the reports got merged. In my bug report, I indicated a temporary measure to actually install the new version with its security fix, but now that the bugs are merged

Bug#782507: libxrender1: i386/amd64 packages not co-installable

Package: libxrender1 Version: 1:0.9.7-1+deb7u1+b1 Severity: important Dear Maintainer, While trying to install version 1:0.9.7-1+deb7u1+b1 from wheezy-security for both amd64 and i386 on a multiarch machine, I got the following problem: - 8< >8 -

Bug#772857: signing-party: gpg-key2latex prints "cESC" on each fingerprint slip

On Thu, 11 Dec 2014 14:02:32 -0500 Brian Minton wrote: > When viewed with xpdf I > saw "cESC" (without the quotes) at the top right corner of each slip. These are the key capabilities, meaning: c - Certify on primary key E - Key is encryption capable S - Key can sign data C - Key can certify oth

Bug#772854: signing-party: QR code: too small quiet zone on large QR code

By the way, currently the QR code has a (L)ow error correction level. You can raise that to a (M)edium error correction level without the QR code getting any larger (the size of the fingerprint is fixed, so this will generally be true for an OPENPGP4FPR: URI). qrencode accepts an argument -lM to sp

Bug#772854: signing-party: QR code: too small quiet zone on large QR code

Package: signing-party Version: 1.1.11-1 Severity: normal Dear Maintainer, When generating paper slips with gpg-key2latex and specifying a somewhat large QR code, the generated QR code does not have the 4 module wide quiet zone that is required by the QR specification (specifically I'm looking at

Bug#674467: opus: Please add multiarch support.

Ron wrote: > I mean really, people who can't figure out how to fix this for themselves > really shouldn't be using m-a on sid, or sid, at all. People who think > sending hundreds of *insistent me-toos* about transition issues in a > development release is the way to fix things *ought to have a g

Bug#674467: opus: Please add multiarch support.

Package: src:opus Followup-For: Bug #674467 I wrote mainly to help Lucio and others building this. But I really want to add my "Me too", because this is a real pain with i386 audio dependencies! Dear Ron, please don't stay silent on this issue. It has been going on for a very long time now! The b

Bug#675942: {fq_,}codel will be in wheezy; tc support needed?

Hello, As Ben Hutchings wrote in this[1] blog post, {fq_,}codel will be in wheezy (which is great news!). Is it part of the plans that a codel-aware tc will also be in wheezy? Thanks for your work, Peter. [1]

Bug#595670: Bug has been fixed for a while

"src" selection for IPv6 has worked for me on wheezy/testing since at least the 21st of August 2012. I remember reading something, probably in a changelog, and thinking "Hey, did they fix that?" and being very happy when it indeed worked for me. I can't remember more specific details like version

Bug#627312: iproute: tc -pretty prints sport/dport swapped

Hello! That's a very quick reply, thanks! On 19/05/11 17:05, Andreas Henriksson wrote: > I'm unfortunately quite busy right now. Since this clearly isn't > anything debian specific, it would be nice if you could discuss > this with upstream directly (Try Stephen Hemminger at Vyatta and the > net.

Bug#627312: iproute: tc -pretty prints sport/dport swapped

Package: iproute Version: 20110107-2 Severity: normal If you request pretty-printed filters with tc -p, it will print "sport" for a match on the /destination/ port, and "dport" for a match on the /source/ port. To reproduce: 1) Create a classful qdisc supporting filters, so the next command gets

Bug#618887: dirvish: Alias to / interpeted as no alias

Package: dirvish Version: 1.2.1-1.1 Severity: normal Tags: patch When having a line in the vault config like: tree: /root/backupmnt/ / It behaves like tree: /root/backupmnt/ The alias to "/" is ignored. This means that a file at the root of the transfer named test, ends up in the index named

Bug#495111: uswsusp: Whitelist entry for MSI Wind

LTD" sys_product = "U-100" sys_version = "Ver.001" bios_version = "4.6.3" By the way; my current kernel is home-compiled. But s2ram worked fine with the stock Debian kernel as well. Unfortunately, some other things didn't. That's why you'

Bug#486347: gcc-4.3: Superfluous warning when -std=c99/gnu99 and noreturn on main()

Bastian Blank wrote: > Well, main returns always in a hosted environment. The bug reporter of bug #141015 used exit() on all occasions, I thought that didn't count as a return? (just curiosity) I think the noreturn attribute is quite overkill for normal computers though, this in contrast to embed

Bug#486347: gcc-4.3: Superfluous warning when -std=c99/gnu99 and noreturn on main()

precision arithmetic library ii libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point Thanks for your time, Peter Lebbing. - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable') Architecture