On Wed, 06 Sep 2017 13:59:43 -0400
Daniel Kahn Gillmor wrote:
> after making that configuration file, have you explicitly restarted
> dirmngr? the simplest way is:
>
> gpgconf --kill dirmngr
>
Thank you, Daniel. There was a problem with how I was restarting
dirmngr on my script. You post
I'm having trouble configuring dirmngr to use a default keyserver.
The current configuration file at .gnupg/dirmngr.conf contains this
single line:
keyserver hkp://pgp.mit.edu
However trying to use --recv-keys always fails:
$ gpg --recv-keys 0x194b631ab2da2888
gpg: no valid OpenPGP
On Tue, 29 Aug 2017 14:33:46 -0400
"Robert J. Hansen" wrote:
> You can prove origination *only if* you can prove the originating PC
> was not compromised. Given how common compromise is today -- a few
> years ago Vint Cerf estimated one in four desktop PCs was compromised
> -- this is a very hig
On Fri, 4 Aug 2017 09:56:09 +
Fiedler Roman wrote:
> PS: CAVEAT, gnupg-users list seems to be configured in strange way:
> "reply to all" does not reply to the list, so please add address
> manually.
OT sidenote: Took me a while to realize this, and I must have annoyed a
few people on my ear
"The researchers didn't perform an exhaustive analysis of the encryption
methods devised by Alice and Bob"
So there isn't much that can be said. The experiment was pretty much a
game of life between the couple and Eve, with the more than predictable
outcome that Eve shows signs of gaining ground r
On Mon, 31 Jul 2017 18:38:09 +0200
Damien Goutte-Gattat wrote:
> The problem with recommanding unnecessary steps is that they will
> confuse the beginner and make him think that GnuPG is more difficult
> to use than it already is.
Which essentially describes my whole first impressions of GnuPG
On Mon, 31 Jul 2017 15:44:52 +0100
Mario Figueiredo wrote:
> On a separate tutorial (2), Alan Eliasen strongly advises against this
> practice.
I'm replying to my own post, because the above seem a little like I'm
trying to make an argument from authority. That was not my inte
On Sun, 30 Jul 2017 22:19:22 +0200
Dirk-Willem van Gulik wrote:
> I see a growing number of keys that have well managed & expired
> separate subkeys for Signing, Encryption and Authentication switch
> from ‘SC’ on the master key to just ‘C’ (all RSA, ignoring DSA).
>
> Would anyone know if there
On Thu, 27 Jul 2017 14:23:44 +0200
Peter Lebbing wrote:
> Now let's get on to a passphrase manager and GnuPG specifically. A
> different way to look at it is this: would you use GnuPG to protect
> your passphrase manager? This is actually a feature request I've seen
> multiple times: please provi
On Thu, 27 Jul 2017 11:46:33 +0200
Peter Lebbing wrote:
[...]
> shared the passphrase. If you can't remember which is 1 and which is
> 2, use something you can recognise. For instance, if the pinentry
> asks you "Please unlock key 0x6228A8BC", you could append a C, the
> very last digit of the id
On Thu, 27 Jul 2017 12:27:30 +0100
MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote:
>
> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.
I already use a p
On Wed, 26 Jul 2017 08:52:12 +0200
Werner Koch wrote:
> There is a kludge in gpg and gpg-agent described in this comment:
> [...]
Hello Werner,
Thank you for the information and debug method. And hopefully this
problem will be fixed sometime in the near future. My brain is old
and tired and it
Hello everyone,
I've been trying to understand gpg-agent cache behavior in the presence
of two distinct keys with the same passphrase. Namely, why is that it
only asks for the passphrase once, regardless of the key being used?
So I've read the Assuan protocol documentation at (1), in particular
t
13 matches
Mail list logo
