pgpenvelope-users Mailing List for pgpenvelope (Page 3)
Brought to you by:
ftobin
Menu
▾
▴
pgpenvelope-users — general pgpenvelope users discussion
You can subscribe to this list here.
| 2000 |
Jan
(1) |
Feb
(22) |
Mar
(11) |
Apr
(9) |
May
(1) |
Jun
(9) |
Jul
(28) |
Aug
(9) |
Sep
(10) |
Oct
(26) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
(4) |
Aug
(8) |
Sep
(9) |
Oct
|
Nov
(2) |
Dec
(8) |
| 2002 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frank T. <ft...@ui...> - 2001-02-10 00:01:44
|
Todd A. Jacobs, at 15:55 -0800 on Fri, 9 Feb 2001, wrote:
One of the things I seem to get a lot of (especially from mutt and Eudora
users) is detached signatures. Is there any way to enable pgpenvelope to
handle a detached message signature?
You're talking PGP/MIME, which is difficult in Pine, since Pine doesn't
allow the display filters to deal with MIME data well (unfortunately).
It's a problem with pgpenvelope, but not at the top of the list for now.
--
Frank Tobin http://www.uiuc.edu/~ftobin/
|
|
From: Todd A. J. <no...@co...> - 2001-02-09 23:54:46
|
One of the things I seem to get a lot of (especially from mutt and Eudora users) is detached signatures. Is there any way to enable pgpenvelope to handle a detached message signature? -- Todd A. Jacobs CodeGnome Consulting, LTD |
|
From: Frank T. <ft...@ui...> - 2001-01-30 17:04:23
|
Todd A. Jacobs, at 01:12 -0800 on Tue, 30 Jan 2001, wrote:
The problem seems to have been with stale gnupg lock files in the user's
home directory. Since pgpenvelope doesn't trap this condition, it
basically waits forever for gpg to exit, which it never does.
Unfortunately, there's nothing clean pgpenvelope can do about this; the
problem exists outside of pgpenvelope. That is, pgpenvelope really can't
know about these lock files. Really, GnuPG should be smart enough to
handle this on it's own; there are frequent complaints about this on the
gnupg-users list.
--
Frank Tobin http://www.uiuc.edu/~ftobin/
|
|
From: Frank T. <ft...@ui...> - 2001-01-29 22:31:26
|
Todd A. Jacobs, at 13:21 -0800 on Sat, 27 Jan 2001, wrote:
I'm getting strange behavior from this version of pgpenvelope running with
gpg 1.0.4. What's happening is that pgpenvelope-decrypt is being called
from my procmailrc, but is somehow hanging. If I kill the spawned instance
of gpg, the filter returns and the message is processed. Otherwise, it
will pretty much wait forever.
Is the message really big?
--
Frank Tobin http://www.uiuc.edu/~ftobin/
|
|
From: Todd A. J. <tj...@co...> - 2001-01-29 01:22:33
|
On Sun, 28 Jan 2001, Frank Tobin wrote: > Is the message really big? Nope. Just the word foo in the message body, plus headers and signature. -- Todd A. Jacobs Senior Network Consultant |
|
From: Frank T. <ft...@ui...> - 2001-01-28 23:51:35
|
Todd A. Jacobs, at 13:21 -0800 on Sat, 27 Jan 2001, wrote:
I'm getting strange behavior from this version of pgpenvelope running
with gpg 1.0.4. What's happening is that pgpenvelope-decrypt is being
called from my procmailrc, but is somehow hanging. If I kill the
spawned instance of gpg, the filter returns and the message is
processed. Otherwise, it will pretty much wait forever.
Is the message really big?
--
Frank Tobin http://www.uiuc.edu/~ftobin/
|
|
From: Frank T. <ft...@ui...> - 2001-01-14 23:53:35
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Billy Donahue, at 13:19 -0500 on Sun, 14 Jan 2001, wrote:
that would be cool. Werner et al. say that that's what bash alias is for,
but that's only useful if you're using bash as the interpreter.
a MUA which does a direct execve of gpg (or pggenvelope, for that matter)
isn't going to be able to use bash's aliases.
exactly.
As far as subkeys go, I never worry about them, and I don't really
understand them.
Hmm, sounds like having multiple subkeys might have been a bad idea in the
OpenPGP spec.
I'm going to start work on a simple wrapper recipient-aliasing program.
If there are other features that might be useful, please let me know.
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjpiO/YACgkQVv/RCiYMT6PUvQCcCYlbjUiAT0OuqU+rBiOjLCLW
yGwAnAr7BHTEKzNtUTgXiqBKvt12ny+a
=tck3
-----END PGP SIGNATURE-----
|
|
From: Billy D. <bi...@da...> - 2001-01-14 18:19:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jan 14, 2001 at 07:03:12AM -0600, Frank Tobin wrote: > Personally, I'm getting the feeling that having multiple subkeys was a bad > idea in OpenPGP. It causes too much confusion among users, and could > easily just be replaced by having multiple primary keys, all signed by a > separate signing key. > > On a side note, is there interest in having a wrapper around GnuPG that > allows you to do things like have aliases for keys, and set "defaults" > such as which subkeys to use during encryption? E.g., you would call > GnuPG to encrypt to your key ABCD, but then the wrapper would look up ABCD > in it's configuration, and substitute the desired subkey? > > If this sort of thing might be interesting, please give me ideas for other > wrapper functionality that might be useful. This is all sort of stuff > that 'could' be in GnuPG, but would probably best be handled currently by > a wrapper program. People keep bugging Werner for an alias feature in the .gnupg/options, and he usually says that it should be handled outside of GnuPG by wrappers. One very very useful thing would be to encrypt to a mailing list by selecting each of the list's subscribers (obviously more useful for corporate mailing lists). I actually need that sort of thing. If I could translate pgpenvelope dev...@da... to gpg -sea -r bi...@da... -r to...@da...\ -r di...@da... -r ha...@da... that would be cool. Werner et al. say that that's what bash alias is for, but that's only useful if you're using bash as the interpreter. a MUA which does a direct execve of gpg (or pggenvelope, for that matter) isn't going to be able to use bash's aliases. As far as subkeys go, I never worry about them, and I don't really understand them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Ye2M+2VvpwIZdF0RArD/AJ4s3md0U5wg5RUTjX1j7w3L+d2F9gCfXqGF 2eJrOrJUdfE/jftP+813gP4= =k6eZ -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2001-01-14 13:03:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been working on getting subkey selection for encryption into pgpenvelope, and have to decide on a couple interface issues. First, if you select a key to encrypt to which has multiple subkeys, should you be immediately prompted to select a subkey? Or should you just, as another menu option, be able to select the subkey to use for a specifc public key you've already selected to use? Personally, I'm getting the feeling that having multiple subkeys was a bad idea in OpenPGP. It causes too much confusion among users, and could easily just be replaced by having multiple primary keys, all signed by a separate signing key. On a side note, is there interest in having a wrapper around GnuPG that allows you to do things like have aliases for keys, and set "defaults" such as which subkeys to use during encryption? E.g., you would call GnuPG to encrypt to your key ABCD, but then the wrapper would look up ABCD in it's configuration, and substitute the desired subkey? If this sort of thing might be interesting, please give me ideas for other wrapper functionality that might be useful. This is all sort of stuff that 'could' be in GnuPG, but would probably best be handled currently by a wrapper program. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjpho5oACgkQVv/RCiYMT6MIqgCfbvSyROXIbRU6Uqg/c+Q4Egv9 cDgAn3HjONz5bRYRbeK2bI2EAw5YgdQp =aDah -----END PGP SIGNATURE----- |
|
From: L. S. <ra...@qu...> - 2001-01-07 15:01:52
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 6 Jan 2001, Frank Tobin wrote:
> Werner, what benefit is there to displaying the keyid for a
> subkey?
>
> I'm not Werner, but i can answer your question. Remember, most OpenPGP
> keys are two keys: the primary (for signing), and the subkey (for
> encryption). Keys are allowed to have multiple subkeys, meaning you can
> encrypt to any one of the subkeys. Hence, these must be uniquely
> identifiable, and hence, we have subkey id's.
>
> Reminds me that I have to put this feature into pgpenvelope...
Thank you. Not having that in pgpenvelope has been driving me nuts for
some time.
__
L. Sassaman
Security Architect | "The world's gone crazy,
Technology Consultant | and it makes no sense..."
|
http://sion.quickie.net | --Sting
-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.
iD8DBQE6WITgPYrxsgmsCmoRAlLhAKCssZImd0qZU/OMPBvyoENU3FSerACeKi5b
ikXuTWsIYDLQ3vNucgZ5UBY=
=pyPX
-----END PGP SIGNATURE-----
|
|
From: Frank T. <ft...@ui...> - 2000-10-09 01:04:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've created a short two-question survey concerning pgpenvelope's packaging covering the issue of whether or not to bundle needed modules at: https://sourceforge.net/survey/survey.php?group_id=1628&survey_id=10953 If you take the time to provide input, I'd appreciate it. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnhGaUACgkQVv/RCiYMT6PadQCcDhfQkAjJtpL2vJk1t8+1bCYg Yg4AoKHpF8rIacxfW4kol7BkTZHXz/IE =frdb -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-08 23:57:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Tobin, at 18:49 -0500 on Sun, 8 Oct 2000, wrote: > If I'm not mistaken, the $threshold is the minimum match lengh. From > "perldoc String::Approx": Duh, I was dumb when I wrote this. Ignore it :) - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnhCdEACgkQVv/RCiYMT6OeAQCgqMWDfiGbpjmRRHCRv5VJwdfv KcMAniwawHDLlQ9g/5/UfwxFQTZxMh60 =TITo -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-08 23:52:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've thought of another problem that might arise. If a message is signed, and inside the signed message, there is a line: - - ----pgpenvelope... How do you think this should be handled? When the message is decrypted, it will look like: - -----pgpenvelope... ...and then be a 'forged' border. However, if I put warning messages in to catch this sort of thing, I would then be 'corrupting' the signed message from the point of the user (e.g., what the user sees on-screen is not actually what was verified/decrypted). - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnhCLQACgkQVv/RCiYMT6M4CQCePCJhVzDIsR9eGPCduMSnoOTH XooAn0nRufmFd0gkU4wQ5nCr98iT417C =/0Ri -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-08 23:49:09
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Billy Donahue, at 19:20 -0400 on Sun, 8 Oct 2000, wrote:
> There needs to be a way of specifying which positions are ok for matches.
> If the algorithm knew that position 34 is no far, then it would be able
> to keep looking for matches.. Maybe there should be a way to specify the
> minimum match length.. The match is actually only 5 characters long in
> the case of the weird match you found. It would be nice be able to tell
> String::Approx to throw that match out and to keep searching.
If I'm not mistaken, the $threshold is the minimum match lengh. From
"perldoc String::Approx":
The implicit default approximateness is 10%, rounded up.
In other words: every tenth character in the pattern may
be an error, an edit. You can explicitly set the maximum
approximateness by supplying a modifier like
number
%numer
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnhB/QACgkQVv/RCiYMT6NMigCeM3rHIbey26G9RjO7NK/6hJC7
ruwAn2EsYGWcNm9GWjMQRV+Y/yjCXXNJ
=Ww35
-----END PGP SIGNATURE-----
|
|
From: Billy D. <bi...@da...> - 2000-10-08 23:20:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 8 Oct 2000, Frank Tobin wrote: > Billy Donahue, at 09:20 -0400 on Sun, 8 Oct 2000, wrote: > > > I think this might be a bug in String::Approx. It's obviously a mistake > > to say that these two strings are only 5 edits of distance from each > > other when positioned at a 34 character offset from each other. > > I've sent mail to the author of String::Approx concerning this. As a > workaround, if we don't use symmetric borders, the problem doesn't seem to > appear. For example: > > -----pgpenvelope processed message Well, the problem makes sense. There needs to be a way of specifying which positions are ok for matches. If the algorithm knew that position 34 is no far, then it would be able to keep looking for matches.. Maybe there should be a way to specify the minimum match length.. The match is actually only 5 characters long in the case of the weird match you found. It would be nice be able to tell String::Approx to throw that match out and to keep searching. I may have to crack open String::Approx to fix this, and I don't really want to have to do that.. - -- "The Funk, the whole Funk, and nothing but the Funk." Linux barcode software mirror: http://dadadada.net/cuecat Billy Donahue <mailto:bi...@da...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE54QEr+2VvpwIZdF0RAoWHAKCdc6OVNvXOQQVT88DffoMLhJFzyACbBo7W H2h79/jc8aAYUA2AxpM+6eo= =CmWr -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-08 20:08:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Billy Donahue, at 09:20 -0400 on Sun, 8 Oct 2000, wrote: > I think this might be a bug in String::Approx. It's obviously a mistake > to say that these two strings are only 5 edits of distance from each > other when positioned at a 34 character offset from each other. I've sent mail to the author of String::Approx concerning this. As a workaround, if we don't use symmetric borders, the problem doesn't seem to appear. For example: - -----pgpenvelope processed message - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjng1DcACgkQVv/RCiYMT6ODBACdHjUDISSSm0YjFrsHqD8LL/oE ThMAnR4JbmK9kXDsBLhN6vVbnq/oVgUn =aMeO -----END PGP SIGNATURE----- |
|
From: Billy D. <bi...@da...> - 2000-10-08 13:20:23
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 8 Oct 2000, Frank Tobin wrote:
> Billy Donahue, at 07:36 -0400 on Tue, 3 Oct 2000, wrote:
>
> > Here's a test message after passing through the forgery filter.
> > My actual pgpenvelope borders are set to be:
>
> I've applied software changes based on the patches you sent (changed a
> little bit to improve efficiency), but unfortunately, I can't replicate
> the behaviour you are getting, even with applying your patch directly.
> For example, my default border is:
>
> > -----pgpenvelope processed message-----
>
> (without "> ")
>
> The following does not trip properly; e.g., it matches at index 34, not 0:
>
> > -----agpenvelope processed message-----
. ^
. 0....5....0....5....0....5....0....
Okay, that's weird. Here's what I'm using to diagnose it...
cat <<"EOF" >approxmatch.pl
#!/usr/bin/perl
use String::Approx qw( aindex );
($thresh,$pattern,$in) = @ARGV;
$fmt = "%10s: %s\n";
printf $fmt, "thresh", $thresh;
printf $fmt, "pattern", $pattern;
printf $fmt, "in", $in;
$at = aindex( $pattern, [ $thresh ], $in );
print "index of match: $at\n";
print "$pattern\n";
print " "x$at ."$in\n";
EOF
perl ./approxmatch.pl '5' \
'-----pgpenvelope processed message-----' \
'-----agpenvelope processed message-----'
producing:
thresh: 5
pattern: -----pgpenvelope processed message-----
in: -----agpenvelope processed message-----
index of match: 34
- -----pgpenvelope processed message-----
-----agpenvelope processed message-----
The result index jumps from 0 to 34 when the threshold hits 6.
The 5 first characters match the last 5 characters of your border.
I guess the aindex doesn't find the BEST match, just A match inside
the threshold.. that's kinda crazy.
What does this mean? It means that someone can send you a message with
the '-----agpenvelope processed message-----' line and it would and pass
undetected through your forgery filter because at position 34. the
decryptor would think it was seeing a quoted border. Hm.. interesting problem.
I think this might be a bug in String::Approx. It's obviously a mistake
to say that these two strings are only 5 edits of distance from each
other when positioned at a 34 character offset from each other.
- --
"The Funk, the whole Funk, and nothing but the Funk."
Linux barcode software mirror: http://dadadada.net/cuecat
Billy Donahue <mailto:bi...@da...>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iD8DBQE54HSP+2VvpwIZdF0RAoXaAKCFpNDj85IeF64XQkbZXApNiJPe1wCgm+IB
/+vdEsg0IVXjVZD8KpWtTJI=
=EJxK
-----END PGP SIGNATURE-----
|
|
From: Frank T. <ft...@ui...> - 2000-10-08 09:53:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Billy Donahue, at 07:36 -0400 on Tue, 3 Oct 2000, wrote: > Here's a test message after passing through the forgery filter. > My actual pgpenvelope borders are set to be: I've applied software changes based on the patches you sent (changed a little bit to improve efficiency), but unfortunately, I can't replicate the behaviour you are getting, even with applying your patch directly. For example, my default border is: > -----pgpenvelope processed message----- (without "> ") The following does not trip properly; e.g., it matches at index 34, not 0: > -----agpenvelope processed message----- (without "> ") The call I'm using in pgpenvelope_decrypt is: aindex( $border, [ $forgery_threshold ], $line ); $forgery_threshold is "10%" (default). If I increase the threshold to "6", (not 6%), I get better a match at index 0 (the desired behaviour). The means I'm testing is by running (inside a checked-out CVS copy of pgpenvelope): perl -Ilib pgpenvelope_decrypt --filter < forgery My changes are in CVS, if you're interested in seeing what I've done. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjngRAcACgkQVv/RCiYMT6NYkACfUqb0NLTWIaq6NcynLWCq2M3o vJkAoIa0KFe6VdwjY2CoAHCPE7ThzgLK =8oHy -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-08 01:14:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm going to throw this out for a little discussion; how useful is it for users to have the modules need by pgpenvelope to be bundled with it? This is always a tricky issue, and I'm not sure how to deal with it. Different packages have different policies; some do not bundle the modules, some do, some have strange automated mechanisms for automatically fetching modules (which I actually don't like). Here are some arguments against bundling modules: 1) Package size; uncompressed, pgpenvelope with modules is about 400 KB; without, about 112 KB. That's over a factor of 3. There is likely even to be a greater factor once compressed, as the modules that make up the difference are already compressed. This is actually doubly-hit because some other modules, such as GnuPG::Interface (which I package) have copies of the needed modules inside of them (e.g., both pgpenvelope and GnuPG::Interface have Class::MethodMaker inside of their packages, so it is included twice in the overall pgpenvelope package). 2) Updating of modules. Sometimes there is a newer module available than the one bundled with pgpenvelope; it might be better for the user to get the module from the newer source, rather than the one bundled with pgpenvelope. As a workaround/substitute, I could provide URL's to locations for each needed package. What do you all feel about the issue? Keep in mind pgpenvelope has a wide range of users, from the complete novice, to highly experienced. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnfyoEACgkQVv/RCiYMT6OZVACghLW54Pte/itf3jWxNpZH8iy/ mQYAnjZ5t89CL8/HMcRHSqd1VXaZtmWd =vRKi -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-05 18:49:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristofer Tingdahl, at 11:15 -0700 on Thu, 5 Oct 2000, wrote: > I wounder if it's possible to insert an interactive question > in the beginning of the perl-script, something like this: > > Message is encrypted, do you want to decrypt it [Y,n]? There are two solutions to your problem. First, if you use the procmail setup described in the manpage, all PGP messages are saved as-is in the pgpenvelope-backup folder. Second, you can enable the following option in your ~/.pgpenvelope/prefs file, as described in ~/.pgpenvelope/prefs.default: confirm-decryption = 1 - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnczT4ACgkQVv/RCiYMT6POcwCfeAEwf+6ywMFx7Yxf2KeDMh4j vXkAn1CDSBGFsYvfFwSprB3FWAIhdJ2P =W2Lw -----END PGP SIGNATURE----- |
|
From: Frank T. <ft...@ui...> - 2000-10-04 00:59:15
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Friedhelm Buescher, at 21:03 +0200 on Tue, 3 Oct 2000, wrote:
> +while (! /^$/) {
> strange things happens : pgp4pine gets the right key, if you choose NOT to
> encrypt nor sign, everything works perfectly. the mail is send as
> normal. If you choose to encrypt or sign, an empty mail is send (as my
> previous mail :) - but WHY ? the patch only strips of the headerlines from
> stdin, so i assume pgpenvelope gets the data as usual - or not ?
The problem might lie in the fact that you are very unforgivein in the
/^$/ match; it's cleaenr and more sane to do:
while ( <STDIN> )
{
last if not /\w/;
...
}
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnagOIACgkQVv/RCiYMT6MRpgCdE/8qyj3lRJh91uh6OwFdQsa5
8/QAniU/ipveU6G+R8/6pRx+VG1hTLm7
=A5WB
-----END PGP SIGNATURE-----
|
|
From: Frank T. <ft...@ui...> - 2000-10-04 00:56:54
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Friedhelm Buescher, at 21:03 +0200 on Tue, 3 Oct 2000, wrote:
> +while (! /^$/) {
> + $_ = <STDIN>;
> + if (/^From: .+ <(.+)>/) { $signing_key_id = $1; }
> + }
> +
Instead of doing this, I am hoping/planning on having a system where
settings can be based on matching regexes to header lines. E.g.,
something like:
- ----
^From: bo...@bo...
signing-key = foo
^To: buddies.*
encrypt-to-recipients = 1
- -----
...but going that route may be going overboard to solve such the simple
problem of determing the signing-key. Your type of system by simply
trying to get a key from From: might be a simpler approach (although not
as extensible, or useful, if the From: could match multiple signing keys).
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnagFEACgkQVv/RCiYMT6MfFgCfda5hObzgWntx5CKR2mr/D1fB
e6kAoKvi6we+tK8rtW1ZMZnbEz/ueeOb
=AJPg
-----END PGP SIGNATURE-----
|
|
From: Billy D. <bi...@da...> - 2000-10-03 22:44:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 3 Oct 2000, Frank Tobin wrote: > > > Billy Donahue, at 07:14 -0400 on Tue, 3 Oct 2000, wrote: > > > Well, it did mangle my patch... Here's an unmangled^Wunsigned version. > > Actually, could you post it to the Patch Manger for pgpenvelope on SF? I > can handle it cleanly there. Sure. - -- "The Funk, the whole Funk, and nothing but the Funk." Linux barcode software mirror: http://dadadada.net/cuecat Billy Donahue <mailto:bi...@da...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE52mE3+2VvpwIZdF0RAqYKAJ4v7otbxgdAUhDkZUAeUZSPXjXlPACfYtqv V9Ot7bJoMtLR6nmm8cOuy44= =n9Z7 -----END PGP SIGNATURE----- |
|
From: Friedhelm B. <bue...@ma...> - 2000-10-03 19:09:29
|
hi. i had the idea of making pine passing the header to pgpenvelope, and
having pgpenvelope figure out the from-line, so that it can choose the
right key for signing. the following patch does the right thing , when the
pine-config is changed to :
sending-filters=/usr/bin/pgpenvelope_encrypt _RECIPIENTS_ _INCLUDEALLHDRS_
--- pgpenvelope_encrypt Sun Jul 23 11:54:58 2000
+++ pgpenvelope_encrypt Tue Oct 3 20:30:07 2000
@@ -87,6 +90,13 @@
);
my $signing_key_id = $config->get( 'signing-key' ) || '';
+
+$_ = " ";
+while (! /^$/) {
+ $_ = <STDIN>;
+ if (/^From: .+ <(.+)>/) { $signing_key_id = $1; }
+ }
+
if ( $signing_key_id )
---
strange things happens : pgp4pine gets the right key, if you choose NOT to
encrypt nor sign, everything works perfectly. the mail is send as
normal. If you choose to encrypt or sign, an empty mail is send (as my
previous mail :) - but WHY ? the patch only strips of the headerlines from
stdin, so i assume pgpenvelope gets the data as usual - or not ?
greetings !
|
|
From: Frank T. <ft...@ui...> - 2000-10-03 18:52:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Billy Donahue, at 04:10 -0400 on Tue, 3 Oct 2000, wrote: > Eek.. if it happens in procmail, that may get noisy on an unattended > terminal. Even if I'm just busy I may not want to see the messages. > (I usually stay logged in while I'm asleep in the next room).. I like > the idea of 'out of band' data, though. Maybe the procmail verifier > can slip some pattern like: $DISPLAY is not set for procmail-running programs, so I couldn't write to the X screen. > You may be looking at a forged message. I don't remember > verifying it, yet it carries pgpenvelope borders. > <press any key> This system is interesting, but I like String::Approx more. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjnaKvIACgkQVv/RCiYMT6NmWACgiltpSrbLvBt9dO35NRvnm2Wa tJUAn0Ivqu8M2eSTdF+ixcQrR8aotWFN =ZIDj -----END PGP SIGNATURE----- |
2 messages has been excluded from this view by a project administrator.
