Bug#730848: postfix-ldap: Please allow SASL binds
Package: postfix-ldap Version: 2.10.2-1 Severity: wishlist Tags: patch Dear Maintainer, LDAP SASL binds have been added to Postfix back to v2.8, at the expense of a flag in the CCARGS [1]. It would be great if postfix-ldap included SASL support. As far as I can tell, the change boilds down to a mere modification in debian/rules: -8- --- debian/rules.orig 2013-11-30 08:42:40.120610017 +0100 +++ debian/rules2013-11-30 08:44:52.449266206 +0100 @@ -45,7 +45,8 @@ STRIP=y endif -CCARGS=-DDEBIAN -DMAX_DYNAMIC_MAPS -DHAS_PCRE -DHAS_LDAP -DHAS_SQLITE \ +CCARGS=-DDEBIAN -DMAX_DYNAMIC_MAPS -DHAS_PCRE -DHAS_LDAP -DUSE_LDAP_SASL \ + -DHAS_SQLITE \ -DMYORIGIN_FROM_FILE \ $(shell getconf LFS_CFLAGS) \ -DHAS_CDB \ -8- Many thanks! Cheers, -- Guilhem. [1] http://www.postfix.org/LDAP_README.html#build , last paragraph. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postfix-ldap depends on: ii libc6 2.17-97 ii libldap-2.4-2 2.4.31-1+nmu2+b1 ii postfix2.10.2-1 postfix-ldap recommends no packages. postfix-ldap suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#659971: /usr/bin/caff: Doesn't properly quote umlauts in $CONFIG{'owner'}
tags 659971 patch
thanks
One could use the (core) module I18N::Langinfo to decode
$CONFIG{'owner'} from the user's locale to Perl's internal format.
Also, since the template is expected to be in UTF-8, it needs to be
converted as well.
Cheers,
--
Guilhem.
--- a/usr/bin/caff
+++ b/usr/bin/caff
@@ -321,6 +321,7 @@
use Text::Template;
use MIME::Entity;
use Encode;
+use I18N::Langinfo;
use Fcntl;
use IO::Select;
use Getopt::Long;
@@ -517,6 +518,10 @@
if ((defined $CONFIG{'also-encrypt-to'}) ! (ref($CONFIG{'also-encrypt-to'}) eq 'ARRAY')) {
$CONFIG{'also-encrypt-to'} = [ $CONFIG{'also-encrypt-to'} ];
};
+ my $locale = Encode::find_encoding(langinfo(I18N::Langinfo::CODESET()));
+ if (defined $locale) {
+ $CONFIG{$_} = $locale-decode($CONFIG{$_}) for qw/owner mail-template/;
+ }
};
sub make_gpg_fds() {
@@ -801,7 +806,7 @@
Type= text/plain,
Charset = utf-8,
Disposition = 'inline',
- Data= $message);
+ Data= Encode::encode('utf-8',$message));
my @key_entities;
for my $key (@keys) {
signature.asc
Description: Digital signature
Bug#659971: /usr/bin/caff: Doesn't properly quote umlauts in $CONFIG{'owner'}
Oh, I forgot about UIDs, which may need to be converted as well. Patch
updated, sorry for the noise.
--
Guilhem.
diff -ru a/caff/caff b/caff/caff
--- a/caff/caff
+++ b/caff/caff
@@ -321,6 +321,7 @@
use Text::Template;
use MIME::Entity;
use Encode;
+use I18N::Langinfo;
use Fcntl;
use IO::Select;
use Getopt::Long;
@@ -517,6 +518,10 @@
if ((defined $CONFIG{'also-encrypt-to'}) ! (ref($CONFIG{'also-encrypt-to'}) eq 'ARRAY')) {
$CONFIG{'also-encrypt-to'} = [ $CONFIG{'also-encrypt-to'} ];
};
+ my $locale = Encode::find_encoding(langinfo(I18N::Langinfo::CODESET()));
+ if (defined $locale) {
+ $CONFIG{$_} = $locale-decode($CONFIG{$_}) for qw/owner mail-template/;
+ }
};
sub make_gpg_fds() {
@@ -790,7 +795,7 @@
my @uids;
for my $key (@keys) {
- push @uids, $key-{'text'};
+ push @uids, Encode::decode('utf-8',$key-{'text'});
};
my $message = $template-fill_in(HASH = { key = $key_id,
uids = \@uids,
@@ -801,7 +806,7 @@
Type= text/plain,
Charset = utf-8,
Disposition = 'inline',
- Data= $message);
+ Data= Encode::encode('utf-8',$message));
my @key_entities;
for my $key (@keys) {
signature.asc
Description: Digital signature
Bug#637222: caff does not produce proper mail for non-ascii domain names (IDN)
tags 637222 patch
thanks
IMHO an argument against fixing the issue in Mail::Mailer directly is
that the Q-Encoding of the headers is typically done when constructing
the MIME::Entity object. Mail::Mailer extracts the envelope from/to
from the header (or delegated the extraction to eg, sendmail(1)), hence
if it were to take care of the conversion of the envelope to ASCII,
I don't see why it shouldn't perform the Q-Encoding as well. Maybe it
should do both, but doing complex massaging of the headers seems to be
beyond what it does at the moment.
Anyway, the enclosed patch, to be applied on top of that posted to #659971
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659971#17
forces caff to convert addresses to ASCII when constructing the
MIME::Entity object, and as far as I can tell, solves the problem with
Internalized Domain Names.
Cheers,
--
Guilhem.
diff -ru a/caff/caff b/caff/caff
--- a/caff/caff
+++ b/caff/caff
@@ -322,6 +322,7 @@
use MIME::Entity;
use Encode;
use I18N::Langinfo;
+use Net::IDN::Encode qw{email_to_ascii};
use Fcntl;
use IO::Select;
use Getopt::Long;
@@ -521,6 +522,8 @@
my $locale = Encode::find_encoding(langinfo(I18N::Langinfo::CODESET()));
if (defined $locale) {
$CONFIG{$_} = $locale-decode($CONFIG{$_}) for qw/owner mail-template/;
+ $CONFIG{$_} = email_to_ascii($locale-decode($CONFIG{$_}))
+ for grep {defined $CONFIG{$_}} qw/email bcc reply-to/;
}
};
@@ -874,7 +877,7 @@
};
$message_entity-head-add(Subject, Your signed PGP key 0x$key_id);
- $message_entity-head-add(To, $address);
+ $message_entity-head-add(To, email_to_ascii(Encode::decode('utf-8', $address)));
$message_entity-head-add(From, ''.Encode::encode('MIME-Q', $CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
$message_entity-head-add(Sender, ''.Encode::encode('MIME-Q', $CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
$message_entity-head-add(Reply-To, $CONFIG{'reply-to'}) if defined $CONFIG{'reply-to'};
diff -ru a/caff/README b/caff/README
--- a/caff/README
+++ b/caff/README
@@ -34,7 +34,8 @@
gnupg (= 1.3.92), perl, libgnupg-interface-perl,
- libtext-template-perl, libmime-perl, libmailtools-perl (= 1.62)
+ libtext-template-perl, libmime-perl, libmailtools-perl (= 1.62),
+ libnet-idn-encode-perl
INSTALLATION
diff -ru a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,8 @@
Architecture: any
Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, gnupg,
libgnupg-interface-perl, libtext-template-perl, libmime-tools-perl,
- libmailtools-perl, libterm-readkey-perl, libclass-methodmaker-perl, qprint
+ libmailtools-perl, libterm-readkey-perl, libclass-methodmaker-perl,
+ libnet-idn-encode-perl, qprint
Recommends: default-mta | mail-transport-agent, libpaper-utils,
libgd-gd2-noxpm-perl | libgd-gd2-perl,
libtext-iconv-perl | libintl-perl | recode, dialog | whiptail
signature.asc
Description: Digital signature
Bug#734179: pinentry-curses: Fails to display multiline prompts
Package: pinentry-curses Version: 0.8.3-1 Severity: important Dear Maintainer, Since the upgrade to 0.8.3-1 pinentry-curses is no longer able to show multiline prompts. This is problematic when used with gpg-agent, since for instance the key ID that is being unlocked is no longer visible. Here is a minimal example: pinentry-curses --lc-ctype=en_US.UTF8 --ttyname=$(tty) END SETDESC This is%0Aa multiline%0Aprompt.%0A SETPROMPT GETPIN END 0.8.3-1 shows some garbage after the first linefeed (encoded as %0A as per the PIN-entry protocol), whereas 0.8.1-1 shows a correct 3-lines prompt. FWIW, the following (multiline) prompt used by gpg2 (2.0.22-3) is properly passed to the gpg-agent (2.0.22-3) as shown in the log, but pinentry-curses 0.8.3-1 only shows the first line. SETDESC Please enter the passphrase to unlock the secret key for the OpenPGP certificate:%0A%22Guilhem Moulin guil...@fripost.org%22%0A4096-bit RSA key, ID 0xC27306B86774D6F7,%0Acreated 2012-11-05 (main key ID 0x39278DA8109E6244).%0A Cheers, -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pinentry-curses depends on: ii libc62.17-97 ii libncurses5 5.9+20130608-1 ii libtinfo55.9+20130608-1 pinentry-curses recommends no packages. Versions of packages pinentry-curses suggests: pn pinentry-doc none -- no debconf information signature.asc Description: Digital signature
Bug#618781: signing-party: [gpgsigs] please support UTF-8-encoded files
tags 618781 patch
thanks
I think the problem is not with gpgsigs per se, but rather with the
LaTeX output it produces. (As Tanguy hinted at, the text output of
UTF-8 encoded input files seems to be rendered properly.) LaTeX is
in fact known for its poor support of Unicode characters in input files
(‘\usepackage[utf8x]{inputenc}‘ slightly improves that, but it's not a
panacea in any way). On the other hand, other typesetting engines such
as LuaLaTeX or XeLaTeX perform much better.
So, as Postscript files poorly support Unicode characters, why bother
at all with the LaTeX engine? I propose the enclosed patch, which makes
--latex produce an output compatible with pdfLaTex, LuaLaTeX and
XeLaTeX. As for the font rendered in the PDF in the two latter cases,
I chose Droid which has very good Unicode coverage and IMHO is much
better looking than GNU Unifont.
* pdfLaTex (no dependencies beside common texlive packages): renders
latin1 characters properly, but fails to render Cyrillic and CJK
characters.
* luaLaTeX (depends on core texlive packages, texlive-luatex, luatex
and fonts-droid): I believe only CJK are not properly rendered.
* XeLaTeX (depends on core texlive packages, texlive-xetex and
fonts-droid): so far I didn't find any character that wasn't
properly rendered.
Also, since the 3 LaTeX typesetting engines above produce a PDF, and
since JPG images can be embedded in PDF files, the conversion from JPG
to EPS (or PDF for that matter) is no longer needed. I therefore
renamed ‘gpgsigs-eps-helper’ as ‘gpgsigs-helper’.
If this patch is accepted, I'll try to port it to gpg-key2ps(1) which
I believe should solve #412512 and #316131/454405.
Cheers,
--
Guilhem.
diff -ru a/gpgsigs/gpgsigs b/gpgsigs/gpgsigs
--- a/gpgsigs/gpgsigs
+++ b/gpgsigs/gpgsigs
@@ -181,8 +181,8 @@
next if $uidstatus eq r;
if ($latex and not $photocount) { # call once per key
my ($shortkey) = substr $key, -8;
- system rm -f $shortkey.[1-9]*.eps;
- system gpg --photo-viewer 'gpgsigs-eps-helper $shortkey' --list-options show-photos --list-key $key /dev/null;
+ system rm -f $shortkey.[1-9]*.jpg;
+ system gpg --photo-viewer 'gpgsigs-helper $shortkey' --list-options show-photos --list-key $key /dev/null;
$photocount = 1;
}
my ($shortkey) = substr $key, -8;
@@ -307,8 +307,19 @@
\documentclass{article}
\usepackage[margin=2cm]{geometry}
\usepackage{alltt}
-\usepackage{graphicx}
-\usepackage{grffile}
+\usepackage{graphicx,grffile}
+\usepackage{ifluatex,ifxetex}
+\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0
+ \usepackage[utf8x]{inputenc}
+\else
+ \usepackage[log-declarations=false]{xparse}
+ \usepackage{fontspec}
+ \setmonofont{Droid Sans Mono}
+ \ifxetex
+\usepackage[quiet]{xeCJK}
+\CJKfontspec{Droid Sans Fallback}
+ \fi
+\fi
\begin{document}
\begin{alltt}
EOF
@@ -388,6 +399,9 @@
print WRITE print_tag($key, $uid) . $_;
next;
}
+ if ( /^[_-]{50,}$/ and $latex ) {
+ $_ = \n\\hrule\n;
+ }
print WRITE;
}
Only in a/gpgsigs: gpgsigs-eps-helper
diff -ru a/gpgsigs/gpgsigs-eps-helper b/gpgsigs/gpgsigs-eps-helper
--- a/gpgsigs/gpgsigs-eps-helper
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-
-ID=$1
-NUM=1
-
-while test -e $ID.$NUM.eps ; do
- NUM=`expr $NUM + 1`
-done
-
-convert - $ID.$NUM.eps
Only in b/gpgsigs: gpgsigs-helper
diff -ru a/gpgsigs/gpgsigs-helper b/gpgsigs/gpgsigs-helper
--- /dev/null
+++ b/gpgsigs/gpgsigs-helper
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+ID=$1
+NUM=1
+
+while test -e $ID.$NUM.jpg ; do
+NUM=$(( $NUM + 1 ))
+done
+
+cat $ID.$NUM.jpg
diff -ru a/gpgsigs/Makefile b/gpgsigs/Makefile
--- a/gpgsigs/Makefile
+++ b/gpgsigs/Makefile
@@ -5,8 +5,8 @@
install:
install -D gpgsigs $(DESTDIR)/usr/bin/gpgsigs
- install -D gpgsigs-eps-helper \
- $(DESTDIR)/usr/share/signing-party/gpgsigs-eps-helper
+ install -D gpgsigs-helper \
+ $(DESTDIR)/usr/share/signing-party/gpgsigs-helper
install -d $(DESTDIR)/usr/share/doc/signing-party/examples/gpgsigs
install -m644 gpgsigs-lt2k5*.txt \
$(DESTDIR)/usr/share/doc/signing-party/examples/gpgsigs
signature.asc
Description: Digital signature
Bug#738718: gpgsigs: should wrap long uids (when used with --latex) and digest lines
Package: signing-party
Version: 1.1.5-1
Severity: normal
Tags: patch
Dear Maintainer,
gpgsigs currently doesn't wrap long UIDs in its LaTeX output. This is
a problem, because after compilation and printing, the full UID is not
always visible on the printout.
I propose the enclosed patch, which crudely folds UIDs that are longer
than 78 characters. (Wrapping on word boundaries only might be
preferable, but that's slightly harder to implement :-P, and the patch
matches a typical terminal behavior.)
Furthermore, longer digests such as SHA-256 might need to be folded as
well. Since gpgparticipants(1) puts placeholders after the digest
algorithm, I propose to replace each placeholder character ‘_’ by the
corresponding hex character from the digest. This allows gpgsigs'
output to follow closely the template given, hence in practice folding
long digests as well.
Thanks,
cheers,
--
Guilhem.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages signing-party depends on:
ii gnupg 1.4.16-1
ii libc6 2.17-97
ii libclass-methodmaker-perl 2.19-1
ii libgnupg-interface-perl0.46-3
ii libmailtools-perl 2.12-1
ii libmime-tools-perl 5.505-1
ii libterm-readkey-perl 2.31-1
ii libtext-template-perl 1.46-1
ii perl 5.18.2-2
ii qprint 1.0.dfsg.2-2
Versions of packages signing-party recommends:
ii dialog 1.2-20130928-1
ii libgd-gd2-perl 1:2.46-3.1+b1
ii libintl-perl1.23-1
ii libpaper-utils 1.1.24+nmu2
ii libtext-iconv-perl 1.7-5+b1
ii postfix [mail-transport-agent] 2.10.2-1
ii recode 3.6-21
ii whiptail0.52.15-3
Versions of packages signing-party suggests:
ii imagemagick8:6.7.7.10-7
ii mutt 1.5.21-6.4
ii texlive-latex-recommended 2013.20140123-1
ii wipe 0.22-1
-- no debconf information
diff -ru a/gpgsigs/gpgsigs b/gpgsigs/gpgsigs
--- a/gpgsigs/gpgsigs
+++ b/gpgsigs/gpgsigs
@@ -317,17 +317,31 @@
while (TXT) {
$line++;
$_ = myrecode($_, $fromcharset, $charset);
- if (/^MD5 Checksum:/ defined $MD5) {
- s/[_[:xdigit:]][_ [:xdigit:]]+_/$MD5/;
- }
- if (/^SHA1 Checksum:/ defined $SHA1) {
- s/[_[:xdigit:]][_ [:xdigit:]]+_/$SHA1/;
- }
- if (/^SHA256 Checksum:/ defined $SHA256) {
- s/[_[:xdigit:]][_ [:xdigit:]]+_/$SHA256/;
- }
- if (/^RIPEMD160 Checksum:/ defined $RIPEMD160) {
- s/[_[:xdigit:]][_ [:xdigit:]]+_/$RIPEMD160/;
+ my $md;
+ if (/^(?md\S+) Checksum:/) {
+ if ($+{md} eq 'MD5') {
+ $md = $MD5;
+ } elsif ($+{md} eq 'SHA1') {
+ $md = $SHA1;
+ } elsif ($+{md} eq 'SHA256') {
+ $md = $SHA256;
+ } elsif ($+{md} eq 'RIPEMD160') {
+ $md = $RIPEMD160;
+ }
+ if (!defined $md) {
+ warn Unknown digest $+{md};
+ } else {
+ $md =~ s/\s//g;
+ my $r = $_;
+ while ( /^(?:.*_)?$/ ) {
+$line++;
+$_ = TXT;
+$r .= $_;
+ }
+$r =~ s/_/%c/g;
+ print WRITE sprintf ($r, unpack (C*, $md));
+ next;
+ }
}
if ( m/^[0-9]+\s+\[ \] Fingerprint OK/ ){
@@ -365,7 +379,15 @@
print WRITE [$inc] incoming signatures\n if $inc =~ /\S/;
if ($refresh or $latex) {
foreach $uid (@{$uids{$key}}) {
-print WRITE print_tag($key, $uid) . $uid\n;
+my $tag = print_tag($key, $uid);
+if (!$latex) {
+ print WRITE $tag .' '. $uid,\n;
+} else {
+ for (my $i = 0; $i length $uid; $i+=78) {
+ print WRITE ($i ? ' ' x length $tag : $tag ), ' ',
+ substr ($uid, $i, 78), \n;
+ }
+}
if ($latex and ($uid =~ /^\[jpeg image/)) {
$photocount++;
print WRITE \\begin{flushright}\n;
signature.asc
Description: Digital signature
Bug#736963: gpgsigs: Doesn't full fingerprint
tags 736963 patch
thanks
The enclosed patch allows the user's key(s) to be passed as gpg accepts
it that is, as short, 0xshort, long or 0xlong format, as well as
a (formatted or not) fingerprint:
- 0x109E6244
- 109E6244
- 0x39278DA8109E6244
- 39278DA8109E6244
- 7420 DF86 BCE1 5A45 8DCE 9976 3927 8DA8 109E 6244
- 7420DF86BCE15A458DCE997639278DA8109E6244
I also changed the hash of signatures and UIDs to prefer the long
(16-digits) format as hash keys: AFIK gpg currently uses that and not
full fingerprints internally (for instance in the output of
--with-columns), so at the moment it doesn't make sense to use all 40
digits there.
Also in the input file, keys can now be passed as short, 0xshort, long,
or 0xlong format; however if fingerprints are present gpgsigs will use
them instead to get the list of keys. That means the input file can be
generated with any --keyid-format (whereas only ‘short’ is currently
accepted), but if --fingerprint is used the 16-digits keyids will be
derived from the 40-digits fingerprint instead.
Cheers,
--
Guilhem.
diff -ru a/gpgsigs/gpgsigs b/gpgsigs/gpgsigs
--- a/gpgsigs/gpgsigs
+++ b/gpgsigs/gpgsigs
@@ -50,7 +50,8 @@
Usage: $PROGRAM_NAME [-r] [-t charset] keyid keytxt [outfile]
-keyid is a long or short keyid (e.g. DE7AAF6E94C09C7F or 94C09C7F)
+keyid is a long or short keyid (e.g. DE7AAF6E94C09C7F or 94C09C7F) or a
+key fingerprint
separate multiple keyids with ','
-rcall gpg --recv-keys before proceeding
-f charset convert keytxt from charset
@@ -118,7 +119,9 @@
my $keytxt = (shift @ARGV) || usage(*STDERR, 1);
my $outfile = (shift @ARGV) || '-';
-map { s/^0x//i; } @mykeys;
+map { y/ //d if /^(?:[0-9A-F]{4} ){5}(?: [0-9A-F]{4}){5}$/; # remove spaces in fprs
+ /^[0-9A-F]{40}$/ ? s/.{24}// : s/^0x//i;
+ } @mykeys;
my %uids = map { $_ = [] } @mykeys;
if (!@mykeys || scalar @ARGV) {
@@ -132,15 +135,18 @@
-r $keytxt or die ($keytxt does not exist\n);
-# get list of keys in file
-my @keys;
+# get list of keys in file (from fingerprints if available)
+my (@keys, @shortkeys);
open (TXT, $keytxt) or die (Cannot open $keytxt\n);
while (TXT) {
- if ( m/^pub +(?:\d+)[DR]\/([0-9A-F]{8}) [0-9]{4}-[0-9]{2}-[0-9]{2} *(.*)/ ) {
- push @keys, $1;
+ if ( m/^pub +(?:\d+)[DR]\/(?:0x)?([0-9A-F]{8}|[0-9A-F]{16}) [0-9]{4}-[0-9]{2}-[0-9]{2}/ ) {
+ push @shortkeys, $1;
+ } elsif ( m/^\s+Key fingerprint = ((?:[0-9A-F]{4} ){5}(?: [0-9A-F]{4}){5}|[0-9A-F]{40})$/ ) {
+ push @keys, substr ($1 =~ y/ //rd, -16);
}
}
close TXT;
+@keys = @shortkeys unless @keys;
# get all known signatures
@@ -167,10 +173,9 @@
$uid =~ s/\\x([0-9a-f][0-9a-f])/ chr(hex($1)) /gie;
$uid = myrecode($uid, UTF-8, $charset);
- my ($shortkey) = substr $key, -8;
# Remember non-revoked uids
next if $uidstatus eq r;
- push @{$uids{$shortkey}}, $uid;
+ push @{$uids{$key}}, $uid;
next;
}
if ( m/^uat:(.)[^:]+::([0-9A-F]+)::\d+ (\d+)/ ) { # uat:-2006-08-03::27BAEAF742BD253C2F3F03B043DC1536880193C4::1 7993:
@@ -180,13 +185,11 @@
$uid = [jpeg image of size $size];
next if $uidstatus eq r;
if ($latex and not $photocount) { # call once per key
- my ($shortkey) = substr $key, -8;
- system rm -f $shortkey.[1-9]*.eps;
- system gpg --photo-viewer 'gpgsigs-eps-helper $shortkey' --list-options show-photos --list-key $key /dev/null;
+ system rm -f $key.[1-9]*.eps;
+ system gpg --photo-viewer 'gpgsigs-eps-helper $key' --list-options show-photos --list-key $key /dev/null;
$photocount = 1;
}
- my ($shortkey) = substr $key, -8;
- push @{$uids{$shortkey}}, $uid;
+ push @{$uids{$key}}, $uid;
next;
}
if ( m/^sig:(?:.*?:){3,3}([0-9A-F]{8})([0-9A-F]{8}):(?:.*?:){5,5}(.*?):/ ) {
@@ -225,9 +228,11 @@
close SIGS;
print STDERR \n;
-for my $k ( keys %{$sigs} ) {
- if ( $k =~ m/^[0-9A-F]{8}([0-9A-F]{8})$/ ) {
+foreach my $k ( keys %uids ) {
+ # if @mykeys were given as short keyids, copy sigs and uids for these keyids
+ if ( $k =~ m/^[0-9A-F]{8}([0-9A-F]{8})$/ and grep { $1 eq $_ } @mykeys ) {
$sigs-{$1} = $sigs-{$k};
+ $uids{$1} = $uids{$k};
}
}
@@ -342,7 +347,7 @@
next;
}
- if ( m/^pub +(?:\d+)[DR]\/([0-9A-F]{8}) [0-9]{4}-[0-9]{2}-[0-9]{2} *(.*)/ ) {
+ if ( m/^pub +(?:\d+)[DR]\/(?:0x)?([0-9A-F]{8}|[0-9A-F]{16}) [0-9]{4}-[0-9]{2}-[0-9]{2} *(.*)/ ) {
$key = $1;
$uid = $2;
#if ($uid) { # in gpg 1.2, the first uid is here
@@ -354,7 +359,9 @@
next;
}
- if ( m/^ *Key fingerprint/ ) {
+ if ( m/^\s+Key fingerprint = ((?:[0-9A-F]{4} ){5}(?: [0-9A-F]{4}){5}|[0-9A-F]{40})$/ ) {
+ # derive the keyid from the fingerprint if available
+ $key = substr $1 =~ y/ //rd, -16;
print WRITE;
my $inc = ;
foreach my $mykey (@mykeys) {
signature.asc
Description: Digital signature
Bug#666974: installs to /dev/sda when grub-installer/bootdev = /dev/sdb
Package: grub-installer Version: 1.85 Followup-For: Bug #666974 Tags: patch Dear Maintainer, The bug is still present in Wheezy's installer. The enclosed (naive) patch makes sure grub-installer jumps to state 2 (hence ignores $default_bootdev) if grub-installer/bootdev is known. It has been successfully tested on manual and automated installations with and without preseeding grub-installer/bootdev. -8--8- diff -ru a/grub-installer b/grub-installer --- a/grub-installer +++ b/grub-installer @@ -599,7 +599,7 @@ exit 10 fi db_get $q - if [ $RET = true ]; then + if [ $RET = true ] ! db_get grub-installer/bootdev; then bootdev=$default_bootdev break else -8--8- Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#739815: RFA: signing-party -- Various OpenPGP related tools
Hi, I'd also be happy to give a hand by becoming an adopter. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#739815: RFA: signing-party -- Various OpenPGP related tools
Hi Thijs, On Sun, 23 Feb 2014 at 14:53:28 +0100, Thijs Kinkhorst wrote: Thank you both for your interest. And thanks for your trust :-) If you give me your alioth username I will arrange the commit access. My alioth username is guilhem-guest. By the way as far as I'm concerned I'll use git-svn if the project sticks to svn as VCS. Just saying, if everyone does the same thing it'd make sense to use switch to git ;-) Some more information on adopting a package and packaging in general can be found here: https://wiki.debian.org/DebianMentorsFaq#How_do_I_adopt_an_existing_package.3F https://www.debian.org/devel/ Thanks! Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#693906: gpgsigs: cannot find gpgsigs-eps-helper (when used with --latex)
Interesting. Since 2008-03-16 /usr/share/signing-party/ is explicitly added to the $PATH. Does your gpg.conf explicitly sets a value for exec-path? I'm just curious as I can't reproduce that bug in a clean sid chroot; But your solution is cleaner is cleaner and more robust since it doesn't rely on shell expansion. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#723024: caff: fails if stdin is not a TTY
That's cool! I cannot think of any side effect either, short of - that'll only work on POSIX systems (unsure if we care, but it'd still be possible to fallback to STDIN on non-POSIX systems), and - one would not longer be able to answer the questions with things like ‘yes | caff …’. (That wouldn't really make sense anyway, as there are configuration options for that). Also, rather than keeping opening/closing the TTY for each question asked, an improvement would be to do it once and for all at the beginning. One could even close STDIN and re-open it as /dev/tty; This behavior can be emulated in a POSIX shell, and is one of the workaround to the bad interaction between xargs and caff (or generally any program proceeding its user interaction over STDIN): xargs sh -c '/dev/tty caff $@' /path/to/fprs I second that patch anyway ;-) If no one objects I'll merge the slight modification outlined above. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#597808: caff: SMTP errors are ignored
Well you've been warned :-P [WARN] You have set arguments to pass to Mail::Mailer. Better fix your MTA. (Also, Mail::Mailer's error reporting is non existant, so it won't tell you when it doesn't work.) As for the error itself, it has nothing to do with caff but with the “non existence“ of Mail::Mailer's error reporting. Rather than making caff (MIME::Entity, actually) use another SMTP client, it'd be easier to improve Mail::Mailer. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#728543: caff: missing dependencie to libnet-smtp-ssl-perl
notfound 728543 1.1.5-1 thanks Hi Carsten, If anything should depend on libnet-smtp-ssl-perl it should probably be libmailtools-perl (which provides Mail::Mailer and which signing-party depends on), not signining-party itself. libmailtools-perl actually added the dependency somewhere between the wheezy (2.09-1) and sid/testing (2.12-1) versions :-) Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#625687: caff: Allow user to sign emails in addition to encryption.
Hi there, While adding signencrypt support to caff certainly wouldn't hurt, I'm unsure what is the threat model exactly and what what kind of vulnerability a message signature would patch. I mean, the only interesting thing in the messages caff sends is the attachment (encrypted together with the rest of the body) containing the recipient's signed UIDs'; I can't think of a way to impersonate that other than cracking the master key, in which case signing the mail would be moot since the sender would have lost already. Now regarding the patch, I think I would feel quite uneasy with Perl variables containing the passphrase to my signing key. (OTOH GnuPG carefully stores in secure memory, unless I misunderstood.) Why don't you use the agent if available, and otherwise fall back to the usual GnuPG prompt? Thanks, cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#720413: caff key import from keyservers is broken
On Wed, 21 Aug 2013 at 10:40:38 -0400, Joey Hess wrote:
caff seems to have its own hard-coded list of keyservers, rather than using
the same ones I have gpg configured to use. This seems a gratuitous
duplication
of configuration.
An alternative would be to grep ~/.gnupg/gpg.conf for ‘keyserver‘ and
‘keyserver-options’ (which can be required if the keyserver is behind a proxy
for instance) and thread them through each call to gpg. However it's a bit
ugly IMHO, and might not be desirable as some people may want to use a specific
keyserver for massive signing homework.
Perhaps caff should grep for ‘keyserver‘ in ~/.caff/gnupghome/gpg.conf instead,
and fall back to ‘--keyserver pool.sks-keyservers.net’ *only* if the user
didn't specify anything in the configuration file? (Still a bit ugly, but I
can't find another way to achieve backward compatibility.) That way if you
don't want to duplicate the configuration you could always symlink the files
;-)
Even once I've manually imported the keys I want to sign, and run caff
with --keys-from-gnupg (which remains misdocumented for 1 year?!),
it fails:
[…]
The current behavior is that unless ‘$CONFIG{'no-download'}’ is set (it isn't
by default) keys are automatically refreshed against the ‘$CONFIG{keyserver}’
(defaults to pool.sks-keyservers.net). I guess these keys weren't exported to
the keyserver your caff ended up talking to, right?
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#728543: caff: missing dependency to libnet-smtp-ssl-perl
Hi Carsten, On Tue, 25 Feb 2014 at 17:24:43 +0100, Carsten Schoenert wrote: So everything should be fine for Jessie or greater. But as I can't check Wheezy directly. So a quick search via packages.debian.org shows me the dependency is still missing in Wheezy https://packages.debian.org/wheezy/signing-party https://packages.debian.org/wheezy/libmailtools-perl Don't know if it's possible to get a new version into stable-security with a better depends field set. You can try your luck and reassign the bug to libmailtools-perl, but IMHO it's unlikely that it would qualify as a security-update :-P In fact since Mail::Mailer is fully usuable without Net::SMTP::SSL for methods other than 'smtps', making libmailtools-perl depend on libnet-smtp-ssl-perl can be seen as controversial, as it seems to contradict Debian Policy section 7.2: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#652686: caff: mail=no doesn't write messages to disk
Hi, Are you sure the issue was encountered using 1.1.4-1? According to the changelog a similar bug, #590666, was fixed during that release. I can't reproduce the bug anyway. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#612178: caff: silently fails if .caff/gnupghome has wrong permissions
Hi, On Tue, 19 Mar 2013 15:47:18 +0100 Dominik George wrote: it actually tells you about the wrong permissions when you tell it to continue after the error. Which is really not very helpful. I pushed a patch to make it dump gpg's standard error after importing the keys, meaning you'd get [INFO] fetching keys, this will take a while... gpg: WARNING: unsafe permissions on homedir `…' gpg: external program calls are disabled due to unsafe options file permissions gpg: keyserver communications error: general error gpg: keyserver receive failed: general error [NOTICE] Import failed for: …. I also wonder how the insecure permissions get set in the first place. I hit this problem a few days ago and I am absolutely sure I did not touch the gnupghome/ permissions. So mayber caff even creates it with inadequate permissions… That would be extremely scary, as the new directories are created using Perl's ‘mkpath’ (from the core module File::Path) with a mode explicitly set to 0700. Hopefully dumping gpg's warning right away would make the bug easier to corner, if bug there is. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#677718: [signing-party] pgp-clean seems to also remove encryption subkey, not only signatures.
Hi, In fact the manpage says (all) subkeys are removed by default unless pgp-clean is used with flag -s: -s --export-subkeys Do not remove subkeys. (Pruned by default.) Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#644472: caff: Support sending mails via MUA (such as mutt)
Hi,
Ideally solving this bug would solve #637115 as well. But I couldn't
find a nice way to integrate mutt (probably other MUAs as well) with
caff. First I've got two questions:
1/ Do you want to interact with the MUA (for instance to edit the
headers), or should it work in batch mode?
2/ Should the encryption be done by the MUA, or should it be fed with
encrypted content already?
If you answer the former in both 1 and 2, then an interface could be
something along the lines of
$CONFIG{'mail-cmd'} = [ 'mutt', '-e', set from='$CONFIG{owner}
$CONFIG{email} pgp_autoencrypt'
, '-s', Your signed PGP key
0x$recipient{keyid}
, '-i', $recipient{'template-file'}
, '-a', $recipient{'signature-file'}
, '--'
, $recipient{address} ]
(Where the hash %recipient is wiped and repopulated for each key.)
Mutt can also work in batch mode (it takes a text/plain body on STDIN),
but then pgp_autoencrypt doesn't seem to work anymore.
echo hello | mutt -e 'set pgp_autoencrypt' -s test -a /path/to/attachement
-- t...@example.org
Sadly if you answer the latter in 2, I couldn't find a way to do
that properly in either batch or interactive mode. It sort of works,
but without manually adding the MIME boundary to the Content-Type the
output looks strange (obviously); when I try to add it manually
mutt -e set from=m...@example.org \
-e 'set content_type=multipart/encrypted;
protocol=\application/pgp-encrypted\;
boundary=\--=_1393531266-28793-1\' \
-s test r...@example.org \
/path/to/caff/body_mail
(where /path/to/caff/body_mail is one of the mails in ~/.caff/keys/
stripped off its headers) mutt seems doesn't seem to treat STDIN as
multipart and r...@example.org receives only the closing boundary.
Feel free to suggest another interface if you like, but IMHO it would be
great to treat the 4 cases in the above questions. Perhaps a mutt guru
here know how to provide multipart content in batch mode?
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#614981: allow option specification for dropbear in /etc/initramfs-tools/initramfs.conf
Control: found -1 2013.60-1 Hi, I fully second this patch. Would be great to see it applied in Jessie ;-) Another common use case is where the dropbear in the ramdisk should listen on a port other than 22: then a simple firewall rule can make it inaccessible from the whole world while keeping the main SSH server accessible. Currently the only way to achieve that is again to edit /usr/share/initramfs-tools/scripts/init-premount/dropbear which isn't a very robust solution as it wouldn't survive an upgrade. Thanks, cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#622560: Bug#614981: signing-party: please include a way to parse gpgparticipants output for caff
Hi there, In case you would like to try it out and give feedback before the release, I pushed a fixed to the repository. svn://svn.debian.org/pgp-tools/trunk/ gpgparticipants formatted content is now accepted on caff's STDIN. (Only v4 keys annotated with Fingerprint OK and ID OK are considered for signing.) Furthermore, caff will croak if a checksum box has not been checked, and will warn if the KSP file didn't include an algorithm of the SHA-2 family. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#594907: kspsig -- Key Signing Party signature verification tool
Hi,
While your tool would certainly be a valuable addition to signing-party,
a blocker is that it gets the digest algorithm on certificate signatures
by parsing the output of ‘--list-packets’, which as far as I can tell
isn't documented.
IMHO a better (and faster) approach would be, as you hinted at, to
extract the OpenPGP signature packets from public key packets, cf. RFC
4880 sections. It's non trivial though :-(
Note that if the key of which to check the signatures is in your
keyring, a workaround is to use gpg2 as the digest algorithm is
available on the (documented parsable) ‘--with-colons’ output.
For instance to list signatures with weak digest algorithms (MD5 and
SHA1 [1]):
gpg2 --with-colons --list-sigs $keyID | grep -E
'^(pub|uid|sig(:[^:]*){14}:[12]):'
(But as of 1.1.6-1 gnupg2 is not a dependency of signing-party, and I'm
unsure if doing it before the whole Debian project migrates away from
gnupg to gnupg2 is the right move :-/)
Cheers,
--
Guilhem.
[1] https://tools.ietf.org/html/rfc4880#section-9.4
signature.asc
Description: Digital signature
Bug#722554: signing-party: please include key-report tool in package
Hi Jonas, This looks useful indeed, but after a quick look at the code it doesn't really appeal to me, as the script seems rather unfinished. Also, I find it rather confusing that it's not possible not to report expired/revoked subkeys in case the key has other valid subkey(s) covering the same capabilities. (Many users have a long-term master key and rotate subkeys every once in a while, but invalid subkeys remain on the keyserver regardless.) Did you try it yourself? Maybe you have another view on the subject. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#648991: include Serafeim's post keysigning-party scripts
Hi, I wonder if these scripts are still useful? As of 1.1.6-1 caff is able to parse key fingerprints directly from a gpgparticipants(1) format (and annotated) list. See also #622560: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622560 Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#592787: caff: $CONFIG{'email'} is not being used for MAIL FROM command
Control: tag -1 wontfix
Hi,
On Thu, 20 Mar 2014 21:51:52 -0700, H. S. Teoh wrote:
I'm also running into this problem, caff insists on sending email with
MAIL FROM as username@localhost instead of the value I set in
$CONFIG{'email'}. I've tried Todd Lyons' workaround but it still
didn't work for me. So, this makes caff unusable for me. :-(
Which version of libmailtools-perl are you using? Also, caff uses
Mail::Mailer to send messages; by default messages are piped to
‘sendmail -t’, and as written in the manpage, the caffrc option
'mailer-send' allows to choose another sending method such as SMTP/SMTPS
with extra parameters as needed. Did you change the default method
(not-recommended, it's best to fix your MTA instead)?
I believe Todd's workaround only work for Mail::Mailer::smtp and
Mail::Mailer::smtps. However I personally find it cleaner to add an
extra parameter 'From' to set the Envelope From, rather than messing
around with the environment:
$CONFIG{'mailer-send'} = [ 'smtps'
, Server = 'smtp.example.org'
, Auth = [ 'username', 'password' ]
, From = $CONFIG{email}
];
If you prefer to use the sendmail binary via Mail::Mailer::sendmail
instead (and can't fix your MTA), you can set the envelope sender
address with ‘-f’, see sendmail(1):
$CONFIG{'mailer-send'} = [ 'sendmail', '-f', $CONFIG{email}, '-t' ];
A 'qmail' method is also available but I've never used it; I'm sure the
binary provides a way to set the Envelope From, though.
(Note that although the soon to be 1.1.6 release adds support for
Internalized Domain Names, the conversion to Punycode is only done
*after* reading the configuration file, so you'll have to encode
$CONFIG{email} — and other parameters to $CONFIG{'mailer-send'} —
manually in case they contain non ASCII characters.)
I'm tagging this bug as ‘wontfix’ because although I didn't find how to
set the Envelope From for Mail::Mailer methods anywhere but in the
source code [1], I believe one should file a documentation bug against
libmailtools-perl instead.
Cheers,
--
Guilhem.
[1] See Mail::Mailer::smtp, Mail::Mailer::smtps and
Mail::Util::mailaddress.
signature.asc
Description: Digital signature
Bug#747296: gpgparticipants: LC_CTYPES fallback causes non-UTF-8 output
Hi Stefan, On Wed, 07 May 2014 at 11:25:37 +0200, Stefan Huber wrote: gpgparticipants sets LC_CTYPE=C.UTF-8 for gpg when printing each key. On systems where C.UTF-8 is not available (e.g., Gentoo), the fallback locale causes the output not to be UTF-8 encoded, even if the overridden LC_CTYPE would have been an UTF-8 locale. IMHO it would be best to force the output to be in English (some of the other tools shipped with signing-party parse it to retrieve the fingerprints for instance). I therefore applied your patch with ‘LANGUAGE=en’. Thanks! -- Guilhem. signature.asc Description: Digital signature
Bug#747296: gpgparticipants: LC_CTYPES fallback causes non-UTF-8 output
On Wed, 07 May 2014 at 14:22:30 +0200, Stefan Huber wrote: Thank you for applying the patch. Since you apply LANGUAGE=en to gpg, you may want to look into using LC_TIME=en for /bin/date, such that the time on the first line is given in English? As ‘en’ is not a valid locale, I think date(1) will fall back to the default ‘C’ locale (unless the higher precedence LC_ALL is set to an existing locale). So I suggest we prefix date with LC_ALL=C instead, which should force date(1) to use unlocalized output. Thanks for pointing that out anyway; the current LANG=C has lower precedence than LC_TIME and LC_ALL. :-) Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#751782: signing-party: caff seems stuck after saving the signed key
Hi, On Mon, 16 Jun 2014 at 17:59:45 +0200, Olivier Berger wrote: False error : a result of my own customizations. Sorry about the bothering. No problem :-) It might still be useful to fix this (which looks like a race condition and/or unexpected output from gpg). Would you mind sharing your .caffrc and your .caff/gnupghome/gpg.conf? You can obfuscate the strings and key IDs, but the configuration options would be useful. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#753383: grub-legacy: grub-install(8) should honor $TMPDIR
Source: grub-legacy
Version: 0.97-67
Severity: normal
Tag: patch
Dear Maintainer,
It'd be convenient to place grub-install's temporary files in $TMPDIR
when set. Right now they are placed in /tmp, which on a typical install
is on the same partition as /; hence if for some reason / is mounted in
read-only mode, it's not possible to (re)install the boot-loader.
--
Guilhem.
--- a/grub-install.in
+++ b/grub-install.in
@@ -31,8 +31,8 @@
grub_shell=${sbindir}/grub
grub_set_default=${sbindir}/grub-set-default
-log_file=/tmp/grub-install.log.$$
-img_file=/tmp/grub-install.img.$$
+log_file=${TMPDIR:-/tmp}/grub-install.log.$$
+img_file=${TMPDIR:-/tmp}/tmp/grub-install.img.$$
rootdir=
grub_prefix=/boot/grub
@@ -47,8 +47,8 @@
mklog=/bin/tempfile --prefix=grub
mkimg=/bin/tempfile --prefix=grub
elif test -x /bin/mktemp; then
-mklog=/bin/mktemp /tmp/grub-install.log.XX
-mkimg=/bin/mktemp /tmp/grub-install.img.XX
+mklog=/bin/mktemp --tmdir grub-install.log.XX
+mkimg=/bin/mktemp --tmdir grub-install.img.XX
else
mklog=
mkimg=
signature.asc
Description: Digital signature
Bug#758991: Seeveral Patch to fixed issue in signing-party-1.1.5
Hi Jochen,
On Sat, 23 Aug 2014 at 17:31:06 +0200, Jochen Schmitt wrote:
I would like to forward several patches which I have applied to the
pgp-tools package in Fedora for upstream integration.
Thanks!
diff -urNp --exclude-from=/home/mdomsch/excludes --minimal
signing-party-1.1.orig/keyanalyze/Makefile
signing-party-1.1/keyanalyze/Makefile
--- signing-party-1.1.orig/keyanalyze/Makefile2009-02-21
04:30:01.0 -0600
+++ signing-party-1.1/keyanalyze/Makefile 2009-04-18 00:04:14.0
-0500
@@ -1,21 +1,16 @@
LDLIBS=-lpthread
CFLAGS=-O2 -W -Wall -g
-all: keyanalyze process_keys pgpring/pgpring
+all: keyanalyze process_keys
Which issue gets fixed by not compiling pgpring?
diff -up signing-party-1.1.4/gpg-key2ps/gpg-key2ps.paper
signing-party-1.1.4/gpg-key2ps/gpg-key2ps
--- signing-party-1.1.4/gpg-key2ps/gpg-key2ps.paper 2013-06-16
16:30:54.643953002 +0200
+++ signing-party-1.1.4/gpg-key2ps/gpg-key2ps 2013-06-16 16:33:36.937227454
+0200
@@ -89,8 +89,8 @@ usage(\*STDERR, 1) unless scalar @ARGV
# determine the paper size through the paperconf tool
my $w; my $h;
if ( `which paperconf` $? == 0 ) {
- $w=`paperconf -w`;
- $h=`paperconf -h`;
+ $w=`paperconf -w | tr , .`;
+ $h=`paperconf -h` | tr , .`;
I just pushed something equivalent, but used Perl's transliteration
operator instead, which should be more efficient than a fork.
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#637222: caff cannot handle IDN domains
Hi Noël,
On Tue, 26 Aug 2014 at 18:43:51 +0200, Noël Köthe wrote:
caff doens not convert the IDN domains to punycode:
Hmm, it's working fine here (signing-party 1.1.8-1):
:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE=en_US.utf8
LC_NUMERIC=C
LC_TIME=en_DK.utf8
LC_COLLATE=en_US.utf8
LC_MONETARY=en_US.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=sv_SE.utf8
LC_NAME=sv_SE.utf8
LC_ADDRESS=sv_SE.utf8
LC_TELEPHONE=sv_SE.utf8
LC_MEASUREMENT=sv_SE.utf8
LC_IDENTIFICATION=en_US.utf8
LC_ALL=
:~$ grep test ~/.caffrc
$CONFIG{'owner'} = 'test IDNA ☮ (✘)';
$CONFIG{'email'} = 'test@λ.example.org';
$CONFIG{'reply-to'} = 'test@λ.example.org';
:~$ caff A45E405C0C6C80F13FF1521768C078BE88F80CDA
:~# postcat -q 6F397402B0
[…]
*** MESSAGE CONTENTS deferred/6/6F397402B0 ***
Received: by localhost.localdomain (Postfix, from userid 1000)
id 6F397402B0; Tue, 26 Aug 2014 18:32:36 +0200 (CEST)
Content-Type: multipart/encrypted;
protocol=application/pgp-encrypted;
boundary=--=_1409070754-10676-3
X-Mailer: MIME-tools 5.505 (Entity 5.505)
From: =?UTF-8?Q?test=20IDNA=20=E2=98=AE=20?=(=?UTF-8?Q?=E2=9C=98?=)
t...@xn--wxa.example.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: t...@xn--wxa.example.org
User-Agent: caff 0.0.0.unknown - http://pgp-tools.alioth.debian.org/
Sender: =?UTF-8?Q?test=20IDNA=20=E2=98=AE=20?=(=?UTF-8?Q?=E2=9C=98?=)
t...@xn--wxa.example.org
To: n...@xn--kthe-5qa.de
Subject: Your signed PGP key 0x68C078BE88F80CDA
Message-Id: 20140826163236.6F397402B0@localhost.localdomain
Date: Tue, 26 Aug 2014 18:32:36 +0200 (CEST)
[…]
Could you share your locales?
--
Guilhem.
signature.asc
Description: Digital signature
Bug#753671: caff: please support gpg2
I did file a bug against gpg2 a couple of weeks ago (#751266). I'm a bit reluctant to implement a dirty bugfix in caff, as one can fallback to gpg in the meantime. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#750357: caff: Perl warning when sending mail
Hi Ralf,
On Mon, 02 Jun 2014 at 22:22:15 +0200, Ralf Jung wrote:
After setting up caff as described in https://wiki.debian.org/caff, I still
get the following warnings when caff sends a mail
Use of uninitialized value $name in pattern match (m//) at
/usr/share/perl5/Mail/Internet.pm line 537, TTY line 1.
Use of uninitialized value $name in sprintf at
/usr/share/perl5/Mail/Internet.pm line 542.
Hmm, does the user you start caff with have a valid user name? What's
the output of
grep $(id -u) /etc/passwd | cut -d':' -f5
From Mail::Internet's source code, it seems like it this module requires
either a non empty user name, or a non empty ‘NAME’ environment
variable.
Does starting caff as
NAME='John Doe' caff …
solve the issue? If it does, it has nothing to do with caff. You may
want to reassign your bug to libmailtools-perl instead, but you can also
change your username or set ‘NAME’ to something not empty in your
.caffrc:
chfn -f John Doe
or
echo '$ENV{NAME} = John Doe' ~/.caffrc
Hope that helps,
cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#730848: postfix-ldap: Please compile it with -DUSE_LDAP_SASL to enable SASL binds
Hi, Is there a reason *not* to enable SASL binds in postfix-ldap? After all, dict_ldap.so is linked against libsasl and OpenLDAP's libldap, which does support SASL binds. Furthermore, ldap_table(5) and /usr/share/doc/postfix/LDAP_README.gz already mention SASL binds (OK it's written that their availability depends on Postfix being compiled with -DUSE_LDAP_SASL, but I guess I wasn't the only one confused by the manpage). A neat use case for SASL binds is that it allows to easily restrict access to the LDAP directory to the ‘postfix’ user only, without the hassle inherent to passwords: server_host = ldapi://%2Fprivate%2Fldapi/ bind = sasl sasl_mechs = EXTERNAL (Assuming a LDAPI socket in Postfix's chroot, and the proper …,cn=peercred,cn=external,cn=auth ACLs on the LDAP directory.) Would be great to have that available in jessie :-) Thanks! -- Guilhem. signature.asc Description: Digital signature
Bug#750357: caff: Perl warning when sending mail
Control: retitle -1 Mail::Internet spews warnings for unnamed users
Control: reassign -1 libmailtools-perl 2.12-1
Control: tag -1 patch
(split /,/, $name)[0] is undefined when $name is the empty string.
--
Guilhem.
--- a/Mail/Internet.pm
+++ b/Mail/Internet.pm
@@ -532,7 +532,7 @@
# seperated fields, only the first of which should be used to prevent
# accidental exposure of system-local information like phone numbers/
# room numbers.
-$name = (split /,/, $name)[0];
+$name = (split /,/, $name)[0] if $name ne ;
if($name =~ /[^\w\s]/)
{ $name =~ s//\/g;
signature.asc
Description: Digital signature
Bug#751105: netcat-openbsd: New upstream version available
Package: netcat-openbsd Version: 1.105-7 Severity: normal Dear Maintainer, An interesting feature available in the new release is the addition of a ‘-F’ flag, to pass the first connected socket to the standard output and exit. (This is useful with the ‘ProxyUseFdPass’ option in OpenSSH 6.5 or latter.) http://www.openbsd.org/cgi-bin/man.cgi?query=nc Thanks! Cheers, -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages netcat-openbsd depends on: ii libbsd0 0.6.0-2 ii libc62.19-1 netcat-openbsd recommends no packages. netcat-openbsd suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#751252: caff: doesn't send email found no signed uids
Control: severity -1 important Hi Ilario, First off, thanks for this thorough report :-) This seems to be due to gpg ignoring signatures under the cutoff certification level (2 by default) when exporting with the ‘export-clean’ option. Compare the output of the following two lines: gpg --min-cert-level=1 --export-options export-clean --export $keyID | gpg --list-packets | grep -B1 -A3 'sigclass 0x11$' gpg --min-cert-level=2 --export-options export-clean --export $keyID | gpg --list-packets | grep -B1 -A3 'sigclass 0x11$' If that behavior isn't consistent, that's a bug in gpg. (And if I got the manpage right, the cutoff certification level is only relevant when building the trustdb, hence should be irrelevant when exporting.) I'd be happy to reassign it myself, but I couldn't a find a key for which export-clean works as expected. Would you mind asking the owner of Key2 if they would like their key to be listed in a bug report and/or a unit test? In the mean time, adding ‘min-cert-level 1’ to caff's gnupghome should help. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#737128: gpg exits with a fatal error about missing trustdb despite successfully having imported a key
Control: notfound -1 1.4.16-1.1 Contol: merge -1 735363 This seems to be working now: gpg --export $keyID | gpg --homedir $(mktemp -d --tmpdir gpg.XX) --trust-model=always --import -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg depends on: ii gpgv 1.4.16-1.1 ii libbz2-1.01.0.6-5 ii libc6 2.19-1 ii libreadline6 6.3-6 ii libusb-0.1-4 2:0.1.12-23.3 ii zlib1g1:1.2.8.dfsg-1 Versions of packages gnupg recommends: ii gnupg-curl 1.4.16-1.1 ii libldap-2.4-2 2.4.39-1 Versions of packages gnupg suggests: pn gnupg-doc none ii imagemagick 8:6.7.7.10+dfsg-3 ii libpcsclite1 1.8.11-3 -- no debconf information signature.asc Description: Digital signature
Bug#751266: gnupg2: Fatal error/non-zero exit code returned when --trust-model=always used
Package: gnupg2 Version: 2.0.23-1 Severity: important Dear Maintainer, gnupg2 is also affected by #735363 (and #737128). $ gpg --export $keyID | gpg2 --homedir $(mktemp -d) --trust-model=always --import gpg: keyring `/tmp/tmp.CgvawKyhkU/secring.gpg' created gpg: keyring `/tmp/tmp.CgvawKyhkU/pubring.gpg' created gpg: Fatal: can't open `/tmp/tmp.CgvawKyhkU/trustdb.gpg': No such file or directory $ echo $? 2 (Other operation that modify the trust database if existing, such as key generation or edition, fail in a similar way.) While the issues have been dealt with in gnupg, gnupg2 is still affected. Cheers, -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg2 depends on: ii dpkg 1.17.10 ii gnupg-agent 2.0.23-1 ii install-info 5.2.0.dfsg.1-4 ii libassuan0 2.1.1-1 ii libbz2-1.0 1.0.6-5 ii libc62.19-1 ii libcurl3-gnutls 7.37.0-1+b1 ii libgcrypt11 1.5.3-4 ii libgpg-error01.12-0.2 ii libksba8 1.3.0-3 ii libreadline6 6.3-6 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.39-1 Versions of packages gnupg2 suggests: pn gnupg-doc none pn xloadimage none -- no debconf information signature.asc Description: Digital signature
Bug#751252: caff: doesn't send email found no signed uids
On Wed, 11 Jun 2014 at 17:56:50 +0200, Ilario Gelmetti wrote: I have to retire my statement on Key2: the problem is present also with this key. To verify this I created a new gpg key with an empty pubring and tried to sign with caff that Key2 and it didn't work. With my main key I didn't see the problem because in the past I signed a few userids of that key (with cert-level=3). I see. In fact gpg's manpage says that “signatures that are not usable” are not exported with option ‘export-clean’, so I manually set (in revision 638) the cutoff level to 1 in such cases. -- Guilhem. signature.asc Description: Digital signature
Bug#751394: busybox: please provide a way to disable buffering in STDOUT
Package: busybox
Version: 1:1.22.0-6
Severity: wishlist
Dear Maintainer,
In udebs, it is common to redirect the standard output of a command to
a fifo, and use that to display progress bars in the installer.
trap 'kill $pid' EXIT
/path/to/command $fifo
while read -u 7 n; do
db_progress SET $n
done 7 $fifo
rm -f $fifo
trap - EXIT
However, if the command buffers its standard output, which for instance
is what cryptsetup(8) does, and/or if the standard output needs to be
piped through sed(1) (which also buffers its standard streams), it's
hard to make sense of the progress bar, which suddenly jumps from 0% to
100% while nothing happens in the meantime.
cryptsetup -q --key-file=$keyfile luksFormat $device | \
sed -nr 's/^Generating key \(([0-9]+)% done\)\.$/\1/p' $fifo
It'd be convenient to provide a way to disable buffering in STDOUT, in
the fashion of stdbuf(1) from GNU coreutils [1]. If the full blown
stdbuf(1) is overkill, it might still be desirable to add a strip down
version disabling buffering only, as found in [2]:
:/lib/stdbuf.c
#include stdio.h
__attribute__ ((constructor)) void
QLqxcKVd20zweBii () {
setvbuf (stdout, NULL, _IOLBF, 0);
}
$ gcc -Wall -x c -s /lib/stdbuf.c -fPIC -shared -o /lib/stdbuf.so
:/bin/stdbuf
#!/bin/sh
LD_PRELOAD=/lib/stdbuf.so $@
Then buffering of STDOUT could be disabled as follows:
stdbuf cryptsetup -q --key-file=$keyfile luksFormat $device | \
stdbuf sed -nr 's/^Generating key \(([0-9]+)% done\)\.$/\1/p' $fifo
Thanks!
Cheers,
--
Guilhem.
[1] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/stdbuf.c
[2] https://lists.gnu.org/archive/html/bug-coreutils/2008-11/msg00138.html
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages busybox depends on:
ii libc6 2.19-1
busybox recommends no packages.
busybox suggests no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#751485: pinentry-curses: concurent calls mess up the terminal (locking missing)
Package: pinentry-curses Version: 0.8.3-2 Severity: normal Tags: upstream Dear Maintainer, When two parallel instance gpg(1) prompt the user for a passphrase, there should be a locking mechanism to avoid both pinentry to try to modify the TTY at the same time. The problem is visible in the following example: $ killall -u $(whoami) -HUP gpg-agent $ echo blah | gpg --recipient $keyID --encrypt \ | gpg --use-agent --decrypt | gpg --use-agent --sign /dev/null (Another example is where one decrypts a file and sends the cleartext to a remote machine through SSH, where the SSH key is in fact an OpenPGP subkey with Authentication capability, which is decrypted using a ProxyCommand.) Thanks! Cheers, -- Guilhem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pinentry-curses depends on: ii libc6 2.19-1 ii libncursesw5 5.9+20140118-1 ii libtinfo5 5.9+20140118-1 pinentry-curses recommends no packages. Versions of packages pinentry-curses suggests: pn pinentry-doc none -- no debconf information signature.asc Description: Digital signature
Bug#741213: mutt: pgpring displays an incorrect length for DSA and Elgamal keys
Package: mutt Version: 1.5.22-1 Severity: normal Tags: patch Dear Maintainer, As signing-party's pgpring, Mutt's does not look at the right field as key lengh for DSA and Elgamal keys, which results to an incorrect output similar to that reported in #602284. The attached patch, adapted from Fabrizio Tarizzo's, fixes the issue; see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602284 for details. Cheers, -- Guilhem. -- Package-specific info: Mutt 1.5.22 (2013-10-16) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.13-1-686-pae (i686) ncurses: ncurses 5.9.20140118 (compiled with 5.9) libidn: 1.28 (compiled with 1.28) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-14' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-14) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'i486-linux-gnu' 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. 0001-__misc__am-maintainer-mode.patch 0002-__features__ifdef.patch 0003-__features__xtitles.patch 0004-__features__trash-folder.patch 0005-__features__purge-message.patch 0006-__features__imap_fast_trash.patch 0007-__features__sensible_browser_position.patch 0008-__features-old__patch-1.5.4.vk.pgp_verbose_mime.patch 0009-__features__compressed-folders.patch 0010-__features__compressed-folders.debian.patch 0011-__debian-specific__Muttrc.patch 0012-__debian-specific__Md.etc_mailname_gethostbyname.patch 0013-__debian-specific__use_usr_bin_editor.patch 0014-__debian-specific__correct_docdir_in_man_page.patch 0015-__debian-specific__dont_document_not_present_feature.patch 0016-__debian-specific__document_debian_defaults.patch 0017-__debian-specific__assumed_charset-compat.patch 0018-__debian-specific__467432-write_bcc.patch 0019-__debian-specific__566076-build_doc_adjustments.patch 0020-__misc__define-pgp_getkeys_command.patch 0021-__misc__gpg.rc-paths.patch 0022-__misc__smime.rc.patch 0023-__misc__fix-configure-test-operator.patch
Bug#602284: pgpring displays wrong key length for some key
On Tue, 21 Nov 2010 at 20:51:12 +0100, Franck Joncourt wrote: Is there a proper document which explains to us how the fields are organized in a keyblock according to the algorithm used? I have looked at the gnupg sources, and found a bit of information in build_packet.c, but this is still confused. The description of OpenPGP public-key packets, as GnuPG implements it, can be found in RFC 4880 section 5.5.2 [1]. (I find it easier to read than C code :-P) The meaning of the first 6 octets is identical for all algorithms. The public-key algorithm itself is given by the 6th byte as per RFC 4880 section 9.1. Then follows a number of multiprecision integers (MPI) depending on the algorithm: RSA (algorithm 1 to 3) public keys have 2 MPIs, DSA (algorithm 17) public keys have 4, and Elgamal (algorithm 16 and 20) public keys have 3. Now, what is commonly called length of the key is always the length of the first of said MPIs (public modulus in case of RSA, prime p in case of DSA and Elgamal). So Fabrizio's patch seems to fix the issue. I pushed (a slightly simplified version of) it to trunk (rev 563). By the way, I have found that a pgpring program is also provided by the mutt package (/usr/lib/mutt/pgpring), whose source files are a bit different :( But at a first look, there are enhancements, and the program still displays the wrong key length. Filed as #741213. Cheers, -- Guilhem. [1] https://tools.ietf.org/html/rfc4880#section-5.5.2 signature.asc Description: Digital signature
Bug#703355: signing-party: include gpg-import-imap script
Control: tag -1 moreinfo Hi Nik, mutt is capable of tagging messages matching a given pattern, and of applying an action on all tagged messages, hence your second motivating point is untrue IMHO. That said, I believe your tool can be of interest, and possibly to mutt users as well. I've got a wishlist, though: * It would be great to be able to use a pre-authenticated tunnel to the IMAP server. In my setup for instance, I use ‘/usr/lib/dovecot/imap’ as a tunnel and rely on unix permissions for authentication; the IMAP server is not directly exposed to the network. * It might be preferable to dump the certification signature (and import them all at once using … | gpg --import), since the user can then use the --import-options of her choice. * I think the default selector, on the Subject: header, is too restrictive and not flexible enough. Alternatives to caff such as PIUS or monkeysign may have other subjects, and it would be great to select messages that were manually crafted as well. However calls to GnuPG are expensive, so ideally certification signatures should be detected without false positive. It's probably hard to come up with a list of all MIME Content-Type used to send signatures by email, but after a quick look my own inbox here is what I found already: 1/ Encrypted message (multipart/encrypted) with attachment (application/pgp-keys or text/plain). 2/ Clear or armored message (multipart/mixed) with encrypted, non-armored, attachment (application/octet-stream). 3/ Clear or armored message (multipart/mixed) with encrypted, armored, attachment (application/pgp-encrypted). 4/ Clear message (text/plain) with armored signature in the body (text/plain). 5/ Signed message (multipart/signed) with armored signature in the body (text/plain). (This list is non exhaustive obviously, so please complete/correct it.) I therefore propose the following algorithm to detect emails containing certification signatures: * If the message is not multipart, or if the MIME Content-Type is text/plain or application/pgp-keys: - If the first non-blank line matches /^-+BEGIN PGP PUBLIC KEY BLOCK-+$/, import the data and stop. (Corresponds to an armored public key.) * If the MIME Content-Type is application/octet-stream or application/pgp-keys: - Read the first 8 bytes; if it matches the beginning of an OpenPGP header (see RFC 4880 sections 4.2 and 5.5), import the data and stop. (Corresponds to a non-armored public key.) * If the message is not multipart, or if the MIME Content-Type is text/plain or application/pgp-encrypted: - If the first non-blank line matches /^-+BEGIN PGP MESSAGE-+$/, try to decrypt, and upon success loop with the decrypted content. (Corresponds to armored encrypted message.) * If the MIME Content-Type is application/octet-stream or application/pgp-encrypted: - Read the first byte; if it matches the beginning of an OpenPGP header (see RFC 4880 sections 4.2, 5.1 and 5.3 ), try to decrypt, and upon success loop with the decrypted content. (Corresponds to non-armored encrypted message.) * If the MIME Content-Type is multipart/signed, loop on each part for which the Content-Type is not application/pgp-signature. (Corresponds to a PGP/MIME signed message.) * If the MIME Content-Type is multipart/mixed, loop on each part. (Corresponds to a clear message.) * If the MIME Content-Type is multipart/encrypted, try to decrypt the message, and upon success loop on each part. (Corresponds to a PGP/MIME (sign)encrypted message.) * Otherwise, drop the message or MIME part and stop. That's just a sketch, but I believe it does cover all the situations described above. (And that's *more* than what mutt's ^K binding is able to detect ;-) It's unclear how that would scale in practice though, so it might be good to keep selectors based on headers. (Or perhaps something more flexible, based on the IMAP SEARCH command as defined in RFC 3501 section 6.4.4? :-) Regarding the parsing of OpenPGP packets headers in non-armored byte streams, let x be the first byte. It MUST match the mask 0x80 (i.e., the most significant bit must be set). * For public keys, if $x also matches the mask 0x40, then $x MUST be 0xc6. Otherwise, $x 0xfc MUST be 0x98. If selecting based on the first byte only leads to too many false positive, one might need to parse the full header and read the first byte of the packet, which MUST be 0x03 or 0x04. (see gpg --export $keyID | hexdump -n8 -ve '8/1 %02X\n'.) * For asymmetrically encrypted data, if $x also matches the mask 0x40, then $x MUST be 0xc1. Otherwise, $x 0xfc MUST be 0x84. If selecting
Bug#742046: mysql-server: please add a debconf variable to identify root using the 'auth_socket' plugin
Package: mysql-server Version: 5.5.35+dfsg-2 Severity: normal Dear Maintainer, When installing a MySQL server in a non-interactive environment (for instance using a configuration manager): DEBIAN_FRONTEND=noninteractive apt-get install mysql-server The post-install hook currently creates a root user without a password, making any local user able to connect as root: guilhem@fresti: ~$ mysql -u root mysql […] mysql SELECT user,host,password,plugin FROM user; +--+---+---++ | user | host | password | plugin | +--+---+---++ | root | localhost | | | | root | fresti| | | | root | 127.0.0.1 | | | | root | ::1 | | | | debian-sys-maint | localhost | *0B79AE943CB9D2719FACD42B17D2550398AB | | +--+---+---++ Since as far as I'm concerned I don't have a use-case where a user should connect to MySQL as root unless she already has UNIX root privileges, I would like to use the Socket Peer-Credential Authentication Plugin [1]. Of course I could manually remove all hosts that are not ‘localhost’ and force authentication using said plugin: mysql DROP USER 'root'@'fresti'; mysql DROP USER 'root'@'127.0.0.1'; mysql DROP USER 'root'@'::1'; mysql INSTALL PLUGIN auth_socket SONAME 'auth_socket.so'; mysql UPDATE user SET plugin = 'auth_socket', password = '' WHERE user = 'root' AND host = 'localhost'; mysql FLUSH PRIVILEGES; mysql SELECT user,host,password,plugin FROM user; +--+---+---+-+ | user | host | password | plugin | +--+---+---+-+ | root | localhost | | auth_socket | | debian-sys-maint | localhost | *0B79AE943CB9D2719FACD42B17D2550398AB | | +--+---+---+-+ mysql QUIT; guilhem@fresti: ~$ mysql -u root mysql ERROR 1698 (28000): Access denied for user 'root'@'localhost' However the race condition opens an obvious insecure windows, during which any user can connect as root and (for instance) add another MySQL user and GRANT it ALL PRIVILEGES. IMHO the best way to overcome the issue would be to add a debconf variable to force Socket Peer-Credential Authentication for the root user. (Or perhaps that should be the default when the password is left blank? Or perhaps even the password should be disabled by default, and only activated if explicitly asked at the installation?) Thanks! Cheers, -- Guilhem. [1] https://dev.mysql.com/doc/refman/5.5/en/socket-authentication-plugin.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mysql-server depends on: ii mysql-server-5.5 5.5.35+dfsg-2 mysql-server recommends no packages. mysql-server suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#742056: slapd: please add a debconf variable to disable RootPW and use unix permissions instead
Package: slapd
Version: 2.4.39-1
Severity: wishlist
Dear Maintainer,
When installing slapd in a non-interactive environment (for instance
using a configuration manager):
DEBIAN_FRONTEND=noninteractive apt-get install slapd
Currently a new database ‘olcDatabase={1}hdb,cn=config’ is automatically
created, and a ‘cn=admin,…’ entry of objectClass simpleSecurityObject is added
to the directory, and its DN (resp. userPassword attribute) is used as RootDN
(resp. RootPW) attribute on the database.
root@fresti: ~# slapcat -n0 -s 'olcDatabase={1}hdb,cn=config' | grep ^olcRoot
olcRootDN: cn=admin,dc=guilhem,dc=org
olcRootPW:: e1NTSEF9a3FzRjFJRDdDR3YvZE02bWZOOGFFMWhabGo0NmRwSHY=
root@fresti: ~# slapcat -n1 -s cn=admin,dc=guilhem,dc=org | grep ^userPassword
userPassword:: e1NTSEF9a3FzRjFJRDdDR3YvZE02bWZOOGFFMWhabGo0NmRwSHY=
That password being randomly generated upon installation of a fresh directory,
it's not so useful (unless it is preseeded, which is arguably insecure).
Fortunately cn=config (DB #0) is writable by root, so she can reset the RootDN
(and RootPW) on DB #1 to the value of her choice, but it would be convenient to
have a debconf variable disabling password generation altogether and instead set
olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
so that only the UNIX root have unrestricted access to DB #1 when SASL-binding
to the ldapi:// socket. (That also removes the need to add a olcRootPW
attribute, or a cn=admin,… entry.)
Thanks!
Cheers,
--
Guilhem.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages slapd depends on:
ii adduser 3.113+nmu3
ii coreutils 8.21-1
ii debconf [debconf-2.0] 1.5.52
ii libc6 2.18-4
ii libdb5.35.3.28-3
ii libgcrypt11 1.5.3-3
ii libgnutls26 2.12.23-13
ii libldap-2.4-2 2.4.39-1
ii libltdl72.4.2-1.7
ii libodbc12.3.1-1
ii libperl5.18 5.18.2-2+b1
ii libsasl2-2 2.1.26.dfsg1-9
ii libslp1 1.2.1-9
ii libwrap07.6.q-25
ii lsb-base4.1+Debian12
ii multiarch-support 2.18-4
ii perl [libmime-base64-perl] 5.18.2-2+b1
ii psmisc 22.21-1
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.26.dfsg1-9
Versions of packages slapd suggests:
ii ldap-utils 2.4.39-1
-- debconf information:
slapd/move_old_database: true
slapd/dump_database: when needed
slapd/no_configuration: false
slapd/backend: HDB
slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/upgrade_slapcat_failure:
slapd/purge_database: false
slapd/password_mismatch:
shared/organization: guilhem.org
slapd/domain: guilhem.org
slapd/invalid_config: true
slapd/allow_ldap_v2: false
signature.asc
Description: Digital signature
Bug#759784: debian-maintainers: Please add Guilhem Moulin as a Debian Maintainer
Oh by the way, please note that the email address I use for packaging, namely guil...@guilhem.org, is not that of the primary UID of my OpenPGP key 7420 DF86 BCE1 5A45 8DCE 9976 3927 8DA8 109E 6244. Thanks! -- Guilhem. signature.asc Description: Digital signature
Bug#753671: caff: please support gpg2
gnupg2 2.0.26-3 has been packaged today, and includes a fix for #751266.
Setting $CONFIG{'gpg'} to be 'gpg2' in the .caffrc is working again.
--
Guilhem.
signature.asc
Description: Digital signature
Bug#316131: gpg-key2latex (replacement for gpg-key2ps)
Hi there, FYI, the soon to be 1.1.11 release of signing-party includes a new script ‘gpg-key2latex’, which hopefully will solve the following limitations inherent to the PS format: - Support for Unicode in User ID (xelatex might be required for CJK characters, though). - Support for UAT (Photo ID) and QR codes. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#768503: unblock: signing-party/1.1.10-1+deb8u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package signing-party
Hi there,
I would like to upload the attached changes: a regression bug has been
introduced in signing-party 1.1.10-1, making caff violate RFC 2822 when
sending messages with a non-English locale. This fixes bug #767371.
unblock signing-party/1.1.10-1+deb8u1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.16-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Thanks!
Cheers,
--
Guilhem.
diff -Nru signing-party-1.1.10/caff/caff signing-party-1.1.10/caff/caff
--- signing-party-1.1.10/caff/caff 2014-10-11 23:11:14.0 +0200
+++ signing-party-1.1.10/caff/caff 2014-11-07 22:17:51.0 +0100
@@ -383,7 +383,7 @@
use IO::Select;
use Getopt::Long;
use GnuPG::Interface;
-use POSIX qw{strftime};
+use POSIX qw{strftime setlocale};
my %CONFIG;
my $REVISION = '$Rev: 710 $';
@@ -908,7 +908,7 @@
};
$message_entity-head-add(From, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
- $message_entity-head-add(Date, strftime(%a, %e %b %Y %H:%M:%S %z,
localtime));
+ $message_entity-head-add(Date, strfCtime(%a, %e %b %Y %H:%M:%S
%z, localtime));
$message_entity-head-add(Subject, Your signed PGP key 0x$key_id);
$message_entity-head-add(To, email_to_ascii($address));
$message_entity-head-add(Sender, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
@@ -1175,6 +1175,18 @@
return 0;
}
+##
+# A non-localized version of POSIX::strftime.
+#
+sub strfCtime($@) {
+my $lc_time = setlocale(POSIX::LC_TIME);
+setlocale(POSIX::LC_TIME, 'C');
+my $str = strftime(@_);
+setlocale(POSIX::LC_TIME, $lc_time);
+return $str;
+}
+
+
###
# argument handling
###
diff -Nru signing-party-1.1.10/debian/changelog
signing-party-1.1.10/debian/changelog
--- signing-party-1.1.10/debian/changelog 2014-10-11 23:09:24.0
+0200
+++ signing-party-1.1.10/debian/changelog 2014-11-07 22:17:51.0
+0100
@@ -1,3 +1,13 @@
+signing-party (1.1.10-1+deb8u1) unstable; urgency=medium
+
+ [ Guilhem Moulin ]
+ * caff:
++ Fix RCF 2822 violation: Never localize the Date header, regarless of
+ the LC_ALL, LC_TIME and LANG in use. Regression introduced in r698.
+ (Closes: #767371)
+
+ -- Guilhem Moulin guil...@guilhem.org Fri, 07 Nov 2014 21:35:13 +0100
+
signing-party (1.1.10-1) unstable; urgency=low
* debian.compat:
signature.asc
Description: Digital signature
Bug#768503: unblock: signing-party/1.1.10-1+deb8u1
Control: retitle -1 unblock: signing-party/1.1.10-2
unblock signing-party/1.1.10-2
On Fri, 07 Nov 2014 at 23:26:24 +0100, Niels Thykier wrote:
On 2014-11-07 22:36, Guilhem Moulin wrote:
I would like to upload the attached changes: a regression bug has been
introduced in signing-party 1.1.10-1, making caff violate RFC 2822 when
sending messages with a non-English locale. This fixes bug #767371.
Please do and let us know once it has been accepted in sid.
Grmbl, I should have waited the package being accepted before filing
that unblock request, actually… The package being native I didn't
modifying the source would lead to a REJECT due to conflicting
.orig.tar.gz. Sorry for the mess.
Anyway, signing-party 1.1.10-2 has just been ACCEPTed in sid. Here is
the new debdiff, with version number fixed to 1.1.10-2.
Cheers,
--
Guilhem.
diff -Nru signing-party-1.1.10/debian/changelog
signing-party-1.1.10/debian/changelog
--- signing-party-1.1.10/debian/changelog 2014-10-11 23:09:24.0
+0200
+++ signing-party-1.1.10/debian/changelog 2014-11-07 23:49:54.0
+0100
@@ -1,3 +1,13 @@
+signing-party (1.1.10-2) unstable; urgency=medium
+
+ [ Guilhem Moulin ]
+ * caff:
++ Fix RCF 2822 violation: Never localize the Date header, regarless of
+ the LC_ALL, LC_TIME and LANG in use. Regression introduced in r698.
+ (Closes: #767371)
+
+ -- Guilhem Moulin guil...@guilhem.org Fri, 07 Nov 2014 21:35:13 +0100
+
signing-party (1.1.10-1) unstable; urgency=low
* debian.compat:
diff -Nru signing-party-1.1.10/debian/patches/bug767371.diff
signing-party-1.1.10/debian/patches/bug767371.diff
--- signing-party-1.1.10/debian/patches/bug767371.diff 1970-01-01
01:00:00.0 +0100
+++ signing-party-1.1.10/debian/patches/bug767371.diff 2014-11-07
23:49:54.0 +0100
@@ -0,0 +1,41 @@
+diff --git a/caff/caff b/caff/caff
+index 696c0c1..ae4bffd 100755
+--- a/caff/caff
b/caff/caff
+@@ -383,7 +383,7 @@ use Fcntl;
+ use IO::Select;
+ use Getopt::Long;
+ use GnuPG::Interface;
+-use POSIX qw{strftime};
++use POSIX qw{strftime setlocale};
+
+ my %CONFIG;
+ my $REVISION = '$Rev$';
+@@ -908,7 +908,7 @@ sub create_mail($$$@) {
+ };
+
+ $message_entity-head-add(From, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
+- $message_entity-head-add(Date, strftime(%a, %e %b %Y %H:%M:%S %z,
localtime));
++ $message_entity-head-add(Date, strfCtime(%a, %e %b %Y %H:%M:%S
%z, localtime));
+ $message_entity-head-add(Subject, Your signed PGP key 0x$key_id);
+ $message_entity-head-add(To, email_to_ascii($address));
+ $message_entity-head-add(Sender, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
+@@ -1175,6 +1175,18 @@ sub import_keys_to_sign() {
+ return 0;
+ }
+
++##
++# A non-localized version of POSIX::strftime.
++#
++sub strfCtime($@) {
++my $lc_time = setlocale(POSIX::LC_TIME);
++setlocale(POSIX::LC_TIME, 'C');
++my $str = strftime(@_);
++setlocale(POSIX::LC_TIME, $lc_time);
++return $str;
++}
++
++
+ ###
+ # argument handling
+ ###
signature.asc
Description: Digital signature
Bug#768579: unblock: signing-party/1.1.10-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package signing-party
Hi there,
I would like to upload the attached changes: a regression bug has been
introduced in signing-party 1.1.10-1, making caff violate RFC 2822 when
sending messages with a non-English locale. This fixes bug RC #767371.
(A previous unblock request has been filled — #768503, but the version
to unblock, namely 1.1.10-2, was not fixing RC #767371 bug. My bad,
sorry for that.)
unblock signing-party/1.1.10-3
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.16-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Thanks!
Cheers,
--
Guilhem.
diff -Nru signing-party-1.1.10/debian/changelog
signing-party-1.1.10/debian/changelog
--- signing-party-1.1.10/debian/changelog 2014-10-11 23:09:24.0
+0200
+++ signing-party-1.1.10/debian/changelog 2014-11-08 02:02:16.0
+0100
@@ -1,3 +1,13 @@
+signing-party (1.1.10-3) unstable; urgency=medium
+
+ [ Guilhem Moulin ]
+ * caff:
++ Fix RCF 2822 violation: Never localize the Date header, regarless of
+ the LC_ALL, LC_TIME and LANG in use. Regression introduced in r698.
+ (Closes: #767371)
+
+ -- Guilhem Moulin guil...@guilhem.org Fri, 07 Nov 2014 21:35:13 +0100
+
signing-party (1.1.10-1) unstable; urgency=low
* debian.compat:
diff -Nru signing-party-1.1.10/debian/patches/bug767371.diff
signing-party-1.1.10/debian/patches/bug767371.diff
--- signing-party-1.1.10/debian/patches/bug767371.diff 1970-01-01
01:00:00.0 +0100
+++ signing-party-1.1.10/debian/patches/bug767371.diff 2014-11-08
02:02:16.0 +0100
@@ -0,0 +1,47 @@
+From: Guilhem Moulin guil...@guilhem.org
+Subject: [PATCH] Cherry-pick r721 to fix RC bug #767371.
+Date: Thu Oct 30 16:54:16 2014 +
+
+Fix RCF 2822 violation: Never localize the Date header.
+
+diff --git a/caff/caff b/caff/caff
+index 696c0c1..ae4bffd 100755
+--- a/caff/caff
b/caff/caff
+@@ -383,7 +383,7 @@ use Fcntl;
+ use IO::Select;
+ use Getopt::Long;
+ use GnuPG::Interface;
+-use POSIX qw{strftime};
++use POSIX qw{strftime setlocale};
+
+ my %CONFIG;
+ my $REVISION = '$Rev: 710 $';
+@@ -908,7 +908,7 @@ sub create_mail($$$@) {
+ };
+
+ $message_entity-head-add(From, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
+- $message_entity-head-add(Date, strftime(%a, %e %b %Y %H:%M:%S %z,
localtime));
++ $message_entity-head-add(Date, strfCtime(%a, %e %b %Y %H:%M:%S
%z, localtime));
+ $message_entity-head-add(Subject, Your signed PGP key 0x$key_id);
+ $message_entity-head-add(To, email_to_ascii($address));
+ $message_entity-head-add(Sender, Encode::encode('MIME-Q',
$CONFIG{'owner'}).' '.$CONFIG{'email'}.'');
+@@ -1175,6 +1175,18 @@ sub import_keys_to_sign() {
+ return 0;
+ }
+
++##
++# A non-localized version of POSIX::strftime.
++#
++sub strfCtime($@) {
++my $lc_time = setlocale(POSIX::LC_TIME);
++setlocale(POSIX::LC_TIME, 'C');
++my $str = strftime(@_);
++setlocale(POSIX::LC_TIME, $lc_time);
++return $str;
++}
++
++
+ ###
+ # argument handling
+ ###
diff -Nru signing-party-1.1.10/debian/patches/series
signing-party-1.1.10/debian/patches/series
--- signing-party-1.1.10/debian/patches/series 2014-10-11 23:09:24.0
+0200
+++ signing-party-1.1.10/debian/patches/series 2014-11-08 02:02:16.0
+0100
@@ -1 +1,2 @@
gpgwrap_makefile.diff
+bug767371.diff
signature.asc
Description: Digital signature
Bug#769890: caff: Does not show fingerprint for verification when multiple uids are present
Control: severity -1 wishlist
Hi Matthijs,
If no UID(s) is (are) selected, gpg wants to make sure you really intend
to sign all UIDs. So a workaround is to preselect all UIDs; with gpg2
it's can be done in one go with a single command in the prompt: ‘uid *’
(OTOH if you use the 1.4 branch, as of 1.4.18 you'll have to select each
UID manually.)
So it could be done by starting your gpg2 prompt as follows:
gpg2 --local-user 3798AF15A1565658 \
--homedir=/home/matthijs/.caff/gnupghome \
--secret-keyring /home/matthijs/.gnupg/secring.gpg \
--no-auto-check-trustdb --trust-model=always \
--edit-key 98E0D178DCB90C1945C50DB1ED0DD3368DE40924 \
showphoto 'uid *' sign
I'll think of the possible drawbacks of making it the default (with gpg2
at least). Another possibility would be to have a configuration option
containing all commands at once:
$CONFIG{'gpg-command'} = [ 'showphoto', 'uid *', 'sign', 'save' ];
Suggestions welcome ;-)
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#769954: signing-party: Support homedir
Hej Nelson, On Mon, 17 Nov 2014 at 19:15:58 -0200, Nelson A. de Oliveira wrote: Couldn't gpg-key2* support a homedir option like gpg? In indeed, and so could caff, gpglist, gpgsigs and probably other tools in the signing-party package ;-) But is there really a use case that's not covered already by exporting a suitable GNUPGHOME? Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#771857: signing-party: using gpg2, signing is skipped with 'No secret key'
Control: severity -1 wishlist Control: retitle -1 Please support GnuPG 2.1 Hi Brian, On Tue, 02 Dec 2014 at 17:23:21 -0500, Brian Minton wrote: If I have the gpg config entry set to gpg2 (with or without the path) version 2.1, I get the following message: (I'm assuming you're talking about caff here.) At the very last support for the 2.1 branch of GnuPG will be added when it enters sid, but hopefully before that. (GnuPG 2.1 is only available in experimental right now.) Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#771436: caff: Support e-mail subject customization
Control: tags -1 + pending Hi Nelson, On Sat, 29 Nov 2014 at 13:17:35 -0200, Nelson A. de Oliveira wrote: caff has a hardcoded e-mail subject. It would be good if we could also customize it (in .caffrc) Done in r739: https://anonscm.debian.org/viewvc/pgp-tools?view=revisionrevision=739 There is only one extension defined at the moment: %k, which expands to the long key ID. More can be added if needed, feel free to reopen and/or to file another bug. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#771857: signing-party: using gpg2, signing is skipped with 'No secret key'
On Tue, 02 Dec 2014 at 17:23:21 -0500, Brian Minton wrote:
If I have the gpg config entry set to gpg2 (with or without the path)
version 2.1, I get the following message:
gpg: skipped 0424DC19B678A1A9: No secret key
0424DC19B678A1A9 is my key, the private key of which is usable by gpg2
and gpg.
On second thought, this might be an issue with the 2.0 and 1.4 branches
as well. gpg exits the edit prompt with return value 2 whenever some
secret key doesn't have its public part in the public keyring.
Really sign all user IDs? (y/N) y
gpg: error checking usability status of
gpg: key : secret key without public key - skipped
gpg q
$ echo $?
2
caff uses the default secret keyring (configurable with
$CONFIG{'secret-keyring'}) but has its own public keyring. Right now
only $CONFIG{'keyid'} is imported from the normal public keyring. Is
0424DC19B678A1A9 the key used as $CONFIG{'keyid'} in your .caffrc? If
not, can you try
gpg --export 0424DC19B678A1A9 | gpg --homedir=$HOME/.caff/gnupghome --import
If that fixes the problem, I've got a proper fix ready ;-)
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#771857: 771857
On Tue, 02 Dec 2014 at 19:20:22 -0500, Brian Minton wrote: Update: That did not in fact fix the problem. I had removed the gpg2 line from the config file. When I put it back in, it still gives the message. I just pushed a fix (r741) for the branches 1.4 and 2.0 of GnuPG. The 2.1 branch has a different keystore and will have to wait :-P -- Guilhem. signature.asc Description: Digital signature
Bug#772854: signing-party: QR code: too small quiet zone on large QR code
Control: tags -1 + pending Hi Peter, On Thu, 11 Dec 2014 at 19:28:29 +0100, Peter Lebbing wrote: 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? Oops I have to confess I didn't read the spec :-/ (The margin was removed to properly align the code with the text, I didn't realize I was breaking the standard here.) Fixed in r745. 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). Thanks, adding dh-python to Build-Depends should fix it. Fixed in r743. On Thu, 11 Dec 2014 at 21:42:21 +0100, Peter Lebbing wrote: 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. Thanks for the suggestion! Pushed as well (r746). Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#771857: caff: Please support GnuPG 2.1
This is due to GnuPG 2.1 ignoring --secret-keyring: --secret-keyring file This is an obsolete option and ignored. All secret keys are stored in the private-keys-v1.d directory below the GnuPG home directory. But caff has its own GnuPG home (~/.caff/gnupghome by default), and there is currently no configuration option to specify ‘~/.gnupg/private-keys-v1.d’ as the location for private keys. I'll file a wishlist bug for that. A dirty fix in the meantime is to symlink the directory: rmdir ~/.caff/gnupghome/private-keys-v1.d ln -s ~/.gnupg/private-keys-v1.d ~/.caff/gnupghome -- Guilhem. signature.asc Description: Digital signature
Bug#771857: caff: Please support GnuPG 2.1
Following http://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html
caff's $CONFIG{'secret-keyring'} has been deprecated, and the symlinks
are automatically created when the secret keyrings are not present.
--
Guilhem.
signature.asc
Description: Digital signature
Bug#644472: caff: Support sending mails via MUA (such as mutt)
I'm a bit reluctant to make caff non-interactive by default, and would rather let users specify the MUA and their options themselves, rather than hardcoding a bunch of supported MUAs in caff. My 'mail-cmd' proposal above seems to achieve the same thing (let users interact with their MUA to add personal messages or something). It should also support any MUA that can get body, attachment, subject and recipient from the command line. And it's not hard to implement :-); I can probably hack something up in the next couple of days if people are interested. -- Guilhem. signature.asc Description: Digital signature
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
Hi Ewen, Your report says you have signing-party 1.1.4-1, but your patch seems to be against a more recent version :-P But anyway I agree that the standard output shouldn't be thrown away like that. That said the absence of GPG_TTY in the environment doesn't seem to bother my gpg(1); doesn't the following work for you? gpg --version gpg --trust-model=always --no-auto-check-trustdb --fingerprint --with-colons --list-public-keys --no-tty --batch -- KEYID /dev/null That should be the faulting command; it works here, even after a ‘unset GPG_TTY’. And yes I do use gpg-agent, but I can't see how it can be relevant here as AFAICT caff doesn't choke on private material. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
Control: retitle -1 caff: The absence of GPG_TTY causes silent caff failures in OSX Control: tag -1 + pending On Wed, 21 Jan 2015 at 11:12:44 +1300, Ewen McNeill wrote: - MacPorts (OS X) (gpg 1.4.18): works _without_ sderr redirected, fails with stderr redirected (no output, exit code 1), unless GPG_TTY is set then it works again. Wow that's odd. I'll take the works on Debian, fails on OS X back to the MacPorts ticket (https://trac.macports.org/ticket/46601). But I do think it'd be helpful if caff would either (a) not redirect stderr or (b) ensure that GPG_TTY is set when stderr is being redirected. Since those seem to be the two safe ways to run gpg reliably. I can't remember of a reason to redirect stderr, and right now it doesn't seem like a good idea to me. I'm a bit reluctant to modify the environment though, especially since it's a weird behavior of GnuPG – and OSX specific :-P — IMHO. So all in all I pushed your patch in r760. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#775702: caff: Using gpg-agent without GPG_TTY causes silent caff failures
On Wed, 21 Jan 2015 at 15:52:45 +1300, Ewen McNeill wrote:
if (defined($ENV{MACHTYPE})
$ENV{MACHTYPE} =~ /apple/ ! defined($ENV{'GPG_TTY'})) {
warn warning: Certain gpg actions may fail if GPG_TTY is not set, ,
causing silent caff failures.\n;
}
But maybe there should be some other conditional on it (eg, if it's a gpg
build option that is the real trigger). (FTR: $MACHTYPE =
x86_64-apple-darwin13 on my OS X 10.9 system.)
Yeah, it'd be great to dig that further. So far I only grepped the
GnuPG source for must be set in shell, but it didn't help. I guess
the next step would be to mail gnupg-de...@gnupg.org, at least if the
culprit is not the OSX maintainer (I dunno how things work there;
assuming these macports are not built by upstream).
So all in all I pushed your patch in r760.
Thanks. For future reference, there seems to be at least one other set of
gpg commands that caff uses (after the keys are signed, to figure out what
to send) which also fails without GPG_TTY set, but I didn't debug that one
as thoroughly once I'd guessed that setting GPG_TTY was a viable workaround.
Alright. How about an error then? I mean, caff tends to produce a
somewhat verbose output, and it's easy to overlook warnings (there has
been some complaints about that in the past).
My blog post about caff on OS/X may possibly help someone else running into
the same issue:
http://ewen.mcneill.gen.nz/blog/entry/2015-01-19-keysigning-with-caff/
(and it also has a reasonable guide to Mail::Mailer settings for doing SMTP
Auth to an external mail server.)
Great. The manpage includes some of it already, but TBH I didn't know
SSL_CERT_DIR/SSL_CERT_FILE would affect the server authentication.
--
Guilhem.
signature.asc
Description: Digital signature
Bug#771857: caff: Please support GnuPG 2.1
In fact I changed that (r773) to symlink the agent's socket(s) instead; it's much cleaner as it doesn't spawn multiple agent in ~/.caff/gnupghome and the temporary directories. However caff won't work with gpg = 2.1.2, due to gpg not flushing its standard output before the status prompts during the pruning. This bug has already been fixed upstream, see http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d2a70fd8 -- Guilhem. signature.asc Description: Digital signature
Bug#784982: mysql-server: False positive when checking for insecure root accounts
Package: mysql-server Version: 5.5.42-1 Severity: normal Dear Maintainer, When checking for insecure root accounts, ‘debian-start.inc.sh’ merely lists root accounts with an empty password: SELECT COUNT(*) FROM mysql.user WHERE user='root' and password=''; However, such an account can be perfectly secure if e.g., it is associated with the ‘auth_socket’ plugin [1] (the client would have to connect to Unix socket and use SO_PEERCRED). The query could be amended as follows: SELECT COUNT(*) FROM mysql.user WHERE user='root' and password='' and plugin!='auth_socket'; However some other plugins such as PAM could be considered secure as well. Cheers, -- Guilhem. [0] https://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html [1] https://dev.mysql.com/doc/refman/5.5/en/socket-authentication-plugin.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: Digital signature
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
Package: src:linux Version: 4.0.2-1 Severity: important Dear Maintainer, I have the following — probably not so common — configuration: - libreboot BIOS (a deblobed coreboot) with a GRUB2 payload - root is BTRFS, with rootflags=subvol=@ Since I don't want to flash a new payload onto the BIOS chip at each kernel upgrade, I'm using the following static grub.cfg: linux /@/vmlinuz root=UUID=[…] rootflags=subvol=@ resume=UUID=[…] ro initrd /@/initrd.img This used to work great until 3.16.0. However my system no longer boots since the 4.0.0 upgrade, due to the symlink /initrd.img now having an absolute target: since GRUB doesn't understand BTRFS subvolumes, it needs to be pointed to /@/boot/initrd.img-4.0.0-1-686-pae somehow. Of course the quickfix on my side is to edit the GRUB script to load ‘initrd /@/boot/initrd.img-4.0.0-1-686-pae’ instead, but it would be nice to make /initrd.img's target relative again in the post-install script (/vmlinuz doesn't have this problem by the way). Cheers, -- Guilhem. -- Package-specific info: ** Version: Linux version 4.0.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) ** Command line: BOOT_IMAGE=/@/vmlinuz root=UUID=a17c2310-b308-4dd0-8cef-a7f8ca750081 rootflags=subvol=@ resume=UUID=102accd9-30dd-4081-8a7f-a1310ad9a1ee ro ** Not tainted -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debconf information excluded signature.asc Description: Digital signature
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
On Fri, 15 May 2015 at 13:47:59 +0100, Ben Hutchings wrote: On Fri, 2015-05-15 at 05:24 +0200, Guilhem Moulin wrote: On Fri, 15 May 2015 at 03:57:35 +0100, Ben Hutchings wrote: GRUB knows how to do this properly, so you're just making things difficult for yourself. Since there is always a risk of bricking the board when flashing the BIOS chip, I don't want to add a hook add flash it whenever I upgrade the kernel. [...] Why would you need to flash the whole chip? Isn't the configuration in its own flash partition? Not that I know of. At the moment the format doesn't allow “support multiple CBFSes per firmware image” [0]. My current way of upgrading the grub.cf is to replace the grub.cfg in the ROM, then flash the whole chip [1]: cbfstool libreboot.rom remove -n grub.cfg cbfstool libreboot.rom add -t raw -n grub.cfg -f grub.cfg flashrom -p internal -w libreboot.rom And using flashrom on the go makes me sweaty ;-) As the coreboot wiki says: “Disadvantages: more risky if you have no way to recover ”. -- Guilhem. [0] http://www.coreboot.org/CBFS#FMAP [1] http://www.coreboot.org/GRUB2#combining_with_coreboot signature.asc Description: Digital signature
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
On Fri, 15 May 2015 at 03:57:35 +0100, Ben Hutchings wrote: GRUB knows how to do this properly, so you're just making things difficult for yourself. Since there is always a risk of bricking the board when flashing the BIOS chip, I don't want to add a hook add flash it whenever I upgrade the kernel. And in case you meant I could make GRUB reads its config file on disk, this unfortunately doesn't apply here since it's fully encrypted (including /boot; decryption takes place in GRUB). -- Guilhem. signature.asc Description: Digital signature
Bug#782696: dput: Please give a way to specify the path to the gpg(1) binary
Package: dput Version: 0.9.6.4 Severity: normal Dear Maintainer, dput uses a hardcoded ‘/usr/bin/gpg’ when checking signatures. This no longer works if the user uses GnuPG 2.1 (currently available in experimental) has migrated her keyring to the keybox format, since this format is not readable by the 1.4 and 2.0 branches. It would be great to have a way to point dput to gpg2 instead. dcut delegates the signing operation to debsign which uses the DEBSIGN_PROGRAM from ~/.devscripts; maybe dput should use that as well? Thanks, -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package dropbear
* Package name: dropbear
Version : 2015.67-1.1
Upstream Author : Matt Johnston m...@ucc.asn.au
* URL : http://matt.ucc.asn.au/dropbear/
* License : MIT
Section : net
It builds those binary packages:
dropbear - transitional dummy package for dropbear-{run,initramfs}
dropbear-bin - lightweight SSH2 server and client - command line tools
dropbear-initramfs - lightweight SSH2 server and client - initramfs
integration
dropbear-run - lightweight SSH2 server and client - startup scripts
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/dropbear
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc
More information about dropbear can be obtained from
http://matt.ucc.asn.au/dropbear/ .
The maintainer told me to go ahead a proceed with the NMU [0].
Changes since the last upload:
* Non-maintainer upload.
[ Matt Johnston ]
* New upstream release. (Closes: #775222.)
[ Guilhem Moulin ]
* debian/source/format: 3.0 (quilt)
* debian/compat: 9
* debian/control: bump Standards-Version to 3.9.6 (no changes necessary).
* debian/copyright: add machine-readable file.
* Split up package in dropbear-bin (binaries), dropbear-run (init scripts)
and dropbear-initramfs (initramfs integration). 'dropbear' is now a
transitional dummy package depending on on dropbear-run and
dropbear-initramfs. (Closes: #692932.)
* Refactorize the package using dh_* tools, including dh_autoreconf.
(Closes: #689618, #777324.)
* dropbear-run:
+ Add a status option to the /etc/init.d script.
+ Pass key files with -r not -d in /etc/init.d script. (Closes: #761143.)
+ Post-installation script: Generate missing ECDSA in addition to RSA and
DSS host keys. (Closes: #776976.)
* dropbear-initramfs:
+ Don't mark /usr/share/initramfs-tools/conf-hooks.d/dropbear as a
configuration file, since it violates the Debian Policy Manual section
10.7.2. (Regression from 2014.64-1.)
+ Delete debian/initramfs/premount-devpts, since /dev/pts in mounted by
init since initramfs-tools 0.94. (Closes: #632656.)
+ Auto-generate host keys in the postinstall script, not when runing
update-initramfs. Pass the '-R' option (via $PKGOPTION_dropbear_OPTION)
for the old behavior. Also, print fingerprint and ASCII art for
generated keys (if ssh-keygen is available).
+ Revert ad2fb1c and remove warning about changing host key. Users
shouldn't be encouraged to use the same keys in the encrypted partition
and in the initramfs. The proper fix is to use an alternative port or
UserKnownHostFile.
+ Set ~root to `mktemp -d $DESTDIR/root-XX` to avoid collisions with
$rootmnt. (Closes: #558115.)
+ Exit gracefully if $IP is 'none' or 'off'. (Closes: #692932.)
+ Start dropbear with flag -s to explicitly disable password logins.
+ Terminate all children before killing dropbear, to avoid stalled SSH
connections. (Closes: #735203.)
+ Run configure_networking in the foreground. (Closes: #584780, #626181,
#739519.)
+ Bring down interfaces and flush network configuration before existing
the ramdisk, to avoid misconfigured network in the regular kernel.
(Closes: #715048, #720987, #720988.)
+ Add a script '/bin/unlock' to the initramfs to make remote unlocking
easier and possibly as a forced-command restrictions in authorized_keys.
Cheers,
--
Guilhem.
[0] https://lists.debian.org/debian-devel/2015/06/msg00285.html
signature.asc
Description: Digital signature
Bug#715048: Patch to add support for an indpendendent initramfs networking config
On Mon, 01 Jun 2015 at 07:53:28 -0500, Karl O. Pinc wrote:
On Mon, 1 Jun 2015 13:46:26 +0200 Guilhem Moulin guil...@guilhem.org wrote:
On Sun, 31 May 2015 at 21:30:25 -0500, Karl O. Pinc wrote:
On Mon, 1 Jun 2015 03:30:36 +0200 Guilhem Moulin guil...@guilhem.org
wrote:
I'd rather not having to manually edit these scripts, and follow your
original patch to add a new configuration variable DROPBEAR_IFDOWN.
(Perhaps unset by default for NFS mounts, and set to “all” otherwise.)
You're right, a configuration variable is the way to go.
My thoughts are in order to support nfs mounts it should not bring
down and flush everything, but instead work only on specific addresses
of specific interfaces. This means using ip addr flush dev ethX to
address.
Why that? Dropbear and nfs both use initramfs-tools's
‘configure_networking’ function, so AFAICT it doesn't make any
difference to the network configuration if dropbear and nfs are used
alone or together.
Since BOOT=nfs doesn't touch the network configuration after mounting
the root fs, I'd say we should do the same here, and only bring the
interfaces down for BOOT=local. (The proper place for that is in a
local-bottom script as you initially proposed, and not init-bottom as I
suggested earlier.)
I've been thinking more deeply. To answer
my own question, ipconfig is required to support
the various configuration protocols, like dhcp.
But it does not need to support bringing the
interface down, the klibc patch is unnecessary.
Oh yes, indeed.
Regards using ip to bring down and de-configure the
interface: I think the scripts need to first bring the
interface down then flush them. After poking around
the flush code I see that it first empties the buffers
and then does something to de-configure the interface
(I think). So if you don't bring the interface
down first you'll have a race condition where you
empty the buffers but more arrives before the
configuration is removed. (Maybe.)
Fair enough. The following snippet (from a local-bottom script) seems
to work fine here:
[ ${DROPBEAR_IFDOWN:-all} != all ] || DROPBEAR_IFDOWN=$(ls /sys/class/net)
for IFACE in $DROPBEAR_IFDOWN; do
ip linkset dev $IFACE down
ip address flush dev $IFACE
ip route flush dev $IFACE
done
--
Guilhem.
signature.asc
Description: Digital signature
Bug#584780: dropbear script for initramfs-tools breaks DNS (and any fixed-address) server
‘configure_networking’ was moved to the background in commit a3b7a7d6. According to debian/changelog it was meant to be a fix for #514213 and #524728. I'd say the proper fix would be to follow Simon McVittie's suggestion [0] and split the dropbear package as follows: * dropbear-bin (executable, private libraries if any) * dropbear (init integration goo) Depends: dropbear-bin * dropbear-initramfs Depends: dropbear-bin, Suggests: dropbear That way dropbear users that are not using the cryptroot remote unlocking feature would simply not install dropbear-initramfs. -- Guilhem. [0] https://lists.debian.org/debian-devel/2015/05/msg00685.html signature.asc Description: Digital signature
Bug#558115: dropbear: uses root fs mountpoint for root's home
Control: tags -1 patch
Here is a patch setting the homedir to $(mktemp -d /root-XX).
--
Guilhem.
--- /home/guilhem/initramfs-tools/hooks/dropbear 2014-08-12 00:15:40.0 +0200
+++ /usr/share/initramfs-tools/hooks/dropbear 2015-06-16 23:11:27.060710678 +0200
@@ -31,8 +31,9 @@
for so in $(find ${LIBC_DIR} -name 'libnss_compat*'); do
copy_exec ${so}
done
+ home=$(mktemp -d $DESTDIR/root-XX)
echo 'passwd: compat' ${DESTDIR}/etc/nsswitch.conf
- echo root:x:0:0:root:/root:/bin/sh ${DESTDIR}/etc/passwd
+ echo root:x:0:0:root:${home#$DESTDIR}:/bin/sh ${DESTDIR}/etc/passwd
for keytype in dss rsa; do
if [ ! -f /etc/initramfs-tools/etc/dropbear/dropbear_${keytype}_host_key ]; then
mkdir -p /etc/initramfs-tools/etc/dropbear
@@ -53,8 +54,8 @@
fi
cat /etc/initramfs-tools/root/.ssh/id_rsa.pub /etc/initramfs-tools/root/.ssh/authorized_keys
fi
- mkdir -p ${DESTDIR}/root/.ssh
- cp /etc/initramfs-tools/root/.ssh/authorized_keys ${DESTDIR}/root/.ssh/
+ mkdir -p $home/.ssh
+ cp /etc/initramfs-tools/root/.ssh/authorized_keys $home/.ssh/
fi
fi
signature.asc
Description: Digital signature
Bug#692932: dropbear: no support for a different initramfs network config from that of the normal system
On Fri, 29 May 2015 at 19:47:43 +0200, Guilhem Moulin wrote:
I believe the issue it that the init-premount script sets $IPOPTS while
‘configure_networking’ uses $IP to pick and configure interfaces.
Forget about that. IP is assigned properly by the ‘init’ script, and
IPOPTS isn't used anywhere. So the whole for loop could be removed, and
replaced by a test on $IP.
That said I think the proper way to use dropbear without the cryptroot
remote unlocking feature would be to follow Simon McVittie's suggestion
[0] and split the dropbear package as follows:
* dropbear-bin (executable, private libraries if any)
* dropbear (init integration goo) Depends: dropbear-bin
* dropbear-initramfs Depends: dropbear-bin, Suggests: dropbear
--
Guilhem.
[0] https://lists.debian.org/debian-devel/2015/05/msg00685.html
--- a/usr/share/initramfs-tools/scripts/init-premount/dropbear
+++ b/usr/share/initramfs-tools/scripts/init-premount/dropbear
@@ -13,22 +13,14 @@
;;
esac
-. /scripts/functions
+[ $IP != off -a $IP != none -a -x /sbin/dropbear ] || exit 0
-[ -x /sbin/dropbear ] || exit 0
+. /scripts/functions
log_begin_msg Starting dropbear
. /conf/initramfs.conf
-for x in $(cat /proc/cmdline); do
- case $x in
- ip=*)
- IPOPTS=${x#ip=}
- ;;
- esac
-done
-
configure_networking
mkdir -p /var/run
signature.asc
Description: Digital signature
Bug#632656: dropbear: duplicate mount /dev/pts in initramfs
In fact /dev/pts is mounted in the ‘init’ initramfs script since commit 261811b5 [0], so we could simply remove ‘scripts/init-premount/devpts’. -- Guilhem. [0] https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/init?id=261811b5d0524c7fe579bf4ca22915c2dc4b636f signature.asc Description: Digital signature
Bug#735203: dropbear does not exit properly in initrd
Control: tags -1 patch Control: retitle -1 Stalled SSH connections after existing initrd due to remaining dropbear children processes To terminate all existing SSH sessions, it's somewhat cleaner to kill all children before exiting the server. Cheers, -- Guilhem. --- dropbear/dropbear 2015-06-01 03:27:45.946440539 +0200 +++ /tmp/dropbear 2015-06-16 01:21:55.167304668 +0200 @@ -19,5 +19,6 @@ log_begin_msg Stopping dropbear -kill `cat /var/run/dropbear.pid` - +pid=$(cat /var/run/dropbear.pid) +ps -eo ppid,pid | sed -nr s/^\s*$pid\s+([0-9]+)\s*$/\1/p | xargs -r kill +kill $pid signature.asc Description: Digital signature
Bug#715048: Patch to add support for an indpendendent initramfs networking config
On Fri, 29 May 2015 at 23:35:26 -0500, Karl O. Pinc wrote: Or maybe adding a flush after the ipconfig brings the interface down. Hopefully this would remove the old boot-temporary ip netmask, routes, etc. and leave the interface clean and ready to get it's normal configuration. Unfortunately I just don't have time right now to try this. Any help would be appreciated. My test was probably not exhaustive, but added the following two lines to a init-bottom script did the trick for me: ip addr flush dev eth0 ip link set dev eth0 down I tried to boot with kernel parameter ‘ip=192.168.1.200:eth0:off’. Without the init-bottom script the normal network configuration seems to be ignored (it keeps IP 192.168.1.200 instead), while with the script eth0 is configured properly (following the /etc/network/interfaces). I'll see if the linux-initramfs-tool would be willing to accept an ‘unconfigure_networking’ function using ip(1). -- Guilhem. signature.asc Description: Digital signature
Bug#715048: Patch to add support for an indpendendent initramfs networking config
On Sun, 31 May 2015 at 21:30:25 -0500, Karl O. Pinc wrote: On Mon, 1 Jun 2015 03:30:36 +0200 Guilhem Moulin guil...@guilhem.org wrote: I'll see if the linux-initramfs-tool would be willing to accept an ‘unconfigure_networking’ function using ip(1). I haven't looked at all the pieces in a long time. The idea of a function is appealing, but no matter what the sysadm is going to have to be involved in bringing the interface down and de-configuring it (per https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;bug=715487;filename=README.Debian.downnet.patch , right? Possibly a little extra editing on the part of a sysadm in this corner case is worth not having a function. I'd rather not having to manually edit these scripts, and follow your original patch to add a new configuration variable DROPBEAR_IFDOWN. (Perhaps unset by default for NFS mounts, and set to “all” otherwise.) But all this raises a question in my mind. If ip is available then why does ipconfig exist at all and why is it used? Why would it even be necessary to patch klibc/ipconfig? /sbin/ip is provided by busybox, which is not required. However it is for remote rootfs unlocking, since a shell is needed to type in the command or execute the SSH_COMMAND. Patching ipconfig would only be useful in those environments where ip is not available, and in those environments the ip flush functionality would need to be built into ipconfig. In this case the right thing to do is not to add a function to linux-intramfs-tool but to dig around in the ip code and port the flush part back into ipconfig. With luck this won't be that hard now that we know where to look. (I think the down part is already done.) It's true that the linux-initramfs-tool maintainers might be reluctant to use ip in ‘unconfigure_networking’ while ‘configure_networking’ uses ipconfig. And using only ip is probably not acceptable since it's not guaranteed to be present. However I doubt I have the skills to patch klibc :-/ I'd say using ip in dropbear's init-bottom script is fine in the meantime. -- Guilhem. signature.asc Description: Digital signature
Bug#632656: dropbear: duplicate mount /dev/pts in initramfs
An arguably simpler alternative to copying mountpoint(1) is to grep through /proc/mounts. -- Guilhem. signature.asc Description: Digital signature
Bug#632656: dropbear: duplicate mount /dev/pts in initramfs
On Fri, 29 May 2015 at 19:18:04 +0200, Guilhem Moulin wrote: An arguably simpler alternative to copying mountpoint(1) is to grep through /proc/mounts. Forgot the patch, sorry. -- Guilhem. --- a/usr/share/initramfs-tools/scripts/init-premount/devpts +++ b/usr/share/initramfs-tools/scripts/init-premount/devpts @@ -13,15 +13,13 @@ ;; esac -. /scripts/functions - -grep -E [[:space:]]+devpts$ /proc/filesystems /dev/null 21 || exit 0 +grep -qE '\sdevpts$' /proc/filesystems || exit 0 # If /dev/pts is already mounted, don't re-mount it. -mountpoint -q /dev/pts || exit 0 +! grep -qE '^devpts\s+/dev/pts\s+devpts\s' /proc/mounts || exit 0 +. /scripts/functions log_begin_msg Mounting devpts mkdir -p /dev/pts mount -t devpts none /dev/pts - signature.asc Description: Digital signature
Bug#692932: dropbear: no support for a different initramfs network config from that of the normal system
tags -1 patch
thanks
I believe the issue it that the init-premount script sets $IPOPTS while
‘configure_networking’ uses $IP to pick and configure interfaces.
--
Guilhem.
--- a/usr/share/initramfs-tools/scripts/init-premount/dropbear
+++ b/usr/share/initramfs-tools/scripts/init-premount/dropbear
@@ -24,7 +24,7 @@
for x in $(cat /proc/cmdline); do
case $x in
ip=*)
- IPOPTS=${x#ip=}
+ IP=${x#ip=}
;;
esac
done
signature.asc
Description: Digital signature
Bug#715048: Patch to add support for an indpendendent initramfs networking config
Hi, The problem is that, while klibc can bring up and down network interfaces, the interface configuration does not go away. What doesn't go away exactly? (What do you mean by “interface configuration”?) I wonder if ip(8) could help, by the way. It's included in the initrd, can flush routes (‘ip addr flush dev $DEVICE’) and bring down interfaces (‘ip link set dev $DEVICE down’). -- Guilhem. signature.asc Description: Digital signature
Bug#786415: /usr/bin/caff: missing perl module PavamVal.pm
The MIME::Field::ParamVal module is provided by libmime-tools-perl, on which caff depends. $ dpkg -L libmime-tools-perl | grep ParamVal.pm /usr/share/perl5/MIME/Field/ParamVal.pm $ dpkg -l | grep libmime-tools-perl ii libmime-tools-perl 5.505-1 all Perl5 modules for MIME-compliant messages Could it be a partial installation of your libmime-tools-perl? Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Helmut, On Fri, 31 Jul 2015 at 07:46:26 +0200, Helmut Grohne wrote: That was quick. Let me answer some of your comments already. I intend to take another stab at the upload when I find more time, but that shall not prevent other interested sponsors from uploading it earlier. Possibly Gerrit replied by then. I still have a hope to make it to Debconf (I'm currently on the waiting list :-/). Would be great to make it happen there! FYI upstream made a new release today. That includes a fix to the two issues you reported in #27; my own patches included in patches/series have been applied as well. http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2015q3/001777.html However, this time I didn't pull in the changes (although Debian is now 3 releases behind…) On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote: Alright, this one is new to me. I'm not sure how blindly I can follow https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’. So checked the package source for openssh and found that openssh-server uses Multi-Arch:foreign, but openssh-sftp-server, which ships ‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what to in my case. It is actually much easier than that. Since dropbear does not ship any libraries or similar, the only Multi-Arch tag that makes sense is foreign. So this is mostly a matter of asking: Does a package expose its architecture via one of its public interfaces? If the answer is no, then foreign is appropriate. […] I didn't spot any reason for not marking all of the dropbear packages M-A:foreign, but this probably warrants a closer look. Thanks for the explanation. Yes, ‘Multi-Arch: foreign’ is the right tag in that case. I have updated my debian/control, but I'll wait for a second round of feedback before uploading the package to mentors. -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi there,
On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
In general, I'd find sponsoring this NMU much easier if the package
split and the fixing of those many bugs could happen in separate
uploads. Each part is complex and the fallout is hard to estimate. I
understand that such a separation would mean more work for you. Do you
think that doing this in two steps is worth the added effort?
Alright, would it help moving forward if I were doing that? Reverting
to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
once 2014.65-1 has entered testing. It'd be quite sad to upload known
bugs in a package containing multiple lintian warnings and errors [0],
but if someone is willing to review and upload the package, but only
with the split of dropbear-{bin,run,initramfs} and without the many
extra bug fixes, then I'm ready to clean, test and release [1].
Cheers,
--
Guilhem.
[0] https://lintian.debian.org/full/p...@smarden.org.html#dropbear_2014.65-1
[1]
https://gitweb.guilhem.org/dropbear?p=dropbear;a=commit;h=64ea640134b67e68daad2096d54afc91b0722895
signature.asc
Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Gianfranco,
On Thu, 20 Aug 2015 at 07:23:55 +, Gianfranco Costamagna wrote:
I didn't follow the thread, and seems that other DDs are already caring of
this one, so I would just put my .02$ (and let me know if you need a review
or help).
Thanks! So far only Helmut has given feedback and offered to have
another look when time allows. I'll ping you if there is no follow-up
by the end of the month or so. (That said I wouldn't mind more eyeballs
looking at the package either ;-)
2) what about updating to the latest version and upload on experimental?
I don't see all this need to go for unstable, I might even sponsor an
experimental upload
because if Gerrit is not satisfied he can continue and upload his version to
unstable,
and experimental will disappear automagically.
Isn't this one the experimental suite pourpose?
We are still in the Stretch early stage, we might delay unstable until other
folks tested it.
If by “update to the latest version” you meant my dropbear-{bin,run,initramfs}
packages,
you'll find them there:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-0.1.dsc
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#796664: signing-party: gpglist does not show all valid identities
Control: tags -1 pending Hi Tomasz, On Sun, 23 Aug 2015 at 12:47:01 +0200, Tomasz Buchert wrote: my gpg key is paticular: it has an uid that has been revoked and then subsequently recreated. As a result, it does not show up in the output of gpglist. I've created a patch that fixes that. It slightly changes the output of gpglist to show the status of each identity. I'd rather avoid that if possible. Your UID doesn't show up because gpglist(1) currently prunes revoked UIDs, while it should keep those with a subsequent selfsig. I pushed a simpler fix in r815. I attach another patch as well, that adds an option (--show-revoked) that shows all identities. Thanks, pushed a slightly modified version of your patch in r816. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#793917: dropbear FTCBFS: runs wrong arch strip
Hi Helmut, On Tue, 28 Jul 2015 at 23:01:57 +0200, Helmut Grohne wrote: dropbear has two problems concerning cross compilation: * It runs a build arch strip which cannot handle the crossed binaries. Thus the build fails (see attached log). * It does not run dpkg-shlibdeps, thus Depends are wrong. There is an ongoing effort to refactor and split the dropbear package in order to isolate the binary, service files and initramfs parts. https://tracker.debian.org/pkg/dropbear https://lists.debian.org/debian-devel/2015/06/msg00285.html https://mentors.debian.net/package/dropbear The resulting packages (not in the NEW queue yet, I'm waiting for a sponsor) are built using dh_strip and dh_shlibdeps hence should the first item while making the Depends line meaningful. dget -x http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Helmut,
On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
Thanks for your work on dropbear. Much appreciated.
And thanks for the extensive feedback! I know it's quite a heavy
changelog, so I didn't really expect anyone other than Gerrit perhaps to
check it out that closely.
On Sat, Jul 11, 2015 at 03:20:52PM +0200, Guilhem Moulin wrote:
Note that while the current maintainer (Gerrit, CC'ed) told me to go
ahead and proceed with a NMU, they are not able to sponsor me at the
moment. Furthermore I'm currently a DM and would be open to
co-maintenance once time is ripe.
My reading of Gerrit's mail is a bit more limited. He wrote to d-devel:
| Unfortunately I cannot support you, but don't hesitate to NMU the
| dropbear package to be able to proceed.
May be this is hair-splitting, but I'd read this as NMUing specifically
for the purpose of splitting out the initramfs stuff (and then moving it
to a different source package). I'd not assume that doing a new upstream
release is covered by the above. Maybe Gerrit can clarify that or we can
go via a delayed queue.
Yeah true, I might have taken too much liberty here. I noticed upstream
was already two releases ahead so I wildly pulled in the new tarball :-/
(plus it fixed #775222 ;-) Then I couldn't split the package without
doing major refactoring (which thanks to debhelper automatically solved
#689618, #692932, #777324, #793006, #793917). And later I guess I got
carried away with enthusiasm on the way and decided to try to fix the
remaining bugs (some of them were quite old, and most fixes were rather
easy; at least the one relevant to the initramfs feature, which didn't
seem to be maintained anymore, and which bothered me personally since I
use this feature myself) :-P
Despite me having lots of comments, your changes are actually of high
quality. Don't get scared! Some comments are picky/matter of taste. Feel
free to disagree.
No worries. Constructive criticism never hurts anyway ;-)
Since you bump the upstream release your NMU version should be -0.1
instead of -1.1.
Thanks, fixed.
I note that the new tilde expansion functionality in the upstream
release is a bit strange. If my own home is /home/helmut, it will
expand ~/foo to /home/helmut//foo (note the double slash). Worse, it
will expand expand ~otheruser/foo to /home/helmut/otheruser/foo,
which does not match the general expectation of tilde expansion.
Well spotted. I guess one ought to file a bug.
Gerrit asked for the binaries to be located in dropbear, but you place
them in dropbear-bin. Maybe Gerrit can also ack this? (It was stated
as a preference.)
In fact in a later mail in the d-d thread Gerrit agreed to make
“dropbear” a transitional package and place binaries to “dropbear-bin”,
as suggested to me by Adam Borowski:
https://lists.debian.org/debian-devel/2015/06/msg00290.html
Since dropbear-initramfs relies on initramfs-tools 0.94 features, the
dependency should be versioned.
Thanks, fixed. (Didn't think it mattered since even oldoldstable has
said feature.)
If you disable password logins by default, please mention in a NEWS
entry!
It was never enabled in the initramfs (disabling it without notice would
have been foolish otherwise, indeed). The change I made (initramfs-only
only) is to no longer make the server *advertise* it, so that clients
won't prompt for a password and try to send it to the server (which is
bound to reject it anyway). Sorry for the confusion.
Would it make sense to install the NEWS file to the transitional package
only? (i.e. mv debian/NEWS debian/dropbear.NEWS)
Yes it would! Fixed, thanks for the suggestion.
It might be safer in the future if dropbear-{initramfs,run} use a (=
${binary:Version}) dependency on dropbear-bin. Will you remember to bump
such a dependency when dropbear-run starts to use a new option? (But
--link-doc incurs this dependency anyway.)
You mean if upstream starts deprecate options used in
dropbear-{initramfs,run}? Which by the way seems to happen right now
with ‘-d’ with is now an alias for ‘-r’ but has been removed from the
manpage, see #761143. (And now I realize I could have written a note
regarding s/-d/-r/ in the NEWS regarding that change :-/)
Yeah that makes sense, I tightened the dependency by specifying the
${binary:Version}.
Please consider whether Multi-Arch:foreign markings are appropriate for
some packages.
Alright, this one is new to me. I'm not sure how blindly I can follow
https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
So checked the package source for openssh and found that openssh-server
uses Multi-Arch:foreign, but openssh-sftp-server, which ships
‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what
to in my case.
Why are dropbear-{initramfs,run} marked as Architecture:any? Do they
contain any architecture specific
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Vincent, Gerrit, On Tue, 14 Jul 2015 at 18:42:53 -0700, Vincent Cheng wrote: NMUs are intended to be minimally intrusive and be targeted to fix specific bugs (and usually RC/important ones); that means that in general, you should avoid things like new upstream releases and extensive packaging changes, and your proposed debdiff should be as small as possible. Yes I know: I intended to split the initramfs stuff, but I couldn't make multiple binary packages into the same source package without major refactoring. Your changes are more in scope of a package adoption than a NMU. I'd be open for adoption of dropbear-initramfs indeed, but it's best to keep the same source package for the three dropbear-*, hence my offer to co-maintenance instead ;-) While I don't want to discourage you from doing extensive work to improve dropbear, you'll likely find it difficult to find a DD other than the maintainer who's willing to sponsor this as a NMU. Fair enough, I'll wait then. Thanks for you answer anyway :-) -- Guilhem. signature.asc Description: Digital signature
Bug#793006: dropbear: please make build reproducible
Hi, On Mon, 20 Jul 2015 at 13:55:35 +0200, Maria Valentina Marin wrote: While working on the “reproducible builds” effort [1], we have noticed that dropbear could not be built reproducibly. There is an ongoing effort to refactor and split the dropbear package in order to isolate the binary, service files and initramfs parts. https://tracker.debian.org/pkg/dropbear https://lists.debian.org/debian-devel/2015/06/msg00285.html The resulting packages (not in the NEW queue yet) should be reproducible already. dget -x http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc Cheers, -- Guilhem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#805327: irssi-plugin-otr: Can't configure the statusbar templates with `/format OTR stb_*`
Package: irssi-plugin-otr
Version: 1.0.0-1+b2
Severity: normal
Dear Maintainer,
‘src/otr-formats.c’ defines a couple of irssi templates to be configured
with ‘/format otr ’. The list of templates and their current
values is listed by the ‘/format otr’ command:
[Statusbar]
stb_plaintext = {sb plaintext}
stb_finished = {sb %yfinished%n}
stb_unknown = {sb {hilight state unknown (BUG!)}}
stb_untrusted = {sb %GOTR%n (%runverified%n)}
stb_trust = {sb %GOTR%n}
I'm able to change these value using
/format otr stb_trust {sb %2OTR%n}
However, possibly due to a compiler optimization in irssi-plugin-otr,
this has no impact on the actual template used in the statusbar.
Cheers,
--
Guilhem.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages irssi-plugin-otr depends on:
ii irssi0.8.17-1+b1
ii libc62.19-22
ii libgcrypt20 1.6.4-3
ii libotr5 4.1.0-2
irssi-plugin-otr recommends no packages.
irssi-plugin-otr suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#803993: RFS: netmask/2.4.3-1 - helps determine network masks
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "netmask" * Package name: netmask Version : 2.4.3-1 Upstream Author : Robert Stone <ta...@trap.mtview.ca.us> * URL : https://github.com/talby-/netmask * License : GPL-2+ Section : net It builds those binary packages: netmask - helps determine network masks To access further information about this package, please visit the following URL: http://mentors.debian.net/package/netmask Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.3-1.dsc Changes since the last upload: [ Robert Stone ] * New upstream release. (Closes: #802884.) [ Guilhem Moulin ] * debian/patches: + Make the build reproducible: setting --version twice no longer prints the build timestamp. * debian/control: + Change 'Vcs-Git' and 'Vcs-Browser' fields to use collab-maint. + Set 'Multi-Arch: foreign'. * debian/patches: + Remove 'Add foreign to AM_INIT_AUTOMAKE macro' patch, applied upstream. * Fix debian/watch file. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#801973: error 255 on package configuration
Hi, On Fri, 16 Oct 2015 at 16:01:21 +0200, e-mmanuel wrote: > During upgrade of roundcube (from 1.1.2+dfsg.1-4 to 1.1.2+dfsg.1-5), > aptitude reports errors and upgrade stops. Hmm odd. The 1.1.2+dfsg.1-4 → 1.1.2+dfsg.1-5 upgrade works just file in a clean(+dialog) sid chroot: ~# echo 'deb http://snapshot.debian.org/archive/debian/20150911T101115Z/ unstable main' >/etc/apt/sources.list ~# apt -o Acquire::Check-Valid-Until=false update ~# apt install dialog ~# apt install --install-recommends roundcube roundcube-sqlite3 ~# dpkg -l | sed -nr 's/^(ii\s+roundcube\S*\s+\S+).*/\1/p' ii roundcube 1.1.2+dfsg.1-4 ii roundcube-core1.1.2+dfsg.1-4 ii roundcube-sqlite3 1.1.2+dfsg.1-4 ~# echo 'deb http://ftp.debian.org/debian unstable main' >/etc/apt/sources.list ~# apt update ~# apt upgrade; echo $? […] 0 ~# dpkg -l | sed -nr 's/^(ii\s+roundcube\S*\s+\S+).*/\1/p' ii roundcube 1.1.2+dfsg.1-5 ii roundcube-core1.1.2+dfsg.1-5 ii roundcube-sqlite3 1.1.2+dfsg.1-5 -- Guilhem. signature.asc Description: PGP signature
