bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

Package: Emacs
Version: 27.0.50


When untarring a file whose contents include a GPG keyring named with
a `.gpg` extension, `tar-untar-buffer` ends up trying to encrypt the
keyring because the `write-region` call for this file gets handed to
`epa-file-write-region`.


        Stefan



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-04-18 built on pastel
Repository revision: 058df7a477bfd9798fc96332dd9a7adcd4a7c2b0
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)

Recent messages:
user-error: No cross-reference here
Warning: hide-sublevels is obsolete!
Mark saved where search started [3 times]
Making completion list...
Warning: hide-sublevels is obsolete!
Mark saved where search started
Mark set
Mark saved where search started
<nil> <down-mouse-3> is undefined
<nil> <mouse-3> is undefined

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Package: Emacs
> Version: 27.0.50
>
>
> When untarring a file whose contents include a GPG keyring named with
> a `.gpg` extension, `tar-untar-buffer` ends up trying to encrypt the
> keyring because the `write-region` call for this file gets handed to
> `epa-file-write-region`.
>
>
>         Stefan
>
>
>
> In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2019-04-18 built on pastel
> Repository revision: 058df7a477bfd9798fc96332dd9a7adcd4a7c2b0
> Repository branch: work
> Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
> System Description: Debian GNU/Linux 9 (stretch)
>
> Recent messages:
> user-error: No cross-reference here
> Warning: hide-sublevels is obsolete!
> Mark saved where search started [3 times]
> Making completion list...
> Warning: hide-sublevels is obsolete!
> Mark saved where search started
> Mark set
> Mark saved where search started
> <nil> <down-mouse-3> is undefined
> <nil> <mouse-3> is undefined

I've tried wrapping the call to `write-region` with `(let
(file-name-handler-alist) ...)` in tar-mode.el:548 and it fixes the
problem. On the other hand, it breaks TRAMP support. Would it be OK to
just remove the `epa-file-handler` from `file-name-handler-alist` while extracting?

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

> Would it be OK to just remove the `epa-file-handler` from
> `file-name-handler-alist` while extracting?

I don't like this idea.  How does jka-compr do it?


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Would it be OK to just remove the `epa-file-handler` from
>> `file-name-handler-alist` while extracting?
>
> I don't like this idea.  How does jka-compr do it?
>
>
>         Stefan

(My attempt at understanding what's causing the issue)

It looks like `jka-compr-write-region` does not do any compression if
`file`'s extension does not match any of the extensions defined in
`jka-compr-compression-info-list`. Writing to a file ending in ".gpg"
just uses `epa-file-handler`, then.

I found that `tar-copy` has the same problem that `tar-untar-buffer`
has. However, `tar-copy` has a small check where if the source file is
compressed and the destination file should be compressed, the jka-compr
file handler is disabled, as no conversion needs to be done. Maybe
something similar could be done for .gpg files. If the file inside the
tarfile is already encrypted and it is being extracted to
<somewhere>.gpg, then the regular `write-region` should be used
(i.e. just copy bytes from one place to another).

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

> It looks like `jka-compr-write-region` does not do any compression if
> `file`'s extension does not match any of the extensions defined in
> `jka-compr-compression-info-list`. Writing to a file ending in ".gpg"
> just uses `epa-file-handler`, then.

Yes, of course, but the question is what it does when the tar's content
has a name that ends in `.gz` or something like that.  I now see that it
has a hack in write-region which looks at the contents to detect if it's
already compressed.

[ I guess this can lead to problem in odd cases such as when you
  manipulate a file of type "foo.mypkg" where mypkg is defined as
  a format that is always gz-compressed: if you save it as
  "foo.mypkg.gz" jka-compr won't re-compress it, but then when you open
  it, it will uncompress it before trying to handle it as a ".mypkg" at
  which point the mypkg tool might signal an error because it expected
  the ".mypkg" to be compressed.  If this will ever happen is
  anyone's guess, but it look sufficiently contrived that I'm not
  too worried.  ]

> I found that `tar-copy` has the same problem that `tar-untar-buffer`
> has. However, `tar-copy` has a small check where if the source file is
> compressed and the destination file should be compressed, the jka-compr
> file handler is disabled, as no conversion needs to be done. Maybe
> something similar could be done for .gpg files. If the file inside the
> tarfile is already encrypted and it is being extracted to
> <somewhere>.gpg, then the regular `write-region` should be used
> (i.e. just copy bytes from one place to another).

I think there should be a way to tell `write-region` that the content
should be written as-is into the file (and hence override jka-compr and
epa but not tramp).  I don't think there is such a thing yet, tho, so
we'll have to invent it.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

> I think there should be a way to tell `write-region` that the content
> should be written as-is into the file (and hence override jka-compr and
> epa but not tramp).  I don't think there is such a thing yet, tho, so
> we'll have to invent it.

Could this be achieved by doing:

(let ((inhibit-file-name-handlers '(jka-compr-handler epa-file-handler))
      (inhibit-file-name-operation 'write-region))
  ...)

or is there a reason why a specific mechanism for this is needed?

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

> (let ((inhibit-file-name-handlers '(jka-compr-handler epa-file-handler))

I don't like hard-coding a specific set of file-name-handler names.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (let ((inhibit-file-name-handlers '(jka-compr-handler epa-file-handler))
>
> I don't like hard-coding a specific set of file-name-handler names.

Ok, I see. How about:

(defmacro with-literal-file-name-handlers (&rest body)
  `(let* ((allowed-file-name-handlers '(tramp-completion-file-name-handler
					tramp-file-name-handler
					file-name-non-special))
	  (file-name-handler-alist
	   (seq-filter (lambda (c) (memq (cdr c) allowed-file-name-handlers))
		       file-name-handler-alist)))
     ,@body))

