From peter at digitalbrains.com Wed Aug 1 11:56:39 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 1 Aug 2018 11:56:39 +0200 Subject: Multiple ways to unlock encrypted root (was: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon) In-Reply-To: References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> Message-ID: <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> On 31/07/18 21:15, Wiktor Kwapisiewicz via Gnupg-devel wrote: > ...I'd be very happy if I could have the same key wrapped by TPM and on > a smartcard (for recovery purposes). I once wrote a little thing to do that on Debian[1], and it was ported[2] to Debian stretch by Erik Nellessen. That solution used LUKS, and LUKS has multiple keyslots. You could have a keyscript that unlocked using TPM, and another keyscript that unlocked using OpenPGP smartcard, each using a different keyslot if desired. You could create a boot loader entry that overrides the keyscript (see below). But you don't even need the multiple keyslots that LUKS offers. That's for multiple passphrases. But if you regard the passphrase as just a random key encryption key, you could have the TPM unwrap and OpenPGP decrypt just produce the same random key that is used as key encryption key, or directly as disk encryption key if you want that. So, as long as you use the TPM, you're not using OpenPGP, and when you use your OpenPGP smartcard, you're not using the TPM at all. They just produce the same value. BTW, overriding a keyscript is distribution-specific, but on Debian: $ mkdir tmp $ cd tmp $ zcat /boot/initrd.img-4.9.0-7-amd64 | cpio -i $ cd conf/conf.d $ cat cryptroot target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,rootdev,lvm=terrence--hg6-root,discard,key=none target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,lvm=terrence--hg6-usr,discard,key=none target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,resumedev,lvm=terrence--hg6-swap,discard,key=none My laptop, which uses full disk encryption with LUKS and a regular passphrase, has these three entries for unlocking the volumes necessary (root fs, /usr, resume partition). But if you supply the options on the kernel command line, these entries from conf/conf.d/cryptroot are not used; your specified options, and only those, are used. You'll get a really long kernel command line. For each line in conf/conf.d/cryptroot, supply one kernel argument "cryptopts=" with options adapted to your liking, and those are the options that will be used. Example: cryptopts=target=mx500_crypt,source=UUID=0de2d0b5-30f2-4308-8141-763a29fe8029,rootdev,lvm=terrence--hg6-root,discard,key=none I've specified a different LUKS partition to decrypt, but kept the rest the same. If I only specify this one, my /usr and resume partition will not be unlocked since command-line cryptopts cause the config file to be ignored entirely. It's clearly no fun to enter these values by hand; you could configure your boot loader to automatically produce a boot entry which has them with the appropriate options, or even extend the initramfs scripts to gracefully handle multiple alternative configs, or write your own keyscript that can fall back to the smartcard when it notices the TPM method is unsuccesful. The latter is probably the cleanest, and doesn't actually need anything from the above :-). Still, it's very useful to know when fiddling with custom encrypted roots, or even when swapping drives, as per the example. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wiktor at metacode.biz Wed Aug 1 13:00:39 2018 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 1 Aug 2018 13:00:39 +0200 Subject: Multiple ways to unlock encrypted root (was: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon) In-Reply-To: <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> Message-ID: Hi Peter, This definitely helps! I've already got GnuPG smartcard LUKS decryption working using this project [0]. It looks and works very well. And I've noticed LUKS slots, the LUKS TPM project [1] requires specific slots but the GnuPG LUKS [0] does not so it may really easy to setup both of them (for a specific definition of "easy" ;). One way or another your idea, scripts and configs will be handy along the way. Thanks for taking your time to describe your setup! Kind regards, Wiktor [0]: https://github.com/fuhry/initramfs-scencrypt [1]: https://github.com/electrickite/luks-tpm > On 31/07/18 21:15, Wiktor Kwapisiewicz via Gnupg-devel wrote: >> ...I'd be very happy if I could have the same key wrapped by TPM and on >> a smartcard (for recovery purposes). > > I once wrote a little thing to do that on Debian[1], and it was > ported[2] to Debian stretch by Erik Nellessen. That solution used LUKS, > and LUKS has multiple keyslots. You could have a keyscript that unlocked > using TPM, and another keyscript that unlocked using OpenPGP smartcard, > each using a different keyslot if desired. You could create a boot > loader entry that overrides the keyscript (see below). > > But you don't even need the multiple keyslots that LUKS offers. That's > for multiple passphrases. But if you regard the passphrase as just a > random key encryption key, you could have the TPM unwrap and OpenPGP > decrypt just produce the same random key that is used as key encryption > key, or directly as disk encryption key if you want that. So, as long as > you use the TPM, you're not using OpenPGP, and when you use your OpenPGP > smartcard, you're not using the TPM at all. They just produce the same > value. > > BTW, overriding a keyscript is distribution-specific, but on Debian: > > $ mkdir tmp > $ cd tmp > $ zcat /boot/initrd.img-4.9.0-7-amd64 | cpio -i > $ cd conf/conf.d > $ cat cryptroot > target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,rootdev,lvm=terrence--hg6-root,discard,key=none > target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,lvm=terrence--hg6-usr,discard,key=none > target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,resumedev,lvm=terrence--hg6-swap,discard,key=none > > My laptop, which uses full disk encryption with LUKS and a regular > passphrase, has these three entries for unlocking the volumes necessary > (root fs, /usr, resume partition). But if you supply the options on the > kernel command line, these entries from conf/conf.d/cryptroot are not > used; your specified options, and only those, are used. You'll get a > really long kernel command line. For each line in conf/conf.d/cryptroot, > supply one kernel argument "cryptopts=" with options adapted to > your liking, and those are the options that will be used. Example: > > cryptopts=target=mx500_crypt,source=UUID=0de2d0b5-30f2-4308-8141-763a29fe8029,rootdev,lvm=terrence--hg6-root,discard,key=none > > I've specified a different LUKS partition to decrypt, but kept the rest > the same. If I only specify this one, my /usr and resume partition will > not be unlocked since command-line cryptopts cause the config file to be > ignored entirely. > > It's clearly no fun to enter these values by hand; you could configure > your boot loader to automatically produce a boot entry which has them > with the appropriate options, or even extend the initramfs scripts to > gracefully handle multiple alternative configs, or write your own > keyscript that can fall back to the smartcard when it notices the TPM > method is unsuccesful. The latter is probably the cleanest, and doesn't > actually need anything from the above :-). Still, it's very useful to > know when fiddling with custom encrypted roots, or even when swapping > drives, as per the example. > > HTH, > > Peter. > -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Aug 1 14:42:49 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 1 Aug 2018 14:42:49 +0200 Subject: Multiple ways to unlock encrypted root In-Reply-To: References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> Message-ID: <7e66210c-490a-0b86-9b8d-f2139e5e0425@digitalbrains.com> Hi Wiktor, On 01/08/18 13:00, Wiktor Kwapisiewicz wrote: > This definitely helps! It would have helped if I remembered to include my own references :-). Here they are: >> I once wrote a little thing to do that on Debian[1], and it was >> ported[2] to Debian stretch by Erik Nellessen. That solution used LUKS, [1] [2] Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guilhem at fripost.org Wed Aug 1 17:20:33 2018 From: guilhem at fripost.org (Guilhem Moulin) Date: Wed, 1 Aug 2018 23:20:33 +0800 Subject: Multiple ways to unlock encrypted root In-Reply-To: <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> References: <1532899727.3142.12.camel@HansenPartnership.com> <6f7c0cfd-8902-a6db-1b3d-7305953432a2@metacode.biz> <1532984048.14893.7.camel@HansenPartnership.com> <8c6ad755-9995-ea0a-28b4-2e47619436cf@metacode.biz> <1533053257.3219.7.camel@HansenPartnership.com> <233174a2-0f78-b3b3-b1e8-da4bc6206456@digitalbrains.com> Message-ID: <20180801152033.GA16417@localhost.localdomain> Hi Peter, On Wed, 01 Aug 2018 at 11:56:39 +0200, Peter Lebbing wrote: > BTW, overriding a keyscript is distribution-specific, but on Debian: > [?] > $ cd conf/conf.d > $ cat cryptroot Note that this file and its format are considered internal implementation details of the cryptsetup initramfs scripts, hence third party scripts *must not* rely on that. In fact we broke all scripts relying on that internal invariant when releasing 2:2.0.3-2, including yours :-P Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903163 Cheers, -- Guilhem. PS. Sorry for the mostly off-topic post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From frank at sauerburger.com Thu Aug 2 08:23:29 2018 From: frank at sauerburger.com (Frank Sauerburger) Date: Thu, 2 Aug 2018 08:23:29 +0200 Subject: certificate of gnupg.org expired Message-ID: <4eff3a6e-a0c2-dafa-2f31-3ff7cb03d3b8@sauerburger.com> Hi, I think the x.509 certificates used for https://gnupg.org/ and https://lists.gnupg.org/ expired this morning. Can someone confirm this? Cheers, Frank -- Frank Sauerburger IT Wattwiller Stra?e 6 D-79241 Wasenweiler Phone | +49 7668 3192560 E-Mail | info at sauerburger.com Web | sauerburger.com OpenPGP Fingerprint 7A80 E9B6 6956 37B3 FC72 7180 09F3 D896 4E8E 39C1 Please encrypt replies to this mail. From georg at riseup.net Thu Aug 2 12:29:23 2018 From: georg at riseup.net (Georg Faerber) Date: Thu, 2 Aug 2018 10:29:23 +0000 Subject: certificate of gnupg.org expired In-Reply-To: <4eff3a6e-a0c2-dafa-2f31-3ff7cb03d3b8@sauerburger.com> References: <4eff3a6e-a0c2-dafa-2f31-3ff7cb03d3b8@sauerburger.com> Message-ID: <20180802102923.GA20294@debian> On 18-08-02 08:23:29, Frank Sauerburger wrote: > I think the x.509 certificates used for https://gnupg.org/ and > https://lists.gnupg.org/ expired this morning. Can someone confirm > this? Seems fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From muelli at cryptobitch.de Thu Aug 2 00:53:52 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Thu, 02 Aug 2018 01:53:52 +0300 Subject: Improving the command line UI of gpg In-Reply-To: References: <20180726232224.243px7fi7ojzjgg4@adversary.org> Message-ID: <46be885fd42096ca8cc8275118691687beecf5fb.camel@cryptobitch.de> On Tue, 2018-07-31 at 17:19 +0200, Andreas Almroth wrote: > If the gpgme approach is the recommended interface for building > wrappers, then perhaps we should at least look at what is missing to > make it usable. I guess the answer is that you must not do things that gpgme does not allow you to do. Like generating revocations. Because... someone decided that this is not a thing that any external program would ever legitimately do. Cheers, Tobi From peter at digitalbrains.com Thu Aug 2 15:11:31 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 2 Aug 2018 15:11:31 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <46be885fd42096ca8cc8275118691687beecf5fb.camel@cryptobitch.de> References: <20180726232224.243px7fi7ojzjgg4@adversary.org> <46be885fd42096ca8cc8275118691687beecf5fb.camel@cryptobitch.de> Message-ID: <83532fe4-b1fd-06f4-58c1-2156efa2de39@digitalbrains.com> On 02/08/18 00:53, Tobias Mueller wrote: > Because... someone decided that this is not a thing that any external > program would ever legitimately do. Or less flippantly, because you can always do the really uncommon things on the GnuPG command line, supposing that anybody confident enough to root around where most do not go would also be proficient in using a command line. I don't see anything wrong with that supposition. That a user conceivably might ever want to do something doesn't mean the feature needs to be replicated in a bunch of frontends, at the cost of development time spent elsewhere. By the way, I've more than once seen Werner show a way to do something with the underlying Assuan protocol that isn't directly available through the API of GPGME, but in that way available to GPGME users anyway. And sometimes it can be solved through --status-fd and friends. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Sat Aug 4 23:24:07 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 4 Aug 2018 22:24:07 +0100 Subject: [PATCH pinentry 0/4] Disable echo when entering passphrase Message-ID: <20180804212411.7895-1-dgouttegattat@incenp.org> Hi GnuPG folks, The following patchset attempts to implement the feature requested by Daniel Kahn Gillmor in [1], that is allowing the user to completely hide the passphrase they're about to enter (not even displaying masking characters) by pressing the backspace key first. This is done for the curses, Gtk+, Qt, and TQt pinentries. There doesn't seem to be an easy way to do it with the FLTK, EFL, or Gnome3 libraries. I didn't look at the Emacs and w32 pinentries. There are some differences between the implementations: * Only the curses variant has an explicit indicator that echoing is disabled (it displays "[no echo]"); the Gtk+, Qt, and TQt variants simply display an empty text box. * In both the Gtk+ and Qt pinentries, once echoing has been disabled the passphrase may still be displayed by clicking the "Show/Hide" button (Gtk+) or the "Show passphrase" checkbox (Qt). But if the user wants to hide the passphrase again, in the Gtk+ pinentry the widget will switch back to no echo, whereas in the Qt pinentry it will return to echoing masking characters. [1] https://dev.gnupg.org/T3428 Damien Goutte-Gattat (4): curses: Disable echoing if backspace is pressed first. gtk: Disable echoing if backspace is pressed first. qt: Disable echoing if backspace is pressed first. tqt: Disable echoing if backspace is pressed first. gtk+-2/pinentry-gtk-2.c | 18 ++++++++++++++++++ pinentry/pinentry-curses.c | 36 ++++++++++++++++++++++++++---------- qt/Makefile.am | 9 +++++---- qt/pinentrydialog.cpp | 18 +++++++++++++++++- qt/pinentrydialog.h | 7 +++++-- qt/pinlineedit.cpp | 36 ++++++++++++++++++++++++++++++++++++ qt/pinlineedit.h | 38 ++++++++++++++++++++++++++++++++++++++ tqt/pinentrydialog.cpp | 14 +++++++++++++- tqt/pinentrydialog.h | 2 ++ tqt/secqlineedit.cpp | 2 ++ tqt/secqlineedit.h | 1 + 11 files changed, 163 insertions(+), 18 deletions(-) create mode 100644 qt/pinlineedit.cpp create mode 100644 qt/pinlineedit.h -- 2.14.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Aug 4 23:24:08 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 4 Aug 2018 22:24:08 +0100 Subject: [PATCH pinentry 1/4] curses: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-1-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> Message-ID: <20180804212411.7895-2-dgouttegattat@incenp.org> * pinentry/pinentry-curses.c (struct dialog): New fields got_input, no_echo. (dialog_input): Disable echoing and display instead "[no echo]" if the backspace key is pressed first. GnuPG-bug-id: 3428 Signed-off-by: Damien Goutte-Gattat --- pinentry/pinentry-curses.c | 36 ++++++++++++++++++++++++++---------- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 89bb5b6..cfc1abd 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -94,6 +94,8 @@ struct dialog int pin_max; /* Length of PIN. */ int pin_len; + int got_input; + int no_echo; int ok_y; int ok_x; @@ -596,6 +598,9 @@ dialog_create (pinentry_t pinentry, dialog_t dialog) addstr (dialog->ok); } + dialog->got_input = 0; + dialog->no_echo = 0; + out: if (description) free (description); @@ -730,6 +735,12 @@ dialog_input (dialog_t diag, int alt, int chr) diag->pin_loc = diag->pin_len; } } + else if (!diag->got_input) + { + diag->no_echo = 1; + move (diag->pin_y, diag->pin_x); + addstr ("[no echo]"); + } break; case 'l' - 'a' + 1: /* control-l */ @@ -801,19 +812,24 @@ dialog_input (dialog_t diag, int alt, int chr) break; } - if (old_loc < diag->pin_loc) - { - move (diag->pin_y, diag->pin_x + old_loc); - while (old_loc++ < diag->pin_loc) - addch ('*'); - } - else if (old_loc > diag->pin_loc) + diag->got_input = 1; + + if (!diag->no_echo) { + if (old_loc < diag->pin_loc) + { + move (diag->pin_y, diag->pin_x + old_loc); + while (old_loc++ < diag->pin_loc) + addch ('*'); + } + else if (old_loc > diag->pin_loc) + { + move (diag->pin_y, diag->pin_x + diag->pin_loc); + while (old_loc-- > diag->pin_loc) + addch ('_'); + } move (diag->pin_y, diag->pin_x + diag->pin_loc); - while (old_loc-- > diag->pin_loc) - addch ('_'); } - move (diag->pin_y, diag->pin_x + diag->pin_loc); } static int -- 2.14.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Aug 4 23:24:10 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 4 Aug 2018 22:24:10 +0100 Subject: [PATCH pinentry 3/4] qt: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-1-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> Message-ID: <20180804212411.7895-4-dgouttegattat@incenp.org> * qt/pinlineedit.h: New file. * qt/pinlineedit.cpp: New file. * qt/Makefile.am: Add new source files. * qt/pinentrydialog.cpp (PinEntryDialog): New member _got_input; Type of _edit member changed to PinLineEdit. (PinEntryDialog::onBackspace): New slot. GnuPG-bug-id: 3428 Signed-off-by: Damien Goutte-Gattat --- qt/Makefile.am | 9 +++++---- qt/pinentrydialog.cpp | 18 +++++++++++++++++- qt/pinentrydialog.h | 7 +++++-- qt/pinlineedit.cpp | 36 ++++++++++++++++++++++++++++++++++++ qt/pinlineedit.h | 38 ++++++++++++++++++++++++++++++++++++++ 5 files changed, 101 insertions(+), 7 deletions(-) create mode 100644 qt/pinlineedit.cpp create mode 100644 qt/pinlineedit.h diff --git a/qt/Makefile.am b/qt/Makefile.am index 698005e..840d0c0 100644 --- a/qt/Makefile.am +++ b/qt/Makefile.am @@ -43,16 +43,17 @@ pinentry_qt_LDADD = \ $(COMMON_LIBS) $(PINENTRY_QT_LIBS) $(libcurses) $(LIBCAP) BUILT_SOURCES = \ - pinentryconfirm.moc pinentrydialog.moc + pinentryconfirm.moc pinentrydialog.moc pinlineedit.moc CLEANFILES = \ - pinentryconfirm.moc pinentrydialog.moc + pinentryconfirm.moc pinentrydialog.moc pinlineedit.moc pinentry_qt_SOURCES = pinentrydialog.h pinentrydialog.cpp \ - main.cpp qrc_pinentry.cpp pinentryconfirm.cpp pinentryconfirm.h + main.cpp qrc_pinentry.cpp pinentryconfirm.cpp pinentryconfirm.h \ + pinlineedit.h pinlineedit.cpp nodist_pinentry_qt_SOURCES = \ - pinentryconfirm.moc pinentrydialog.moc + pinentryconfirm.moc pinentrydialog.moc pinlineedit.moc .h.moc: $(MOC) `test -f '$<' || echo '$(srcdir)/'`$< -o $@ diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp index d42ae4a..b7f2e53 100644 --- a/qt/pinentrydialog.cpp +++ b/qt/pinentrydialog.cpp @@ -36,6 +36,7 @@ #include #include #include +#include "pinlineedit.h" #ifdef Q_OS_WIN #include @@ -137,6 +138,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name, : QDialog(parent), mRepeat(NULL), _grabbed(false), + _got_input(false), mVisibilityTT(visibilityTT), mHideTT(hideTT), mVisiActionEdit(NULL), @@ -163,7 +165,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name, _prompt = new QLabel(this); _prompt->hide(); - _edit = new QLineEdit(this); + _edit = new PinLineEdit(this); _edit->setMaxLength(256); _edit->setEchoMode(QLineEdit::Password); @@ -205,6 +207,8 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name, this, SLOT(updateQuality(QString))); connect(_edit, SIGNAL(textChanged(QString)), this, SLOT(textChanged(QString))); + connect(_edit, SIGNAL(backspacePressed()), + this, SLOT(onBackspace())); QTimer::singleShot(0, _edit, SLOT(setFocus())); @@ -356,6 +360,16 @@ void PinEntryDialog::setQualityBarTT(const QString &txt) } } +void PinEntryDialog::onBackspace() +{ + if (!_got_input) { + _edit->setEchoMode(QLineEdit::NoEcho); + if (mRepeat) { + mRepeat->setEchoMode(QLineEdit::NoEcho); + } + } +} + void PinEntryDialog::updateQuality(const QString &txt) { int length; @@ -366,6 +380,8 @@ void PinEntryDialog::updateQuality(const QString &txt) _timer->stop(); } + _got_input = true; + if (!_have_quality_bar || !_pinentry_info) { return; } diff --git a/qt/pinentrydialog.h b/qt/pinentrydialog.h index 52b7343..396f03b 100644 --- a/qt/pinentrydialog.h +++ b/qt/pinentrydialog.h @@ -33,6 +33,7 @@ class QLabel; class QPushButton; class QLineEdit; +class PinLineEdit; class QString; class QProgressBar; class QCheckBox; @@ -89,6 +90,7 @@ protected slots: void textChanged(const QString &); void focusChanged(QWidget *old, QWidget *now); void toggleVisibility(); + void onBackspace(); protected: /* reimp */ void showEvent(QShowEvent *event); @@ -100,13 +102,14 @@ private: QLabel *_prompt; QLabel *_quality_bar_label; QProgressBar *_quality_bar; - QLineEdit *_edit; - QLineEdit *mRepeat; + PinLineEdit *_edit; + QLineEdit *mRepeat; QPushButton *_ok; QPushButton *_cancel; bool _grabbed; bool _have_quality_bar; bool _timed_out; + bool _got_input; pinentry_t _pinentry_info; QTimer *_timer; QString mRepeatError, diff --git a/qt/pinlineedit.cpp b/qt/pinlineedit.cpp new file mode 100644 index 0000000..6e62f50 --- /dev/null +++ b/qt/pinlineedit.cpp @@ -0,0 +1,36 @@ +/* pinlineedit.cpp - Modified QLineEdit widget. + * Copyright (C) 2018 Damien Goutte-Gattat + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see . + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include "pinlineedit.h" + +#include + +PinLineEdit::PinLineEdit(QWidget *parent) : QLineEdit(parent) +{ +} + +void +PinLineEdit::keyPressEvent(QKeyEvent *e) +{ + QLineEdit::keyPressEvent(e); + + if ( e->key() == Qt::Key::Key_Backspace ) + emit backspacePressed(); +} + +#include "pinlineedit.moc" diff --git a/qt/pinlineedit.h b/qt/pinlineedit.h new file mode 100644 index 0000000..ffc1ef1 --- /dev/null +++ b/qt/pinlineedit.h @@ -0,0 +1,38 @@ +/* pinlineedit.h - Modified QLineEdit widget. + * Copyright (C) 2018 Damien Goutte-Gattat + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see . + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _PINLINEEDIT_H_ +#define _PINLINEEDIT_H_ + +#include + +class PinLineEdit : public QLineEdit +{ + Q_OBJECT + +public: + PinLineEdit(QWidget *); + +signals: + void backspacePressed(); + +protected: + void keyPressEvent(QKeyEvent *); +}; + +#endif // _PINLINEEDIT_H_ -- 2.14.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Aug 4 23:24:11 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 4 Aug 2018 22:24:11 +0100 Subject: [PATCH pinentry 4/4] tqt: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-1-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> Message-ID: <20180804212411.7895-5-dgouttegattat@incenp.org> * tqt/secqlineedit.h (backspacePressed): New signal. * tqt/secqinternal.cpp (SecTQLineEdit::backspace): Emit new signal. * tqt/pinentrydialog.h (_got_input): New member field. (onBackspace): New slot. * tqt/pinentrydialog.cpp (onBackspace): New slot. (PinEntryDialog::updateQuality): Prevent echo disabling as soon as the text has been edited. GnuPG-bug-id: 3428 Signed-off-by: Damien Goutte-Gattat --- tqt/pinentrydialog.cpp | 14 +++++++++++++- tqt/pinentrydialog.h | 2 ++ tqt/secqlineedit.cpp | 2 ++ tqt/secqlineedit.h | 1 + 4 files changed, 18 insertions(+), 1 deletion(-) diff --git a/tqt/pinentrydialog.cpp b/tqt/pinentrydialog.cpp index 069eeaf..6a2ae12 100644 --- a/tqt/pinentrydialog.cpp +++ b/tqt/pinentrydialog.cpp @@ -32,7 +32,8 @@ PinEntryDialog::PinEntryDialog( TQWidget* parent, const char* name, bool modal, bool enable_quality_bar ) - : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed( false ) + : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed( false ), + _got_input( false ) { TQBoxLayout* top = new TQVBoxLayout( this, 6 ); TQBoxLayout* upperLayout = new TQHBoxLayout( top ); @@ -89,6 +90,8 @@ PinEntryDialog::PinEntryDialog( TQWidget* parent, const char* name, this, SIGNAL( rejected() ) ); connect( _edit, SIGNAL( textModified(const SecTQString&) ), this, SLOT( updateQuality(const SecTQString&) ) ); + connect (_edit, SIGNAL (backspacePressed()), + this, SLOT (onBackspace ())); connect (this, SIGNAL (accepted ()), this, SLOT (accept ())); connect (this, SIGNAL (rejected ()), @@ -131,6 +134,8 @@ void PinEntryDialog::updateQuality( const SecTQString & txt ) int percent; TQPalette pal; + _got_input = true; + if (!_have_quality_bar || !_pinentry_info) return; pin = (char*)txt.utf8(); @@ -159,6 +164,13 @@ void PinEntryDialog::updateQuality( const SecTQString & txt ) } +void PinEntryDialog::onBackspace() +{ + if (!_got_input) + _edit->setEchoMode( SecTQLineEdit::NoEcho ); +} + + void PinEntryDialog::setDescription( const TQString& txt ) { _desc->setText( txt ); diff --git a/tqt/pinentrydialog.h b/tqt/pinentrydialog.h index d6f20c6..eb4d332 100644 --- a/tqt/pinentrydialog.h +++ b/tqt/pinentrydialog.h @@ -63,6 +63,7 @@ public: public slots: void updateQuality(const SecTQString &); + void onBackspace(); signals: void accepted(); @@ -86,6 +87,7 @@ private: bool _grabbed; bool _have_quality_bar; pinentry_t _pinentry_info; + bool _got_input; }; diff --git a/tqt/secqlineedit.cpp b/tqt/secqlineedit.cpp index ee95c8d..da0637a 100644 --- a/tqt/secqlineedit.cpp +++ b/tqt/secqlineedit.cpp @@ -719,6 +719,8 @@ void SecTQLineEdit::backspace() d->del( TRUE ); } d->finishChange( priorState ); + + emit backspacePressed(); } /*! diff --git a/tqt/secqlineedit.h b/tqt/secqlineedit.h index bd28cec..126f231 100644 --- a/tqt/secqlineedit.h +++ b/tqt/secqlineedit.h @@ -187,6 +187,7 @@ signals: void returnPressed(); void lostFocus(); void selectionChanged(); + void backspacePressed(); protected: bool event( TQEvent * ); -- 2.14.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Aug 4 23:24:09 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 4 Aug 2018 22:24:09 +0100 Subject: [PATCH pinentry 2/4] gtk: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-1-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> Message-ID: <20180804212411.7895-3-dgouttegattat@incenp.org> * gtk+-2/pinentry-gtk-2.c (backspace_handler): New callback. (create_window): Attach previous callback to "backspace" signal. GnuPG-bug-id: 3428 Signed-off-by: Damien Goutte-Gattat --- gtk+-2/pinentry-gtk-2.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c index c803628..1e07fdc 100644 --- a/gtk+-2/pinentry-gtk-2.c +++ b/gtk+-2/pinentry-gtk-2.c @@ -419,6 +419,22 @@ changed_text_handler (GtkWidget *widget) } +/* Called upon a press on Backspace in the entry widget. + Used to completely disable echoing if we got no prior input. */ +static void +backspace_handler (GtkWidget *widget, gpointer data) +{ + (void)data; + + if (!got_input) + { + gtk_entry_set_invisible_char (GTK_ENTRY (entry), 0); + if (repeat_entry) + gtk_entry_set_invisible_char (GTK_ENTRY (repeat_entry), 0); + } +} + + #ifdef HAVE_LIBSECRET static void may_save_passphrase_toggled (GtkWidget *widget, gpointer data) @@ -713,6 +729,8 @@ create_window (pinentry_t ctx) gtk_widget_set_size_request (entry, 200, -1); g_signal_connect (G_OBJECT (entry), "changed", G_CALLBACK (changed_text_handler), entry); + g_signal_connect (G_OBJECT (entry), "backspace", + G_CALLBACK (backspace_handler), entry); hbox = gtk_hbox_new (FALSE, HIG_TINY); gtk_box_pack_start (GTK_BOX (hbox), entry, TRUE, TRUE, 0); /* There was a wish in issue #2139 that this button should not -- 2.14.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From aheinecke at intevation.de Mon Aug 6 09:48:00 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 06 Aug 2018 09:48:00 +0200 Subject: [PATCH pinentry 3/4] qt: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-4-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> <20180804212411.7895-4-dgouttegattat@incenp.org> Message-ID: <4823210.4L846mBWij@esus> Hi, On Saturday, August 4, 2018 10:24:10 PM CEST Damien Goutte-Gattat via Gnupg- devel wrote: > * qt/pinlineedit.h: New file. > * qt/pinlineedit.cpp: New file. > * qt/Makefile.am: Add new source files. > * qt/pinentrydialog.cpp (PinEntryDialog): New member _got_input; > Type of _edit member changed to PinLineEdit. > (PinEntryDialog::onBackspace): New slot. Ok from me for the Qt pinentry. The show passphrase button can be first used to show the length of the passphrase and then again to actually show the passphrase. This adds an additional protection for the show passphrase button which makes sense in this "someone is looking over my shoulder" mode. Thanks, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From deloptes at gmail.com Mon Aug 13 09:52:14 2018 From: deloptes at gmail.com (deloptes) Date: Mon, 13 Aug 2018 09:52:14 +0200 Subject: [PATCH pinentry 4/4] tqt: Disable echoing if backspace is pressed first. In-Reply-To: <20180804212411.7895-5-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> <20180804212411.7895-5-dgouttegattat@incenp.org> Message-ID: Hi Damien, highly appreciated that you add patches to the TQT code. Thanks On Sat, Aug 4, 2018 at 11:24 PM, Damien Goutte-Gattat via Gnupg-devel < gnupg-devel at gnupg.org> wrote: > * tqt/secqlineedit.h (backspacePressed): New signal. > * tqt/secqinternal.cpp (SecTQLineEdit::backspace): Emit new signal. > * tqt/pinentrydialog.h (_got_input): New member field. > (onBackspace): New slot. > * tqt/pinentrydialog.cpp (onBackspace): New slot. > (PinEntryDialog::updateQuality): Prevent echo disabling as soon as > the text has been edited. > > GnuPG-bug-id: 3428 > Signed-off-by: Damien Goutte-Gattat > --- > tqt/pinentrydialog.cpp | 14 +++++++++++++- > tqt/pinentrydialog.h | 2 ++ > tqt/secqlineedit.cpp | 2 ++ > tqt/secqlineedit.h | 1 + > 4 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/tqt/pinentrydialog.cpp b/tqt/pinentrydialog.cpp > index 069eeaf..6a2ae12 100644 > --- a/tqt/pinentrydialog.cpp > +++ b/tqt/pinentrydialog.cpp > @@ -32,7 +32,8 @@ > > PinEntryDialog::PinEntryDialog( TQWidget* parent, const char* name, > bool modal, bool enable_quality_bar ) > - : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed( > false ) > + : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed( > false ), > + _got_input( false ) > { > TQBoxLayout* top = new TQVBoxLayout( this, 6 ); > TQBoxLayout* upperLayout = new TQHBoxLayout( top ); > @@ -89,6 +90,8 @@ PinEntryDialog::PinEntryDialog( TQWidget* parent, const > char* name, > this, SIGNAL( rejected() ) ); > connect( _edit, SIGNAL( textModified(const SecTQString&) ), > this, SLOT( updateQuality(const SecTQString&) ) ); > + connect (_edit, SIGNAL (backspacePressed()), > + this, SLOT (onBackspace ())); > connect (this, SIGNAL (accepted ()), > this, SLOT (accept ())); > connect (this, SIGNAL (rejected ()), > @@ -131,6 +134,8 @@ void PinEntryDialog::updateQuality( const SecTQString > & txt ) > int percent; > TQPalette pal; > > + _got_input = true; > + > if (!_have_quality_bar || !_pinentry_info) > return; > pin = (char*)txt.utf8(); > @@ -159,6 +164,13 @@ void PinEntryDialog::updateQuality( const SecTQString > & txt ) > } > > > +void PinEntryDialog::onBackspace() > +{ > + if (!_got_input) > + _edit->setEchoMode( SecTQLineEdit::NoEcho ); > +} > + > + > void PinEntryDialog::setDescription( const TQString& txt ) > { > _desc->setText( txt ); > diff --git a/tqt/pinentrydialog.h b/tqt/pinentrydialog.h > index d6f20c6..eb4d332 100644 > --- a/tqt/pinentrydialog.h > +++ b/tqt/pinentrydialog.h > @@ -63,6 +63,7 @@ public: > > public slots: > void updateQuality(const SecTQString &); > + void onBackspace(); > > signals: > void accepted(); > @@ -86,6 +87,7 @@ private: > bool _grabbed; > bool _have_quality_bar; > pinentry_t _pinentry_info; > + bool _got_input; > }; > > > diff --git a/tqt/secqlineedit.cpp b/tqt/secqlineedit.cpp > index ee95c8d..da0637a 100644 > --- a/tqt/secqlineedit.cpp > +++ b/tqt/secqlineedit.cpp > @@ -719,6 +719,8 @@ void SecTQLineEdit::backspace() > d->del( TRUE ); > } > d->finishChange( priorState ); > + > + emit backspacePressed(); > } > > /*! > diff --git a/tqt/secqlineedit.h b/tqt/secqlineedit.h > index bd28cec..126f231 100644 > --- a/tqt/secqlineedit.h > +++ b/tqt/secqlineedit.h > @@ -187,6 +187,7 @@ signals: > void returnPressed(); > void lostFocus(); > void selectionChanged(); > + void backspacePressed(); > > protected: > bool event( TQEvent * ); > -- > 2.14.4 > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgouttegattat at incenp.org Tue Aug 14 16:15:31 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 14 Aug 2018 15:15:31 +0100 Subject: [PATCH pinentry 0/4] Disable echo when entering passphrase In-Reply-To: <20180804212411.7895-1-dgouttegattat@incenp.org> References: <20180804212411.7895-1-dgouttegattat@incenp.org> Message-ID: <2fc5c188-be19-e8e9-a53d-b16fc50300ed@incenp.org> Hi GnuPG folks, On 08/04/2018 10:24 PM, Damien Goutte-Gattat via Gnupg-devel wrote: > Damien Goutte-Gattat (4): > curses: Disable echoing if backspace is pressed first. > gtk: Disable echoing if backspace is pressed first. > qt: Disable echoing if backspace is pressed first. > tqt: Disable echoing if backspace is pressed first. Given that the feature was requested on the bug tracker, that the idea received Werner's approval at the time, and that no one complained about the implementation in the past 10 days, I intend to apply the patchset to the master branch of pinentry by tomorrow. Thanks to Andre and "deloptes" for the green light regarding the Qt and TQt variants. Cheers, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Thu Aug 16 01:01:10 2018 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 16 Aug 2018 01:01:10 +0200 Subject: [project idea] Improve the usability of GnuPG CLI Message-ID: Hi, Since this GSoC term is almost over, I would like to share a few project ideas that might be used on future terms. I am not sure whether I will be able to mentor next year, but I think that sharing and discussing project ideas never hurts. If I don't publish them somewhere it is quite possible that I will forget about them. The best thing would be to use some idea management tool, but anyway we can use the tools that we already have. This project idea originates from this discussion: https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033852.html The idea is to write a CLI wrapper for the `gpg` command (in Bash, or Python, or something else) that improves the usability of `gpg` by trying to imitate the style of the `git` command. Basically it should do something like this: - Clearly separate the commands from the options and arguments. - Use bash autocomplete whenever possible. - Create a separate man page for each command. - Give contextual help when user seems to be lost. - Etc. In order to do this, the student should learn very well the commands and options of `gpg` and their usage. Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionic at ionic.de Fri Aug 17 19:25:27 2018 From: ionic at ionic.de (Mihai Moldovan) Date: Fri, 17 Aug 2018 19:25:27 +0200 Subject: Legacy Firmware/INT 13H supporting >512 byte sectors? In-Reply-To: References: <171d135e-4f54-5253-e06c-60d09b64e7aa@ionic.de> Message-ID: <171b81cc-8caf-75b9-964e-574053e8462f@ionic.de> [resent to list, since I forgot to add a CC header] * On 08/17/2018 06:11 PM, Vladimir 'phcoder' Serbinenko wrote: > Sure. Any BIOS able to read CD supports 2K sectors. > If you mean HDD then I have never seen one. I wrote support for non-512B sectors > in GRUB but so far it's untested as I couldn't find such a BIOS Ah, of course. CD sectors are 2K big. Yeah, that makes sense. I meant HDD sectors, yes. My firmware is doing weird things: it always reports a sector size of 512 bytes, reads and outputs data in 512 byte chunks, but sector addressing is actually HDD-dependent (i.e., for 4Kn drives 4K-based). I'll work around that using some heuristic, but that's only part of the problem. The bigger issue will probably be the boot image, which likely is too small to incorporate sophisticated code. I guess I could trick THAT into behaving correctly by spreading the core image file out over several sectors and only using the first 512 bytes of each sector. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From ionic at ionic.de Fri Aug 17 21:31:46 2018 From: ionic at ionic.de (Mihai Moldovan) Date: Fri, 17 Aug 2018 21:31:46 +0200 Subject: Legacy Firmware/INT 13H supporting >512 byte sectors? In-Reply-To: <171b81cc-8caf-75b9-964e-574053e8462f@ionic.de> References: <171d135e-4f54-5253-e06c-60d09b64e7aa@ionic.de> <171b81cc-8caf-75b9-964e-574053e8462f@ionic.de> Message-ID: * On 08/17/2018 07:25 PM, Mihai Moldovan wrote: > [resent to list, since I forgot to add a CC header] > [...] Sorry, sent on to the wrong mailing list. Please ignore this message. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From gnupg-devel at use.startmail.com Mon Aug 20 11:30:45 2018 From: gnupg-devel at use.startmail.com (Jasper Spaans) Date: Mon, 20 Aug 2018 11:30:45 +0200 Subject: gpgme python bindings release plans? Message-ID: Hi, First of all: thanks very much for your work on the gpgme python bindings! We (StartMail) have just started using these for developing our new backend, and this is so much more fun than manually calling the gnupg binary and parsing its output.. I was wondering, are there any plans for a fresh release of these bindings, as the current version on PyPI is about six months old now, and lots of changes have taken place recently. We're currently running a development-build based on a recent git clone, but for production I'd like to use something that has gone through an actual release process. Cheers, Jasper (Of course, if there's anything we can do to help out, just let me know and I'll see if we can make some time for that!) From peter at digitalbrains.com Mon Aug 20 14:02:10 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 20 Aug 2018 14:02:10 +0200 Subject: gpgme python bindings release plans? In-Reply-To: References: Message-ID: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> On 20/08/18 11:30, Jasper Spaans wrote: > I was wondering, are there any plans for a fresh release of these > bindings, as the current version on PyPI is about six months old now, The gist of it is that the bindings are spread by upstream bundled with GPGME, rather than through PyPi. This is because the bindings are tightly coupled to the GPGME library, so they should be built and installed together. But that's all I can tell you, I'm not well acquainted with it. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Aug 21 12:19:37 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Aug 2018 12:19:37 +0200 Subject: Improving the command line UI of gpg In-Reply-To: <46be885fd42096ca8cc8275118691687beecf5fb.camel@cryptobitch.de> (Tobias Mueller's message of "Thu, 02 Aug 2018 01:53:52 +0300") References: <20180726232224.243px7fi7ojzjgg4@adversary.org> <46be885fd42096ca8cc8275118691687beecf5fb.camel@cryptobitch.de> Message-ID: <874lfo3tty.fsf@wheatstone.g10code.de> On Thu, 2 Aug 2018 00:53, muelli at cryptobitch.de said: > I guess the answer is that you must not do things that gpgme does not > allow you to do. Like generating revocations. Because... someone decided Do you have a need for this for a real world project and not just for a prototype? If that is the case we are fast to add a new interface. Instead of blowing up the interface for all possible use cases, as we did for gpg, we want to limit GPGME to be useful for real world use cases. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 21 12:25:24 2018 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Aug 2018 12:25:24 +0200 Subject: [PATCH pinentry 0/4] Disable echo when entering passphrase In-Reply-To: <2fc5c188-be19-e8e9-a53d-b16fc50300ed@incenp.org> (Damien Goutte-Gattat via Gnupg-devel's message of "Tue, 14 Aug 2018 15:15:31 +0100") References: <20180804212411.7895-1-dgouttegattat@incenp.org> <2fc5c188-be19-e8e9-a53d-b16fc50300ed@incenp.org> Message-ID: <87zhxg2ezv.fsf@wheatstone.g10code.de> On Tue, 14 Aug 2018 16:15, gnupg-devel at gnupg.org said: > the implementation in the past 10 days, I intend to apply the patchset > to the master branch of pinentry by tomorrow. Fine. My only concern is that a user accidentally hits Backspace does not see anything and then hist Okay. When entering a PIN that could increase the odds of accidentally blocking the card (false entry counter). So what about either - not using this feature for a PIN - making sure "[no echo]" is always disabled. Shalom-Salam, Werner p.s. I did not looked at the code so it might already do that. -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Tue Aug 21 19:16:30 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Aug 2018 19:16:30 +0200 Subject: [PATCH pinentry 0/4] Disable echo when entering passphrase In-Reply-To: <87zhxg2ezv.fsf@wheatstone.g10code.de> References: <20180804212411.7895-1-dgouttegattat@incenp.org> <2fc5c188-be19-e8e9-a53d-b16fc50300ed@incenp.org> <87zhxg2ezv.fsf@wheatstone.g10code.de> Message-ID: <3a27f96c-bf48-ad6f-8db7-9e9cb35dd21b@digitalbrains.com> On 21/08/18 12:25, Werner Koch wrote: > - not using this feature for a PIN The GnuK is using a "PIN" but it can actually be a real passphrase, and it encrypts the data on card. So I don't think GnuPG can really tell apart between a PIN and a passphrase... My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Tue Aug 21 21:31:53 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 21 Aug 2018 20:31:53 +0100 Subject: [PATCH pinentry 0/4] Disallow echo disabling when prompting for a PIN. In-Reply-To: <87zhxg2ezv.fsf@wheatstone.g10code.de> References: <87zhxg2ezv.fsf@wheatstone.g10code.de> Message-ID: <20180821193153.17632-1-dgouttegattat@incenp.org> Hi Werner, > So what about either > > - not using this feature for a PIN > - making sure "[no echo]" is always disabled. (I assume you meant "always displayed" or similar here.) For the curses pinentry, "[no echo]" is always displayed when echoing is disabled. There's no easy way to achieve the same thing with the Gtk/Qt/TQt pinentries though, so for them I am in favor of the first solution. It's implemented with the patch below, which uses the presence of "PIN" in the prompt text to distinguish between a PIN prompt and a passphrase prompt (same logic already used in gpg-agent). -- >8 -- Subject: [PATCH pinentry] Disallow echo disabling when prompting for a PIN. * gtk+-2/pinentry-gtk-2.c (create_window): Do not setup the backspace handler when prompting for a PIN. callback only when not prompting for a PIN. * qt/pinentrydialog.h (_got_input): Rename field to _disable_echo_allowed. * qt/pinentrydialog.cpp (PinEntryDialog::setPrompt): Disallow echo disabling when prompting for a PIN. * tqt/pinentrydialog.h (_got_input): Rename field to _disable_echo_allowed. * tqt/pinentrydialog.cpp (PinEntryDialog::setPrompt): Disallow echo disabling when prompting for a PIN. Signed-off-by: Damien Goutte-Gattat --- gtk+-2/pinentry-gtk-2.c | 10 ++++++++-- qt/pinentrydialog.cpp | 8 +++++--- qt/pinentrydialog.h | 2 +- tqt/pinentrydialog.cpp | 8 +++++--- tqt/pinentrydialog.h | 2 +- 5 files changed, 20 insertions(+), 10 deletions(-) diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c index 1e07fdc..a4522e4 100644 --- a/gtk+-2/pinentry-gtk-2.c +++ b/gtk+-2/pinentry-gtk-2.c @@ -729,8 +729,14 @@ create_window (pinentry_t ctx) gtk_widget_set_size_request (entry, 200, -1); g_signal_connect (G_OBJECT (entry), "changed", G_CALLBACK (changed_text_handler), entry); - g_signal_connect (G_OBJECT (entry), "backspace", - G_CALLBACK (backspace_handler), entry); + + /* Enable disabling echo if we're not asking for a PIN. */ + if (pinentry->prompt && !strstr (pinentry->prompt, "PIN")) + { + g_signal_connect (G_OBJECT (entry), "backspace", + G_CALLBACK (backspace_handler), entry); + } + hbox = gtk_hbox_new (FALSE, HIG_TINY); gtk_box_pack_start (GTK_BOX (hbox), entry, TRUE, TRUE, 0); /* There was a wish in issue #2139 that this button should not diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp index b7f2e53..a58e636 100644 --- a/qt/pinentrydialog.cpp +++ b/qt/pinentrydialog.cpp @@ -138,7 +138,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name, : QDialog(parent), mRepeat(NULL), _grabbed(false), - _got_input(false), + _disable_echo_allowed(true), mVisibilityTT(visibilityTT), mHideTT(hideTT), mVisiActionEdit(NULL), @@ -318,6 +318,8 @@ void PinEntryDialog::setPrompt(const QString &txt) { _prompt->setText(txt); _prompt->setVisible(!txt.isEmpty()); + if (txt.contains("PIN")) + _disable_echo_allowed = false; } QString PinEntryDialog::prompt() const @@ -362,7 +364,7 @@ void PinEntryDialog::setQualityBarTT(const QString &txt) void PinEntryDialog::onBackspace() { - if (!_got_input) { + if (_disable_echo_allowed) { _edit->setEchoMode(QLineEdit::NoEcho); if (mRepeat) { mRepeat->setEchoMode(QLineEdit::NoEcho); @@ -380,7 +382,7 @@ void PinEntryDialog::updateQuality(const QString &txt) _timer->stop(); } - _got_input = true; + _disable_echo_allowed = false; if (!_have_quality_bar || !_pinentry_info) { return; diff --git a/qt/pinentrydialog.h b/qt/pinentrydialog.h index 396f03b..d5e6963 100644 --- a/qt/pinentrydialog.h +++ b/qt/pinentrydialog.h @@ -109,7 +109,7 @@ private: bool _grabbed; bool _have_quality_bar; bool _timed_out; - bool _got_input; + bool _disable_echo_allowed; pinentry_t _pinentry_info; QTimer *_timer; QString mRepeatError, diff --git a/tqt/pinentrydialog.cpp b/tqt/pinentrydialog.cpp index 6a2ae12..b7aa309 100644 --- a/tqt/pinentrydialog.cpp +++ b/tqt/pinentrydialog.cpp @@ -33,7 +33,7 @@ PinEntryDialog::PinEntryDialog( TQWidget* parent, const char* name, bool modal, bool enable_quality_bar ) : TQDialog( parent, name, modal, TQt::WStyle_StaysOnTop ), _grabbed( false ), - _got_input( false ) + _disable_echo_allowed ( true ) { TQBoxLayout* top = new TQVBoxLayout( this, 6 ); TQBoxLayout* upperLayout = new TQHBoxLayout( top ); @@ -134,7 +134,7 @@ void PinEntryDialog::updateQuality( const SecTQString & txt ) int percent; TQPalette pal; - _got_input = true; + _disable_echo_allowed = false; if (!_have_quality_bar || !_pinentry_info) return; @@ -166,7 +166,7 @@ void PinEntryDialog::updateQuality( const SecTQString & txt ) void PinEntryDialog::onBackspace() { - if (!_got_input) + if (_disable_echo_allowed) _edit->setEchoMode( SecTQLineEdit::NoEcho ); } @@ -208,6 +208,8 @@ SecTQString PinEntryDialog::text() const void PinEntryDialog::setPrompt( const TQString& txt ) { _prompt->setText( txt ); + if (txt.contains("PIN")) + _disable_echo_allowed = false; } TQString PinEntryDialog::prompt() const diff --git a/tqt/pinentrydialog.h b/tqt/pinentrydialog.h index eb4d332..8ec3fd5 100644 --- a/tqt/pinentrydialog.h +++ b/tqt/pinentrydialog.h @@ -87,7 +87,7 @@ private: bool _grabbed; bool _have_quality_bar; pinentry_t _pinentry_info; - bool _got_input; + bool _disable_echo_allowed; }; -- 2.14.4 From wk at gnupg.org Wed Aug 22 10:29:48 2018 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Aug 2018 10:29:48 +0200 Subject: [PATCH pinentry 0/4] Disallow echo disabling when prompting for a PIN. In-Reply-To: <20180821193153.17632-1-dgouttegattat@incenp.org> (Damien Goutte-Gattat via Gnupg-devel's message of "Tue, 21 Aug 2018 20:31:53 +0100") References: <87zhxg2ezv.fsf@wheatstone.g10code.de> <20180821193153.17632-1-dgouttegattat@incenp.org> Message-ID: <8760023itf.fsf@wheatstone.g10code.de> On Tue, 21 Aug 2018 21:31, gnupg-devel at gnupg.org said: > (I assume you meant "always displayed" or similar here.) Sure. > For the curses pinentry, "[no echo]" is always displayed when > echoing is disabled. I noticed that. > It's implemented with the patch below, which uses the presence of > "PIN" in the prompt text to distinguish between a PIN prompt and a > passphrase prompt (same logic already used in gpg-agent). It ist not ideal but the best solution we have right now. It would be better if gpg-agent could tell pinentry who is the requestor (gpg-agent or scdaemon); this requires quite some re-structuring in gpg-agent. So this would be something for the future. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aheinecke at intevation.de Wed Aug 22 14:46:06 2018 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 22 Aug 2018 14:46:06 +0200 Subject: New GPGME language binding: gpgme.js - JavaScript / Browser Message-ID: <3101862.O8Euy8htBm@esus> Hi, today I've merged Maximilian Krambachs work in the javascript-binding branch into master as our fifth language binding \o/. It's still under development and the API is not yet to consider stable. But Mailvelope is currently in the process of integrating it and so we thought that it should be part of the next release. I find it a bit exiting as this creates a bridge between GnuPG and Webmailers / the JavaScript world. The next Gpg4win release will already contain an optional component to register GnuPG (through gpgme-json) as a native messaging provider with which gpgme can be used from Mailvelope. Cheers, Andre More Details from the README: gpgme.js - JavaScript for GPGME ------------------------------- Initially developed for integration with the Mailvelope Web Extension. Overview -------- gpgme.js is a javascript library for direct use of GnuPG in browsers. It interacts with GPGME through nativeMessaging and gpgme-json. It is meant to be distributed directly by its downstream users in their extension package. As such it is not integrated in the autotools build system. See build instructions below. gpgme-json ---------- gpgme-json (see core src/gpgme-json.c) the json to GPGME bridge is required as native messaging backend for gpgme.js to work. It needs to be installed and registered as native messaging backend with the browser. See gpgme-mozilla.json and gpgme-chrome.json examples in the top level doc/examples as example manifests. Any web extension using gpgme.js will need to be whitelisted in the manifest file by its id. Distributors are encouraged to create manifest packages for their distributions. Building gpgme.js ----------------- gpgme.js uses webpack, and thus depends on Node.js for building. All dependencies will be installed (in a local subdirectory) with the command `npm install`. To create a current version of the package, the command is `npx webpack --config webpack.conf.js`. If you want a more debuggable (i.e. not minified) build, just change the mode in webpack.conf.js. Demo and Test WebExtension: --------------------------- The Demo Extension shows simple examples of the usage of gpgme.js. The BrowsertestExtension runs more intensive tests (using the mocha and chai frameworks). Tests from BrowserTestExtension/tests will be run against the gpgmejs.bundle.js itself. They aim to test the outward facing functionality and API. Unittests as defined in ./unittests.js will be bundled in gpgmejs_unittests.bundle.js, and test the separate components of gpgme.js, which mostly are not exported. The file `build_extension.sh` may serve as a pointer on how to build and assemble these two Extensions and their dependencies. It can directly be used in most linux systems. The resulting folders can just be included in the extensions tab of the browser in questions (extension debug mode needs to be active). For chrome, selecting the folder is sufficient, for firefox, the manifest.json needs to be selected. Please note that it is just for demonstration/debug purposes! For the Extensions to successfully communicate with gpgme-json, a manifest file is needed. - `~/.config/chromium/NativeMessagingHosts/gpgmejson.json` In the browsers' nativeMessaging configuration folder a file 'gpgmejs.json' is needed, with the following content: - For Chrome/Chromium: ``` { "name": "gpgmejson", "description": "This is a test application for gpgme.js", "path": "/usr/bin/gpgme-json", "type": "stdio", "allowed_origins": ["chrome-extension://ExtensionIdentifier/"] } ``` The usual path for Linux is similar to: `~/.config/chromium/NativeMessagingHosts/gpgmejson.json` for For Windows, the path to the manifest needs to be placed in `HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\gpgmejson` - For firefox: ``` { "name": "gpgmejson", "description": "This is a test application for gpgme.js", "path": "/usr/bin/gpgme-json", "type": "stdio", "allowed_extensions": ["ExtensionIdentifier at temporary-addon"] } ``` The ExtensionIdentifier can be seen as Extension ID on the about:addons page if addon-debugging is active. In firefox, the temporary addon is removed once firefox exits, and the identifier will need to be changed more often. The manifest for linux is usually placed at: `~/.mozilla/native-messaging-hosts/gpgmejson.json` Documentation ------------- The documentation can be built by jsdoc. It currently uses the command `./node_modules/.bin/jsdoc -c jsdoc.conf`. -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From dgouttegattat at incenp.org Wed Aug 22 22:38:24 2018 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 22 Aug 2018 21:38:24 +0100 Subject: [PATCH pinentry 0/4] Disallow echo disabling when prompting for a PIN. In-Reply-To: <8760023itf.fsf@wheatstone.g10code.de> References: <87zhxg2ezv.fsf@wheatstone.g10code.de> <20180821193153.17632-1-dgouttegattat@incenp.org> <8760023itf.fsf@wheatstone.g10code.de> Message-ID: <6a570a91-466a-3fe7-a7eb-2864bf3f8c9d@incenp.org> On 08/22/2018 09:29 AM, Werner Koch wrote: > It ist not ideal but the best solution we have right now. OK then, I will merge that. Thanks. Regards, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Aug 24 17:27:16 2018 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 24 Aug 2018 17:27:16 +0200 Subject: https://git.gnupg.org - certificate expired Message-ID: <582f97aa-3ba5-ace4-10b2-7352dda498c8@sumptuouscapital.com> FYI; the https://git.gnupg.org/ certificate is expired again The certificate expired on 08/24/2018 09:31 AM. The current time is 08/24/2018 05:26 PM. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nulla regula sine exceptione No rule without exception -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg-devel at use.startmail.com Sun Aug 26 21:21:31 2018 From: gnupg-devel at use.startmail.com (Jasper Spaans) Date: Sun, 26 Aug 2018 21:21:31 +0200 Subject: gpgme python bindings release plans? In-Reply-To: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> Message-ID: On 20/08/2018 14:02, Peter Lebbing wrote: > The gist of it is that the bindings are spread by upstream bundled with > GPGME, rather than through PyPi. This is because the bindings are > tightly coupled to the GPGME library, so they should be built and > installed together. > > But that's all I can tell you, I'm not well acquainted with it. Thanks Peter! That is a bit unusual for Python packages, but I guess there's not much to do about it for now. Anyway, I followed your advice and made some packages for gpgme and python, but they somehow failed when trying to load the python module (based on current git head of gpgme): ? user at testing-gpg:~$ python3 -m gpg ? Traceback (most recent call last): ? ... ? ImportError: /usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: undefined symbol: gpgme_data_new_from_estream This was on a ubuntu 16.04 vm, stock packages, except libgpg-error which I created and installed a 1.32 package for. Doing a git bisect, the commit that causes the Python module to fail is commit f42cd70f18d53df47cc2d027bade736377d39b71 Author: Werner Koch Date:?? Thu Jul 19 09:50:30 2018 +0200 core: New interface gpgme_data_new_from_estream. which seems to be a reasonable commit given the ImportError missing symbol. Let me see if I can create my first patch :) Cheers, Jasper From gnupg-devel at use.startmail.com Sun Aug 26 22:03:31 2018 From: gnupg-devel at use.startmail.com (Jasper Spaans) Date: Sun, 26 Aug 2018 22:03:31 +0200 Subject: [PATCH] core: export gpgme_data_new_from_estream function. In-Reply-To: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> Message-ID: On 26/08/2018 21:21, Jasper Spaans wrote: > Let me see if I can create my first patch :) Here it is, it was just a symbol that was not being exported. Verified that with this change applied the Python bindings work again for me. From: Jasper Spaans Date: Sun, 26 Aug 2018 21:44:34 +0200 Subject: [PATCH] core: export gpgme_data_new_from_estream function. --- ?src/gpgme.def???? | 2 ++ ?src/libgpgme.vers | 1 + ?2 files changed, 3 insertions(+) diff --git a/src/gpgme.def b/src/gpgme.def index a01d89a2..c6902208 100644 --- a/src/gpgme.def +++ b/src/gpgme.def @@ -272,5 +272,7 @@ EXPORTS ???? gpgme_op_encrypt_sign_ext???????????? @202 ???? gpgme_op_encrypt_sign_ext_start?????? @203 ? +??? gpgme_data_new_from_estream?????????? @204 + ?; END ? diff --git a/src/libgpgme.vers b/src/libgpgme.vers index b49c86d9..080c9cd5 100644 --- a/src/libgpgme.vers +++ b/src/libgpgme.vers @@ -153,6 +153,7 @@ GPGME_1.0 { ???? gpgme_data_get_encoding; ???? gpgme_data_new; ???? gpgme_data_new_from_cbs; +??? gpgme_data_new_from_estream; ???? gpgme_data_new_from_fd; ???? gpgme_data_new_from_file; ???? gpgme_data_new_from_filepart; -- 2.18.0 From wk at gnupg.org Mon Aug 27 09:09:44 2018 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Aug 2018 09:09:44 +0200 Subject: [PATCH] core: export gpgme_data_new_from_estream function. In-Reply-To: (Jasper Spaans's message of "Sun, 26 Aug 2018 22:03:31 +0200") References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> Message-ID: <87pny41e13.fsf@wheatstone.g10code.de> On Sun, 26 Aug 2018 22:03, gnupg-devel at use.startmail.com said: > Here it is, it was just a symbol that was not being exported. Verified > that with this change applied the Python bindings work again for me. Applied. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From muelli at cryptobitch.de Mon Aug 27 12:20:37 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Mon, 27 Aug 2018 12:20:37 +0200 Subject: gpgme python bindings release plans? References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> Message-ID: Hi, On Sun, 2018-08-26 at 21:21 +0200, Jasper Spaans wrote: > That is a bit unusual for Python packages, but I guess > there's not much to do about it for now. One thing one could do is upload the library along with the Python bindings. And that's not that unusual for packages on PyPi. And it could be done easily. Cheers, Tobi From ben at adversary.org Thu Aug 30 08:44:41 2018 From: ben at adversary.org (Ben McGinnes) Date: Thu, 30 Aug 2018 16:44:41 +1000 Subject: gpgme python bindings release plans? References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> Message-ID: <20180830064441.z7ngi3ljmx4t7scw@adversary.org> On Sun, Aug 26, 2018 at 09:21:31PM +0200, Jasper Spaans wrote: > On 20/08/2018 14:02, Peter Lebbing wrote: >> The gist of it is that the bindings are spread by upstream bundled with >> GPGME, rather than through PyPi. This is because the bindings are >> tightly coupled to the GPGME library, so they should be built and >> installed together. >> >> But that's all I can tell you, I'm not well acquainted with it. > > Thanks Peter! That is a bit unusual for Python packages, Most Python packages, certainly those on PyPI, are also written entirely or almost entirely in Python as well. These bindings are generated with SWIG from header files which are generated when GPGME itself is compiled. In order to dynamically generate the bindings, we must have the location of gpgme.h for that specific architecture, operating system and build. This is why in this case the PyPI copy or copies are never recommended and, unlike so many other projects, should only be used if it's not possible to compile GPGME and generate the bindings directly, even as a regular user. If someone is in that position, though, there's a much higher probability that even the PyPI option won't help them anyway. > but I guess there's not much to do about it for now. Perhaps not, but I recommend you read the HOWTO for the bindings; it's the lang/python/docs/GPGMEpythonHOWTOen.org org-mode file. > Anyway, I followed your advice and made some packages for gpgme and > python, but they somehow failed when trying to load the python > module (based on current git head of gpgme): > > ? user at testing-gpg:~$ python3 -m gpg Don't check the bindings using this method, it won't work because this module is not an executable program in that sense. A better check from a shell w=is this: bash-4.4$ python3.7 -c "import gpg; print(gpg.version.versionstr)" 1.11.2-beta257 bash-4.4$ The output of which should match the installed library version: bash-4.4$ gpgme-config --version 1.11.2-beta257 bash-4.4$ > ? Traceback (most recent call last): > ? ... > ? ImportError: > /usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: > undefined symbol: gpgme_data_new_from_estream Interestingly enough, I hadn't seen this error at all until this commit: 08cd34afb762975b0273575035dacf69449ef241 I'd had up to commit 138e1dde027338358a8da19ff8592b7369494534 running live for nearly a week (that's the commit immediately prior to your patch). > This was on a ubuntu 16.04 vm, stock packages, except libgpg-error which > I created and installed a 1.32 package for. Oh dear, mixing and matching between whatever modifications Canonical have made with parts of current source. I guess that explains why it broke on OS X and possibly other BSDs. > Doing a git bisect, the commit that causes the Python module to fail is > > commit f42cd70f18d53df47cc2d027bade736377d39b71 > Author: Werner Koch > Date:?? Thu Jul 19 09:50:30 2018 +0200 > > core: New interface gpgme_data_new_from_estream. > > which seems to be a reasonable commit given the ImportError missing symbol. I'd be surprised if it really caused the error if that were to be tested on any Linux system which either stuck entirely with that distributions packages *or* entirely with building the GnuPG software from source (yes, all of it), but *not* mixing and matching between the two. On Sun, Aug 26, 2018 at 10:03:31PM +0200, Jasper Spaans wrote: > On 26/08/2018 21:21, Jasper Spaans wrote: > > Let me see if I can create my first patch :) > Here it is, it was just a symbol that was not being exported. Verified > that with this change applied the Python bindings work again for me. Maybe so, but it broke for others, whether that was due to the exported symbols conflicting with the inner API module name (i.e. _gpgme) or the lack of defined functions for the estream in the core, could go either way, but I'm leaning towards it being caused by the exported symbol not lining up with _gpgme. I've fixed those conflicts with this commit: 1d00fb987b903e245d484bddfe3c0a0aba670ac1 That, however, required changing both of your updates, so you should test it ASAP to see if it still works or whether Ubuntu is going to be a point of pain in future. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Thu Aug 30 15:46:08 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Aug 2018 15:46:08 +0200 Subject: [Announce] GnuPG 2.2.10 released Message-ID: <87tvncvufz.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.10. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. As an Universal Crypto Engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.10 ===================================- gpg: Refresh expired keys originating from the WKD. [#2917] gpg: Use a 256 KiB limit for a WKD imported key. gpg: New option --known-notation. [#4060] scd: Add support for the Trustica Cryptoucan reader. agent: Speed up starting during on-demand launching. [#3490] dirmngr: Validate SRV records in WKD queries. Release-info: https://dev.gnupg.org/T4112 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.10 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.10.tar.bz2 (6503k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.10.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.10_20180830.exe (3919k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.10_20180830.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win installer featuring this version of GnuPG will be available soon. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.10.tar.bz2 you would use this command: gpg --verify gnupg-2.2.10.tar.bz2.sig gnupg-2.2.10.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.10.tar.bz2, you run the command like this: sha1sum gnupg-2.2.10.tar.bz2 and check that the output matches the next line: 3e87504e2ca317718aa9b6299947ebf7e906b54e gnupg-2.2.10.tar.bz2 c67cde7dffc82d592dff8538ed1ac8c28cc7c33d gnupg-w32-2.2.10_20180830.tar.xz 682002bce9e45309179a09348df3b92a82bdc501 gnupg-w32-2.2.10_20180830.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and two contractors. All work exclusively on GnuPG and closely related software like Libgcrypt and GPGME. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. =========== -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gnupg-devel at use.startmail.com Thu Aug 30 16:33:24 2018 From: gnupg-devel at use.startmail.com (Jasper Spaans) Date: Thu, 30 Aug 2018 16:33:24 +0200 Subject: gpgme python bindings release plans? In-Reply-To: <20180830064441.z7ngi3ljmx4t7scw@adversary.org> References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> Message-ID: On 30/08/2018 08:44, Ben McGinnes wrote: > I've fixed those conflicts with this commit: > 1d00fb987b903e245d484bddfe3c0a0aba670ac1 > > That, however, required changing both of your updates, so you should > test it ASAP to see if it still works or whether Ubuntu is going to be > a point of pain in future. Indeed your fix has broken my build instead. (I don't know what Ubuntu has to do with this; and in case my previous message was not clear enough: I did not use any Ubuntu-provided versions of libgpg-error or gpgme. I wouldn't be surprised if this will cause breakage on Debian as well.) Anyway, looking at the binary objects that were generated when building from git head (a9863717b1b82b3077edd0db85454ba801eac9bd , one version ahead of your commit): $ nm /usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so | grep gpgme_data_new_from_estream ???????????????? U gpgme_data_new_from_estream 000000000004c350 t _wrap_gpgme_data_new_from_estream The U means the symbol is undefined here and needs to be provided by another shared library. If that is nonsense, something on the Python side should stop referring to it. $ nm /usr/lib/libgpgme.so | grep gpgme_data_new_from_estream 000000000000b3a0 t gpgme_data_new_from_estream Where the small t indicates that it is a symbol known inside this library, but not exported. This is similar to the situation before my (now reverted) patch was applied. Random thoughts: - there are some traces of Jenkins in the ticket system, but is it still actively being used? I just tried accessing jenkins.gnupg.org but that returns "service not available"? If that Jenkins is being maintained though, I wouldn't mind setting up some jobs to test for these kinds of regressions. - what version of swig are you using? Cheers, Jasper From ben at adversary.org Fri Aug 31 00:06:10 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 31 Aug 2018 08:06:10 +1000 Subject: gpgme python bindings release plans? References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> Message-ID: <20180830220610.hgdji4manue2jf6g@adversary.org> On Thu, Aug 30, 2018 at 04:33:24PM +0200, Jasper Spaans wrote: > On 30/08/2018 08:44, Ben McGinnes wrote: > > I've fixed those conflicts with this commit: > > 1d00fb987b903e245d484bddfe3c0a0aba670ac1 > > > > That, however, required changing both of your updates, so you should > > test it ASAP to see if it still works or whether Ubuntu is going to be > > a point of pain in future. > Indeed your fix has broken my build instead. Really? Interesting. Raise a task on dev.gnupg.org with the full traceback and other relevant errors. I'll also need the details of which packages are standard for the distro and which aren't (if they're listed on the gnupg.org download page, include them here). > (I don't know what Ubuntu has to do with this; and in case my previous > message was not clear enough: I did not use any Ubuntu-provided versions > of libgpg-error or gpgme. Ah, but what of the rest of the GnuPG stack; like libassuan, libksba, libgcrypt and GPG itself? > I wouldn't be surprised if this will cause breakage on Debian as > well.) That's easy enough to check, we'll get dkg to try it out before we release. He can test it while I nudge things closer to his wishlist items (Installing for more than two Python releases at the same time). > Anyway, looking at the binary objects that were generated when building > from git head (a9863717b1b82b3077edd0db85454ba801eac9bd , one version > ahead of your commit): > > $ nm > /usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so > | grep gpgme_data_new_from_estream > ???????????????? U gpgme_data_new_from_estream > 000000000004c350 t _wrap_gpgme_data_new_from_estream > > The U means the symbol is undefined here and needs to be provided by > another shared library. If that is nonsense, something on the Python > side should stop referring to it. Well, originally nothing on the Python side referred to it and the new_from_stream function is just an alias to new_from_fd because Python doesn't differentiate betwee streams (or parts thereof) and files or file type objects. It's all data and it's all either bytes or strings. There's now a new_from_estream function aliased to the stream one. You can see much more of this via grepping the output of running strings on the SWIG integrated binary. > $ nm /usr/lib/libgpgme.so | grep gpgme_data_new_from_estream > 000000000000b3a0 t gpgme_data_new_from_estream > > Where the small t indicates that it is a symbol known inside this > library, but not exported. Hang on a tic ... you've got libgpgme in /usr/lib, but the corresponding Python modules in /usr/local/lib > This is similar to the situation before my (now reverted) patch was > applied. It's not entirely reverted, it's just been modified. The modifications prevent it trying to rename the dynamically generated submodule for "_gpgme" (i.e. gpg._gpgme) being renamed to gpg.gpgme at certain reference points and thus causing a fatal import error for everyone on other platforms (when large chunks of that are imported into gpg.core and wrapped at higher level). > Random thoughts: > - there are some traces of Jenkins in the ticket system, but is it still > actively being used? I just tried accessing jenkins.gnupg.org but that > returns "service not available"? If that Jenkins is being maintained > though, I wouldn't mind setting up some jobs to test for these kinds of > regressions. I don't believe it is still active, Phabricator was supposed to take the place of all of that, but management of that has been handed over to (one of the) Bernhards, if I recall correctly. > - what version of swig are you using? The latest version; 3.0.12. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From muelli at cryptobitch.de Fri Aug 31 11:23:49 2018 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 31 Aug 2018 11:23:49 +0200 Subject: gpgme python bindings release plans? In-Reply-To: <20180830064441.z7ngi3ljmx4t7scw@adversary.org> References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> Message-ID: <50e0b11561bb703206e08345e26fb8f21123ad64.camel@cryptobitch.de> Hi, On Thu, 2018-08-30 at 16:44 +1000, Ben McGinnes wrote: > In order to dynamically generate the bindings, we > must have the location of gpgme.h for that specific architecture, > operating system and build. but you could still upload upload binary packages to PyPI, if you wanted to, no? Because the technical reasons you cite should be covered by PEP513. Cheers, Tobi From wk at gnupg.org Fri Aug 31 13:42:40 2018 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Aug 2018 13:42:40 +0200 Subject: gpgme python bindings release plans? In-Reply-To: <20180830220610.hgdji4manue2jf6g@adversary.org> (Ben McGinnes's message of "Fri, 31 Aug 2018 08:06:10 +1000") References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> <20180830220610.hgdji4manue2jf6g@adversary.org> Message-ID: <871saewymn.fsf@wheatstone.g10code.de> On Fri, 31 Aug 2018 00:06, ben at adversary.org said: >> returns "service not available"? If that Jenkins is being maintained >> though, I wouldn't mind setting up some jobs to test for these kinds of >> regressions. > > I don't believe it is still active, Phabricator was supposed to take We had problems with the hardware and despite that the new hardware is in place we don't use the Jenkins right now: It turned out that we spent too much time fixing Jenkins setup problems (actually our build scripts). We will eventually get it online again but there are more important tasks right now. As soon as it is back the "on vacation" note at the dev.gnupg.org link will be removed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ben at adversary.org Fri Aug 31 14:27:30 2018 From: ben at adversary.org (Ben McGinnes) Date: Fri, 31 Aug 2018 22:27:30 +1000 Subject: gpgme python bindings release plans? In-Reply-To: <50e0b11561bb703206e08345e26fb8f21123ad64.camel@cryptobitch.de> References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> <50e0b11561bb703206e08345e26fb8f21123ad64.camel@cryptobitch.de> Message-ID: <20180831122730.zlxrezmxnhu7eiio@adversary.org> On Fri, Aug 31, 2018 at 11:23:49AM +0200, Tobias Mueller wrote: > Hi, > > On Thu, 2018-08-30 at 16:44 +1000, Ben McGinnes wrote: > > In order to dynamically generate the bindings, we > > must have the location of gpgme.h for that specific architecture, > > operating system and build. > but you could still upload upload binary packages to PyPI, if you wanted > to, no? Because the technical reasons you cite should be covered by > PEP513. These bindings don't meet the requirements of PEP513. Indeed, the very purpose of the bindings explicitly breaks the manylinux policy that PEP discusses. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ben at adversary.org Fri Aug 31 18:31:46 2018 From: ben at adversary.org (Ben McGinnes) Date: Sat, 1 Sep 2018 02:31:46 +1000 Subject: gpgme python bindings release plans? References: <20106d60-e5c7-a37b-312f-3a2ec9b87e21@digitalbrains.com> <20180830064441.z7ngi3ljmx4t7scw@adversary.org> Message-ID: <20180831163146.hpwut45rfb2hrmth@adversary.org> On Thu, Aug 30, 2018 at 04:33:24PM +0200, Jasper Spaans wrote: > On 30/08/2018 08:44, Ben McGinnes wrote: > > I've fixed those conflicts with this commit: > > 1d00fb987b903e245d484bddfe3c0a0aba670ac1 > > > > That, however, required changing both of your updates, so you should > > test it ASAP to see if it still works or whether Ubuntu is going to be > > a point of pain in future. > Indeed your fix has broken my build instead. > > (I don't know what Ubuntu has to do with this; and in case my previous > message was not clear enough: I did not use any Ubuntu-provided versions > of libgpg-error or gpgme. I wouldn't be surprised if this will cause > breakage on Debian as well.) Oh, by the way, when you compiled GPGME and subsequently the Python bindings, which C compiler did you use: GCC or Clang? Also which version of either was used? What is the output of: python3.5 -c "import sys; print(sys.version)" Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: