GNU bug report logs - #3829
23.0.96; Cannot read gpg file

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 3829 in the body.
You can then email your comments to 3829 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Андрей Парамонов <cmr.pent <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Cc: rfrancoise <at> debian.org
Subject: 23.0.96; Cannot read gpg file
Date: Sun, 12 Jul 2009 16:47:28 +0400

[Message part 1 (text/plain, inline)]

To reproduce:

0) emacs -Q

1) C-x C-f attached file

2) Emacs says:
File exists, but cannot be read

I'm ready to provide any additional info,
Andrey Paramonov

In GNU Emacs 23.0.96.1 (i486-pc-linux-gnu, GTK+ Version 2.16.4)
 of 2009-07-11 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20090710-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--build' 'i486-linux-gnu' '--host'
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.96/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.96/site-lisp:/usr/share/emacs/site-lisp'
'--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu'
'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN
-DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed'
'CPPFLAGS=''

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: ru_RU.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  delete-selection-mode: t
  show-paren-mode: t
  pc-selection-mode: t
  pretty-control-l-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-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
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
File exists, but cannot be read

===File ~/trusted.gpg=======================================
============================================================

[trusted.gpg (application/octet-stream, attachment)]

Message #10 received at 3829 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Daiki Ueno <ueno <at> unixuser.org>
Cc: 3829 <at> debbugs.gnu.org
Subject: Re: 23.0.96; Cannot read gpg file
Date: Sun, 12 Jul 2009 13:34:01 -0400

Hi Daiki,

Could you take a look at bug#3829?  Thanks:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3829

Message #15 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Daiki Ueno <ueno <at> unixuser.org>
To: Андрей Парамонов <cmr.pent <at> gmail.com>
Cc: 3829 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org,
        rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Mon, 13 Jul 2009 06:44:28 +0900

>>>>> In <5f0660120907120547o33e6480an6eab53a9a79b4a2e <at> mail.gmail.com> 
>>>>>	Андрей Парамонов <cmr.pent <at> gmail.com> wrote:
> To reproduce:

> 0) emacs -Q

> 1) C-x C-f attached file

> 2) Emacs says:
> File exists, but cannot be read

That is because the file contains only public keys instead of encrypted
content.  Handling such a file in a fancy way would be a feature request
after the release.

How about M-x find-file-literally if you just want to see the binary
content?

Regards,
-- 
Daiki Ueno

Message #25 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Андрей Парамонов <cmr.pent <at> gmail.com>
To: Daiki Ueno <ueno <at> unixuser.org>
Cc: 3829 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org,
        rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Mon, 13 Jul 2009 11:01:22 +0400

2009/7/13 Daiki Ueno <ueno <at> unixuser.org>:
> How about M-x find-file-literally if you just want to see the binary
> content?
>

Yes, this works (that's the behavior I expected). However, some other
functions (i.e. mail-attach-file) do not work. Also, the message "File
exists, but cannot be read" is a bit vague to me (file could not be
read due to many reasons, i.e. file permissions).

Is it possible to fall back to find-file-literally behavior, if a gpg
file cannot be opened with the new method?

Andrey

Message #35 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Daiki Ueno <ueno <at> unixuser.org>
To: Андрей Парамонов <cmr.pent <at> gmail.com>
Cc: 3829 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org,
        rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 14 Jul 2009 12:06:46 +0900

severity 3829 wishlist
thanks

>>>>> In <5f0660120907130001v1c9b83e9nb278e847140653a8 <at> mail.gmail.com> 
>>>>>	Андрей Парамонов <cmr.pent <at> gmail.com> wrote:
> 2009/7/13 Daiki Ueno <ueno <at> unixuser.org>:
> > How about M-x find-file-literally if you just want to see the binary
> > content?
> >