I realize that in this case I'm hard-coding the specific
file name handlers that *can* be used. I'm not sure how to express "only
use these file handlers" without explicitly mentioning them. I'm also
not sure if we only care for `tramp-file-name-handler`, or for the three
I listed above.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

> I realize that in this case I'm hard-coding the specific
> file name handlers that *can* be used.

Exactly, it's no better.

> I'm not sure how to express "only use these file handlers" without
> explicitly mentioning them.

Instead, you should state the property you want, and then let each
file-name-handler decide how to handle that property.  E.g.:

    (let ((write-region-provides-raw-file-contents t))
      (write-region ...))

Of course, the problem here is that by using dynamic scoping, this var
will affect all write-regions that will take place during this call,
which might lead to more problems.

Maybe it would be better to have it as an argument to `write-region`, or
to introduce a new function?

Or maybe, not use `write-region` but `copy-file` instead (which already
provides the expected semantics (i.e. it doesn't (un)compress or
(en/de)crypt, IIUC).


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I realize that in this case I'm hard-coding the specific
>> file name handlers that *can* be used.
>
> Exactly, it's no better.
>
>> I'm not sure how to express "only use these file handlers" without
>> explicitly mentioning them.
>
> Instead, you should state the property you want, and then let each
> file-name-handler decide how to handle that property.  E.g.:
>
>     (let ((write-region-provides-raw-file-contents t))
>       (write-region ...))
>
> Of course, the problem here is that by using dynamic scoping, this var
> will affect all write-regions that will take place during this call,
> which might lead to more problems.

I see, I hadn't realized that tar-mode still used dynamic scoping (I
imagine converting it to lexical is a lot of work).

> Maybe it would be better to have it as an argument to `write-region`, or
> to introduce a new function?
>
> Or maybe, not use `write-region` but `copy-file` instead (which already
> provides the expected semantics (i.e. it doesn't (un)compress or
> (en/de)crypt, IIUC).

It looks like `copy-file` only deals with files and not buffers, so we
would need to find a way to use it from tar-mode. Looking at the source
in fileio.c, it also seems like it uses `find-file-name-handler` for
`FILE` or `NEWNAME`, so it's possible it won't be useful for us.

If we added a new argument to `write-region` like you mentioned, say
`RAW`, could we then use symbol properties to decide whether the found
file name handler can be used or not? Like so:

(put 'jka-compr-handler 'provides-raw-file-contents nil)
(put 'epa-file-handler 'provides-raw-file-contents nil)

(put 'tramp-file-name-handler 'provides-raw-file-contents t)
(put 'tramp-completion-file-name-handler 'provides-raw-file-contents t)
(put 'file-name-non-special 'provides-raw-file-contents t)

The downside being that anyone adding a new file name handler must
remember to set the property to t if needed.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

>> Instead, you should state the property you want, and then let each
>> file-name-handler decide how to handle that property.  E.g.:
>>
>>     (let ((write-region-provides-raw-file-contents t))
>>       (write-region ...))
>>
>> Of course, the problem here is that by using dynamic scoping, this var
>> will affect all write-regions that will take place during this call,
>> which might lead to more problems.
>
> I see, I hadn't realized that tar-mode still used dynamic scoping (I
> imagine converting it to lexical is a lot of work).

