* bug#3829: 23.0.96; Cannot read gpg file
@ 2009-07-12 12:47 Андрей Парамонов
2009-07-12 21:44 ` Daiki Ueno
2019-08-30 11:19 ` Lars Ingebrigtsen
0 siblings, 2 replies; 11+ messages in thread
From: Андрей Парамонов @ 2009-07-12 12:47 UTC (permalink / raw)
To: emacs-pretest-bug; +Cc: rfrancoise
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-12 12:47 bug#3829: 23.0.96; Cannot read gpg file Андрей Парамонов
@ 2009-07-12 21:44 ` Daiki Ueno
2009-07-13 7:01 ` Андрей Парамонов
2019-08-30 11:19 ` Lars Ingebrigtsen
1 sibling, 1 reply; 11+ messages in thread
From: Daiki Ueno @ 2009-07-12 21:44 UTC (permalink / raw)
To: Андрей Парамонов
Cc: emacs-pretest-bug, rfrancoise, 3829
>>>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-12 21:44 ` Daiki Ueno
@ 2009-07-13 7:01 ` Андрей Парамонов
2009-07-14 3:06 ` Daiki Ueno
0 siblings, 1 reply; 11+ messages in thread
From: Андрей Парамонов @ 2009-07-13 7:01 UTC (permalink / raw)
To: Daiki Ueno; +Cc: emacs-pretest-bug, rfrancoise, 3829
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-13 7:01 ` Андрей Парамонов
@ 2009-07-14 3:06 ` Daiki Ueno
2009-07-14 7:17 ` Glenn Morris
2009-07-14 10:51 ` Андрей Парамонов
0 siblings, 2 replies; 11+ messages in thread
From: Daiki Ueno @ 2009-07-14 3:06 UTC (permalink / raw)
To: Андрей Парамонов
Cc: emacs-pretest-bug, rfrancoise, 3829
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-14 3:06 ` Daiki Ueno
@ 2009-07-14 7:17 ` Glenn Morris
2009-07-14 7:25 ` Processed: " Emacs bug Tracking System
2009-07-14 10:51 ` Андрей Парамонов
1 sibling, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2009-07-14 7:17 UTC (permalink / raw)
To: Daiki Ueno; +Cc: 3829
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Processed: Re: bug#3829: 23.0.96; Cannot read gpg file
2009-07-14 7:17 ` Glenn Morris
@ 2009-07-14 7:25 ` Emacs bug Tracking System
0 siblings, 0 replies; 11+ messages in thread
From: Emacs bug Tracking System @ 2009-07-14 7:25 UTC (permalink / raw)
To: Glenn Morris; +Cc: Emacs Bugs
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-14 3:06 ` Daiki Ueno
2009-07-14 7:17 ` Glenn Morris
@ 2009-07-14 10:51 ` Андрей Парамонов
2009-07-14 19:59 ` Stefan Monnier
1 sibling, 1 reply; 11+ messages in thread
From: Андрей Парамонов @ 2009-07-14 10:51 UTC (permalink / raw)
To: Daiki Ueno; +Cc: emacs-pretest-bug, rfrancoise, 3829
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-14 10:51 ` Андрей Парамонов
@ 2009-07-14 19:59 ` Stefan Monnier
0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2009-07-14 19:59 UTC (permalink / raw)
To: Андрей Парамонов
Cc: rfrancoise, Daiki Ueno, 3829
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2009-07-12 12:47 bug#3829: 23.0.96; Cannot read gpg file Андрей Парамонов
2009-07-12 21:44 ` Daiki Ueno
@ 2019-08-30 11:19 ` Lars Ingebrigtsen
2020-08-04 19:27 ` Lars Ingebrigtsen
1 sibling, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2019-08-30 11:19 UTC (permalink / raw)
To: Андрей Парамонов
Cc: 3829, rfrancoise
Андрей Парамонов <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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2019-08-30 11:19 ` Lars Ingebrigtsen
@ 2020-08-04 19:27 ` Lars Ingebrigtsen
2020-08-04 19:43 ` Lars Ingebrigtsen
0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-04 19:27 UTC (permalink / raw)
To: Андрей Парамонов
Cc: rfrancoise, 3829
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#3829: 23.0.96; Cannot read gpg file
2020-08-04 19:27 ` Lars Ingebrigtsen
@ 2020-08-04 19:43 ` Lars Ingebrigtsen
0 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-04 19:43 UTC (permalink / raw)
To: Андрей Парамонов
Cc: 3829, rfrancoise
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-08-04 19:43 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-12 12:47 bug#3829: 23.0.96; Cannot read gpg file Андрей Парамонов
2009-07-12 21:44 ` Daiki Ueno
2009-07-13 7:01 ` Андрей Парамонов
2009-07-14 3:06 ` Daiki Ueno
2009-07-14 7:17 ` Glenn Morris
2009-07-14 7:25 ` Processed: " Emacs bug Tracking System
2009-07-14 10:51 ` Андрей Парамонов
2009-07-14 19:59 ` Stefan Monnier
2019-08-30 11:19 ` Lars Ingebrigtsen
2020-08-04 19:27 ` Lars Ingebrigtsen
2020-08-04 19:43 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.