[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23619: Some epg tests fail
From: |
npostavs |
Subject: |
bug#23619: Some epg tests fail |
Date: |
Mon, 20 Feb 2017 13:16:37 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Daiki Ueno <ueno@gnu.org> writes:
> npostavs@users.sourceforge.net writes:
>
>> Although this doesn't solve the problem for gpg 2.0.
>
> For a proper fix, you might want to check how GPGME and its test suites
> do.
I don't see anything to handle gpg 2.0, specifically. They do disable
pinentry for versions below 2.1. Maybe their tests don't work with 2.0
either?
>> I think we could use '--batch' with '--passphrase' or 'passphrase-fd'
>> for this, although neither of these works as a callback.
>
> If that approach makes all interactions with gpg synchronous, it
> wouldn't be acceptable.
With '--passphrase-fd', interactions remain asynchronous from Emacs'
point of view, but gpg sends no output until receiving the passphrase on
the given fd, so the normal callback doesn't get triggered. So to make
that work, we would have to send the callback's output immediately after
starting the gpg process.
Using '--passphrase' means giving the passphrase on the command line,
which is not very good in terms of security for normal use, though
acceptable for tests.
- bug#23619: Some epg tests fail, npostavs, 2017/02/19
- bug#23619: Some epg tests fail, Daiki Ueno, 2017/02/19
- bug#23619: Some epg tests fail, npostavs, 2017/02/19
- bug#23619: Some epg tests fail, Daiki Ueno, 2017/02/20
- bug#23619: Some epg tests fail, npostavs, 2017/02/20
- bug#23619: Some epg tests fail, Daiki Ueno, 2017/02/20
- bug#23619: Some epg tests fail,
npostavs <=
- bug#23619: Some epg tests fail, Daiki Ueno, 2017/02/21
- bug#23619: Some epg tests fail, npostavs, 2017/02/21
- bug#23619: Some epg tests fail, Daiki Ueno, 2017/02/24
- bug#23619: Some epg tests fail, npostavs, 2017/02/28