Re: Thoughts on GnuPG and automation

2015-03-04 Thread Ville Määttä
On 04.03.15 12:48, Werner Koch wrote: >> that doesn't tell you about proprietary projects that have chosen not to >> > use GPGME. I've had clients refuse to use GPGME because of the >> > licensing, even under the LGPLv2.1. (Foolish, I know.) Other times > And I have had several hints that it was

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Ville Määttä
On 04.03.15 18:21, Bjarni Runar Einarsson wrote: > GPGME proponents will be frustrated to hear that this knowledge actually > makes me feel much better about Mailpile's decision to wrap gpg > directly: it means I've removed two layers of abstraction between my > code and gpg! Win! Although supposed

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Ville Määttä
On 04.03.15 01:55, Hans of Guardian wrote: > In Android, you can't really have shared libraries. Apps share functionality > at a higher level (aka Activities and Services). Qt applications can share Qt libraries [1] with an external dependency called Ministro [2]. [1]: http://doc.qt.io/qtcreato

where can one find an official gnupg project statement on the state of sub project?

2015-03-04 Thread Paulo Lopes
Hello, I am a active use of gnupg and gnupg smart card, and unfortunately my OSS contributions are to other projects where I do have more experience so I totally understand any reply to my question. Currently I use: * gnupg * gnupg2 * poldi And did use: * scute It turns out that gnupg and gnu

Re: Re: Thoughts on GnuPG and automation

2015-03-04 Thread Bjarni Runar Einarsson
Werner Koch wrote: > > > I think that one solution would be to have mailpile use a per-session > > gpg home dir. > > That is an architectural decision. > > BTW, gpg-agent has this --extra-socket feature which distinguishes > between remote and local use (modulo some discussed changes). It woul

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Steve Jones
On Wed, 04 Mar 2015 10:50:53 +0100 "Robert J. Hansen" wrote: > The possibility of *every encrypted communication* being intercepted > and stored for later exploitation ... is not real, and we need to stop > treating it as such. I remember when we used to think this about the NSA or GCHQ taking i

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Tue, 3 Mar 2015 16:23, br...@minton.name said: > It breaks mailpile because gpg-agent is not session aware. A user could > be logged in locally, using mailpile, and a remote attacker could access > the web interface of that locally running mailpile instance, which since > it is talking to the

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 11:10, pe...@digitalbrains.com said: > > [JSON] > > [GPGME] That already exists: gpgme-tool. It creates output in XML but adding an option for JSON output should be straightforward. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Robert J. Hansen
> That has not been said. Not by you, correct. I've heard it from others. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 10:57, r...@sixdemonbag.org said: > You're looking at FOSS projects that have successfully used GPGME, but Sure. > that doesn't tell you about proprietary projects that have chosen not to > use GPGME. I've had clients refuse to use GPGME because of the > licensing, even unde

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 10:50, r...@sixdemonbag.org said: >> I don't known for sure about encrypted mail but it is known that >> https connection information is recorded and stored for future >> attacks: > > Perhaps. Plausible, even, given storage requirements for connection > information. But stor

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Peter Lebbing
On 04/03/15 00:55, Hans of Guardian wrote: > [...] what I'm trying to say is that for programming environments > where GPGME does not make sense, there should be the ability to > easily make a native version of what GPGME is doing. Couldn't this be achieved by writing a C program that, for instanc

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Daniele Nicolodi
On 03/03/15 14:29, Hans of Guardian wrote: > It is actually more difficult to wrap GPGME in Java than to have just > rewritten GPGME in Java. GPGME is a fine API for C/C++, it is a bad > API for other languages. You end up with an API that feels like a C > API forced into the language, e.g. Java,

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Tue, 3 Mar 2015 21:29, h...@guardianproject.info said: > * Android will kill apps when it needs to, app lifecycle is automatically > managed, > the app has no control over it, and often zero warning is given That is the same as with Linux. Ever heard of the OOM killer? > * Android was not

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Robert J. Hansen
> It can't be that bad: > > $ apt-cache rdepends libgpgme11 | wc -l 84 > > and the majority of problems I hear are by projects which do not use > GPGME. So I wonder a bit about your statement. You're looking at FOSS projects that have successfully used GPGME, but that doesn't tell you about pr

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Robert J. Hansen
> I don't known for sure about encrypted mail but it is known that > https connection information is recorded and stored for future > attacks: Perhaps. Plausible, even, given storage requirements for connection information. But storing traffic, when 99.99% of it is good -- that's ridiculou

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 01:43, robe...@broadcom.com said: > I think Peter and the group already adequately answered this: If GPGME > is not providing an interface that meets Android requirements, then > look into how GPGME interfaces to GPG and emulate that interface. FWIW, EasyPG, the GnuPG interfac

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 00:50, h...@guardianproject.info said: > If you are interested, you should read the details. Because you are > missing some key details here. I believe they log all PGP encrypted > communication. That would be easy for them to do. I don't know about > HTTPS. I don't known

Re: Thoughts on GnuPG and automation

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 01:45, r...@sixdemonbag.org said: > ever hacked on GnuPG has found situations where GPGME isn't a good > solution, sometimes for architectural reasons and sometimes for API > reasons and sometimes for language binding reasons and sometimes for > licensing reasons and... etc. I

gpgme and Java (was: Thoughts on GnuPG and automation)

2015-03-04 Thread Werner Koch
On Wed, 4 Mar 2015 00:57, h...@guardianproject.info said: > thread at this point. The bizarre Java wrapper of GPGME was not the > biggest part of the problem of the GnuPG-for-Android port, but it was > nonetheless a real problem. Sure it is possible to use GPGME with You mean Stefan's decade o