Re: application/pgp-signature is unsupported

[David Champion]

* On 15 Mar 2011, Joseph wrote: 
> The addition in mailcap I just added in, but it makes no difference.
> I know before it used to ask me if I want to view the signature but some how 
> it doesn't any more.

What is the value of $pgp_verify_sig?  What you describe sounds like
it used to be ask-yes (or ask-no) and now it's just no.

-- 
David Champion • d...@uchicago.edu • IT Services • University of Chicago

Re: [OT] GPG signature fails

[Aaron Toponce]

On Mon, Mar 14, 2011 at 05:31:42PM -0500, Derek Martin wrote:
> If this verifies, I just figured it out.

Still a bad signature here. I wonder if it has anything to do with the
fact that your signature is 159 bits, and not 160?

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


signature.asc
Description: Digital signature

Re: [OT] GPG signature fails

[Simon Ward]

On Sun, Mar 13, 2011 at 01:48:26PM +0100, Remco Rijnders wrote:
> Possibly... but it consistently is with only Derek's emails. Your
> signature validates fine for example.
> 
> Using mutt and gpg as available in / from Debian Squeeze.

It’s not just you as I am seeing it too, with both gpg and gpg2.
Package versions are:

gnupg  1.4.10-4
gnupg2 2.0.14-2
mutt   1.5.20-9+squeeze1

Simon
-- 
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall


signature.asc
Description: Digital signature

Re: Is it possible to add a margin at the left side of pager?

[Simon Ruderich]

On Fri, Feb 18, 2011 at 04:27:03PM +0800, Yue Wu wrote:
> Hi, list,
>
> As the title, I feel too tight for eye when the left side of the pager
> is at the most left of the fringe of a xterm window, is it possible to
> add a margin between the left side of xterm window and pager?
>
> Regards,
> Yue Wu

Hi,

You could use $display_filter to add it. Something like this:

set display_filter="fold -w 70 | sed 's/^//g'"

The only problem is it will destroy coloring :-/ Not sure if this
can be avoided.

If you use screen you could also add a minimal vertical split to
the left so you get a gap. Something like (^A = Ctrl-A)

^A | (vertical split)
^A - (choose the empty window)
^A :resize 5 (make it five characters wide)
^A  (go to main region)

Regards,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


pgpzKwibk0mHL.pgp
Description: PGP signature

Re: [OT] GPG signature fails

[Derek Martin]

On Tue, Mar 15, 2011 at 07:28:21AM -0600, Aaron Toponce wrote:
> On Mon, Mar 14, 2011 at 05:31:42PM -0500, Derek Martin wrote:
> > If this verifies, I just figured it out.
> 
> Still a bad signature here. I wonder if it has anything to do with the
> fact that your signature is 159 bits, and not 160?

Yeah, I checked, and the signatures from that message and the previous
one looked the same, cryptographically speaking.

Here's what I see:

$ gpg --list-packets foo2.txt
:signature packet: algo 17, keyid 1C49C048DFBEAD02
version 3, created 1300141736, md5len 5, sigclass 01
digest algo 2, begin of digest c9 92
data: [159 bits]
data: [160 bits]

Odd.


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpuFNjCQt6CN.pgp
Description: PGP signature

Re: sign plian text messages only

[Simon Ruderich]

On Wed, Feb 23, 2011 at 11:15:32PM +0100, tim smy wrote:
> I would like to set up mutt to sign plain text messages. please
> advise if the lines below are relevant to be placed in the
> muttrc and if some lines are missing please let me know.
>
> set pgp_clearsign_command="gpg --no-verbose --batch --output - 
> --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f"
> set pgp_sign_as=0x12345678
> set pgp_timeout=60
> set pgp_create_traditional=yes.
^ better remove that .
> set pgp_auto_decode=yes
>
> thanks
> tim

Hi,

Looks good to me. I'm not sure what $pgp_* options you need
though - I have all the lines from the gpg.conf example file in
my muttrc. And you might want to add $pgp_verify_command so you
can verify received messages.

Regards,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


pgpjr1gHlHT9Q.pgp
Description: PGP signature

Re: [OT] GPG signature fails

[Derek Martin]

