GNU bug report logs - #20634
25.0.50; Conflict between Tramp and EasyPG

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20634 in the body.
You can then email your comments to 20634 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; Conflict between Tramp and EasyPG
Date: Sat, 23 May 2015 17:23:38 +0200

Hi there,

I use EasyPG for transparent access of encrypted files with
extension .gpg.  If I copy an encrypted file, say test.gpg, via ssh
(Tramp) to a remote location, then I’m asked what public key to use
for encryption (none for symmetric encryption), and the encrypted
file is encrypted again, rendering it useless from within Emacs.
(If I open the remote file via Tramp, the outer layer of encryption
is removed, and I see the original encrypted file.)

Recipe:

0. Encrypt a file: test.gpg

1. emacs -Q

2. Open directory of test.gpg (C-x C-f).

3. Copy (C) the file to a remote location
   (e.g., /user <at> localhost:/tmp).

   The key chooser opens.  Copy is cancelled if I cancel the choice.
   Otherwise, a remote file is created, which is not a copy but an
   encrypted file with two layers of encryption.

4. Open the remote file (C-x C-f /user <at> localhost:/tmp/test.gpg).
   Observe encrypted data.

In contrast, if I copy an encrypted file to a local directory, it is
copied without extra encryption.

Note also that if I copy a plaintext file (test.txt) locally to one
with gpg extension (test.gpg), it remains a plaintext file.  If I
copy that to a remote location, it gets encrypted.  This may be a
bug or a feature, but is certainly inconsistent behavior.

Best wishes
Jens

Message #8 received at 20634 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
Cc: 20634 <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Sun, 24 May 2015 18:24:04 +0200

Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:

> Hi there,

Hi Jens,

> I use EasyPG for transparent access of encrypted files with
> extension .gpg.  If I copy an encrypted file, say test.gpg, via ssh
> (Tramp) to a remote location, then I’m asked what public key to use
> for encryption (none for symmetric encryption), and the encrypted
> file is encrypted again, rendering it useless from within Emacs.
> (If I open the remote file via Tramp, the outer layer of encryption
> is removed, and I see the original encrypted file.)

Thanks for the report; I could reproduce the problem using your
recipe. Could you, please, check whether the following patch fixes the
problem?

--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/tramp/lisp/tramp-sh.el.~master~	2015-05-24 18:17:53.333961247 +0200
--- /home/albinus/src/tramp/lisp/tramp-sh.el	2015-05-24 18:13:15.299684599 +0200
***************
*** 2122,2136 ****
  KEEP-DATE is non-nil if NEWNAME should have the same timestamp as FILENAME."
    ;; We must disable multibyte, because binary data shall not be
    ;; converted.  We don't want the target file to be compressed, so we
