[PATCH] Wash output of org-encrypt-entry, take 3

[PATCH] Wash output of org-encrypt-entry, take 3

[Óscar Fuentes]

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

Sorry, clicked on Send before the patch was attached.

With a gpg executable with default settings, org-encrypt-entry produces
output like this:

 -----BEGIN PGP MESSAGE-----
 Version: GnuPG v1.4.10 (GNU/Linux)

 jA0EAwMCBWZVym6QMPVgyTxreTb1AEL3uTO+qCh2lR9/Qxk4nEMpPr9/RwNk95Gb
 slUra9X+N+qSWghEHvvxY0Ol8Yw9Ko4n7JVhHFs=
 =E4vw
 -----END PGP MESSAGE-----

The first line (Version:...) can change from machine to machine and over
time (as gpg is updated with a new version.) This is problematic when
the file is stored under version control, because as you decrypt and
encrypt an entry that line will change and create differences among the
file on the workspace and the file stored on VC.

Second, the empty line just wastes space and it is plain ugly once we
remove the first one with the Version text.

Finally, on some systems (mostly Windows) depending on how your Emacs
and gpg are configured, ^M characters may appear at the end of every
line of gpg output once it is inserted on the Emacs buffer. This happens
when the buffer uses Unix line-endings but gpg uses DOS line-endings.

The patch removes all that junk from the encrypted text just before it
is inserted on the buffer.

I'm assuming that the transformations made by this patch are
uncontroversial and desirable. If anyone actually prefers to keep that
noise on his encrypted org entries, an alternative implementation that
uses a configurable list of regexps is trivial to implement, but then
every user would have to do some job for achieving the same result.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: wash-crypt-string.patch --]
[-- Type: text/x-diff, Size: 1123 bytes --]

diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index b649e39..308628e 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -112,6 +112,15 @@ This setting can also be overridden in the CRYPTKEY property."
     (let ((epg-context (epg-make-context nil t t)))
       (epg-encrypt-string epg-context str (epg-list-keys epg-context crypt-key)))))
 