On Tue, Mar 15, 2011 at 09:25:47AM -0500, Derek Martin wrote:
> On Tue, Mar 15, 2011 at 07:28:21AM -0600, Aaron Toponce wrote:
> > On Mon, Mar 14, 2011 at 05:31:42PM -0500, Derek Martin wrote:
> > > If this verifies, I just figured it out.
> > 
> > Still a bad signature here. I wonder if it has anything to do with the
> > fact that your signature is 159 bits, and not 160?
> 
> Yeah, I checked, and the signatures from that message and the previous
> one looked the same, cryptographically speaking.
> 
> Here's what I see:
> 
> $ gpg --list-packets foo2.txt
> :signature packet: algo 17, keyid 1C49C048DFBEAD02
> version 3, created 1300141736, md5len 5, sigclass 01
> digest algo 2, begin of digest c9 92
> data: [159 bits]
> data: [160 bits]
> 
> Odd.

Actually, do either of these last two messages (this one, and the one
I'm replying to) verify correctly?  I upgraded OpenSSL, and now I see
this:

$ gpg --list-packets foo4.txt
:signature packet: algo 17, keyid 1C49C048DFBEAD02
version 3, created 1300199147, md5len 5, sigclass 01
digest algo 2, begin of digest 57 51
data: [160 bits]
data: [160 bits]

Starting to look like an OpenSSL bug after all..

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgprC4Qct7Nur.pgp
Description: PGP signature

Re: getmail starts too many processes

[Simon Ruderich]

On Thu, Mar 10, 2011 at 07:26:02PM +0800, chris M. sprite wrote:
> I find that one that i start getmail to download mails, then
> the getmail will starts too many process so that it will use
> too many RAM.
>
> [snip]

Hi,

I've never encountered something similar. getmail is just one
python process and takes up only little memory (~ 10MiB in my
case).

Are you sure these are getmail processes? (Try top/htop).

Regards,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


pgpF6bxOdDZSK.pgp
Description: PGP signature

Re: [OT] GPG signature fails

[Simon Ruderich]

On Tue, Mar 15, 2011 at 09:34:37AM -0500, Derek Martin wrote:
> Actually, do either of these last two messages (this one, and the one
> I'm replying to) verify correctly?  I upgraded OpenSSL, and now I see
> this:
>
> $ gpg --list-packets foo4.txt
> :signature packet: algo 17, keyid 1C49C048DFBEAD02
> version 3, created 1300199147, md5len 5, sigclass 01
> digest algo 2, begin of digest 57 51
> data: [160 bits]
> data: [160 bits]
>
> Starting to look like an OpenSSL bug after all..

Both messages don't verify for me here in mutt (tip, gpg 1.4.10,
Debian Squeeze).

gpg: Signature made Tue 15 Mar 2011 03:34:37 PM CET using DSA key ID 
DFBEAD02
gpg: BAD signature from "Derek D. Martin "

I get this output on the signature:

$ gpg --list-packets
:signature packet: algo 17, keyid 1C49C048DFBEAD02
version 3, created 1300199677, md5len 5, sigclass 0x01
digest algo 2, begin of digest 12 73
data: [160 bits]
data: [158 bits]

Regards,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


pgpN5VCTDLZuV.pgp
Description: PGP signature

Re: [OT] GPG signature fails

[David J. Weller-Fahy]

* Derek Martin  [2011-03-15 09:42 -0500]:
> Actually, do either of these last two messages (this one, and the one
> I'm replying to) verify correctly?  I upgraded OpenSSL, and now I see
> this:
> 
> $ gpg --list-packets foo4.txt
> :signature packet: algo 17, keyid 1C49C048DFBEAD02
> version 3, created 1300199147, md5len 5, sigclass 01
> digest algo 2, begin of digest 57 51
> data: [160 bits]
> data: [160 bits]
> 
> Starting to look like an OpenSSL bug after all..

Odd... I see a bad signature as well.  Here's the data I get from this
message (saved to mbox).

#v+
dave@pooh:~$ gpg --list-packets tst.msg
:signature packet: algo 17, keyid 1C49C048DFBEAD02
version 3, created 1300199677, md5len 5, sigclass 0x01
digest algo 2, begin of digest 12 73
data: [160 bits]
data: [158 bits]
#v-

Version information is as follows.

#v+
gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, 
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
#v-

Not sure what other diagnostics to do... suggestions?

Regards,
-- 
dave [ please don't CC me ]


pgpvf3Fn8pb4t.pgp
Description: PGP signature

Re: application/pgp-signature is unsupported

[Joseph]

On 03/15/11 08:11, David Champion wrote:

* On 15 Mar 2011, Joseph wrote:

The addition in mailcap I just added in, but it makes no difference.
I know before it used to ask me if I want to view the signature but some how it 
doesn't any more.


What is the value of $pgp_verify_sig?  What you describe sounds like
it used to be ask-yes (or ask-no) and now it's just no.

--
David Champion ??? d...@uchicago.edu ??? IT Services ??? University of Chicago


I tried all combinations:
set crypt_verify_sig=ask-no
set crypt_verify_sig=ask-yes
set crypt_verify_sig=yes

Makes no difference, I always get 
[-- application/pgp-signature is unsupported (use 'v' to view this part) --]


--
Joseph

Re: rsync removes the "N" from mailboxes with new mail

[Nathan Stratton Treadway]

On Sun, Mar 13, 2011 at 07:13:33 -0700, Dan McDaniel wrote:
> Just to point out that rsync v2.6.4 is pretty old. Current is 3.0.7.
> Even my Debian Lenny system (Lenny was released two years ago) is
> running 3.0.3. Perhaps there was a change in rsync's behavior since
> 2.6.4. Version 3.0.7 does not change the access times on my system. 

This is getting a bit off topic for this list, but just to wrap up the
thread:  

I liked your theory that rsync's behavior had changed in later versions,
but after fairly extensive searching through the "news" files for the
program I wasn't able to find any mention of such a change (though I did
find a mention of better atime-management in the "rsync3.txt" 
wish-list...).


So I did some additional testing on an Ubuntu Lucid system, and those
tests confirmed that rsync v3.0.7 DOES still set the atime for the
source file (with or without the "-t" option) -- when used on a
filesystem that has "normal" atime behavior enabled.

However, I also noticed that on Lucid's kernel, filesystems are mounted
by default with the "relatime" option turned on, which means that atimes
are NOT updated in the usual sorts of "quick test of rsync" case (i.e.
when you view a file and then try copying it with rsync).  In other
words, in order to see that rsync was updating the atime of the source
file, I had to specifically use the "strictatime" mount option.

I discovered that this kernel default was changed as of Linux v2.6.30;
for more information on the change, you can search for occurrences of
"relatime" in:
   http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30

So I'm guessing that whatever system you have with rsync 3.0.7 also has
a new enough kernel that the relatime change explains the results of
your tests

(I've include a transcript of my tests below.)


Nathan




==> general info:
# rsync --version | head -1
rsync  version 3.0.7  protocol version 30
# uname -rvmo
2.6.32-28-server #55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011 x86_64 GNU/Linux


==> set up a few aliases to use later  
# alias now='echo -n "[$(date +%T)]: "'
# alias ftimes='stat -c "File: %N
atime: %x
mtime: %y
ctime: %z
"'

==> mount a filesystem with default mount options:
# mount /root/temp_ext4.img /mnt -oloop
# cd /mnt


==> create a file, then access the file, and check the file times:

# now; rm -f atime.test*; echo "hello" > atime.test; ftimes atime.test
[10:27:05]: File: `atime.test'
atime: 2011-03-15 10:27:05.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:27:05.0 -0400

# sleep 5; now; cat atime.test; ftimes atime.test
[10:27:11]: hello
File: `atime.test'
atime: 2011-03-15 10:27:11.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:27:05.0 -0400


==> run rsync, then check the file times
# now; rsync -v atime.test atime.test_rsync
[10:29:06]: atime.test

sent 80 bytes  received 31 bytes  222.00 bytes/sec
total size is 6  speedup is 0.05

# ftimes atime.test*
File: `atime.test'
atime: 2011-03-15 10:27:11.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:27:05.0 -0400

File: `atime.test_rsync'
atime: 2011-03-15 10:29:06.0 -0400
mtime: 2011-03-15 10:29:06.0 -0400
ctime: 2011-03-15 10:29:06.0 -0400


# now; rsync -v -t atime.test atime.test_rsync-t
[10:37:47]: atime.test

sent 80 bytes  received 31 bytes  222.00 bytes/sec
total size is 6  speedup is 0.05

# ftimes atime.test*
File: `atime.test'
atime: 2011-03-15 10:27:11.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:27:05.0 -0400

File: `atime.test_rsync'
atime: 2011-03-15 10:29:06.0 -0400
mtime: 2011-03-15 10:29:06.0 -0400
ctime: 2011-03-15 10:29:06.0 -0400

File: `atime.test_rsync-t'
atime: 2011-03-15 10:37:47.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:37:47.0 -0400
==> So, the atime of source file was not changed by either "rsync"...

# now; cat atime.test; ftimes atime.test
[10:38:43]: hello
File: `atime.test'
atime: 2011-03-15 10:27:11.0 -0400
mtime: 2011-03-15 10:27:05.0 -0400
ctime: 2011-03-15 10:27:05.0 -0400
==> ... but then again, using "cat" again didn't update atime, either...

# grep /mnt /proc/mounts
/dev/loop0 /mnt ext4 rw,relatime,barrier=1,data=writeback 0 0
==> because the volume is mounted with 'relatime" by default (though
since it's the default, that doesn't show up in the output of
"mount"):
# mount | grep /mnt
/dev/loop0 on /mnt type ext4 (rw)



==> now, switch the mount to use "strictatime"
# mount /root/temp_ext4.img /mnt -oremount,strictatime
# grep /mnt /proc/mounts
/dev/loop0 /mnt ext4 rw,barrier=1,data=writeback 0 0
# mount | grep /mnt
/dev/loop0 on /mnt type ext4 (rw,strictatime)


==> then repeat the tests:

# now; rm -f atime.test*; echo "hello" > atime.test; ftimes atime.test
[10:42:54

Re: application/pgp-signature is unsupported

[Derek Martin]

On Tue, Mar 15, 2011 at 10:09:15AM -0600, Joseph wrote:
> I tried all combinations:
> set crypt_verify_sig=ask-no
> set crypt_verify_sig=ask-yes
> set crypt_verify_sig=yes
> 
> Makes no difference, I always get [-- application/pgp-signature is
> unsupported (use 'v' to view this part) --]

Almost sounds to me like you may not have PGP support compiled in?
When you run mutt -v  what do you get?  Do you get any errors about
unknown options when Mutt starts up? 

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpq1YDB6TAQu.pgp
Description: PGP signature

Re: application/pgp-signature is unsupported

[Joseph]

On 03/15/11 16:21, Derek Martin wrote:

On Tue, Mar 15, 2011 at 10:09:15AM -0600, Joseph wrote:

I tried all combinations:
set crypt_verify_sig=ask-no
set crypt_verify_sig=ask-yes
set crypt_verify_sig=yes

Makes no difference, I always get [-- application/pgp-signature is
unsupported (use 'v' to view this part) --]


Almost sounds to me like you may not have PGP support compiled in?
When you run mutt -v  what do you get?  Do you get any errors about
unknown options when Mutt starts up?



GPG is compiled IN
Here is the output of mutt -v

System: Linux 2.6.36-gentoo-r5 (x86_64)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
hcache backend: GDBM version 1.8.3. 10/15/2002 (built Jan 22 2010 20:58:12)
Compile options:
-DOMAIN
-DEBUG
+HOMESPOOL  -USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  -USE_FCNTL  +USE_FLOCK   
+USE_POP  -USE_NNTP  -USE_IMAP  -USE_SMTP  
+USE_SSL_OPENSSL  -USE_SSL_GNUTLS  -USE_SASL  -USE_GSS  +HAVE_GETADDRINFO  
-HAVE_REGCOMP  +USE_GNU_REGEX  +COMPRESSED  
+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  +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="Maildir"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc/mutt"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

patch-1.5.20.sidebar.20090619.txt
dgc.subjrx
fg.smarttime
vvv.initials
vvv.quote
vvv.nntp
rr.compressed

mail-client/mutt-1.5.20-r18  USE="crypt gdbm gpg nls pop sidebar ssl -berkdb -debug -doc -gnutls -idn -imap -mbox -nntp -qdbm -sasl -smime -smtp 
-tokyocabinet"


--
Joseph