bug#1471: marked as done (23.0.60; Visiting GnuPG-encrypted file yields "file exists, but cannot be read")

[don@donarmstrong.com (Emacs bug Tracking System)]

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


Your message dated Wed, 17 Dec 2008 11:21:35 +0900
with message-id <87hc538rtc.fsf@broken.deisui.org>
and subject line Re: bug#1471: 23.0.60; Visiting GnuPG-encrypted file yields "file exists, but cannot be read"
has caused the Emacs bug report #1471,
regarding 23.0.60; Visiting GnuPG-encrypted file yields "file exists, but cannot be read"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1471: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1471
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 6246 bytes --]

From: Eric Hanchrow <eric.hanchrow@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; Visiting GnuPG-encrypted file yields "file exists, but cannot be read"
Date: Tue, 02 Dec 2008 08:48:54 -0800
Message-ID: <87hc5mjzex.fsf@offby1.atm01.sea.blarg.net>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

At the shell:

  $ cd /usr/local/src/emacs-via-git/src/

create a tiny encrypted file.

  $ echo Fee fi fo fum | gpg --symmetric > decrypt-me.gpg
  gpg: gpg-agent is not available in this session

You can't see it in this transcript, but I typed a very short passphrase: "foo"

Proof that the file is indeed encrypted:

  $ cat decrypt-me.gpg 
  -----BEGIN PGP MESSAGE-----
  Version: GnuPG v1.4.9 (GNU/Linux)

  jA0EAwMCJkAO8t1a89pgySSta9bxO023orfaXtK+Y0RuUP+8ohMfpLLgVlYWiTeN
  sX8mKnE=
  =HGzp
  -----END PGP MESSAGE-----

Proof that I haven't forgotten the passphrase:

  $ gpg --decrypt < decrypt-me.gpg 
  gpg: CAST5 encrypted data
  gpg: gpg-agent is not available in this session
  Enter passphrase:                   gpg: encrypted with 1 passphrase
  Fee fi fo fum
  gpg: WARNING: message was not integrity protected

Now let's visit the file in emacs:
  $ ./emacs -Q -nw

I then typed C-x C-f decrypt-me.gpg RET.  Emacs prompted me for the
passphrase for symmetric encryption, as I'd expect.  I entered it, and
then instead of seeing "Fee fi fo fum" in the buffer, as I'd expected, I
saw an error in the echo area: "File exists, but cannot be read".

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/src/emacs-via-git/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.9 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2008-12-01 on debian
configured using `configure  '--enable-maintainer-mode' '--with-xpm=yes' '--with-jpeg=no' '--with-gif=no' '--with-tiff=no' '--with-xft' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-netsplit-mode: t
  smerge-mode: t
  eldoc-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-log-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  desktop-save-mode: t
  recentf-mode: t
  display-time-mode: t
  global-auto-revert-mode: t
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
RET C-x k RET ESC x r e p o r t - e m a c s - b TAB 
RET C-g C-x b i n i RET ESC < C-s g p g C-s C-s C-s 
C-s C-a C-s e a s y C-s C-a ESC x ESC p RET

Recent messages:
Partially completed
/home/erich/private/: 0% (0/19181)
File exists, but cannot be read
/home/erich/private/: 0% (0/19181)
File exists, but cannot be read
/home/erich/private/: 0% (0/19181)
File exists, but cannot be read
Quit
Mark set
Mark saved where search started [2 times]

-- 
If you can't change your underwear, can you be sure you have any?



[-- Attachment #3: Type: message/rfc822, Size: 3530 bytes --]

From: Daiki Ueno <ueno@unixuser.org>
To: Rudi Schlatte <rudi@constantly.at>
Cc: 1471-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1471: 23.0.60; Visiting GnuPG-encrypted file yields "file exists, but cannot be read"
Date: Wed, 17 Dec 2008 11:21:35 +0900
Message-ID: <87hc538rtc.fsf@broken.deisui.org>


>>>>> In <84E12317-4EF9-48A6-9D17-F9ABAB090617@constantly.at> 
>>>>>	Rudi Schlatte <rudi@constantly.at> wrote:
> Just as additional datapoint: I saw the reported behavior too, at
> roughly the same time as the original report, but not in an emacs
> compiled from yesterday's git mirror.  Opening a file encrypted with
> gpg works as expected again for me again.

Thanks for the information.  I also got the same report from Eric
privately.  He said that the bug seems like fixed at some time between
the following dates:

Date:   Tue Dec 2 01:12:39 2008 +0000
Date:   Wed Dec 3 21:57:10 2008 +0000

Since I had not added any change (except a wording patch) in that time
span, I suspect other part of Emacs affected the behavior.

Now I'm trying to close this bug.

Regards,
-- 
Daiki Ueno