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

[Peter Lebbing]

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
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured 
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[ERROR @radicale] transport problem: REPORT 'check for items': Neon error code 
1, no HTTP status: Certificate verification error: unrecognized errors (524288)
[...]
--8<---cut here---end--->8---

What should happen:

--8<---cut here---start->8---
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured 
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[INFO @radicale] @radicale/cal-vakanties: using configured 
database=https://butters.digitalbrains.com:5232/peter/calendars/vakanties.ics/
[INFO @radicale] @radicale/con-personal: using configured 
database=https://butters.digitalbrains.com:5232/peter/contacts/personal.vcf/
[INFO @radicale] @radicale/tasks-personal: using configured 
database=https://butters.digitalbrains.com:5232/peter/tasks/personal.ics/
[INFO @radicale] @radicale/cal-personal: starting normal sync, two-way (peer is 
server)
[INFO @radicale] @radicale/cal-vakanties: starting normal sync, two-way (peer 
is server)
[INFO @radicale] @radicale/con-personal: starting normal sync, two-way (peer is 
server)
[INFO @radicale] @radicale/tasks-personal: starting normal sync, two-way (peer 
is server)
[...]
--8<---cut here---end--->8---

cadaver fares no better:

--8<---cut here---start->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Could not open collection:
Certificate verification error: unrecognized errors (524288)
dav:/peter/? 
--8<---cut here---end--->8---

The Radicale server is the latest from debian-oldstable/stretch:
radicale 1.1.1+20160115-4.

It turns out that GnuTLS requests OCSP stapling from the Radicale
server, but the Radicale server does not include a stapled response.
When libneon invokes GnuTLS's gnutls_certificate_verify_peers2(), it
returns a bit set in gnutls_certificate_status_t:

/**
 * gnutls_certificate_status_t:
 * @GNUTLS_CERT_MISSING_OCSP_STATUS: The certificate requires the server to 
send the certifiate status, but no status was received.
 */
typedef enum {
GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,
} gnutls_certificate_status_t;

This is the 524288 (1 << 19) seen in the error messages above.

The conservative patch is simple, and has been attached. It is for
Debian stable, because I currently don't have a properly configured VM
for doing it based on unstable, and it is so trivial that I don't think
this will present any problems to you. Please let me know if I am
mistaken in this or you'd like me to do further tests.

For discussion I here include the patch:

-if (status && status != GNUTLS_CERT_INVALID) {
+if (status && status != GNUTLS_CERT_INVALID
+&& status != GNUTLS_CERT_MISSING_OCSP_STATUS) {
 char *errstr = verify_error_string(status);
 ne_set_error(sess, _("Certificate verification error: %s"), errstr);
 ne_free(errstr);   
 return NE_ERROR;
 }

I don't really understand why GNUTLS_CERT_INVALID does /not/ cause
certificate verification to fail. But it could be that this bit is never
set alone, always together with a more precise failure bit, and as such
it never triggers on modern GnuTLS's (since it tests that only that bit
is set). This test was introduced in neon upstream in this git commit:

https://github.com/notroj/neon/commit/b514d5b2864155431c155d051fa4aa306fd4
commit b514d5b
Author: Joe Orton 
Date:   Tue Aug 11 14:15:33 2009 +

With the patch applied, syncevolution again works as above in "What
should happen", and cadaver is also much happier:

--8<---cut here---start->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Authentication required for Radicale - Password Required on server 
`butters.digitalbrains.com':
Username: peter
Password: 
dav:/peter/> ls
Listing collection `/peter/': succeeded.
[...]
--8<---cut here---end--->8---

Since this is something that worked fine on Debian stable until some
weeks ago, and then stopped working, I strongly suspect some Debian
stable update introduced a change causing this new

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

[Peter Lebbing]

-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 portion of the ToS octet.

I think I should emphasise the point that DSCP CS6 is the same as IP
Precedence 6 *by design*, it's not a coincidence. So the experiment
proves that IP Precedence 6 is encoded as 0xc0, which is what proves the
layout of the octet.

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 
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEZQCNwiCq4qJXTWzVlp4Bj95s3KEFAl1L6ycACgkQlp4Bj95s
3KHnVgf/a7pav4qO9gYI0rMXi2GsIAtjxWKHaJheph8YXP3vP1LE1v+vOStQB+zC
MPFN1IcUElo0+8ozrQ2RQsus3f4KxJIGPVRSXNAWnprlcEF3NRvVAZBkIjMYSWX9
se/v3BnExMk+IU9sUhDw1nH8KFYosa84zbxbT1buoGxbUzEoXZyezBkEB3CSqqtB
kn4mSZEoWrkahYsW71bFW7IEfuhCfh7GGq4VmO3aoLxGjIqhjrQgI6Cu+j3XUn3G
Sz32dfH5QGgDhsNBIHjlZPr2zlUAhVPJRv/+kdtgXVQiNAQUmFbHLEzoMeGlk4LP
Q6J6xy9ZOK66q1UpIC2cygqdx4WbCA==
=zRTY
-END PGP SIGNATURE-

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

[Peter Lebbing]

-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 deployed firewalls. It's a thorny situation.

Here's why I conclude the mask is wrong.

Let's take RFC 1349[1], which added the Minimize-Cost bit to ToS. First
off, realise that this conflicts with ECN, that's just part of the can
of worms that is ToS, and it complicates a solution to this issue even
more.

RFC 1349 chapter 3 defines the Type of Service Octet as:

The Type of Service octet consists of three fields:

0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 | |   | |
 |   PRECEDENCE|  TOS  | MBZ |
 | |   | |
 +-+-+-+-+-+-+-+-+

Note how the bit endianness is different than, for example, usual x86
diagrams. I think this is where the wrong mask stems from: the author of
the wrong mask was accustomed to diagrams with a different bit
endianness and ended up confused.

Now let's look at chapter 4 which defines this TOS field from bits 3
through 6:

1000   --   minimize delay
0100   --   maximize throughput
0010   --   maximize reliability
0001   --   minimize monetary cost
   --   normal service

And let's compare that to:

# iptables -m tos --help
iptables v1.6.0
[...]
tos match options:
[!] --tos value[/mask]Match Type of Service/Priority field value
[!] --tos symbol  Match TOS field (IPv4 only) by symbol
  Accepted symbolic names for value are:
  (0x10) 16 Minimize-Delay
  (0x08)  8 Maximize-Throughput
  (0x04)  4 Maximize-Reliability
  (0x02)  2 Minimize-Cost
  (0x00)  0 Normal-Service

Take a good look at these hexadecimals corresponding to the symbolic
names. They match the byte from RFC 1349 only if you flip the
bit-endianness such that the least significant bit is on the right
(Minimize-Cost has the lowest numerical value). Note that these
hexadecimals are correct; it is only the mask that is wrong.

This is on stretch/oldstable, but the help is no different on
buster/stable. I'll continue with a stretch system, though.

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 portion of the ToS octet.

# iptables -I INPUT -m tos --tos 0xc0 -j NFLOG --nflog-group 2

Ping it:

$ ping -Q 0xc0 -c 1 10.0.1.1

And take a look at the packet in the PCAP log file of that nflog, with
Wireshark:

Internet Protocol Version 4, Src: 10.0.1.133, Dst: 10.0.1.1
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
 ..00 = Explicit Congestion Notification: Not ECN-Capable Transport 