+(defun org-crypt-wash-encrypted-string (str)
+  "Remove superfluos and annoying text from the encrypted string."
+  (with-temp-buffer
+    (insert str)
+    (goto-char (point-min))
+    (while (re-search-forward "^Version:.*$\\|\^M\\|^\n" nil t)
+      (replace-match ""))
+    (buffer-string)))
+
 (defun org-encrypt-entry ()
   "Encrypt the content of the current headline."
   (interactive)
@@ -132,6 +141,7 @@ This setting can also be overridden in the CRYPTKEY property."
           (setq end (point)
                 encrypted-text
 		(org-encrypt-string (buffer-substring beg end) crypt-key))
+	  (setq encrypted-text (org-crypt-wash-encrypted-string encrypted-text))
           (delete-region beg end)
           (insert encrypted-text)
           (when folded

Re: [PATCH] Wash output of org-encrypt-entry, take 3

[Bernt Hansen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> +(defun org-crypt-wash-encrypted-string (str)
> +  "Remove superfluos and annoying text from the encrypted string."
> +  (with-temp-buffer

Typo in the docstring: superfluos -> superfluous
-- 
Bernt

Re: [PATCH] Wash output of org-encrypt-entry, take 3

[Bernt Hansen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> With a gpg executable with default settings, org-encrypt-entry produces
> output like this:
>
>  -----BEGIN PGP MESSAGE-----
>  Version: GnuPG v1.4.10 (GNU/Linux)
>
>  jA0EAwMCBWZVym6QMPVgyTxreTb1AEL3uTO+qCh2lR9/Qxk4nEMpPr9/RwNk95Gb
>  slUra9X+N+qSWghEHvvxY0Ol8Yw9Ko4n7JVhHFs=
>  =E4vw
>  -----END PGP MESSAGE-----
>
> The first line (Version:...) can change from machine to machine and over
> time (as gpg is updated with a new version.) This is problematic when
> the file is stored under version control, because as you decrypt and
> encrypt an entry that line will change and create differences among the
> file on the workspace and the file stored on VC.
>
> Second, the empty line just wastes space and it is plain ugly once we
> remove the first one with the Version text.
>
> Finally, on some systems (mostly Windows) depending on how your Emacs
> and gpg are configured, ^M characters may appear at the end of every
> line of gpg output once it is inserted on the Emacs buffer. This happens
> when the buffer uses Unix line-endings but gpg uses DOS line-endings.
>
> The patch removes all that junk from the encrypted text just before it
> is inserted on the buffer.
>
> I'm assuming that the transformations made by this patch are
> uncontroversial and desirable. If anyone actually prefers to keep that
> noise on his encrypted org entries, an alternative implementation that
> uses a configurable list of regexps is trivial to implement, but then
> every user would have to do some job for achieving the same result.

<patch snipped>

Other than the typo in the docstring this patch seems to work as
advertised with my minimal testing on GNU Emacs 23.2.1
(i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven,
modified by Debian

Regards,
-- 
Bernt

Re: [PATCH] Wash output of org-encrypt-entry, take 3

[Julien Danjou]

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

On Fri, Mar 18 2011, Óscar Fuentes wrote:

> The first line (Version:...) can change from machine to machine and over
> time (as gpg is updated with a new version.) This is problematic when
> the file is stored under version control, because as you decrypt and
> encrypt an entry that line will change and create differences among the
> file on the workspace and the file stored on VC.

This is true only if you modify the content of the entry, so I'm not
sure there's a real harm done here.

> Second, the empty line just wastes space and it is plain ugly once we
> remove the first one with the Version text.

This line is required by the protocol.

> Finally, on some systems (mostly Windows) depending on how your Emacs
> and gpg are configured, ^M characters may appear at the end of every
> line of gpg output once it is inserted on the Emacs buffer. This happens
> when the buffer uses Unix line-endings but gpg uses DOS line-endings.

I do not feel the right place and/or way to fix and encoding bug.

> +(defun org-crypt-wash-encrypted-string (str)
> +  "Remove superfluos and annoying text from the encrypted string."
> +  (with-temp-buffer
> +    (insert str)
> +    (goto-char (point-min))
> +    (while (re-search-forward "^Version:.*$\\|\^M\\|^\n" nil t)
> +      (replace-match ""))
> +    (buffer-string)))
> +

Ultimately, maybe simpler with `string-match'.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] Wash output of org-encrypt-entry, take 3

[David Maus]

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

At Mon, 21 Mar 2011 14:54:09 +0100,
Julien Danjou wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> On Fri, Mar 18 2011, Óscar Fuentes wrote:
> 
> > The first line (Version:...) can change from machine to machine and over
> > time (as gpg is updated with a new version.) This is problematic when
> > the file is stored under version control, because as you decrypt and
> > encrypt an entry that line will change and create differences among the
> > file on the workspace and the file stored on VC.
> 
> This is true only if you modify the content of the entry, so I'm not
> sure there's a real harm done here.

gpg --no-emit-version

Can be configured in gpg.conf.

> 
> > Second, the empty line just wastes space and it is plain ugly once we
> > remove the first one with the Version text.
> 
> This line is required by the protocol.

+1

> 
> > Finally, on some systems (mostly Windows) depending on how your Emacs
> > and gpg are configured, ^M characters may appear at the end of every
> > line of gpg output once it is inserted on the Emacs buffer. This happens
> > when the buffer uses Unix line-endings but gpg uses DOS line-endings.
> 
> I do not feel the right place and/or way to fix and encoding bug.

Don't think this is a bug at all: The gpg executable (as well as plain
Emacs btw ) uses whatever is deemed the line-ending signature of the
operating system. Washing out the ^M overrules the system settings and
enforces the assumption that lines are terminated by a single
newline. This sound like a bad idea: You might get the opposite
situation -- the Org file uses "DOS"-style CRLF and the encrypted
block doesn't.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]