On 21/02/18 17:22, Teemu Likonen wrote:
> default-key FINGERPRINT!
That would help for command-line usage for a user with only one private
key. But anything else might not use the default key.
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me
Daniel Kahn Gillmor [2018-02-20 21:35:12-08] wrote:
> Anyway, here's one concrete example (hinted at above) of a
> programmatic gap that is much easier to achieve by mucking around with
> the internal state rather than by the programmatic interface:
>
> * I want to introduce a new
On Tue, 20 Feb 2018 20:36, n...@walfield.org said:
> "uncool". I left because we (Werner and I) could not work well
> together. This is the same reason that Justus, Kai and Marcus left.
Okay, you raised it and now my Lavamat wants to reply on this: Secret
negotiations with other companies,
On Tue 2018-02-20 16:08:35 +0100, Werner Koch wrote:
> On Mon, 19 Feb 2018 19:45, d...@fifthhorseman.net said:
>
>> GnuPG is under active development, and it has never had a fully-featured
>> stable API (Application Programming Interface). What i mean is, there
>> are some capabilities that are
On Tue 2018-02-20 13:18:40 +0100, Dashamir Hoxha wrote:
> One solution to this situation may be to install the latest GnuPG
> in a Docker container, where it can have all the required libraries
> and dependencies that it needs, without disturbing the host OS.
I think this misses the point that
On Mon, Feb 19, 2018 at 10:45:52AM -0800, Daniel Kahn Gillmor wrote:
>
> How can GnuPG contribute to fixing this problem? The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have
At Tue, 20 Feb 2018 16:08:35 +0100,
Werner Koch wrote:
> > Yet another complementary approach might be to aggressively police the
> > ecosystem by finding other software that deends on GnuPG in any of the
> > aforementioned brittle ways, and either ask those developers to stop
>
> That is what
On Mon, 19 Feb 2018 19:45, d...@fifthhorseman.net said:
> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface). What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not
On 02/20/2018 01:18 PM, Dashamir Hoxha wrote:
> If anybody is willing to give a try to any of these solutions I would
> like to help.
I would be generally cautious for both approaches without proper support
in the surrounding infrastructure. In particular an upgrade to a
depending library would
On Mon, Feb 19, 2018 at 7:45 PM, Daniel Kahn Gillmor
wrote:
> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try
On 19/02/18 19:45, Daniel Kahn Gillmor wrote:
> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.
You are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Monday 19 February 2018 at 8:51:08 PM, in a message with no id,
ed...@pettijohn-web.com wrote:-
> I think gpgme is the answer here as well. If you mean
> specifically
> a python interface to gpgme then it's probably up to
> a python
On Feb 19, 2018 12:45 PM, Daniel Kahn Gillmor wrote:
>
> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try to
On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.
Here's one last try to explain the situation.
GnuPG (and the libraries it depends on) are used by (aka "depended
14 matches
Mail list logo