Like I was saying above I'm beginning to think this is a "MS Word" issue in sending the email. A problem on the sending side.
I have suspicion that word is replacing some spaces with simmilar characters after the pgp program is encrypting it.
I used my script I mentioned earlier (its easy to debug now) and am getting a copy of the message being sent to gpg for verification.
I then compare that file with copying and pasting text into vi.
then I did a diff on the two files.
Lone behold there are differences that are naked to the human eye.
diff steve.msg test.sh_verify_20070622082019
4c4
< I believe I can have the interface ready for entering data by July. I will need Jeff to get the www test environment up, install Tomcat, and the Apache JK connector
---
> I believe I can have the interface ready for entering data by July. I will need Jeff to get the www test environment up, install Tomcat, and the Apache JK connector
32c32
< What is the status of the database? We would like to begin really using it in July.
---
> What is the status of the database? We would like to begin really using it in July.
65c65
< -----END PGP SIGNATURE-----
---
> -----END PGP SIGNATURE-----
\ No newline at end of file
the newline one can be ignored
diff steve.msg test.sh_verify_20070622082019|hexdump -c
0000000 4 c 4 \n < I b e l i e v e
0000010 I c a n h a v e t h e i
0000020 n t e r f a c e r e a d y f
0000030 o r e n t e r i n g d a t a
0000040 b y J u l y . I w i
0000050 l l n e e d J e f f t o
0000060 g e t t h e w w w t e s t
0000070 e n v i r o n m e n t u p ,
0000080 i n s t a l l T o m c a t ,
0000090 a n d t h e A p a c h e
00000a0 J K c o n n e c t o r \n - - -
00000b0 \n > I b e l i e v e I c
00000c0 a n h a v e t h e i n t e
00000d0 r f a c e r e a d y f o r
00000e0 e n t e r i n g d a t a b y
00000f0 J u l y . 302 240 302 240 I w i l
0000100 l n e e d J e f f t o g
0000110 e t t h e w w w t e s t
0000120 e n v i r o n m e n t u p ,
0000130 i n s t a l l T o m c a t ,
0000140 a n d t h e A p a c h e J
0000150 K c o n n e c t o r \n 3 2 c 3
0000160 2 \n < W h a t i s t h e
0000170 s t a t u s o f t h e d a
0000180 t a b a s e ? W e w o u l
0000190 d l i k e t o b e g i n
00001a0 r e a l l y u s i n g i t
00001b0 i n J u l y . \n - - - \n > W
00001c0 h a t i s t h e s t a t u
00001d0 s o f t h e d a t a b a s
00001e0 e ? 302 240 W e w o u l d l i
00001f0 k e t o b e g i n r e a l
0000200 l y u s i n g i t i n J
0000210 u l y . \n 6 5 c 6 5 \n < - - -
0000220 - - E N D P G P S I G N A T
0000230 U R E - - - - - \n - - - \n > -
0000240 - - - - E N D P G P S I G N
0000250 A T U R E - - - - - \n \ N o
0000260 n e w l i n e a t e n d o
0000270 f f i l e \n
0000277
as you can see it seems spaces after punctuations are different when looked at with hexdump(typical MS auto correct)
for example
"J u l y . I" from my vi copied one
versus
"J u l y . 302 240 302 240 I" from the one firegpg was sending.
Like I was saying earlier I think firegpg was right here and that it is an invalid signature versus my copy and paste and gpg saying it was a valid signature.
Because I suspect an issue with copy and paste in linux(I have noticed it before) in which linux is correcting the bad characters into spaces.
Example: when I select text from vi that has tabs in it the copied text has spaces that approximate the tab. I think something similar is happening.
hmm maybe that is the unicode character for space. unicode would take up 2 characters
Last edited by jeff.sadowski (2007-06-22 22:13:22)