(0)
Total Length: 84
Identification: 0x5029 (20521)
Flags: 0x4000, Don't fragment
Time to live: 64
Protocol: ICMP (1)
Header checksum: 0xd33a [validation disabled]
[Header checksum status: Unverified]
Source: 10.0.1.133
Destination: 10.0.1.1

This proves:

- - That -m tos --tos 0xc0 matches a packet that has 0xc0 in the DS Field
  (because this is the only rule in the firewall logging to that nflog
  group)

- - That 0xc0 means DSCP CS6, because I believe Wireshark's analysis, it's
  been correct in different instances of looking at the DSCP field with
  packets generated by several systems.

So that means that the mask 0x3f is a mistake.

But changing the mask to 0xfc will make -m tos --tos Minimize-Cost break
because that is actually one of the ECN bits. I tested it and --tos
0x02/0xfc predictably did not match ping -Q 0x02. Changing the mask to
0xff causes less breakage, but still changes the behaviour on existing
deployments... :-(

Perhaps the best solution is to deprecate the symbolic --tos arguments,
urging everyone to exclusively use the numerical format. Put this in
NEWS so people hopefully notice, perhaps the Release Notes. And then
maybe someday DSCP and ECN will be less broken. Firewalls currently
using symbolic --tos arguments already misqualify ECN and IP Precedence
as well, it's not just DSCP.

HTH,

Peter.

[1] 

- -- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me 

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

[Peter Lebbing]

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.Wandboard.img.gz
http://ftp.nl.debian.org/debian/dists/stretch-proposed-updates/main/installer-armhf/20170615+deb9u5+b3/images/netboot/SD-card-images/partition.img.gz

I could completely install a base system on a Wandboard Quad without any
surprises. It works fine. (Well, it didn't reboot by itself at the end
of the installation and needed a press of the reset button, but the
chances that this is related to this bug are very small.)

I also did an install on an Odroid-XU4, using the partition.img.gz from
above but a "firmware" taken from the running system because Debian
doesn't seem to provide them for d-i. It worked up until the moment it
could not find a network card. I presume the reason is that d-i doesn't
include the various drivers needed for USB host on a Samsung Exynos5422
SoC, which is again unrelated to this bug. I didn't have a lot of time
on my hands and I have forgotten how to switch to a shell when d-i is
running on a serial port :-D, so I gave up. It worked perfectly up until
that moment.

HTH,

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 unbootable version. I noticed this today while
trying to install a new system using:

http://http.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Wandboard.img.gz

The installer worked when I overwrote the /vmlinuz in that image with
the one from the new 4.9.144-3.1.

Thanks,

Peter.

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.9.0-8-armmp (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

[Peter Lebbing]

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 patch dirvish with this fix.

Excellent, thank you!

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 



signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Peter Lebbing]

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 be necessary ;-)

I have once programmed GnuK into a very cheap Maple Mini clone for
somebody. He hasn't tried to use it yet, but I don't expect any issues.
It's not a really practical form-factor for mobile use (it needs a USB
cable, it's not a "stick" form), but for development on a desktop, it
should be fine.

I'll bring one programmed with GnuK to the 35C3. I also ordered another
ten; if they come over from China in time, I'll program them as well,
give you another one and pass them around to interested people.

These are the boards:


If you want to protect them a bit, just put some shrink tube around it.

HTH,

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 



signature.asc
Description: OpenPGP digital signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Peter Lebbing]

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'm not sure if the implementation
> currently found in our branch would choke if the wrong smartcard is
> inserted: I wasn't able to test this as I have only one token :-)

I have an idea on how to do this all more elegantly, but I haven't found
the time to work it out yet. Please don't block on this when the current
solution works for single reader, single smartcard cases. I don't know
when I'll find the time, but I'll try something out and submit it as a
patch.

I can test with multiple test readers and cards and intend to do so.

(For someone wondering: why do we need support for multiple card
readers? Consider the situation where a laptop has a built-in smartcard
reader but the user wishes to use a GnuK, which is a removable USB
device, to unlock his partition instead. This user cannot remove the
built-in smartcard reader.)

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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
information in there. The only key in the keyring is the imported key,
and all other trust info is purged, even though there is trust-model
always. This is the user's real homedir... and what I meant when I said
I lost my actual trustdb.

That was the purpose of TMPTRUST.

But since the --import should be fast enough to an empty keyring, it is
much more solid to just --import inside the initramfs.

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 least for gpg.conf and gpg-agent.conf
> I'm really not convinced of the usefulness to give users the stick to
> beat themselves with.

Luckily, this particular application should just be working after
initial setup, no need to mess with it anymore unless you buy a new
smartcard reader.

I think scdaemon.conf is necessary for some people.

> Since /etc/cryptsetup-initramfs normally won't be re-written upon
> GnuPG upgrades, we have to trust that GnuPG developers have well
> thought-out upgrade paths and migrations.  It's just a (documented)
> fact that today (GnuPG 2.2.10) `gpg --import` uses ‘pubring.kbx’ as
> default public keyring (and falls back to ‘pubring.gpg’); with <2.1 it
> was ‘pubring.gpg’; and for all I know it might be ‘pubring.kbx2’ in
> some later version.  Since keyrings created with a particular version
> of GnuPG might be used by any (later) version, they need to remain
> supported; either directly, or through a migration mechanism.

Well, the ultimate fail-safe migration mechanism is very
straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
the decrypt script, --import that first. I see you already use a
default, empty homedir anyway, might as well just --import to that. I do
wonder why you ended up creating the homedir manually, doesn't GnuPG do
that for you when it's the /default/ homedir? I can't just try it out
and see myself, I don't have a Debian testing handy :-). Can build one,
obviously.

My assumption was that when GnuPG significantly changes, changes to
/etc/cryptsetup-initramfs would be necessary anyway. But let's see
whether the keyring format is declared stable.

For now, the --import during initramfs appeals most to me.

> 
>> I don't see a reason to be using the --export approach here anyway?
> 
> I'm not fond of the `| gpg --import` due to the added clutter.  Today
> 
> gpg --export $KEYID | gpg --homedir="$(mktemp -d)" --import
> 
> creates a trust database ‘trustdb.gpg’ (unless we pass
> `--trust-model=always`), a backup keyring ‘pubring.kbx~’ and an empty
> directory ‘private-keys-v1.d’.  It also launches gpg-agent(1) and
> dirmngr(1) processess (unless we pass `--no-autostart`), and if there
> is no /run/user/$UID directory, uses destination homedir for the agent
> / dirmngr sockets.

Ah. Yes, a trustdb issue, which I thought went fine in the past (I'm not
sure), but it now is all sorts of not fine indeed (lost my actual
trustdb; luckily I have daily backups to rely on). All the other issues
but the trustdb issue are caused by the temporary homedir. This
invocation seems to be fine:

$ TMPTRUST=$(mktemp)
$ gpg --no-default-keyring --keyring /home/peter/test.kbx 
--trustdb-name="$TMPTRUST" --import test.gpg
$ rm "$TMPTRUST"

But I notice your phrasing "today" :-). This might not be future-proof,
although very little truly is, of course. We are here because it's not
the standalone binary gpg 1.4 was anymore. And it used to be possible
to just import smartcard stubs.

My 2 cents,

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 started manually before).

Oh, I hadn't realized. That's a blocking issue.

