D90: 707_0001-common-Add-a-function-for-copying-data-from-one-iobu.patch

This implements the requested --unwrap feature. It strips the first level of
encryption and then dumps the data.

$ gpg2 --decrypt --unwrap /tmp/a | gpg2 --list-packets
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate

:compressed packet: algo=2

off=2 ctb=90 tag=4 hlen=2 plen=13

:onepass_sig packet: keyid 58859975EE37CF96
version 3, sigclass 0x00, digest 8, pubkey 1, last=1

off=17 ctb=cb tag=11 hlen=2 plen=13 new-ctb

:literal data packet:
mode b (62), created 1446641593, name="",
raw data: 7 bytes

off=32 ctb=88 tag=2 hlen=2 plen=156

:signature packet: algo 1, keyid 58859975EE37CF96
version 4, created 1446641611, md5len 0, sigclass 0x00
digest algo 8, begin of digest b7 8a
hashed subpkt 2 len 4 (sig created 2015-11-04)
subpkt 16 len 8 (issuer key ID 58859975EE37CF96)
data: [1023 bits]

Based on Werner's response, I believe that the underlying issue is resolved.
Thus, I'm going to close this.

Committed in de9b234.

Committed in e16d716.

Frankly, I do not like the hidden key feature in particular if used to
encrypt-to-self. The problem is that if someone encrypts to a group and forgets
to add your key, gpg will do a trial decrypt which is pretty annoying. Maybe we
can add a second kind of wildcard keyid to rfc4880bis which states that this has
been encrypted to the key of the sender

I have no idea what a trusted extension is and I can happily read / modify the
body through OOM.

I'm marking this as resolved as I don't see anything to do here.

We don't ship gtksecmementry any more so that is definitely no longer relevant.
Closing.

This is still the case.

GtkSecureEntry has been removed from pinentry.

The attached patch builds on the patch in #806. It provides a
--encrypt-to-default-key. One could imagine adding an
--hidden-encrypt-to-default-key as well. Werner: is this acceptable?

D44: 706_0001-gpg-Add-encrypt-to-default-key.patch

I implemented this as follows: it is possible to specify --default-key multiple
times. The last specified key for which a secret key is available is taken. If
multiple such keys are available, the others are simply ignored. The patch is a
bit noisy, because we need to pass the ctrl structure around. But, I've tested
it as follows:

  gpg2 -a -s --default-key 58859975EE37CF96 --default-key 58859975EE37CF95

and it correctly takes the 96 key, which is available (95 is not).

Werner: thoughts?

D43: 705_0001-gpg-Allow-multiple-default-key-options.-Take-the-las.patch

Fix in ea99f88.

Hi!

@dkg:
Can you tell me more about your tab-return use case? Do you have hints/personal
observations about how many people are affected?
In the gtk2 pinentry this did not work so far (See my T2139 (bernhard on Oct 29 2015, 04:42 PM / Roundup)) other
implementation do not seem to allow it (I've also tested kdm login screen)
and it does not make much sense either when you can press "return" right away.
So to me it is still unclear how many people are affected.

@aheinecke: Thanks for contributing another case.
I think it is a good solution for a system login screen, where a login-change
probably is harder to do.
I think this slightly changes when you think about passphrases for pinentry
that may get entered less often and some people keep a backup on paper (which is
actually good under some circumstances) and I would claim that a passphrase
change on a key on average is easier to do than a system password.

@werner: You wrote that you've checked some other implementation, it would be cool
to have a list of those. Screenshots would be even better.

@all, my current design ideas are

• to have a text below the entry field, close to it, saying "show password" and a on-off switch or second best a check-box, third best a button.

Rationale: Because the space requirement is mainly in width. An on-off switch

probably has the most natural mapping, but this depend on the overal GUI design
of the system. On some a real slider-switch may not be available or look alien,
then we should use what ever users will recognise as an on-off thing.
The text is much less work than to select/design an icon and it uses
less height.

• It is okay to have that in the accessibility tab list, even after the entry field, because I personally believe that a lot more people want the natural order when using tab at all. Right now the data for how many people actually have the tab-enter habit is unknown, maybe Daniel can help us out here.

Btw. The Windows 10 login screen implements this as a button that you can not
tab to and only shows the password for as long as you keep clicking it.
It also disables / hides the show password button once the password entry field
loses input focus.

They use a heavily abstracted eye icon and no tooltip. Probably with the
rationale that if a user clicks there and it shows the password
(unintentionally) he can quickly release the mouse button again before someone
can read the password.

On Thu 2015-10-29 04:34:03 -0400, Bernhard Reiter via BTS wrote:

@dkg: I have been thinking about your use case:

I wonder about what fraction of people we are speaking of.
In many applications, just like pinentry, you can just hit "enter" right away
so there is no need to first hit "tab". First hitting "tab" does not make sense
for these kind of dialoges.

Then in some implementation like pinentry-gtk2 0.8.3-2,
this does not work right now, because the next tab is "cancel" which users then
would reach. So it depends on the standard for dialog windows where the
ok and cancel buttons are. Was there any problem report on pinentry-gtk-2?
I am not sure if any pinentry-gtk-2 user actually had this problem?

Daniel:
Thanks for your comment and adding the use case. I saw your suggestions
on the list like changing the tab order.

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

Some people are used to pinentry and have a common keyboard-based type, tab, hit
enter workflow.

Please make sure that this workflow doesn't accidentally switch their password
to visible when this change is implemented.

My suggestion is also, to seek for an icon that is more self-explanatory.
Actually I would like the "gtk_switch" gui component, though Werner is right
that it takes up a bit more of space.

re T2120 (wk on Oct 19 2015, 07:54 PM / Roundup): of course I meant "Now".

Yes, thanks for the quick review and merge! I assume this will be released in
whatever release comes after 2.1.9.

I'm setting the status here to "resolved".

Thanks for the quick fix!

No available with 2.1.9.

I already applied your pacthes. May I close that bug?

With the informsec code we had "decent" support for encrypted / decrypted
attachments.

With 1.3.0 we have very nice read support for MIME Attachments (including
Outlook's internal preview). And send support is on the roadmap.

But this is event based code. I'd say we can close this issue.

I have to check if this is possible (Depending on the parameters in the forward
reply events this could even be trivial)

You may want to try out the latest 1.3.0 Beta version which supports reading
PGP/MIME mails. See:

https://wiki.gnupg.org/GpgOL/Development/Testversions

Fixed in the repo. Will show up with the next site rebuild. Thanks.

D333: 691_0001-Remove-Korean-documentations.patch

Done with commit 9db6547. Thanks for reminding me about this annoyance.

Thank you, I'll send the DCO.
Also, I'll rebase the patches against current git master and adjust them to
conform with the doc/HACKING requirements.

Nope. Search for the original discussion on the debian bug tracker. We
introduced this option just for one Debian user and it shall in general not be
used. Thus who feel that they need a longer key should anywa switch to ecc.

gpg-agent has a --allow-emacs-pinentry option which should solve dkg's concerns
of unintended use of the emapcs pinebtry feature.

Thus I change your request for a generic method to pass options to pinentry to a
feature request.

Sorry, I missed that for 2.0.29

This should be something similar to gpg --always-trust

No DCO received, no review, won't apply. Sorry.

To be considered for 1.7

We can consider that for 1.7.
Can you please send a DCO to gcrypt-devel (see doc/HACKING).