> Yes, this works (that's the behavior I expected). However, some other
> functions (i.e. mail-attach-file) do not work.

Well, please elaborate what is your problem...  Do you really want to
attach binary files with mail-attach-file?  I think it is not feasible
and most people use uuencode before attaching.

I believe that Emacs commands which read binary contents are carefully
designed whether or not to do automatic decoding (i.e. mml-attach-file
in Gnus).  If you find _real problems_, please let me know.

> Also, the message "File exists, but cannot be read" is a bit vague to
> me (file could not be read due to many reasons, i.e. file
> permissions).

Agreed.  Unfortunatelly the improvement is not as easy to implement as
expected.  This would also be a feature request.

> Is it possible to fall back to find-file-literally behavior, if a gpg
> file cannot be opened with the new method?

Though there is no fall back mechanism, you can stop it manually by:

C-u -1 M-x auto-encryption-mode

Regards,
-- 
Daiki Ueno

Message #43 received at 3829 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Daiki Ueno <ueno <at> unixuser.org>
Cc: 3829 <at> debbugs.gnu.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 14 Jul 2009 03:17:20 -0400

severity 3829 wishlist
stop

Daiki Ueno wrote:

> severity 3829 wishlist
> thanks

Just in case you did not know, such commands have no effect unless you
cc the control server (bcc'd in this message).

Message #50 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Андрей Парамонов <cmr.pent <at> gmail.com>
To: Daiki Ueno <ueno <at> unixuser.org>
Cc: 3829 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org,
        rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 14 Jul 2009 14:51:26 +0400

2009/7/14 Daiki Ueno <ueno <at> unixuser.org>:
> Well, please elaborate what is your problem...  Do you really want to
> attach binary files with mail-attach-file?  I think it is not feasible
> and most people use uuencode before attaching.
>
> I believe that Emacs commands which read binary contents are carefully
> designed whether or not to do automatic decoding (i.e. mml-attach-file
> in Gnus).  If you find _real problems_, please let me know.
>

The real problem is that I couldn't even attach the problematic file
via Emacs, so I had to use Gmail web interface for reporting the bug.
Don't know if it can be considered "real" though.

Thanks for your effort,
Andrey

Message #60 received at 3829 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 3829 <at> debbugs.gnu.org, Daiki Ueno <ueno <at> unixuser.org>,
        rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 14 Jul 2009 15:59:53 -0400

> The real problem is that I couldn't even attach the problematic file
> via Emacs, so I had to use Gmail web interface for reporting the bug.
> Don't know if it can be considered "real" though.

That's actually a different problem: the default MUA to compose email
doesn't really know how to attach files.  I've just changed it to
message-mode which can do it much better.


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: rfrancoise <at> debian.org, 3829 <at> debbugs.gnu.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Fri, 30 Aug 2019 13:19:57 +0200

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> To reproduce:
>
> 0) emacs -Q
>
> 1) C-x C-f attached file
>
> 2) Emacs says:
> File exists, but cannot be read

(The user included a trusted.gpg file; which is a key ring.)

The problem here is that there are two common uses of the .gpg suffix.

Emacs assumes that all files that end with .gpg are encrypted files, and
will error out dramatically when trying to read those files.  The only
way the user has to look at them is with `M-x find-file-literally'.

But .gpg is also a common suffix for key ring files.

Emacs could be more helpful here and check the first few bytes of the
file to see what type it is.

https://lists.gnupg.org/pipermail/gnupg-users/2013-September/047725.html

But that doesn't seem to be totally trivial.

Should Emacs treat these as normal files if gpg gives an error message
when trying to open them?

---
Error while decrypting with "/usr/bin/gpg2":

gpg: decrypt_message failed: Unexpected error
---

That doesn't seem very logical, either...

Anybody got any ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 3829 <at> debbugs.gnu.org, rfrancoise <at> debian.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 04 Aug 2020 21:27:33 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Emacs assumes that all files that end with .gpg are encrypted files, and
> will error out dramatically when trying to read those files.  The only
> way the user has to look at them is with `M-x find-file-literally'.
>
> But .gpg is also a common suffix for key ring files.

I had a look at this again, and there doesn't really seem to be a good
set of magic bytes for these files.  "\x01gpg" is used by some, and
"\x99\x01" for others, apparently, and ... a bunch of other two-byte
codes.  But there apparently isn't anything that ensures what the byte
prefixes are in encoded files?  (I'm trying to understand the logic in
"file"...)

On the other hand, we could just let gpg try to decrypt the data and if
we get

gpg -d /tmp/trusted.gpg 
gpg: decrypt_message failed: Unexpected error

then we can just take that as a hint that it's not encrypted data and
then insert the bytes instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: rfrancoise <at> debian.org, 3829 <at> debbugs.gnu.org
Subject: Re: bug#3829: 23.0.96; Cannot read gpg file
Date: Tue, 04 Aug 2020 21:43:46 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> On the other hand, we could just let gpg try to decrypt the data and if
> we get
>
> gpg -d /tmp/trusted.gpg 
> gpg: decrypt_message failed: Unexpected error
>
> then we can just take that as a hint that it's not encrypted data and
> then insert the bytes instead.

I've now done this on the trunk.  I think it's a better, less annoying
behaviour than before...  probably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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