> I'm reluctant to do that since there are plenty of options that would
> break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
> /path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
> etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
> custom config files yet.

I meant *.conf files specific to the initramfs, so no breaking options
would be picked up from the normal homedir. scdaemon options like
disable-ccid, enable-pinpad-varlen, disable-pinpad and maybe reader-port
might be useful in some setups where card readers are not completely
compliant with GnuPG's expectations. I couldn't find any useful
(documented :-) options for gpg or gpg-agent either.

> The `--export` command produces RFC 4880 compatible output, which is
> also the format for gpgv(1) keyrings and is bound to be supported
> forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
> the private key material).

Is this documented that it is bound to be supported by gpg? Because I
always hear and repeat myself that the format of a keyring is an
implementation detail, and anybody building keyrings this way should be
prepared for problems, which they do have. [1] is fresh in my memory,
but it might actually have been caused by a different problem. It's not
the first time it's cropped up though.

> Why would that block migration to GnuPG 2.1?

It's not related to migration here. I meant that you aren't supposed to
be constructing keyrings with --export, this has to my knowledge never
been an intended feature. You use --no-default-keyring --keyring X
--import to build keyrings only (well, appending is possible with
--primary-keyring as well). I don't see a reason to be using the
--export approach here anyway?

> gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
> since 2.1.7 AFAIK):

Ah yes, I forgot that it wasn't documented, so when I went to the
documentation to check, well... :-)

I'm going to raise the issue of how private the directory/filename
structure in private-keys-v1.d is on GnuPG-Users. Because if they are
deemed an acceptable API, we could just copy a configurable .key stub,
or even find it ourself from an OpenPGP key identifier and
--with-keygrip --with-colons --list-secret-keys etcetera.

It would be easier if we could just --import a stub.

On 23/09/2018 17:17, Guilhem Moulin wrote:
> If we want this to be widely used we should make initramfs image
> generation as quiet as possible.

I meant document it in README.gnupg-sc, not on every initramfs image
generation. Just say that anything in /etc/cryptsetup-initramfs is going
to end up unencrypted in the initramfs, but that since the key for
unlocking the filesystem is already stored encrypted in that directory,
this does not compromise the unlock key. This obviously implies anything
else would be compromised. IMHO, sometimes good documentation can take
the place of full automation/checking.

Cheers,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060936.html

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




signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 what I'm actually using myself.

This might need some more thought... I'm not really happy with the "wait
for a random smartcard to be available and import that as stubs"
solution, but copying the whole homedir might need some more tuning as
well... Or we just accept that people who put data in a directory named
cryptsetup-initramfs should expect that this data ends up in their
initramfs, and limit our safety checks. We can still document it,
obviously, with a clearly phrased warning that although the key itself
is encrypted, nothing else is.

Anyway, Guilhem, thanks for working on this!

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>



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 homedir an API or implementation detail" is a bit muddy
IMHO. I think openpgp-revocs.d is an API, since it is not *consumed* by
GnuPG AFAIK, so it must be something meant for others (users,
frontends), right? So I think we're not intruding on implementation
details by omitting this directory.

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>



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

Hi Guilhem!

On 23/09/2018 05:57, Guilhem Moulin wrote:
> We already have some logic in place to wait until the source device is
> present, so we can as well wait until the card is present.

Note that GnuPG now supports multiple card readers at the same time. The
solution will fail then. Furthermore, it also precludes showing the nice
prompt with /which/ smartcard to insert for people with multiple
smartcards. Further reflection might reveal other cases where it is
suboptimal or wrong... How about copying the whole homedir without
random_seed, but first checking to make sure there are only smartcard
keys as private keys? I think the following does that:

--8<---cut here---start->8---
#!/bin/sh

UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | 
\
gawk -F: '$1=="sec" || $1=="ssb" \
{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')

if [ -n "$UNSAFEKEYS" ]; then
echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
exit 1
fi
--8<---cut here---end--->8---

It will only accept true OpenPGP smartcard keys (matched on ISO 7816
Application Identifier) or empty stubs (no secret key whatsoever). No
other secret key material should be necessary for this particular
application. Note that the dialect is dash; if run in bash, echo would
need -e.

Whatever the solution, I think it's a good idea to copy *.conf to the
GnuPG homedir as well (that's not an implementation detail, it's a
supported API).

I'm a bit worried that currently, the implementation detail that the old
pubring.gpg format is the same format as gpg --export is being used.
This is tripping up people upgrading to GnuPG 2.1, and I think it's a
better idea to avoid it here as well. The attached patch tries to do
this (but obviously doesn't combine well with the proposal of copying
the whole homedir, which would get this for free :-).

> By the way, I also added a local-bottom script to kill gpg-agent and
> scdaemon before execution is turned over to the init binary :-)

A good idea. If we copy a whole homedir, it might be needed to put the
homedir in its regular place for that. I suppose this is possible? I
think gpgconf 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 7957c591fccf3d5745bee4507a66b78ff4414a5f Mon Sep 17 00:00:00 2001
From: Peter Lebbing 
Date: Sun, 23 Sep 2018 11:48:11 +0200
Subject: [PATCH] Use modern keybox format for gpg

---
 debian/README.gnupg-sc   | 4 ++--
 debian/initramfs/hooks/cryptgnupg-sc | 4 ++--
 debian/scripts/decrypt_gnupg-sc  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/README.gnupg-sc b/debian/README.gnupg-sc
index 4320269d..2861eed0 100644
--- a/debian/README.gnupg-sc
+++ b/debian/README.gnupg-sc
@@ -36,9 +36,9 @@ decrypting the keyfile at initramfs stage
 
 If the device is to be unlocked at initramfs stage (such as for the root FS or
 the resume device), you need to copy the public part of the encryption
-key to /etc/cryptsetup-initramfs/pubring.gpg:
+key to a keyring named /etc/cryptsetup-initramfs/pubring.kbx:
 
-# gpg --export 0xDEADBEEF >/etc/cryptsetup-initramfs/pubring.gpg
+# gpg --export 0xDEADBEEF | gpg --no-default-keyring --keyring /etc/cryptsetup-initramfs/pubring.kbx --import
 
 Then the provided initramfs hooks should do all additionally required
 work for you when the initramfs is created or updated.