!   ;; let-bind `jka-compr-inhibit' to t.
!   ;; We remove `tramp-file-name-handler' from
    ;; `inhibit-file-name-handlers'; otherwise the file name handler for
    ;; `insert-file-contents' might be deactivated in some corner cases.
    (let ((coding-system-for-read 'binary)
  	(coding-system-for-write 'binary)
  	(jka-compr-inhibit t)
  	(inhibit-file-name-handlers
! 	 (remq 'tramp-file-name-handler inhibit-file-name-handlers)))
      (with-temp-file newname
        (set-buffer-multibyte nil)
        (insert-file-contents-literally filename)))
--- 2122,2137 ----
  KEEP-DATE is non-nil if NEWNAME should have the same timestamp as FILENAME."
    ;; We must disable multibyte, because binary data shall not be
    ;; converted.  We don't want the target file to be compressed, so we
!   ;; let-bind `jka-compr-inhibit' to t.  `epa-file-handler' shall not
!   ;; be called either.  We remove `tramp-file-name-handler' from
    ;; `inhibit-file-name-handlers'; otherwise the file name handler for
    ;; `insert-file-contents' might be deactivated in some corner cases.
    (let ((coding-system-for-read 'binary)
  	(coding-system-for-write 'binary)
  	(jka-compr-inhibit t)
  	(inhibit-file-name-handlers
! 	 (cons epa-file-handler
! 	       . (remq 'tramp-file-name-handler inhibit-file-name-handlers))))
      (with-temp-file newname
        (set-buffer-multibyte nil)
        (insert-file-contents-literally filename)))
***************
*** 3205,3211 ****
  	 (if (fboundp 'find-buffer-file-type)
  	     (symbol-function 'find-buffer-file-type)
  	   nil))
! 	(inhibit-file-name-handlers '(jka-compr-handler image-file-handler))
  	(inhibit-file-name-operation 'insert-file-contents))
      (unwind-protect
  	(progn
--- 3206,3213 ----
  	 (if (fboundp 'find-buffer-file-type)
  	     (symbol-function 'find-buffer-file-type)
  	   nil))
! 	(inhibit-file-name-handlers
! 	 '(epa-file-handler image-file-handler jka-compr-handler))
  	(inhibit-file-name-operation 'insert-file-contents))
      (unwind-protect
  	(progn
--8<---------------cut here---------------end--------------->8---

> Note also that if I copy a plaintext file (test.txt) locally to one
> with gpg extension (test.gpg), it remains a plaintext file.  If I
> copy that to a remote location, it gets encrypted.  This may be a
> bug or a feature, but is certainly inconsistent behavior.

It is rather a feature (a copy operation shall not change the file
contents). The above patch shall fix this as well.

> Best wishes
> Jens

Best regards, Michael.

Message #11 received at 20634 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
Cc: 20634 <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Mon, 25 May 2015 12:47:56 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Jens,

> Thanks for the report; I could reproduce the problem using your
> recipe. Could you, please, check whether the following patch fixes the
> problem?

There was a typo in the patch. I've fixed it in the Emacs repository;
could you please test that version?

>> Best wishes
>> Jens

Best regards, Michael.

Message #14 received at 20634 <at> debbugs.gnu.org (full text, mbox):

From: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 20634 <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Mon, 25 May 2015 18:32:04 +0200

On 2015-05-25, at 12:47, Michael Albinus wrote:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> Hi Jens,
>
>> Thanks for the report; I could reproduce the problem using your
>> recipe. Could you, please, check whether the following patch fixes the
>> problem?
>
> There was a typo in the patch. I've fixed it in the Emacs repository;
> could you please test that version?

Hi Michael,

many thanks for your quick reply.  Unfortunately, that does not
solve my issue.  The new file still gets encrypted a second time.
I traced what happens:

In tramp-do-copy-or-rename-file-via-buffer, the call to
with-temp-file results in a call to epa-file-handler, where the
argument operation has the value 'write-region.  In
epa-file-handler, op is let-bound to 'epa-file-write-region, which
gets called without looking at inhibit-file-name-handlers.

I also tried to let-bind inhibit-file-name-operation to
'write-region in tramp-do-copy-or-rename-file-via-buffer, but that
did not work either.

Best wishes
Jens

Message #17 received at 20634 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
Cc: 20634 <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Mon, 25 May 2015 20:35:45 +0200

Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:

> Hi Michael,

Hi Jens,

> many thanks for your quick reply.  Unfortunately, that does not
> solve my issue.  The new file still gets encrypted a second time.

Indeed, I haven't tested all use cases :-(

I've pushed an improved version of the patch; could you please check?
That seems to work for me.

> Best wishes
> Jens

Best regards, Michael.

Message #22 received at 20634-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
Cc: 20634-done <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Tue, 26 May 2015 16:17:30 +0200

Version: 25.1

Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:

> Hi Michael,

Hi Jens,

> fixed :-)

Thanks for confirmation. I'm closing the ticket.

> Many thanks
> Jens

Best regards, Michael.

Message #25 received at 20634 <at> debbugs.gnu.org (full text, mbox):

From: Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org>
To: 20634 <at> debbugs.gnu.org
Subject: Re: bug#20634: 25.0.50; Conflict between Tramp and EasyPG
Date: Tue, 26 May 2015 16:31:35 +0200

> I've pushed an improved version of the patch; could you please check?
> That seems to work for me.

Hi Michael,

fixed :-)

Many thanks
Jens

P.S. My first reply went to Michael only.  Sorry about that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.