Gnus development mailing list
 help / color / mirror / Atom feed
* gnus: pgg-gpg-lookup-key uses wrong regular expression
@ 2003-11-14 15:27 Manoj Srivastava
  2003-11-14 22:13 ` Simon Josefsson
  2003-11-15  0:50 ` Simon Josefsson
  0 siblings, 2 replies; 3+ messages in thread
From: Manoj Srivastava @ 2003-11-14 15:27 UTC (permalink / raw)
  Cc: David D. Smith, 220521-forwarded, ding

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

Gnus v5.10.2
GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit)
 of 2003-10-31 on raven, modified by Debian

Hi,

      [Please retain the CC to 220521-forwarded@bugs.debian.org, so
      that the Debian BTS has a record of your contribution]

	This was reported by a Debian user.

In pgg-gpg-kookup-key (line 113 of pgg-gpg.el), that re-search-forward
call places point at the end of "^\\(sec\\|pub\\):" Next, it splits
that string at point on ":" separation. The problem is that if the
string looks like this:

"sec::foo:bar", split string returns '("foo" "bar"), not what the code
actually expects it to return, '("" "foo" "bar"). The code wants to
extract the third element of that list return from the split which is
now unpredictable. This bug was provoked because when I'm signing, it
parses a string like the one given, but when I'm verifying, it parses
a string like "pub:u:foo:bar" which returns '("u" "foo" "bar") and the
third element of that list is indeed what we want.

From the documentation of the split-string function, "If there is
match for SEPARATORS at the beginning of STRING, we do not include a
null substring for that.  Likewise, if there is a match at the end of
STRING, we don't include a null substring for that.

Changing the regular expression to not include the first colon, so
"^\\(sec\\|pub\\)" produces the proper result every time. Another
option may be to search forward to the point found by the original
regular expression and back up one place, so we know every time that
the string to be split will begin with a separator.

	manoj


[-- Attachment #2: User settings --]
[-- Type: application/emacs-lisp, Size: 20835 bytes --]

[-- Attachment #3: Type: text/plain, Size: 259 bytes --]

-- 
I thought YOU silenced the guard!
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gnus: pgg-gpg-lookup-key uses wrong regular expression
  2003-11-14 15:27 gnus: pgg-gpg-lookup-key uses wrong regular expression Manoj Srivastava
@ 2003-11-14 22:13 ` Simon Josefsson
  2003-11-15  0:50 ` Simon Josefsson
  1 sibling, 0 replies; 3+ messages in thread
From: Simon Josefsson @ 2003-11-14 22:13 UTC (permalink / raw)
  Cc: David D. Smith, 220521-forwarded, ding

Manoj Srivastava <srivasta@debian.org> writes:

> Gnus v5.10.2
> GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit)
>  of 2003-10-31 on raven, modified by Debian
>
> Hi,
>
>       [Please retain the CC to 220521-forwarded@bugs.debian.org, so
>       that the Debian BTS has a record of your contribution]
>
> 	This was reported by a Debian user.
>
> In pgg-gpg-kookup-key (line 113 of pgg-gpg.el), that re-search-forward
> call places point at the end of "^\\(sec\\|pub\\):" Next, it splits
> that string at point on ":" separation. The problem is that if the
> string looks like this:
>
> "sec::foo:bar", split string returns '("foo" "bar"), not what the code
> actually expects it to return, '("" "foo" "bar"). The code wants to
> extract the third element of that list return from the split which is
> now unpredictable. This bug was provoked because when I'm signing, it
> parses a string like the one given, but when I'm verifying, it parses
> a string like "pub:u:foo:bar" which returns '("u" "foo" "bar") and the
> third element of that list is indeed what we want.
>
> From the documentation of the split-string function, "If there is
> match for SEPARATORS at the beginning of STRING, we do not include a
> null substring for that.  Likewise, if there is a match at the end of
> STRING, we don't include a null substring for that.
>
> Changing the regular expression to not include the first colon, so
> "^\\(sec\\|pub\\)" produces the proper result every time. Another
> option may be to search forward to the point found by the original
> regular expression and back up one place, so we know every time that
> the string to be split will begin with a separator.

The `split-string in Emacs CVS subr.el contain the following change
that fixes the problem.  As this changes the behaviour of
`split-string', there should be a NEWS entry about it, which there
isn't.  Trying the various examples in the Elisp manual also doesn't
return the same values.  I'll forward this to emacs-devel@gnu.org,
then we can find out whether the right solution is to fix Debian's
Emacs or fix Emacs CVS and Gnus.

	* subr.el (split-string): Implement specification that splitting on
	explicit separators retains null fields.  Add new argument
	OMIT-NULLS.  Special-case (split-string "a string").




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gnus: pgg-gpg-lookup-key uses wrong regular expression
  2003-11-14 15:27 gnus: pgg-gpg-lookup-key uses wrong regular expression Manoj Srivastava
  2003-11-14 22:13 ` Simon Josefsson
@ 2003-11-15  0:50 ` Simon Josefsson
  1 sibling, 0 replies; 3+ messages in thread
From: Simon Josefsson @ 2003-11-15  0:50 UTC (permalink / raw)
  Cc: David D. Smith, 220521-forwarded, ding

Let me know if this works or not.  Apparently, the behaviour of the
new split-string was intentional, so it is no longer possible to use
the function portably...  Well, it was useful while it lasted.

2003-11-15  Simon Josefsson  <jas@extundo.com>

	* pgg-gpg.el (pgg-gpg-lookup-all-secret-keys)
	(pgg-gpg-lookup-key): Use regexp match instead of
	split-string (split-string is different between emacs 21.2 and
	21.4).  Reported by ultrasoul@ultrasoul.com (David D. Smith).

--- pgg-gpg.el.~6.21.~	2003-11-09 22:36:49.000000000 +0100
+++ pgg-gpg.el	2003-11-15 01:43:13.000000000 +0100
@@ -114,12 +114,9 @@
       (with-temp-buffer
 	(apply #'call-process pgg-gpg-program nil t nil args)
 	(goto-char (point-min))
-	(while (re-search-forward "^\\(sec\\|pub\\):"  nil t)
-	  (push (substring
-		 (nth 3 (split-string
-			 (buffer-substring (match-end 0)
-					   (progn (end-of-line) (point)))
-			 ":")) 8)
+	(while (re-search-forward
+		"^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\)" nil t)
+	  (push (substring (match-string 2) 8)
 		pgg-gpg-all-secret-keys)))))
   pgg-gpg-all-secret-keys)
 
@@ -131,12 +128,9 @@
     (with-temp-buffer
       (apply #'call-process pgg-gpg-program nil t nil args)
       (goto-char (point-min))
-      (if (re-search-forward "^\\(sec\\|pub\\):"  nil t)
-	  (substring
-	   (nth 3 (split-string
-		   (buffer-substring (match-end 0)
-				     (progn (end-of-line)(point)))
-		   ":")) 8)))))
+      (if (re-search-forward "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\)"
+			     nil t)
+	  (substring (match-string 2) 8)))))
 
 (defun pgg-gpg-encrypt-region (start end recipients &optional sign)
   "Encrypt the current region between START and END.




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-11-15  0:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-14 15:27 gnus: pgg-gpg-lookup-key uses wrong regular expression Manoj Srivastava
2003-11-14 22:13 ` Simon Josefsson
2003-11-15  0:50 ` Simon Josefsson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).