diff --git a/debian/initramfs/hooks/cryptgnupg-sc b/debian/initramfs/hooks/cryptgnupg-sc
index 57255fad..0a607ab8 100755
--- a/debian/initramfs/hooks/cryptgnupg-sc
+++ b/debian/initramfs/hooks/cryptgnupg-sc
@@ -39,9 +39,9 @@ copy_keys() {
 RV=0
 crypttab_foreach_entry copy_keys
 
-PUBRING="/etc/cryptsetup-initramfs/pubring.gpg"
+PUBRING="/etc/cryptsetup-initramfs/pubring.kbx"
 if [ -f "$PUBRING" ]; then
-copy_file pubring "$PUBRING" "/cryptroot/pubring.gpg"
+copy_file pubring "$PUBRING" "/cryptroot/pubring.kbx"
 else
 cryptsetup_message "WARNING: $PUBRING: No such file"
 fi
diff --git a/debian/scripts/decrypt_gnupg-sc b/debian/scripts/decrypt_gnupg-sc
index 8bb9d81d..932e1bf0 100755
--- a/debian/scripts/decrypt_gnupg-sc
+++ b/debian/scripts/decrypt_gnupg-sc
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-PUBRING="/cryptroot/pubring.gpg"
+PUBRING="/cryptroot/pubring.kbx"
 [ -f "$PUBRING" ] || PUBRING=
 
 run_gpg() {
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 user multiple times when they
mistype their passphrase/PIN. I didn't look into this for stretch yet.

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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/keys is created, and in that homedir,
the smartcard stubs for the OpenPGP card are created (per README.md[1]).
This separate GnuPG homedir, specifically meant just for the unlocking
of the LUKS container, is then copied to the initramfs. If this were not
done, you'd have to do "gpg --card-status" in your initramfs to create
these stubs everytime you boot, before decryption. It'd get awkward if
you forgot to insert your smartcard, because adding --card-status makes
it a two-step process: first --card-status, second --decrypt. Right now,
if you forgot to insert your smartcard, the --decrypt would fail and be
retried. The failure would prompt you to insert your smartcard.

It's not copying your normal GnuPG private-keys-v1.d to initramfs,
that'd be not so clever. Still, in the interest of clarity, it warns the
user that if they dumped sensitive information in /etc/keys, they might
want to reconsider.

> decrypt_gnupg_sc:
>  * How common are the cards requiring pcscd(8) that don't work with the
>existing ‘decrypt_opensc’ keyscript but do work with the
>‘decrypt_gnupg_sc’ keyscript?

It's more tied to the reader rather than the card. My own smartcard
reader works great with the internal CCID driver of GnuPG, and my
version of this script does not have pcscd. Erik Nellessen apparently
has a smartcard reader that is not supported by GnuPG, but the card in
it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
GnuPG-supported reader myself, it makes it all a lot smoother.

HTH,

Peter.

[1]


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



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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

The following can be observed:

Statement:
tree: /somewhere

Effect:
$srctree = "/somewhere"
$aliastree is empty

Correct!

Statement:
tree: /somewhere/

Effect:
$srctree = "/somewhere"
$aliastree is empty

Correct! Trailing slashes are removed.

Statement:
tree: /somewhere/ /alias

Effect:
$srctree = "/somewhere"
$aliastree = "/alias"

Correct! But accidentally. This is probably why the bug was not spotted
when it was introduced.

Statement:
tree: /somewhere /alias

Effect:
$srctree = "/somewher"
$aliastree = "/alias"

Wrong!

This is because of the following snippet:
- --8<---cut here---start->8---
#+SIS: KHL 2005-02-18  SpacesInSource fix
#-SIS: ($srctree, $aliastree) = split(/\s+/, $$Options{tree})
($srctree, $aliastree) = split(/[^\\]\s+/, $$Options{tree})
or seppuku 228, "ERROR: no source tree defined";
$srctree =~ s(\\ )( )g; #+SIS
$srctree =~ s(/+$)();
- --8<---cut here---end--->8---

So what happened on the last example? The split statement splits the
string "/somewhere /alias" into the components:
First part: "/somewher"
Separator: "e "
Second part: "/alias"

So the last character of the first part is gobbled as part of the
separator. Since an optional trailing slash is also removed, as long as
a trailing slash is used on the first part, everything still works. But
not including the trailing slash is a perfectly valid configuration.

I don't know any Perl, so I don't know the correct way to fix this. I
had a quick look and didn't see it.

Cheers,

Peter.

- -- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dirvish depends on:
ii  libtime-modules-perl  2015.103-2
ii  libtime-period-perl   1.20-8.2
ii  perl  5.24.1-3+deb9u2
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u2
ii  rsync 3.1.2-1+deb9u1

Versions of packages dirvish recommends:
pn  ssh  

dirvish suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFMBAEBCAA2FiEEZQCNwiCq4qJXTWzVlp4Bj95s3KEFAlqENdMYHHBldGVyQGRp
Z2l0YWxicmFpbnMuY29tAAoJEJaeAY/ebNyhA7oH/3fop7cthO1D+8jufZNFBnaK
kvNup5afXdBG7n1DC+FjPg8IqjiTQgsdzg4Q875h+anjFKNQuvROoYlpzwRwsjEI
OinjA/GZfzSxrwjGrx1kO8CcoL/B9ucppE1KXctc7qy6lO2KlqfMzoX/ZidV7Db1
GlgaCoBFeiWo+aqpAbBmlPi6M8xKpZj8k7BteHzklxJeWiDcym7B87IR1Q+Vntw5
sw8OzyVQzBGJgYcq4dZeHQ8xHd67sCaUTZGWdzQgIjdhWt1Aw2EtyMumT0q5u6rA
/NFcbvjt3GwQJ5oM/d8xXfYWZF0g/sabLbC6M+UydDDG4iu7cQ7kqem8cAzuRWk=
=+yoZ
-END PGP SIGNATURE-

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

[Peter Lebbing]

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 



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
#define CONFIG_EXTRA_ENV_SETTINGS \
[...]
"console=" CONFIG_DEFAULT_CONSOLE \

/etc/flash-kernel/bootscript/bootscr.uboot-generic:
  setenv bootargs "${bootargs} console=${console}"

The patch below makes the situation equal to what Debian patches in odroid.h: 
drop it from CONFIG_DEFAULT_CONSOLE. Judging from a grep in include/configs, I 
think the same situation exists for s5pc210_universal.h, s5p_goni.h, trats2.h 
and trats.h, but I don't have these devices. There are many more header files 
that have a "console=" in their CONFIG_DEFAULT_CONSOLE, but I don't see that 
definition being subsequently used somewhere, so I don't know whether it's 
being used wrongly or not.

Thanks for your efforts,

Peter.

*** 
src/debian/u-boot-2017.09+dfsg1/debian/patches/odroid-xu3/double-console-string
Index: u-boot-2017.09+dfsg1/include/configs/odroid_xu3.h
===
--- u-boot-2017.09+dfsg1.orig/include/configs/odroid_xu3.h
+++ u-boot-2017.09+dfsg1/include/configs/odroid_xu3.h
@@ -34,7 +34,7 @@
 
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
 
-#define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
+#define CONFIG_DEFAULT_CONSOLE "ttySAC2,115200n8\0"
 
 /* USB */
 #define CONFIG_USB_EHCI_EXYNOS


-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.9.0-3-armmp-lpae (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#852318: lightning: Fake mtime in packaged files

[Peter Lebbing]

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 something relevant. I think
all files in a .deb binary package have a 0 fractional seconds part. I
think they are stored with one second resolution. But the problematic
files have a fake mtime of 2010-01-01 0:00 UTC that is the same over
different .deb binary packages.

> But this looks like something that could be come from the
> tools the reproducibly team is using and creating.

That does sound like a clue!

> Next we need to clarify with which package version such timestamps are
> shipped for the first time.

Done!

Using my backups, I could trivially deduce which stable package
introduced the change. In 38.8.0-1~deb8u1, the times are still recent.
In 1:45.1.0-1~deb8u1, the 2010-01-01 times show up.

Next using snapshot.debian.org[1], using a manual binary search through
the .deb files, I could pinpoint that

41.0~b2-1

is the first version where the 2010-01-01 times show up. The one before
that, 40.0~b1-1, still has recent mtimes.

HTH,

Peter.

[1] http://snapshot.debian.org/package/icedove/

-- 
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#852318: lightning: Fake mtime in packaged files

[Peter Lebbing]

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-visible changes, this change is not the problem.

> I suggest to get in contact with upstream by simply answering in the bug
> report with your analyze. We can patch the source once the position of
> usptream is clear.

I wonder if this is appropriate. IMO, the bug is about something else
entirely. It's just that the fix effected a different problem.

Mozilla bug #1277976 is about what users expect a certain keyboard
shortcut does, in a nutshell.

This Debian bug report I opened is about (many) files having fake
metadata, confusing backup tools.

While the one led to the other in this specific instance, they are in
essence unrelated. If you really suggest I bring it up in that bug
report, I'll do so. But it feels like conflating issues in a single bug
report.

I could also open a new upstream bug report. I'm always a bit uncertain
whether to report upstream or to Debian. I'm using Debian, it feels like
I should report it there. But I'm also using upstream, right...

I think in any case Debian should be aware of this specific issue, and
decide whether to fix this in stable as well. For users of a whole class
of backup solutions, it's a potential, but relatively benign data-loss
issue. Only filesystem-specific tools and backup tools that always
compare or checksum every byte of every file in the filesystem will not
be fooled by the fake metadata.

Thanks,

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#852318: lightning: Fake mtime in packaged files

[Peter Lebbing]

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 peter peter 4096 2017-01-18 00:26:06.0 +0100 calendar-js
drwxr-xr-x 6 peter peter 4096 2017-01-23 15:18:24.237512811 +0100 chrome
-rw-r--r-- 1 peter peter 5953 2010-01-01 01:00:00.0 +0100 
chrome.manifest
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.0 +0100 components
drwxr-xr-x 3 peter peter 4096 2017-01-18 00:26:06.0 +0100 defaults
-rw-r--r-- 1 peter peter 1772 2010-01-01 01:00:00.0 +0100 install.rdf
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.0 +0100 modules
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.0 +0100 timezones

Why is this a problem? It's a problem when people use certain backup
solutions. For instance, I use dirvish, which underneath uses rsync with
a --link-dest argument set to the previous backup. Rsync by default
inspects file metadata only to see if it needs to transfer anything. If
mode, mtime and *size* all stay the same, rsync concludes that the file
is unchanged and hardlinks to the file present in the previous backup.

Periodically, I let rsync run with the --checksum argument to check the
integrity of my backups. That's when I discovered these files had
changed only in data, but not in mtime or size:

usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
usr/lib/iceowl-extension/chrome/calendar/content/calendar/calendar-dnd-listener.js
usr/lib/iceowl-extension/chrome/calendar/content/calendar/calendar-migration-dialog.js
usr/share/firefox-esr/browser/defaults/preferences/devtools.js
usr/share/firefox-esr/browser/defaults/preferences/firefox.js
usr/share/firefox-esr/browser/defaults/preferences/webide-prefs.js

This is on Debian stable. All of these files differed just in comments,
/except/ for 
usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd:

diff -ur 
20170121-0302/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
 
20170122-0307/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
--- 
20170121-0302/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
 2010-01-01 01:00:00.0 +0100
+++ 
20170122-0307/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
 2010-01-01 01:00:00.0 +0100
@@ -47,4 +47,4 @@
 
 
 
-
+



Apparently at some time in the past, an updated iceowl-extension package
shipped a new file where this "accesskey" changed from a C to an a. At
that moment, my backups no longer reflected the files on the system. If
I were to restore from backup, the old file with the old C access key
would be restored, and my system's behaviour would have changed because
of it.

I suggest these synthetic, fake mtimes should be fixed to reflect actual
changes. I can't believe that someone wrote the two versions of
menuOverlay.dtd with two different access keys in the same, very first
second of 2010, so why does the mtime reflect that this is what
happened? It confuses backup tools because we don't have the Archive
attribute that MS-DOS could use for these purposes. Instead they rely on
truthful metadata, where the mtime is the last time the file content was
changed, not some fake piece of non-information.

Thanks for your packaging efforts,

Peter.

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 
'unstable'), (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#844631: Ahh it's a Disaster

[Peter Lebbing]

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 validity is now independent of the browser build date
>   (closes: #844631).
> [...]
> 
>  -- Michael Gilbert   Sun, 11 Dec 2016 04:48:45 +
> 

I'm no longer bitten by this bug.

HTH,

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#844631: Seem like Chromium issue 664177

[Peter Lebbing]

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/detail?id=664177

[2] https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1641380

-- 
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#788704: gnutls28: VIA PadLock accelerated AES-CBC segfaults

[Peter Lebbing]

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 on the same machine and to some SMTP
server I picked out of my logs that also supported all those ciphers.
Furthermore, exim4 was able to use AES-128-CBC to deliver some test
mails to other SMTP servers.

So it seems to work fine.

Thanks for maintaining the Debian packages and a pleasant bug reporting
experience!

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



signature.asc
Description: OpenPGP digital signature

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

[Peter Lebbing]

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 backporting that commit to GnuTLS in jessie/stable, to not
deviate unnecessarily from upstream and fix the problem.

The message [1] also mentions a second commit which prevents calling the code
with a length 0 in the first place, as it is a useless action. That commit is
not necessary to fix this specific bug.

With regards,

Peter.

[1] https://lists.gnupg.org/pipermail/gnutls-devel/2015-June/007627.html

[2] 
https://gitlab.com/gnutls/gnutls/commit/023156ae2504c1911f8f2e66a0ebde316931671c

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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:00 info kernel: [ 3466.879332] exim4[2381]: 
 segfault at 4aeb2453 ip b6a4a5e2 sp bf7bfde0 error 4 in 
 libgnutls-deb0.so.28.41.0[b6996000+13a000]

There's nothing in the exim4 log; it crashes before anything is logged.

The problem is not limited to exim4: I could reproduce the crash with
gnutls-cli. This is also how I discovered AES-CBC was to blame. It turns
out that lib/accelerated/x86/elf/e_padlock-x86.s segfaults in the
function padlock_cbc_encrypt() because it has not been written to handle
the case where it is requested to encrypt 0 bytes of data; it expects a
strictly positive number. Yet, it is called with a length of 0. The
function overwrites 512 bytes on the top of its stack, and then
dereferences a pointer in the overwritten data.

The attached patch simply checks for a 0 length in the C functions that
call the handwritten assembly PadLock AES encryption routines, so the
call is avoided. The patch fixed the issue on my system.

All the functions padlock_{ecb,cbc,cfb,ofb,ctr32}_encrypt() share almost
all their code. The AES-CGM ciphers in GnuTLS don't seem to call the
function with a 0 length, but my patch also checks for 0 in that cipher
mode on the basis once bitten, twice shy.

The rest of the mail is a detailed description of the problem with
length 0.

I don't include a steps to reproduce this because it's likely you
don't have access to a system with a VIA PadLock engine. But it's
trivial to reproduce with gnutls-cli and an SMTP server to connect to.

To my surprise, e_padlock-x86.s is a generated file[4]; the source is
not included with GnuTLS. The source is the file
engines/asm/e_padlock-x86.pl in openssl; from the Git repository for
GnuTLS version 3.3.8, it can be concluded that the source is commit
34ccd24 in the OpenSSL Git.

First, a small aside on return values. OpenSSL checks the return value
(an int) of padlock_cbc_encrypt(), and indeed the function can abort if
the struct padlock_cipher_data is not aligned on a 16-byte boundary, or
if len is not a multiple of 16 (AES block size). But there's something
odd: /if/ the function aborts, the return value (EAX) is not set; it is
kept at the value it was when the function was called. On a succesful
return, it's set to 1.

GnuTLS never checks the return value. If it is possible that the length
is not a multiple of 16, GnuTLS will not notice that the
padlock_cbc_encrypt() call did nothing (unless it does some checks on
the data later).

I analysed the behaviour of padlock_cbc_encrypt() with GDB.

During my debugging, the input and output data were never aligned on a
16-byte boundary. padlock_cbc_encrypt() checks for this because not all
VIA processors can cope with this, or only at a tremendous speed
penalty. To fix the alignment, an aligned block of room is allocated on
the stack, and the data is copied there, encrypted in place, and copied to
the destination.

This part of the program is the problematic part:

File openssl/engines/asm/e_padlock-x86.pl, line 204:
--- 8 -- 8 ---
204:cmp($len,$chunk);
205:cmovc  ($chunk,$len);  # 
chunk=lenPADLOCK_CHUNK?PADLOCK_CHUNK:len
206:and(eax,$chunk); # out_misaligned?chunk:0
207:mov($chunk,$len);
208:neg(eax);
209:and($chunk,$PADLOCK_CHUNK-1);  # chunk=len%PADLOCK_CHUNK
210:lea(esp,DWP(0,eax,ebp));# alloca
211:mov(eax,$PADLOCK_CHUNK);
212:cmovz  ($chunk,eax); # chunk=chunk?:PADLOCK_CHUNK
--- 8 -- 8 ---
[1]

At the start, EAX is all ones (binary), signifying the output is not
aligned on a 16-byte boundary.  Room is allocated on the stack for the
data in line 210. Either `len` bytes or PADLOCK_CHUNK (512), whichever
is less.

The purpose of `chunk` is to take up to PADLOCK_CHUNK bytes from
`len` to process. If `len` is not a multiple of 512, the remainder is
processed first. After the remainder is processed, either a multiple of
PADLOCK_CHUNK still needs to be processed, or we're done.

To this end, it ANDs `len` with 511 in line 209. If `len` is a multiple
of 512, the result is zero, so a full PADLOCK_CHUNK is processed (line
212).

But if `len` was already zero to begin with, this test produces the
wrong result, and results in `chunk` also being set to 512, to process
512 bytes of data.

The confusion comes now. The code has just set aside 0 bytes on the
stack for copying data. Then it copies 512 bytes of data from the input
pointer to the stack (in line 265 of the source[2]), thereby overwriting
the other information it is keeping on the stack. For good measure, this
is then encrypted as 

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

[Peter Lebbing]

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 -
root@timmy:/var/log/apt# grep libxrender1 term.log
Preparing to replace libxrender1:i386 1:0.9.7-1+deb7u1 (using 
.../libxrender1_1%3a0.9.7-1+deb7u1+b1_i386.deb) ...
De-configuring libxrender1:amd64 ...
Unpacking replacement libxrender1:i386 ...
Preparing to replace libxrender1:amd64 1:0.9.7-1+deb7u1 (using 
.../libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb) ...
Unpacking replacement libxrender1:amd64 ...
dpkg: error processing 
/var/cache/apt/archives/libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/libxrender1/changelog.Debian.gz', 
which is different from other instances of package libxrender1:amd64
 /var/cache/apt/archives/libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb
root@timmy:/var/log/apt# 
- 8  8 -

The beginning of that file is indeed different in both packages:

- 8  8 -
libxrender (1:0.9.7-1+deb7u1+b1) wheezy-security; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against fixed libx11 for DSA 3224

 -- amd64 / i386 Build Daemon (brahms) buildd_amd64-bra...@buildd.debian.org  
Tue, 14 May 2013 19:28:26 +0200
- 8  8 -

- 8  8 -
libxrender (1:0.9.7-1+deb7u1+b1) wheezy-security; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for i386; no source changes.
  * Rebuild against fixed libx11 for DSA 3224

 -- amd64 / i386 Build Daemon (x86-grnet-01) 
buildd_amd64-x86-grnet...@buildd.debian.org  Tue, 14 May 2013 19:28:26 +0200
- 8  8 -

I think multiarch requires the files that are in both packages to be
exactly the same to be able to install both.

Since this little bug prevents installation on multiarch machines, I've set
the severity to important.

For now, I've resolved the situation on my machine as follows:

# cd /var/cache/apt/archives
# ls libxrender1_1%3a0.9.7-1+deb7u1+b1_*.deb
libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb
libxrender1_1%3a0.9.7-1+deb7u1+b1_i386.deb
# dpkg --force-overwrite -i libxrender1_1%3a0.9.7-1+deb7u1+b1_*.deb

I'm including this information for other users looking at this bug report
and wishing to have a quick solution. Do this only after the failed upgrade
(which downloads the files to /var/cache/apt/archives and verifies the
signature on the download) and checking that the '*' in the globbing pattern
indeed only matches the two wanted files (I had already determined that, I 
didn't actually do the 'ls' command).

Thanks for your work,

Peter.

-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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 you don't see that anymore.

So here's my suggestion to get your system back in a good state, with
the update installed:

 For now, I've resolved the situation on my machine as follows:
 
 # cd /var/cache/apt/archives
 # ls libxrender1_1%3a0.9.7-1+deb7u1+b1_*.deb
 libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb
 libxrender1_1%3a0.9.7-1+deb7u1+b1_i386.deb
 # dpkg --force-overwrite -i libxrender1_1%3a0.9.7-1+deb7u1+b1_*.deb
 
 I'm including this information for other users looking at this bug report
 and wishing to have a quick solution. Do this only after the failed upgrade
 (which downloads the files to /var/cache/apt/archives and verifies the
 signature on the download) and checking that the '*' in the globbing pattern
 indeed only matches the two wanted files (I had already determined that, I 
 didn't actually do the 'ls' command).

HTH,

Peter.

-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libxrender1 depends on:
ii  libc6  2.13-38+deb7u8
ii  libx11-6   2:1.5.0-1+deb7u2
ii  multiarch-support  2.13-38+deb7u8

libxrender1 recommends no packages.

libxrender1 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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 NEN-ISO/IEC 18004:2006 section 5.3.7). When quickly browsing
through the source, it appears a zero quiet zone is explicitly specified
with the qrencode option -m0. For small QR codes, that might work out
due to the size of the surrounding text (I didn't check), but when
looking at the result of:

$ gpg-key2latex --show-qrcode --attr-height 10 0xDE500B3E

I noticed that the quiet zone is only about 2 modules, and that's
assuming you cut it exactly at the lines. My phone had no problem
scanning the picture even on a starkly contrasting background, but it's
not according to spec, so I wonder why the option -m0 is specified in
the first place?

By the way, the reportbug-generated dependency versions below seem to
have a little multiarch related bug; the version of my python:any
package is 2.7.8-1 (amd64 arch).

Thank you for your work on this package.

Greetings,

Peter.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'stable'), (100, 
'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages signing-party depends on:
ii  gnupg  1.4.18-4
ii  libc6  2.19-11
ii  libclass-methodmaker-perl  2.21-1+b1
ii  libgnupg-interface-perl0.50-3
ii  libmailtools-perl  2.13-1
ii  libmime-tools-perl 5.505-1
ii  libnet-idn-encode-perl 2.201-1
ii  libterm-readkey-perl   2.32-1+b1
ii  libtext-template-perl  1.46-1
ii  perl   5.20.1-1
pn  python:any none
ii  qprint 1.0.dfsg.2-2

Versions of packages signing-party recommends:
ii  dialog 1.2-20140911-1
ii  libgd-perl [libgd-gd2-perl]2.53-1+b1
ii  libpaper-utils 1.1.24+nmu3
ii  nullmailer [mail-transport-agent]  1:1.13-1
ii  whiptail   0.52.17-1

Versions of packages signing-party suggests:
ii  fonts-droid1:4.4.4r2-2
ii  imagemagick8:6.8.9.6-4+b1
pn  mutt   none
ii  qrencode   3.4.3-1
ii  texlive-font-utils 2014.20140927-1
ii  texlive-latex-recommended  2014.20140927-1
pn  texlive-xetex  none
pn  wipe   none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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 specify a medium error
correction level. So you get a more resilient QR code for free.

monkeysign also generates them with medium error correction level.

I thought I should mention this here because if you were to change the
invocation of the qrencode program related to this bug, you might as well do
this in one go. I'm sorry if you consider it inappropriate here.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

On Thu, 11 Dec 2014 14:02:32 -0500 Brian Minton br...@minton.name 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 other keys

Or, quoting from the DETAILS document coming with GnuPG:

 12. Field:  Key capabilities:
 e = encrypt
 s = sign
 c = certify
 a = authentication
   A key may have any combination of them in any order.  In
   addition to these letters, the primary key has uppercase
   versions of the letters to denote the _usable_
   capabilities of the entire key, and a potential letter 'D'
   to indicate a disabled key.
 

So this is not a bug, but a feature.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674467: opus: Please add multiarch support.

[Peter Lebbing]

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 good think* 
 about what this word *'unstable'* means and how software development works.

 [...] to *real software developers* in favour of people with unrealistic
 expectations [...]

 [...] the people *actually doing work*.

 The people who expect others to do it for them will just have to be patient,
 or *smarter* about what release they use, or both.

 [...]  it will possibly encourage more people who *shouldn't be using sid* 
 and/or sid+m-a, to keep using it, etc. etc ...
 
 Which is a good part of the reason I haven't done this double work either.
 
 If the me-too storm proved anything at all, it was that enough people already
 *didn't get it* without doing even more work to *breed more of them*. If it
 wasn't for that I might have considered doing this more seriously.

 [..] people who do have fairly *reasonable expectations* to meet.

Emphasis is mine.

Please don't be disrespectful of users running jessie/testing and... testing it
for bugs, and reporting them.

About jessie: Of the people including such information, I saw one who appeared
to run sid, the other 5 seemed to run jessie. So you're using a hyperbole
stating all these people shouldn't be running sid, and making this
better-than-thou remark that people should know the meaning of the word 
'unstable'.

Let me remind you of article 4 of the Debian Social Contract:

 Our priorities are our users and free software
 
 We will be guided by *the needs of our users* and the free software 
 community. We will place their interests first in our priorities. We will 
 support the needs of our users for operation in many different kinds of 
 computing environments. We will *not object to non-free works* that are 
 intended to be used on Debian systems, or attempt to charge a fee to people 
 who create or use such works. We will allow others to create distributions 
 containing both the Debian system and other works, without any fee from us. 
 In furtherance of these goals, we will provide an integrated system of 
 high-quality materials with no legal restrictions that would prevent such 
 uses of the system.

Again, emphasis mine.

The bug was reported in May 2012. In July 2013, *more than a year later*, you
wrote a very short reply why you were not acting, but not taking the effort to
really explain it any further. The reason remains rather unclear at that moment.
Other than that, you pretty much said nothing until now. And now you're
disrespectful of the people who keep trying to get this under your attention?
They're nagging, when they keep raising the issue because the maintainer simply
does not respond to the bug report? You might have done more if it weren't that
you're encouraging these annoying Debian users?

I understand you're looking at this from a different perspective than I am, but
I find your condescending tone very inappropriate. Especially the breeding
remark; users are not cattle, and *you* are most definitely not the farmer
owning said cattle.

I also think the remark about people actually doing work in particular is
offensive and highly unwanted.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674467: opus: Please add multiarch support.

[Peter Lebbing]

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 bug was initially reported
almost one and a half year ago. What is there against applying the small
patch? I don't understand your reasoning about backports or new
versions, as this issue seems orthogonal to me.

...

Hello Lucio,

I got it working as follows with the pbuilder hint you got at debian-user:

# is as root, $ is as regular user. Replace you by your username in
the sudoers file. I removed the sudoers entry afterwards, as I'm overly
cautious :).

# aptitude install pbuilder
# pbuilder --create --distribution jessie --architecture i386
# visudo
  Add the following:
  you ALL=(ALL) SETENV: /usr/sbin/pbuilder, /usr/bin/pdebuild, 
/usr/bin/debuild-pbuilder

$ cd src/debian/
$ apt-get source opus
$ cd opus-1.1~beta/
$ patch -p1 ../opus-multiarch.diff
  (obviously I downloaded it there. It succeeds with fuzz)
$ pdebuild --architecture i386
[...]

Result is in /var/cache/pbuilder/result/

You will also need to do a regular amd64 build with dpkg-buildpackage.

HTH,

Peter.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'oldstable'), 
(100, 'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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]http://womble.decadent.org.uk/blog/whats-in-the-linux-kernel-for-debian-70-wheezy-part-1.html

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595670: Bug has been fixed for a while

[Peter Lebbing]

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 numbers. I found the date by
looking through backups.

So this bug can probably be closed. [1] advises me that it probably shouldn't be
me to do that.

HTH,

Peter.

[1]http://www.debian.org/Bugs/Developer

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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 accepted
by the kernel (the default pfifo_fast is classless and rejects filters)

# tc qdisc add dev eth0 root handle 1: htb 

2) Create a filter for TCP dport 1234 (TCP starts at byte 20, first 32 bits is
sport/dport)

# tc filter add dev eth0 protocol ip parent 1: u32 match u32 0x04d2 \
  0x at 20 flowid 1:1

3) List the filters

# tc -p filter ls dev eth0

Expected result:
Output as:
...
  match dport 1234

Actual result:
...
  match sport 1234


The exact reverse happens when we do an actual match on the TCP sport:

Step 1) as before

2)
# tc filter add dev eth0 protocol ip parent 1: u32 match u32 0x04d2 \
  0x at 20 flowid 1:1

Step 3) as before

