bug#3829: 23.0.96; Cannot read gpg file

bug#3829: 23.0.96; Cannot read gpg file

[Андрей Парамонов]

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

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=======================================
============================================================

[-- Attachment #2: trusted.gpg --]
[-- Type: application/octet-stream, Size: 25671 bytes --]

bug#3829: 23.0.96; Cannot read gpg file

[Daiki Ueno]

>>>>> In <5f0660120907120547o33e6480an6eab53a9a79b4a2e@mail.gmail.com> 
>>>>>	Андрей Парамонов <cmr.pent@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

bug#3829: 23.0.96; Cannot read gpg file

[Андрей Парамонов]

2009/7/13 Daiki Ueno <ueno@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

bug#3829: 23.0.96; Cannot read gpg file

[Daiki Ueno]

severity 3829 wishlist
thanks

>>>>> In <5f0660120907130001v1c9b83e9nb278e847140653a8@mail.gmail.com> 
>>>>>	Андрей Парамонов <cmr.pent@gmail.com> wrote:
> 2009/7/13 Daiki Ueno <ueno@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

bug#3829: 23.0.96; Cannot read gpg file

[Glenn Morris]

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).

Processed: Re: bug#3829: 23.0.96; Cannot read gpg file

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 3829 wishlist
bug#3829: 23.0.96; Cannot read gpg file
Severity set to `wishlist' from `normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#3829: 23.0.96; Cannot read gpg file

[Андрей Парамонов]

2009/7/14 Daiki Ueno <ueno@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

bug#3829: 23.0.96; Cannot read gpg file

[Stefan Monnier]

> 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

bug#3829: 23.0.96; Cannot read gpg file

[Lars Ingebrigtsen]

Андрей Парамонов <cmr.pent@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

bug#3829: 23.0.96; Cannot read gpg file

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#3829: 23.0.96; Cannot read gpg file

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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