All files use dynamically scoped variables.  `lexical-binding` only
determines the scoping to use for those vars that aren't declared as
dynamically scoped.  The fact that tar-mode.el hasn't (yet) been
converted to use lexical-binding has no effect on the above example
(because I presume there that write-region-provides-raw-file-contents
would be a variable declared somewhere in files.el as being dynamically
scoped, like file-name-handler-alist).

>> Maybe it would be better to have it as an argument to `write-region`, or
>> to introduce a new function?
>>
>> Or maybe, not use `write-region` but `copy-file` instead (which already
>> provides the expected semantics (i.e. it doesn't (un)compress or
>> (en/de)crypt, IIUC).
>
> It looks like `copy-file` only deals with files and not buffers, so we
> would need to find a way to use it from tar-mode.

I know.  Maybe we can extend it to allow the source to be a buffer?

> Looking at the source in fileio.c, it also seems like it uses
> `find-file-name-handler` for `FILE` or `NEWNAME`, so it's possible it
> won't be useful for us.

Not sure why you think that could make it not useful.

> If we added a new argument to `write-region` like you mentioned, say
> `RAW`, could we then use symbol properties to decide whether the found
> file name handler can be used or not?

No, no: we do want the file-name-handler to be called.
We just want it to receive enough info to determine how it will do its
job (e.g. whether it needs to compress/encrypt the data or not).


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Federico Tedin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> All files use dynamically scoped variables.  `lexical-binding` only
> determines the scoping to use for those vars that aren't declared as
> dynamically scoped.  The fact that tar-mode.el hasn't (yet) been
> converted to use lexical-binding has no effect on the above example
> (because I presume there that write-region-provides-raw-file-contents
> would be a variable declared somewhere in files.el as being dynamically
> scoped, like file-name-handler-alist).

Ok, didn't know this. I have some reading to do regarding the specifics
of `lexical-binding` and how it affects (or not) defvar, defcustom, etc.

> I know.  Maybe we can extend it to allow the source to be a buffer?
>
>> Looking at the source in fileio.c, it also seems like it uses
>> `find-file-name-handler` for `FILE` or `NEWNAME`, so it's possible it
>> won't be useful for us.
>
> Not sure why you think that could make it not useful.
>
>> If we added a new argument to `write-region` like you mentioned, say
>> `RAW`, could we then use symbol properties to decide whether the found
>> file name handler can be used or not?
>
> No, no: we do want the file-name-handler to be called.
> We just want it to receive enough info to determine how it will do its
> job (e.g. whether it needs to compress/encrypt the data or not).

Both my points were made assuming that we didn't want the file-name-handlers
to be called; but now that you mention that we do want them to be
called, they no longer apply.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 09 May 2019 20:24:02 -0400
> Cc: 35495@debbugs.gnu.org, Daiki Ueno <ueno@unixuser.org>
> 
> I think there should be a way to tell `write-region` that the content
> should be written as-is into the file (and hence override jka-compr and
> epa but not tramp).

It isn't clear to me how you distinguish between the file-name
handlers that should and shouldn't be disabled here.  I assume you are
aware that Tramp doesn't necessarily send the file's contents verbatim
over the wire?

One way of teaching find-file-name-handler to distinguish between
various handlers is to have some properties on the handlers' symbols.
Then we could bind some variable to the list of properties to filter
out "unwanted" handlers.  But we should come up with a useful list of
properties first, and for that we need a clear distinction I ask about
above.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

> It isn't clear to me how you distinguish between the file-name
> handlers that should and shouldn't be disabled here.

Each file-name handler will make that decision on its own.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: federicotedin@gmail.com,  35495@debbugs.gnu.org,  ueno@unixuser.org
> Date: Sat, 11 May 2019 08:55:55 -0400
> 
> > It isn't clear to me how you distinguish between the file-name
> > handlers that should and shouldn't be disabled here.
> 
> Each file-name handler will make that decision on its own.

Will each handler also write code to implement that decision?  If so,
we can stop being bothered by that issue.  But if someone of us will
have to implement that decision, the question still stands, doesn't
it?

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

>> > It isn't clear to me how you distinguish between the file-name
>> > handlers that should and shouldn't be disabled here.
>> Each file-name handler will make that decision on its own.
> Will each handler also write code to implement that decision?

Well, the handler will execute code rather than write it, but yes,
someone will have to change jka and epa to implement this new behavior
of write-region.

> If so, we can stop being bothered by that issue.  But if someone of us
> will have to implement that decision, the question still stands,
> doesn't it?

Hmm... I think you're referring to the question of what this new
"write-region-provides-raw-file-contents" should precisely mean, so that
maintainers of file-name-handlers can decide how to implement it.

Here's one attempt: "the data provided to write-region reflects the actual
bytes that should be placed into the file rather than the data returned
by `insert-file-contents`".

Maybe another way to define it would be: "the data provided to
write-region reflects the data one would like to get from
`insert-file-contents-literally` rather than that returned by
`insert-file-contents`"

And that made me discover that we have another occurrence of the same
problem in `insert-file-contents-literally`:

    (defun insert-file-contents-literally (filename &optional visit beg end replace)
      "Like `insert-file-contents', but only reads in the file literally.
    See `insert-file-contents' for an explanation of the parameters.
    A buffer may be modified in several ways after reading into the buffer,
    due to Emacs features such as format decoding, character code
    conversion, `find-file-hook', automatic uncompression, etc.
    
    This function ensures that none of these modifications will take place."
      (let ((format-alist nil)
            (after-insert-file-functions nil)
            (coding-system-for-read 'no-conversion)
            (coding-system-for-write 'no-conversion)
            (inhibit-file-name-handlers
             ;; FIXME: Yuck!!  We should turn insert-file-contents-literally
             ;; into a file operation instead!
             (append '(jka-compr-handler image-file-handler epa-file-handler)
                     (and (eq inhibit-file-name-operation 'insert-file-contents)
                          inhibit-file-name-handlers)))
            (inhibit-file-name-operation 'insert-file-contents))
        (insert-file-contents filename visit beg end replace)))

So this FIXME suggests maybe we should introduce a new file operation
`write-region-literally`?


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: federicotedin@gmail.com,  35495@debbugs.gnu.org,  ueno@unixuser.org
> Date: Sat, 11 May 2019 10:10:37 -0400
> 
> Hmm... I think you're referring to the question of what this new
> "write-region-provides-raw-file-contents" should precisely mean, so that
> maintainers of file-name-handlers can decide how to implement it.

Yes.

> Here's one attempt: "the data provided to write-region reflects the actual
> bytes that should be placed into the file rather than the data returned
> by `insert-file-contents`".

Well, we'll need to make this more accurate, to exclude encoding, EOL
conversion, and the likes, but okay.  (And "raw" sounds like a wrong
word for this.)

>              ;; FIXME: Yuck!!  We should turn insert-file-contents-literally
>              ;; into a file operation instead!
>              (append '(jka-compr-handler image-file-handler epa-file-handler)
>                      (and (eq inhibit-file-name-operation 'insert-file-contents)
>                           inhibit-file-name-handlers)))
>             (inhibit-file-name-operation 'insert-file-contents))
>         (insert-file-contents filename visit beg end replace)))
> 
> So this FIXME suggests maybe we should introduce a new file operation
> `write-region-literally`?

Probably.  But the question of what should that do (since you rejected
tweaking inhibit-file-name-operation for that) still stands, I think.

And I'm not sure we will always want to disable encoding and EOL
conversion, so that should be an add-on for "truly" literal I/O.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

>> So this FIXME suggests maybe we should introduce a new file operation
>> `write-region-literally`?
> Probably.  But the question of what should that do (since you rejected
> tweaking inhibit-file-name-operation for that) still stands, I think.

In the absence of a file-name-handler, it should just defer to write-region.

> And I'm not sure we will always want to disable encoding and EOL
> conversion, so that should be an add-on for "truly" literal I/O.

I am.  I'd even say it should signal an error if the buffer isn't unibyte.
Anything else would be asking for trouble.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: federicotedin@gmail.com,  35495@debbugs.gnu.org,  ueno@unixuser.org
> Date: Sat, 11 May 2019 15:55:01 -0400
> 
> >> So this FIXME suggests maybe we should introduce a new file operation
> >> `write-region-literally`?
> > Probably.  But the question of what should that do (since you rejected
> > tweaking inhibit-file-name-operation for that) still stands, I think.
> 
> In the absence of a file-name-handler, it should just defer to write-region.

I'm confused: I thought we were talking about features implemented via
file-name handlers.  jka-compr is, for example.

Or are you saying write-region-literally shouldn't even try file-name
handlers?  That'd be different from what
insert-file-contents-literally does.

> > And I'm not sure we will always want to disable encoding and EOL
> > conversion, so that should be an add-on for "truly" literal I/O.
> 
> I am.

For the present use case, sure.  But we are discussing a more general
solution, right?  The question is, will all of them want to disable
those conversions?

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier]

>> In the absence of a file-name-handler, it should just defer to write-region.
> I'm confused: I thought we were talking about features implemented via
> file-name handlers.  jka-compr is, for example.

Here's how I hope for it to work:

write-region-literally checks file-name-handler, finds HANDLER and delegates
to it, if HANDLER has a special handler for it (e.g. jka), then that
handler will presumably end up calling write-region, but if it doesn't,
then it rebinds inhibit-file-name-operation’ and
‘inhibit-file-name-handlers’ and calls write-region-literally again
which this time won't find this file-name-handler.

> For the present use case, sure.  But we are discussing a more general
> solution, right?  The question is, will all of them want to disable
> those conversions?

I'm suggesting to add write-region-literally and the "inverse" or
insert-file-contents-literally.  Just like
it is the case for insert-file-contents(-literally), there are in theory
middle points, but in practice those can be reached by manually
performing the extra encoding/decoding that the `-literally` version
doesn't do but that we'd need in this case.

IOW since we don't have any
`insert-file-contents-literally-but-please-do-the-coding-system-decoding`,
I don't think we want a `write-region-literally-but-not-quite`.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: federicotedin@gmail.com,  35495@debbugs.gnu.org,  ueno@unixuser.org
> Date: Sun, 12 May 2019 11:23:26 -0400
> 
> IOW since we don't have any
> `insert-file-contents-literally-but-please-do-the-coding-system-decoding`,
> I don't think we want a `write-region-literally-but-not-quite`.

The use cases are quite different, so analogies are not necessarily
helpful in designing the new primitive.

But okay, I guess when/if a suitable use case comes up, we can always
change this later.

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Lars Ingebrigtsen]

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

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> When untarring a file whose contents include a GPG keyring named with
> a `.gpg` extension, `tar-untar-buffer` ends up trying to encrypt the
> keyring because the `write-region` call for this file gets handed to
> `epa-file-write-region`.

I'm unable to reproduce this on the current trunk -- but I can't
reproduce it in Emacs 26.3/27.1 either.

I'm using the following tar file as the test case.  Is there anything
more needed to reproduce the problem, or has it really gone away?


[-- Attachment #2: test.tgz --]
[-- Type: application/x-gtar-compressed, Size: 8560 bytes --]

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2022-04-22 15:13:20] wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> When untarring a file whose contents include a GPG keyring named with
>> a `.gpg` extension, `tar-untar-buffer` ends up trying to encrypt the
>> keyring because the `write-region` call for this file gets handed to
>> `epa-file-write-region`.
>
> I'm unable to reproduce this on the current trunk -- but I can't
> reproduce it in Emacs 26.3/27.1 either.

How have you tried to reproduce it?

I did:

    emacs -Q .../test.tgz
    M-x tar-untar-buffer RET

and it prompted me (in a new *Keys* buffer) to choose a key to encrypt
some file.


        Stefan

bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> When untarring a file whose contents include a GPG keyring named with
>>> a `.gpg` extension, `tar-untar-buffer` ends up trying to encrypt the
>>> keyring because the `write-region` call for this file gets handed to
>>> `epa-file-write-region`.
>>
>> I'm unable to reproduce this on the current trunk -- but I can't
>> reproduce it in Emacs 26.3/27.1 either.
>
> How have you tried to reproduce it?
>
> I did:
>
>     emacs -Q .../test.tgz
>     M-x tar-untar-buffer RET
>
> and it prompted me (in a new *Keys* buffer) to choose a key to encrypt
> some file.

Sorry; didn't read the bug report closely enough -- I assumed just
opening the tgz file would trigger it.  With `M-x tar-untar-buffer' I
can reproduce the problem on the trunk.

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