Instead of the actual sport 1234, the output now says dport 1234.

By the way, you could see the numeric matchers are actually correct by
generating some matching traffic and checking the filters with

# tc -p -s -d filter ls dev eth0

If you telnet /to/ a port 1234 over eth0, for example, you'll see the success
counter increasing for sport 1234.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iproute depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libdb4.8  4.8.30-4   Berkeley v4.8 Database Libraries [

Versions of packages iproute recommends:
ii  libatm1  1:2.5.1-1.2 shared library for ATM (Asynchrono

Versions of packages iproute suggests:
ii  iproute-doc   20110107-2 networking and traffic control too

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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...@vger.kernel.org mailing list).

Okay, I'll take it upstream.

 The code to do the matching is found in tc/f_u32.c, function parse_ipv4
 under the case 20:  at approx line no 860.

 Maybe it's just a simple mistake of doing it backwards there, maybe
 it's a deeper problem somewhere else

Ah, I'll have a look there before I write them. If it's a simple swap of
strings, I might be able to spot that directly.

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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Peter Lebbing]

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

/root/backupmnt/test

Whereas one would expect the index file to contain this name as

/test

because of the alias option.

Attached patch fixes that behaviour. Currently, dirvish does the
following things:

- remove trailing slashes
- if alias is empty, set it equal to path, the first argument to the
  tree option.

By reversing the order of these two operations, the behaviour ought to
be as expected for all cases, including alias to root, if you ask me.

Thanks,

Peter.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (100, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dirvish depends on:
ii  libtime-modules-perl 2006.0814-2 Various Perl modules for time/date
ii  libtime-period-perl  1.20-8  Perl library for testing if a time
ii  perl 5.10.1-17   Larry Wall's Practical Extraction 
ii  perl-modules 5.10.1-17   Core Perl modules
ii  rsync3.0.7-2 fast remote file copy program (lik

Versions of packages dirvish recommends:
pn  ssh   none (no description available)

dirvish suggests no packages.

-- Configuration Files:
/etc/cron.d/dirvish changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/sbin/dirvish (from dirvish package)
--- dirvish.pl  2005-02-19 02:07:53.0 +0100
+++ dirvish.pl.new  2011-03-19 10:41:21.0 +0100
@@ -418,8 +418,8 @@
or seppuku 228, ERROR: no source tree defined;
 $srctree =~ s(\\ )( )g; #+SIS
 $srctree =~ s(/+$)();
-$aliastree =~ s(/+$)();
 $aliastree ||= $srctree;
+$aliastree =~ s(/+$)();
 
 $destree = join(/, $vault, $image, 'tree');
 $reftree = join('/', $vault, $$Options{Reference}, 'tree');

Bug#495111: uswsusp: Whitelist entry for MSI Wind

[Peter Lebbing]

Package: uswsusp
Version: 0.8-1
Severity: wishlist

Hello,

I tested s2ram on my brand new MSI Wind, and it works fine without any
workarounds needed. I tested it from both X and the virtual console;
however, I did not test with a framebuffer. I couldn't find a way to enable
the framebuffer. The stock Debian kernel doesn't do it, and for some reason
the kernel I specially compiled to test framebuffer support, didn't activate
the framebuffer either. I gave up then :).

My system info:

This machine can be identified by:
sys_vendor   = MICRO-STAR INTERNATIONAL CO., 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'll see a custom kernel in the reportbug output below.

Greets,

Peter Lebbing.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26.2-wind (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages uswsusp depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libdirectfb-1.0-0 1.0.1-9direct frame buffer graphics - sha
ii  libgcc1   1:4.3.1-2  GCC support library
ii  libgcrypt11   1.4.1-1LGPL Crypto library - runtime libr
ii  libglib2.0-0  2.16.4-2   The GLib library of C routines
ii  libgpg-error0 1.4-2  library for common error values an
ii  liblzo2-2 2.03-1 data compression library
ii  libpci3   1:3.0.0-4  Linux PCI Utilities (shared librar
ii  libsplashy1   0.3.10-2   Library to draw splash screen on b
ii  libx86-1  1.1+ds1-2  x86 real-mode library

Versions of packages uswsusp recommends:
ii  initramfs-tools   0.92e  tools for generating an initramfs
ii  mount 2.13.1.1-1 Tools for mounting and manipulatin

Versions of packages uswsusp suggests:
pn  splashy   none (no description available)

-- debconf information:
* uswsusp/compute_checksum: true
  uswsusp/no_snapshot:
* uswsusp/suspend_loglevel:
  uswsusp/no_swap:
  uswsusp/resume_offset:
* uswsusp/early_writeout: true
* uswsusp/image_size: 483377479
* uswsusp/compress: true
  uswsusp/create_RSA_key: false
* uswsusp/snapshot_device:
  uswsusp/RSA_key_file: /etc/uswsusp.key
* uswsusp/max_loglevel:
* uswsusp/resume_device: /dev/sda3
  uswsusp/shutdown_method: platform
* uswsusp/encrypt: false
* uswsusp/splash: false
  uswsusp/RSA_key_bits: 1024
  uswsusp/continue_without_swap: true




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Peter Lebbing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: gcc-4.3
Severity: normal

This bug report is actually a duplicate of bug #141015, which was filed
against gcc-3.0. The bug was never fixed because it was deemed unimportant:
when the bug reporter used a different combination of settings, he no longer
got the warning. However, he also no longer got the /functionality/.

The following code generates the warning:

-  test.c 

int main () __attribute__ ((noreturn));

int main () {
  for (;;) {
// Endless loop
  }
}

- --- End of test.c ---

$ gcc -std=gnu99 test.c -o test
test.c: In function ‘main’:
test.c:7: warning: function declared ‘noreturn’ has a ‘return’ statement

This is because C99 implicitly adds a return 0; at the end of main().

This bug is still a bit bothersome to me. When I compile a C program for use
on a microcontroller with the package gcc-avr, the noreturn attribute on
main() actually triggers better optimisation, resulting in more optimal
stack usage. This can be a big benefit on a device with usually between 128
and 1024 bytes of RAM. Most programs on these devices never return from
main(). Very often an endless loop like above is used, or something similar.

Please consider fixing this bug for users like me who'd rather not see a
confusing warning message on compilation.

I did not file this bug against gcc-avr because the problem doesn't seem to
be there. However, for your information, here's my current package information:

Package: gcc-avr
Version: 1:4.3.0-2

Versions of packages gcc-avr depends on:
ii  binutils-avr  2.18-3 Binary utilities supporting Atmel'
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libgmp3c2 2:4.2.2+dfsg-3 Multiprecision 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: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

- --
I'm using 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://wwwhome.ewi.utwente.nl/~lebbing/pubkey.txt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSFUjg/qr/97I5g4/AQLOUgP9FCp0MWLfh38xBvNolcmV1Kk+eEMiycdO
KH2WB8BPvScE/OuL8/MKLt8QVFyro5Z87ZCYxhrTmRiHIdQ4D1bcA68yR+zwDjA4
NvF8Yp5AwZcNfq83rtWVS+SGm2KPTlpLtun6e+afzwKMuvSB4ssJxa56oOE2b+S/
Bqpkh9xBAZc=
=MxU0
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Peter Lebbing]

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

 I doubt that you want a hosted compiler environment while building code 
 for such a device. Use -ffreestanding and/or use a different name then 
 main.

I have to admit I might not fully understand what you mean. I looked at the
description of -ffreestanding; I'm under the impression you are talking
about a program that does not use standard libraries, whereas I'm talking
about development using avr-libc.

The avr-libc documentation has this to say about -ffreestanding:

 However, this also turns off all optimizations normally done by the
 compiler which assume that functions known by a certain name behave as
 described by the standard. E. g., applying the function strlen() to a
 literal string will normally cause the compiler to immediately replace
 that call by the actual length of the string, while with -ffreestanding,
 it will always call strlen() at run-time.

Doesn't sound like what I want.

Thanks for the reply,

Peter.

-- 
I'm using 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://wwwhome.ewi.utwente.nl/~lebbing/pubkey.txt



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]