Re: Thoughts on GnuPG and automation

[Werner Koch]

On Thu, 26 Feb 2015 15:57, b...@pagekite.net said:

> As it's rather long, I won't paste the whole thing in here, but I do

Please give me a few days to comment on this.  I have some urgent tasks
right now.  But as a first hint: automation has never been second class
citizen and has been build into gpg more or less right from the
beginning (0.2.12, spring 1998).

I know of one university in Germany which runs its webmail system using
GnuPG 2 and with pinentry.  This was actually the reasons to add the
PINENTRY_USER_DATA kludge.

Back to release work.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

Bjarni Runar Einarsson wrote:
> Hello GnuPG users!
> 
> I just published a follow-up to Smári's blog post about the Mailpile
> team's frustration while working with GnuPG. The post is here:
> 
>
> https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html
> 
> As it's rather long, I won't paste the whole thing in here, but I do
> welcome any and all feedback. The gist of it is: the GnuPG CLI is not
> very well suited for automation and the 2.x design appears to make some
> things we want to do almost impossible.
> 
> Corrections (if I made any factual errors) will be posted to the web
> ASAP, and I'll link back to this thread in the archives so webby people
> can see your replies. I hope this qualifies as constructive critism!
> 
> As I said on our IRC channel: If we're lucky it'll be a humiliating
> "you're just doing it wrong, here is the solution". ;-)
> 
> Cheers,
>  - Bjarni
> 
> -- 
> Sent using Mailpile, Free Software from www.mailpile.is

As the lead dev on the Android port of GnuPG, I definitely can share your pain
on working with the GnuPG suite.  For example, GnuPG is built heavily around
UNIX assumptions, and Android is not UNIX at all, and it is much further from
UNIX than Windows is.  We ultimately got pinentry working on Android, with
much struggle.  After going through that, I also had lots of grips, which I
probably should have written up like you did.

With all the recent attention to GnuPG and Werner's work, I have begun to
think about things differently.  GnuPG has an amazing security track record.
It has had few serious security bugs, nothing even close to heartbleed that I
know of, and yet it is core to providing security to GNU/Linux distros, as
well as protecting people like Laura Poitras and Edward Snowden.  So instead
of complaining about the difficulties, I now try to think about whether such
difficulties might actually be related to what makes GnuPG so solid.  I think
anyone interested in providing usable security needs to think hard about this.
 Sure we can make things easier to use, but it is a very slippery slope
towards reducing security.

I also have to call out that part of the problem that mailpile is continuing:
it is generally more fun to write code, rather than figure out someone else's
library.  That is especially true when its a complicated thing like GnuPG.
But in order to have shared maintenance and work, we all need to take
responsibility and try to build upon the work of others whenever possible.
Mailpile did not do that, and instead wrote yet another incomplete python API
for GnuPG.

Now all that said, we definitely need to be debating how to improve working
with GnuPG so that we can build software that is intuitive and private by
design, on top of the solid GnuPG track record.  For example, I think that
`gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have `gpg
--json` as the parseble interface, then implement a GPGME-style framework in
each language (Python, Java, etc).

Another possibility is making ASSUAN, the internal protocol between GnuPG
components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as
far as I understand it, since in 2.1, even commands like gpg communicate with
gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work.
Contrary to the mailpile write-ups, I think that having all the work happen in
gpg-agent makes sense, as long as there is a good API to it.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 12:02 PM, Hans-Christoph Steiner wrote:
> 
> Bjarni Runar Einarsson wrote:
>> Hello GnuPG users!

..

> 
> With all the recent attention to GnuPG and Werner's work, I have
> begun to think about things differently.  GnuPG has an amazing
> security track record. It has had few serious security bugs,
> nothing even close to heartbleed that I know of, and yet it is core
> to providing security to GNU/Linux distros, as well as protecting
> people like Laura Poitras and Edward Snowden.  So instead of
> complaining about the difficulties, I now try to think about
> whether such difficulties might actually be related to what makes
> GnuPG so solid.  I think anyone interested in providing usable
> security needs to think hard about this. Sure we can make things
> easier to use, but it is a very slippery slope towards reducing
> security.
> 

Hear hear, you can't have proper security without proper operational
security surrounding it, and that require an educated population to
use it.

Security is not something that can be solved technically (alone). What
we would need are better ways to educate people, and get it into
school earlier, like the algorithm classes in kindergarden in britain
teching kids algos through games (i.e physical games)

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Manus manum lavat
One hand washes the other
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8F0yAAoJEP7VAChXwav6UrsH+wWhafqn1fDjW3SE789jdsRm
/9M3e8ZPmueNB4CDadig3/4nFrl5WTcMrXfDMC62xXLTwftu2mSe8K8t7QX2CDRn
VgdTU07gARqnkwEcV+I82Y9SKeUaDfGRmoWUgh0+T3Z4MozXvp23BlFoqcHrKK5H
9ld/Sj5Ncd63JfUQKlEi4kakyGIShctoJ+P0gDje31pqVP65znWw+xi4F06sW0dm
FYPtogg73vtpJkQI6is9Luw7BFR+dE+pWGrxP6166igu1Mwn8I5bg05tqxjFe7dL
weIZffLCd8+iRsNnsr29xbKahsvvfyIrimKZX0nXvuflHftMC2uYARKdx+q8eUw=
=Xs+E
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Peter Lebbing]

On 27/02/15 12:02, Hans-Christoph Steiner wrote:
> For example, I think that
> `gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
> is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have `gpg
> --json` as the parseble interface, then implement a GPGME-style framework in
> each language (Python, Java, etc).

I'd say the JSON interface could just be an additional set of functions in
GPGME; and GPGME simply talks the old colon-separated protocol to the gpg
binary. You can't just take out the colon-separated protocol, and that protocol
has all the information. You could simply have GPGME reformat the output.

Unless you mean that you want to speak to the gpg binary yourself, without GPGME
in between. In that, case, I simply think you might be on the wrong track, and
should use a library. If GPGME itself is a problem because you don't know what
platform you should compile for, like in Python, then the library could be
re-implemented in pure Python instead of using a foreign function interface.

The old calling conventions of the binary cannot change, otherwise you'd break
everything that already depends on it. And adding multiple ways of doing the
same thing in the gpg binary seems the wrong place; more code, more chance of
bugs, etcetera. This is where libraries come in, to save you the burden of
working with the gpg binary.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Brian Minton]

Yes, but the colon protocol doesn't support things like passphrase entry, etc.

On Fri, Feb 27, 2015 at 9:09 AM, Peter Lebbing  wrote:
> On 27/02/15 12:02, Hans-Christoph Steiner wrote:
>> For example, I think that
>> `gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
>> is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have 
>> `gpg
>> --json` as the parseble interface, then implement a GPGME-style framework in
>> each language (Python, Java, etc).
>
> I'd say the JSON interface could just be an additional set of functions in
> GPGME; and GPGME simply talks the old colon-separated protocol to the gpg
> binary. You can't just take out the colon-separated protocol, and that 
> protocol
> has all the information. You could simply have GPGME reformat the output.
>
> Unless you mean that you want to speak to the gpg binary yourself, without 
> GPGME
> in between. In that, case, I simply think you might be on the wrong track, and
> should use a library. If GPGME itself is a problem because you don't know what
> platform you should compile for, like in Python, then the library could be
> re-implemented in pure Python instead of using a foreign function interface.
>
> The old calling conventions of the binary cannot change, otherwise you'd break
> everything that already depends on it. And adding multiple ways of doing the
> same thing in the gpg binary seems the wrong place; more code, more chance of
> bugs, etcetera. This is where libraries come in, to save you the burden of
> working with the gpg binary.
>
> 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 
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Feb 27, 2015, at 3:09 PM, Peter Lebbing wrote:

> On 27/02/15 12:02, Hans-Christoph Steiner wrote:
>> For example, I think that
>> `gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
>> is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have 
>> `gpg
>> --json` as the parseble interface, then implement a GPGME-style framework in
>> each language (Python, Java, etc).
> 
> I'd say the JSON interface could just be an additional set of functions in
> GPGME; and GPGME simply talks the old colon-separated protocol to the gpg
> binary. You can't just take out the colon-separated protocol, and that 
> protocol
> has all the information. You could simply have GPGME reformat the output.
> 
> Unless you mean that you want to speak to the gpg binary yourself, without 
> GPGME
> in between. In that, case, I simply think you might be on the wrong track, and
> should use a library. If GPGME itself is a problem because you don't know what
> platform you should compile for, like in Python, then the library could be
> re-implemented in pure Python instead of using a foreign function interface.
> 
> The old calling conventions of the binary cannot change, otherwise you'd break
> everything that already depends on it. And adding multiple ways of doing the
> same thing in the gpg binary seems the wrong place; more code, more chance of
> bugs, etcetera. This is where libraries come in, to save you the burden of
> working with the gpg binary.

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, python, etc.  That makes for more coding mistakes because 
it feels foreign to the programmer.  More mistakes means more security issues.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Brian Minton]

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 same gpg-agent, would think the remote user is
logged in (or more precisely, has the private key).

I think that one solution would be to have mailpile use a per-session
gpg home dir.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Peter Lebbing]

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.

In my opinion, if this is the case, then that is indeed the proper
solution: write a general-purpose library à la GPGME, but don't call gpg
directly from your application.

Calling the gpg binary is indeed an API, as was said here. It's the API
GPGME uses, for instance. GPGME does not somehow load gpg in its address
space or something; it simply invokes gpg, in a separate process.

That calling the gpg binary is an API doesn't make it the right API for
other programs to use. The right API in general would be GPGME or an
alternative to GPGME.

Just like libc is the proper API for a program to use instead of
directly issuing syscalls to the Linux kernel. The syscall interface is
an API; it's just not the right one in many cases.

At least, this is my view of it.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Feb 27, 2015, at 1:19 PM, Bjarni Runar Einarsson wrote:

> Hi Hans-Christoph!
> 
> Hans-Christoph Steiner  wrote:
>> With all the recent attention to GnuPG and Werner's work, I have begun to
>> think about things differently.  GnuPG has an amazing security track record.
>> It has had few serious security bugs, nothing even close to heartbleed that I
>> know of, and yet it is core to providing security to GNU/Linux distros, as
>> well as protecting people like Laura Poitras and Edward Snowden. So instead
>> of complaining about the difficulties, I now try to think about whether such
>> difficulties might actually be related to what makes GnuPG so solid.
> 
> Some of the more jaded will call this Stockholm syndrome. :-P
> 
> I don't agree with the voices that want to discard PGP and start from
> scratch. There is valuable experience and maturity in this project,
> which is why we care enough to complain when it is hard to work with.
> 
>> anyone interested in providing usable security needs to think hard about 
>> this.
>> Sure we can make things easier to use, but it is a very slippery slope
>> towards reducing security.
> 
> I really disagree with this. If a security tool is too hard to
> understand, whether for a developer or user, then insecurity will be the
> inevitable result: people will use it wrong. This is only in part
> GnuPG's resposibility, most of the complexity is inherited from OpenPGP
> and the fact that public/private key crypto and key management are just
> very complex topics.
> 
> This is the one point where I agree with the voices calling for
> abandoning OpenPGP entirely. It can well be argued that the whole
> cryptoscheme has been field tested and proven too complex for humans to
> use correctly. That's not exactly GnuPG's problem either, but these
> voices are becoming louder and, increasingly, there is finally
> competition in this space. The project will get marginalized if
> usability is ignored completely.
> 
> Mailpile's attempt to make OpenPGP easy to use is us stubbornly trying
> to prove that it can be done. But I'm only somewhat optimistic that
> we'll succeed, and we'll only do so if we face reality and drop a large
> number of the features that make PGP what it is - in particular the web
> of trust and default trust model, and who knows what else. I don't mind
> if that code exists inside GnuPG, but Mailpile is absolutely not going
> to be using it.

I think if you actually disagree, you are missing my essential point.  But my 
guess is that we agree more than disagree.  Of course, I entirely agree that 
bad usability can also make a technically secure system actually very insecure. 
 This point is not mutually exclusive with what I said, and indeed both must be 
taken fully into account.

So for example, we could make PGP email really easy if we consider only a mass 
surveillance threat model.  Just make all the processes transparent in the 
background: passphrases, key generation, downloading public keys, etc.  But 
that would produce a system that would not work for the highly targeted threat 
models like Edward Snowden and Laura Poitras.  They would need to use a 
specialized system, and that specialized system might then be a marker of 
suspicion (for example, lots of governments, including the NSA, already mark 
all PGP messages as suspicious).  That then makes it a lot harder for people 
who suddenly realize that they might be under scrutiny.

There is a big tide of thinking about usability of security tools.  This is a 
great thing, and we need lots of contributions. But what it happening far too 
often these days is that the new generation are trumpeting "ease of use" above 
all else.  We are seeing systems like keybase.io that make things really easy, 
but also expect users to upload their _private_ key to some alpha web service.  
That is terrible security practice.

I've also been arguing that we need to make encryption much easier to do.  But 
we are failing as UX designers if we do not deeply understand the systems that 
are trying to make easier to use.  And that is why I advocate thinking long and 
hard about GnuPG, and what makes it hard to use, and what makes it secure.  
Only then can we really make solid security usable.


>> I also have to call out that part of the problem that mailpile is continuing:
>> it is generally more fun to write code, rather than figure out someone else's
>> library. That is especially true when its a complicated thing like GnuPG.
>> But in order to have shared maintenance and work, we all need to take
>> responsibility and try to build upon the work of others whenever possible.
>> Mailpile did not do that, and instead wrote yet another incomplete
>> python API for GnuPG.
> 
> Fair enough. We were in a hurry, and we probably did make a mistake
> here. There is a reason why we haven't broken our library out and
> published separately though: we do hope to tear it out and replace it
> with something more standard down the li

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

Hans, please trim your quoted material.

> They would need to use a specialized system, and that specialized
> system might then be a marker of suspicion (for example, lots of
> governments, including the NSA, already mark all PGP messages as
> suspicious).

Unless you've got a desk somewhere deep inside Fort Meade and you're
sitting in on briefings the rest of us aren't, you don't know this.

There's a lot of panic and paranoia in the air already without people
making it worse by treating what they *think* is true as if they *know*
it's true.

(I don't know if what he's claiming is true or false... but I *do* know
that I don't believe his certainty, and I wouldn't believe anyone else
who claimed to be certain, either!)

> trumpeting "ease of use" above all else.  We are seeing systems like 
> keybase.io that make things really easy, but also expect users to 
> upload their _private_ key to some alpha web service.

keybase doesn't expect users to upload the private key.  It works just
fine if you don't, and in fact you have to go through an extra couple of
steps to put the private key on the keybase servers.

For some use cases this is a good practice.  For many more it's a bad
practice.  But it's way too facile to simply say,

> That is terrible security practice.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

Yeah, mailpile has a very unusual architecture, so its no surprise it'll need 
some unusual tricks.  Unusual tricks in software that aims to be secure 
generally make me nervous since it is important to keep code readable and 
understandable for both the core devs, but also contributors, auditors, etc.

.hc

On Mar 3, 2015, at 4:23 PM, Brian Minton wrote:

> 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 same gpg-agent, would think the remote user is
> logged in (or more precisely, has the private key).
> 
> I think that one solution would be to have mailpile use a per-session
> gpg home dir.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 4:43 PM, Peter Lebbing wrote:

> 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.
> 
> In my opinion, if this is the case, then that is indeed the proper
> solution: write a general-purpose library à la GPGME, but don't call gpg
> directly from your application.
> 
> Calling the gpg binary is indeed an API, as was said here. It's the API
> GPGME uses, for instance. GPGME does not somehow load gpg in its address
> space or something; it simply invokes gpg, in a separate process.
> 
> That calling the gpg binary is an API doesn't make it the right API for
> other programs to use. The right API in general would be GPGME or an
> alternative to GPGME.
> 
> Just like libc is the proper API for a program to use instead of
> directly issuing syscalls to the Linux kernel. The syscall interface is
> an API; it's just not the right one in many cases.
> 
> At least, this is my view of it.
> 
> Peter.

Different programming languages and operating systems can have very different 
ways of launching and handling external processes.  By forcing them all to 
launch GPG in the UNIX way makes for complicated and weird software.  For 
example, Android works very differently than any UNIX or even Windows, 
especially when it comes to launching and managing processes.

At the risk of being repetitive: Android runs the Linux kernel, but is it far 
far far from being UNIX or GNU/Linux.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> Different programming languages and operating systems can have very 
> different ways of launching and handling external processes.

Eh.  Different operating systems, sure: that's the nature of kernels.
They provide different syscalls, and that's at root how you launch an
external process -- by making syscalls.

But different programming languages can have very different ways of
launching and handling external processes?  I've never seen that to be
true.  C#'s Process, C's fork/exec, Python's subprocess, Go's
syscall.StartProcess()... it's all pretty much identical.  There are a
couple of exotics, but they're exotic.

> By forcing them all to launch GPG in the UNIX way makes for
> complicated and weird software.

It *can* make for complicated and weird software.  I don't doubt that
GnuPG doesn't fit well into the Android model, but this isn't a reason
to do GPGME differently.

If I'm Count Rugen, I'm not going to complain that glovemakers need to
change the way they do things to accommodate my six fingers.  I'm going
to acknowledge that my hands are quite a lot different from the
glovemakers' models, and rather than tell the glovemakers how
five-fingered gloves are a mistake because they don't account for the
possibility of six, I'm just going to hire a tailor to make my gloves.

(Count Rugen: the six-fingered villain from _The Princess Bride_.)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 5:01 PM, Robert J. Hansen wrote:

> Hans, please trim your quoted material.
> 
>> They would need to use a specialized system, and that specialized
>> system might then be a marker of suspicion (for example, lots of
>> governments, including the NSA, already mark all PGP messages as
>> suspicious).
> 
> Unless you've got a desk somewhere deep inside Fort Meade and you're
> sitting in on briefings the rest of us aren't, you don't know this.
> 
> There's a lot of panic and paranoia in the air already without people
> making it worse by treating what they *think* is true as if they *know*
> it's true.
> 
> (I don't know if what he's claiming is true or false... but I *do* know
> that I don't believe his certainty, and I wouldn't believe anyone else
> who claimed to be certain, either!)

This is definitely public information from the Snowden leaks.  There is also 
quite a bit of information about other governments doing similar things.  
Here's one example article:

http://www.forbes.com/sites/andygreenberg/2013/06/20/leaked-nsa-doc-says-it-can-collect-and-keep-your-encrypted-data-as-long-as-it-takes-to-crack-it/

> 
>> trumpeting "ease of use" above all else.  We are seeing systems like 
>> keybase.io that make things really easy, but also expect users to 
>> upload their _private_ key to some alpha web service.
> 
> keybase doesn't expect users to upload the private key.  It works just
> fine if you don't, and in fact you have to go through an extra couple of
> steps to put the private key on the keybase servers.
> 
> For some use cases this is a good practice.  For many more it's a bad
> practice.  But it's way too facile to simply say,
> 
>> That is terrible security practice.

keybase has started to downplay the private key stuff.  When it started, you 
had to upload your private key to use the service.

Uploading your private key to keybase sets people up for a centralized system 
with terrible security. It'll be an obvious target, and they are a startup 
doing webby things, which also has a terrible security track record.  There are 
so many exploits in ruby, javascript, etc.  The fact that they even considered 
this an option just shows that they only care about easy, not about secure.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 5:49 PM, Robert J. Hansen wrote:

>> Different programming languages and operating systems can have very 
>> different ways of launching and handling external processes.
> 
> Eh.  Different operating systems, sure: that's the nature of kernels.
> They provide different syscalls, and that's at root how you launch an
> external process -- by making syscalls.
> 
> But different programming languages can have very different ways of
> launching and handling external processes?  I've never seen that to be
> true.  C#'s Process, C's fork/exec, Python's subprocess, Go's
> syscall.StartProcess()... it's all pretty much identical.  There are a
> couple of exotics, but they're exotic.
> 
>> By forcing them all to launch GPG in the UNIX way makes for
>> complicated and weird software.
> 
> It *can* make for complicated and weird software.  I don't doubt that
> GnuPG doesn't fit well into the Android model, but this isn't a reason
> to do GPGME differently.
> 
> If I'm Count Rugen, I'm not going to complain that glovemakers need to
> change the way they do things to accommodate my six fingers.  I'm going
> to acknowledge that my hands are quite a lot different from the
> glovemakers' models, and rather than tell the glovemakers how
> five-fingered gloves are a mistake because they don't account for the
> possibility of six, I'm just going to hire a tailor to make my gloves.
> 
> (Count Rugen: the six-fingered villain from _The Princess Bride_.)

Android has an installed base of hundreds of millions.  Desktop UNIX is the 
exotic system here as compared to Windows, Android, etc.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Peter Lebbing]

On 03/03/15 18:29, Hans of Guardian wrote:
> Android has an installed base of hundreds of millions.  Desktop UNIX
> is the exotic system here as compared to Windows, Android, etc.

I have no idea about how difficult it is to launch the gpg binary with a
few pipes attached to a few file descriptors and perhaps anything else
you need.

But I fail to see why you brought it up.

I thought we were discussing two alternatives:

- Call gpg directly
- Use a library such as GPGME that calls gpg for you

In both cases, the gpg binary is executed as a separate process. So it
seems to me any issues with this are the same in both cases. In fact, if
it indeed is tricky as you say, you're better off if you have a library
do this for you, so you don't have to get it right in each and every
application.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> This is definitely public information from the Snowden leaks.  There 
> is also quite a bit of information about other governments doing 
> similar things.  Here's one example article:

If all encrypted traffic is deemed suspicious, then 99.999% of the
suspicious set -- Amazon transactions, Google searches, SMTP transfers,
instant messaging, OkCupid profiles, iTunes purchases, and more -- is
totally clean.  You'd have statistically better odds by arresting random
people on suspicion of murder.  The policy would be completely
pants-on-head absurd.

This leads to a different question: "Is it more likely that this is the
real pants-on-head absurd policy, or that the _Forbes_ journo has
profoundly misunderstood the subject?"

Just because something's been published doesn't mean it should be
trusted.  Bring your brain -- and when someone tells you something that
supports your worldview, look at that thing hard and twice.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> Android has an installed base of hundreds of millions.

So?

GnuPG and GPGME are products of their birth, just like anything else.
It was built for desktop operating systems.  If you want to make it live
in the mobile space, go with God and I wish you all the luck in the
world -- but if GPGME isn't working well for you, the burden is on you
to do something better.  The burden isn't on GPGME to totally change how
it does things.

I really don't understand what you're getting at here.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Werner Koch]

On Tue,  3 Mar 2015 14:29, h...@guardianproject.info said:

> 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

Sorry, but that is not your problem.  The problem on Android seems to be
that it is not easy to install anything else than plain Java apps.

We have GPGME bindings for all kind of languages from Ada over Java to
Scheme.  Thus I can't see the problem - need another kind of data object
to be handled in GPGME?  No problem, it can easily be done.  Is the
event loop the problem?  That is somewhat harder to get right but that
is always the case if you use a library.

I don't really understand your complaints given that we worked together
to port GnuPG to Android.  GPGME is just a small thing on top of it and
way easier than GnuPG itself.  It has nothing to do with fork+exec -
GnuPG uses that itself a lot.

In 2010 we ported GnuPG and GPGME and Kontact (includes KMail) to
Windows Mobile 6.5.  I can tell you, that was a task but we finally did
it.  And the problems were not due to GnuPG (even that it ate up many of
the scarce process slots) but due to the shear amount of memory KDE
stuff required.  Consider as an example this: On Windows CE (the kernel
of Windows Mobile), you don't have stdout and stdin, nor is there a way
to inherit or pass on file descriptors.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:

> On 03/03/15 18:29, Hans of Guardian wrote:
>> Android has an installed base of hundreds of millions.  Desktop UNIX
>> is the exotic system here as compared to Windows, Android, etc.
> 
> I have no idea about how difficult it is to launch the gpg binary with a
> few pipes attached to a few file descriptors and perhaps anything else
> you need.
> 
> But I fail to see why you brought it up.
> 
> I thought we were discussing two alternatives:
> 
> - Call gpg directly
> - Use a library such as GPGME that calls gpg for you
> 
> In both cases, the gpg binary is executed as a separate process. So it
> seems to me any issues with this are the same in both cases. In fact, if
> it indeed is tricky as you say, you're better off if you have a library
> do this for you, so you don't have to get it right in each and every
> application.
> 
> Peter.

GPGME is that library that wraps gpg execution, and I've spent weeks of my life 
working GPGME on Android.  The way that GPGME wraps gpg is built entirely on 
UNIX assumptions, which is turns out that Windows works actually pretty close 
to that.  Android, on the other hand is a very different story. Some key 
differences:

* 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

* Android was not meant to support launching processes from a shell/terminal,
 it was there for core debugging, then opened up on demand from devs, but it
 is very much a second class citizen to a Java Android app.

* all apps are child processes of 'zygote'

* there is no way to install shared libraries to be shared by apps

There are other differences as well.  And iOS actually works a lot like 
Android, but also blends some UNIX stuff in.  I think we can also find similar 
issues when looking at how to make a proper Python API for GnuPG (though 
probably not as extreme).

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Ingo Klöcker]

On Tuesday 03 March 2015 19:31:14 Robert J. Hansen wrote:
> > This is definitely public information from the Snowden leaks.  There
> > is also quite a bit of information about other governments doing
> 
> > similar things.  Here's one example article:
> If all encrypted traffic is deemed suspicious, then 99.999% of the
> suspicious set -- Amazon transactions, Google searches, SMTP transfers,
> instant messaging, OkCupid profiles, iTunes purchases, and more -- is
> totally clean.  You'd have statistically better odds by arresting random
> people on suspicion of murder.  The policy would be completely
> pants-on-head absurd.

After the recent terrorist attacks in Paris and Brussels some German 
politicians are again arguing that we need Vorratsdatenspeicherung (data 
retention, i.e. storage of all communication meta data for 6 months) in 
Germany to prevent such attacks. Obviously, 99.999 % of this data will be 
completely unrelated to terrorist attacks, i.e. totally clean as you put it. 
You'd have statistically better odds by arresting random people on suspicion 
of terror. Still this completely pants-on-head absurd policy will become 
reality if those German politicians get what they want.


> This leads to a different question: "Is it more likely that this is the
> real pants-on-head absurd policy, or that the _Forbes_ journo has
> profoundly misunderstood the subject?"

Well, the Guardian wrote

"However, alongside those provisions [to minimise data collected from US 
persons; I.K.], the Fisa court-approved policies allow the NSA to:

[...]

• Retain and make use of "inadvertently acquired" domestic communications if 
they contain usable intelligence, information on criminal activity, threat of 
harm to people or property, are encrypted, or are believed to contain any 
information relevant to cybersecurity;"

Full article: 
http://www.theguardian.com/world/2013/jun/20/fisa-court-nsa-without-warrant

Specifically, see Exhibit B, Section 5 (3) a.
http://www.theguardian.com/world/interactive/2013/jun/20/exhibit-b-nsa-procedures-document


Moreover, see the recent article

http://justsecurity.org/19308/congress-latest-rules-long-spies-hold-encrypted-data-familiar/

which claims

"The Intelligence Authorization Act of 2015, which passed Congress this last 
December, should bring the question back to the fore. It established retention 
guidelines for communications collected under Executive Order 12333 and 
included an exception that allows NSA to keep ‘incidentally’ collected 
encrypted communications for an indefinite period of time."


So, you are right, that the articles do not claim that the NSA collects and 
keeps all encrypted communication forever.


Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Brad Rogers]

On Tue, 3 Mar 2015 21:24:15 +0100
Ingo Klöcker  wrote:

Hello Ingo,

>of terror. Still this completely pants-on-head absurd policy will
>become reality if those German politicians get what they want.

It's not just in Germany:  Politicians across the world utilise similar
scaremongering tactics to justify their paranoid, and xenophobic, vision
of society.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Just coz they do it in the movies, don't mean to say that it's cool
Keep It Clean - The Vibrators


pgp6igwuIkv0s.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Sandeep Murthy]

> On 4 Mar 2015, at 07:24, Ingo Klöcker  wrote:

> After the recent terrorist attacks in Paris and Brussels some German
> politicians are again arguing that we need Vorratsdatenspeicherung (data
> retention, i.e. storage of all communication meta data for 6 months) in
> Germany to prevent such attacks. Obviously, 99.999 % of this data will be
> completely unrelated to terrorist attacks, i.e. totally clean as you put it.
> You'd have statistically better odds by arresting random people on suspicion
> of terror. Still this completely pants-on-head absurd policy will become
> reality if those German politicians get what they want.
> 

In Australia this idea, unfortunately, may become reality - a proposed
change to existing laws to require companies to retain metadata is being
debated in parliament, although public opinion is against data retention.
Hopefully this change will fail.

Once such a data retention law is in place it is dangerous because inevitably
there is a “mission creep” that sets in - it is not hard to imagine one day that
encryption software users, maybe GPG users, will be required to disclose
information about the way they use it.  I think in the UK recently the PM
made some ambiguous comments which can be interpreted as seeking a
ban on end-to-end encryption software by private users on the grounds that
terrorists benefit just as much as ordinary law-abiding citizens from using
encryption.  Of course this shows he just does not understand the issues
involved and this idea will not go anywhere.

Sandeep Murthy
s.mur...@mykolab.com


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Matthias Mansfeld]

On 4 Mar 2015 at 7:47, Sandeep Murthy wrote:

[...]
> Once such a data retention law is in place it is dangerous because
> inevitably there is a "mission creep" that sets in - it is not
> hard to imagine one day that encryption software users, maybe GPG
> users, will be required to disclose information about the way they use
> it.  I think in the UK recently the PM made some ambiguous comments
> which can be interpreted as seeking a ban on end-to-end encryption
> software by private users on the grounds that terrorists benefit just
> as much as ordinary law-abiding citizens from using encryption.  Of
> course this shows he just does not understand the issues involved and
> this idea will not go anywhere.

I assume everybody here knows http://xkcd.com/538/

... and stuff like this is law in some countries. Coercive 
detention, or (if we just forget "law, what the f*** is law") some 
fine ideas used against unlawful combatants..

Today in paranoid mode
Matthias

--
Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das 
erschweren, mailen wir uns gerne mit (Open)PGP verschlüsselt.
-- 
Matthias Mansfeld Elektronik * Leiterplattenlayout
Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8
Internet: http://www.mansfeld-elektronik.de
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:31 PM, Robert J. Hansen wrote:

>> This is definitely public information from the Snowden leaks.  There 
>> is also quite a bit of information about other governments doing 
>> similar things.  Here's one example article:
> 
> If all encrypted traffic is deemed suspicious, then 99.999% of the
> suspicious set -- Amazon transactions, Google searches, SMTP transfers,
> instant messaging, OkCupid profiles, iTunes purchases, and more -- is
> totally clean.  You'd have statistically better odds by arresting random
> people on suspicion of murder.  The policy would be completely
> pants-on-head absurd.
> 
> This leads to a different question: "Is it more likely that this is the
> real pants-on-head absurd policy, or that the _Forbes_ journo has
> profoundly misunderstood the subject?"
> 
> Just because something's been published doesn't mean it should be
> trusted.  Bring your brain -- and when someone tells you something that
> supports your worldview, look at that thing hard and twice.

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.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:

> On 03/03/15 18:29, Hans of Guardian wrote:
>> Android has an installed base of hundreds of millions.  Desktop UNIX
>> is the exotic system here as compared to Windows, Android, etc.
> 
> I have no idea about how difficult it is to launch the gpg binary with a
> few pipes attached to a few file descriptors and perhaps anything else
> you need.
> 
> But I fail to see why you brought it up.
> 
> I thought we were discussing two alternatives:
> 
> - Call gpg directly
> - Use a library such as GPGME that calls gpg for you
> 
> In both cases, the gpg binary is executed as a separate process. So it
> seems to me any issues with this are the same in both cases. In fact, if
> it indeed is tricky as you say, you're better off if you have a library
> do this for you, so you don't have to get it right in each and every
> application.
> 
> Peter.

In Android, you can't really have shared libraries.  Apps share functionality 
at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ the 
shared library in effect, since it provides OpenPGP via Activities.

No one is saying that each app should have a custom wrapper for GnuPG.  What I 
think mailpile is saying, and 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.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> If you are interested, you should read the details.

Did.  Have.

> Because you are missing some key details here.

In other words, "you're wrong, but I'm not going to present any evidence
or reasoning, I'm just going to make vague statements about how you're
missing details which I am privy to."

> I believe they log all PGP encrypted communication.

At this point, you saying that you believe something -- without
supporting evidence -- no longer carries any weight with me.  If you're
going to present this without evidence, I'm going to reject it without
comment.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Thoughts on GnuPG and automation

[Bob (Robert) Cavanaugh]

Native to what? Processor, OS?
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.
For you to request that the interface be changed can be likened to someone 
requesting that I2C be changed because you have a hard time implementing it. 
This is pretty much a non-starter IMHO. Implementing interfaces to existing 
infrastructures is bread-and-butter to software development. Stop asking for 
fundamental infrastructure changes and start solving your problem. The group 
has literally hundreds of m-y that can be used productively to help you do 
this, but harness the group's power in a constructive manner.

Bob Cavanaugh



-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Hans of 
Guardian
Sent: Tuesday, March 03, 2015 3:55 PM
To: Peter Lebbing
Cc: gnupg
Subject: Re: Thoughts on GnuPG and automation


On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:


In Android, you can't really have shared libraries.  Apps share functionality 
at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ the 
shared library in effect, since it provides OpenPGP via Activities.

No one is saying that each app should have a custom wrapper for GnuPG.  What I 
think mailpile is saying, and 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.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 8:52 PM, Werner Koch wrote:

> On Tue,  3 Mar 2015 14:29, h...@guardianproject.info said:
> 
>> 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
> 
> Sorry, but that is not your problem.  The problem on Android seems to be
> that it is not easy to install anything else than plain Java apps.
> 
> We have GPGME bindings for all kind of languages from Ada over Java to
> Scheme.  Thus I can't see the problem - need another kind of data object
> to be handled in GPGME?  No problem, it can easily be done.  Is the
> event loop the problem?  That is somewhat harder to get right but that
> is always the case if you use a library.
> 
> I don't really understand your complaints given that we worked together
> to port GnuPG to Android.  GPGME is just a small thing on top of it and
> way easier than GnuPG itself.  It has nothing to do with fork+exec -
> GnuPG uses that itself a lot.
> 
> In 2010 we ported GnuPG and GPGME and Kontact (includes KMail) to
> Windows Mobile 6.5.  I can tell you, that was a task but we finally did
> it.  And the problems were not due to GnuPG (even that it ate up many of
> the scarce process slots) but due to the shear amount of memory KDE
> stuff required.  Consider as an example this: On Windows CE (the kernel
> of Windows Mobile), you don't have stdout and stdin, nor is there a way
> to inherit or pass on file descriptors.

And that is why this thread is going on, so hopefully we can come to an 
agreement that there are many areas where GnuPG can be used but GPGME is a bad 
solution to do it.  That is all I ask really from this 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 Java, but it is not good, and ill-fitting APIs make 
for bad software, which in turn often leads to bad security.  It also took a 
lot of time.  In retrospect, I think it would have been quicker to write a 
native GPGME in Java on Android than to continue the work on the gnupg-for-java 
wrapper.

Now I'm trying to convey my experience of what I learned by actually getting 
GPGME working on Android, and how the situation can be improved.  It turns out 
that I came to some quite similar conclusions to the mailpile team: there needs 
to be a shared interface for native frameworks, GPGME is not the way for many 
popular environments.

.hc
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> And that is why this thread is going on, so hopefully we can come to 
> an agreement that there are many areas where GnuPG can be used but 
> GPGME is a bad solution to do it.

Maybe I'm a little irritable here, but -- pretty much everyone who's
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.

No one has ever said GPGME is the all-purpose, all-in-one solution.  No
one.  So why are we having this discussion?  What was the point in even
bringing it up?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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.

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.

Right, it is not easy to control the advanced features of OpenPGP with
GPGME. It can be done and there is quite some example code available.
Please also consider that GPGME is not an OpenPGP thing but a protocol
independent library for off-line encryption protocols (actually it is
also possible to do add online things with it).  GPGME works on all kind
of platforms, form WindowsCE over Android to any Unix system.  There are
two open bugs out of 69 filed bugs over the last 10 years.  Development
might have been a bit slower in the last 2 years after Marcus had to
leave us. 

If there are real problems and not just a "I do not like the
open-process-close" paradigm, this should be raised and discussed
(gnupg-devel).  In particular problems with language binding should be
solved and if possible I'd like to add the language binding to the gpgme
release to be sure that it is a one-stop-solution.

> No one has ever said GPGME is the all-purpose, all-in-one solution.  No
> one.  So why are we having this discussion?  What was the point in even

Right, key signing and such is not a primary goal of GPGME.  It is about
bread-and-butter encryption services.  we always said, that if there is
a real need for a new interface we will add that.  But before we do that
it is important to see whether such a use pattern actually works.

GPGME is under the LGPGv2.1+ - this is the most liberal copyleft license
I know.  On purpose this has not been changed to GPLv3 or LGPGv3 so that
it can even be used by evil DRM riddled proprietary software.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 for sure about encrypted mail but it is known that https
connection information is recorded and stored for future attacks:

For its part, Britain's GCHQ collects information about encryption
using the TLS and SSL protocols -- the protocols https connections
are encrypted with -- in a database called "FLYING PIG." The British
spies produce weekly "trends reports" to catalog which services use
the most SSL connections and save details about those
connections. Sites like Facebook, Twitter, Hotmail, Yahoo and
Apple's iCloud service top the charts, and the number of catalogued
SSL connections for one week is in the many billions -- for the top
40 sites alone.




Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 interface used by Emacs, is more or less exactly
modelled after GPGME - in Elisp of course.  This is due to an Emacs
policy to keep the C-written core small with not to much dependencies.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 ridiculous.

The reason why I'm so fervent about stomping down on fashionable
misinformation, by the way, is because the people propagating these
things are *hurting* *people*.

Security is as much a state of mind as it is a state of reality.  Here
in the United States, violent crime is down 50% since the 1990s, and
crimes against children are down even more than that.  Yet, due to a
steady stream of awful news stories, most people feel they're in more
danger than ever before, and parents are genuinely afraid to let their
kids play outdoors.  The last time we've been this safe in our
communities was the early 1970s, and we feel like we're under siege.

That's no way to live.  When people feel like they're under siege they
act like they're under siege.  Personal relationships fray.  People stop
trusting each other.  Happiness plummets.  Suffering increases.

We face a lot of threats on the electronic front, yes.  We absolutely
need to face these threats squarely.  If we pretend a real threat
doesn't exist, that's terrible for our overall health as a society.

But if we pretend a false threat *does* exist... that's just as bad.

The possibility of widespread metadata collection is real, troubling,
and the free countries of the world need to engage in some spirited
discussion about it.

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.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 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
I've discovered GPGME doesn't support a particular feature I need, like
discovering the default preference lists that are currently in use.  Etc.

This doesn't impact my opinion of GPGME as a tool.  It just means that,
like all tools, there are environments where other tools are better ideas.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 meant to support launching processes from a shell/terminal,
>  it was there for core debugging, then opened up on demand from devs, but it
>  is very much a second class citizen to a Java Android app.

Why do you want to launch a process from a shell or terminal (actually a
shell is just an interpreter which has options to be used on a tty (job
control etc.))

> * all apps are child processes of 'zygote'

All processes excuted from GPGME are children of init. What is the
problem?

> * there is no way to install shared libraries to be shared by apps

I can't comment on this.

> There are other differences as well.  And iOS actually works a lot

Given that we worked together on adding features to GnuPG and GPGME for
use on Android I can't see your point.  Given that Android uses a Unix
kernel it is much more Unix than Windows or VMS.

You are thinking in the context of an application which runs on that
Android Unix kernel.  That might be indeed limited.  However we are
hackers and we can find ways to make almost everything work.

Shall we sit down and talk about the Android problems?  If we can do that
close to my place I will be available most of the time.  If it is better
for you to do it somewhere else, like Berlin, we need a bit more
planning.  Travel expenses should not be a concern.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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, python, etc.  That makes for
> more coding mistakes because it feels foreign to the programmer.
> More mistakes means more security issues.

Hello,

I have no idea about the Java tooling for interfacing to external
libraries, but (after seeing so many complaints on the mailing list)
I've recently started to work on Python bindings to GPGME using Cython,
and so far it has been an extremely smooth process and the resulting
Python API feels quite pythonic (I haven't started with the asynchronous
calls yet, those will probably be harder to map in a pythonic way).

The fact that writing the bindings is quite easy, is due indeed to the
fact that GPGME is a fine API for C (and to Cython to a large extent).

Cheers,
Daniele


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 instance,
talks via JSON to you, and itself uses GPGME to call the gpg binary?


[JSON]

[GPGME]


I think there is opposition to adding more stuff to the gpg binary. I
don't think there is opposition to you writing a program that uses GPGME
:). If it's good, it might be picked up for wider inclusion.

Since your Java/Python/etc program needs to install gpg anyway, it could
install the other C program as well. Packaging and distribution
definitely isn't a solved problem, but a separate one from what we are
now discussing, so let's not muddle this discussion by including it just
now.

Peter.

PS: When I say "you could write" I mean "someone could write"

-- 
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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 storing traffic, when 99.99% of it is good --
> that's ridiculous.

That has not been said.  From my understanding the FLYING PIG thing is
about extracting information from all gathered TLS handshakes.  This
shall either be used as a tool to decrypt suspicious connections or to
research weaknesses in TLS.  The authors of the article should be able
to explain that more in terms we understand - shall I ask them?

> That's no way to live.  When people feel like they're under siege they
> act like they're under siege.  Personal relationships fray.  People stop
> trusting each other.  Happiness plummets.  Suffering increases.

I fully agree with you on that.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 under the LGPLv2.1.  (Foolish, I know.)  Other times

And I have had several hints that it was used anyway and violating the
license.  But that is another story.

If there is a compelling reason to change the license, like to increase
the adaption of mail encryption, I am willing to consider that.  I am
able do that for most of the code but there are some practical
drawbacks, like the ability to share code between the other libraries.

> I've discovered GPGME doesn't support a particular feature I need, like
> discovering the default preference lists that are currently in use.  Etc.

The bug tracker allows to file feature requests ...


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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

[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.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 same gpg-agent, would think the remote user is

How do you distinguish between a remote user and a remote hacker?  I use
my Gnus MUA most of the time locally, but if need arise I can also login
from remote and use the very same process and gpg-agent.

It is also questionable what remote means: Client-server is a core
principle of Unix and in particular X11.

> 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 would
be easy to extend it in a way that gpg can tell gpg-agent to act as if
it was used via --extra-socket.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 in
every single email that crossed their borders.

-- 
Steve Jones 
Key fingerprint: 3550 BFC8 D7BA 4286 0FBC  4272 2AC8 A680 7167 C896


pgpb9gmjiGWFb.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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/qtcreator/creator-deploying-android.html
[2]:
https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro

-- 
Ville



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 supposedly such layers are supposed to help
> developers (and people will continue to accuse me of NIH and whatnot),
> in my experience on other projects, they've more often than not been
> sources of additional architectural constraints and bugs of their own.

Separation of concerns. Separating different, sufficiently unrelated,
functionality into their own layer / process / service can be just as
beneficial as on a normal *NIX using multiple processes to achieve a
given task. I.e. the so called "UNIX philosophy" [1].

> OpenSSL wrapper libraries for Python are a prime example, for one. More
> code: more bugs.

Implementing something in one monolithic binary instead of two or more
separate binaries does not necessarily mean much more code. We can
always screw up wherever the functionality is.

> This is one of the reasons having a native "protocol" such as JSON or
> Assuan in the gpg binary itself (or the gpg-agent if things move there)
> appeals to me so much.

I'm not taking sides one way or the other right now on this one…

> With two layers of wrappers, we have to wait for GPGME to get updated
> and THEN wait for the Python wrappers to get updated.

With separate layers they can be updated separately. There is no need
for every single GPG user to update the binary if a change in some
layered feature needs to be updated.

If features live in a separate layer, certainly there needs to be some
coordination and care that a change does not break some dependant layer.
But that's not really anything new and one needs to always be careful
with such things whether with monolithic and modular binaries alike.

> A well defined protocol also
> has the potential to eliminate mountains of platform-specific hacks

So it has.

[1]: https://en.wikipedia.org/wiki/Unix_philosophy

-- 
Ville



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[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 used anyway and violating the
> license.  But that is another story.
> 
> If there is a compelling reason to change the license, like to increase
> the adaption of mail encryption, I am willing to consider that.  I am
> able do that for most of the code but there are some practical
> drawbacks, like the ability to share code between the other libraries.
> 

I'd rather not have a license changed off copyleft.

-- 
Ville



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

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?

OOM killer is only comparable to the Android lifecycle in that it has the
power to kill processes.  In Android, apps are killed regularly, often many
times a day.  GNU/Linux was designed around the user telling a process to end
(i.e. File->Quit or TERM).  OOM killer is only a last resort in extreme
situations. Android is designed around the system entirely determining when
apps are terminated.


>> * Android was not meant to support launching processes from a shell/terminal,
>>  it was there for core debugging, then opened up on demand from devs, but it
>>  is very much a second class citizen to a Java Android app.
> 
> Why do you want to launch a process from a shell or terminal (actually a
> shell is just an interpreter which has options to be used on a tty (job
> control etc.))
>
>> * all apps are child processes of 'zygote'
> 
> All processes excuted from GPGME are children of init. What is the
> problem?
>
>> * there is no way to install shared libraries to be shared by apps
> 
> I can't comment on this.
> 
>> There are other differences as well.  And iOS actually works a lot
> 
> Given that we worked together on adding features to GnuPG and GPGME for
> use on Android I can't see your point.  Given that Android uses a Unix
> kernel it is much more Unix than Windows or VMS.
> 
> You are thinking in the context of an application which runs on that
> Android Unix kernel.  That might be indeed limited.  However we are
> hackers and we can find ways to make almost everything work.

It is a Linux kernel, which is most often used in UNIX-style OSes.  But
Android does not follow UNIX style, and Linux does not require an OS to follow
them either.  For example, in Android, UIDs and GIDs represent system
permissions, not users and groups.  You are going to be confusing things if
you expect Android's Linux kernel to provide a UNIX environment for you.  Even
when Android's Linux kernel does support UNIX-ish things like symlinks, the
Android runtime layer does not treat them as first class citizens.  Even
things like mount paths work differently in Android.  A given mount path can
have multiple simulatenous locations mounted to it, one per Android user 
account.


> Shall we sit down and talk about the Android problems?  If we can do that
> close to my place I will be available most of the time.  If it is better
> for you to do it somewhere else, like Berlin, we need a bit more
> planning.  Travel expenses should not be a concern.

Sure, that sounds good.  I'm sorry I can't make the April meeting.  I'll be
back in Europe this summer indefinitely.  I might be able to put together a
multi-pronged trip to your area of the world, if that makes sense.  But
perhaps it makes the most sense to have a meeting at a relevant conference or
similar thing.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

Why do I get so many responses like this on this list?  I've spent a ton of
time solving our own problems with the Android port, we also made sure to take
out a support contract with Werner to pay him to answer our questions.  I only
wish we'd had more so we could pay him for all the work he has done, but we
have long since run out of money for working on GnuPG.  I continue this on my
own time because I believe it is important.

The point of this discussion is to talk about an shared architecture for using
GnuPG outside of C/C++ on UNIX.  That's why Bjarni started it, and that's why
I've joined in here.  It seems that half of this thread has been griping about
the discussion process.  We need a little more faith in each other so we can
have productive discussions and further our shared goals.

.hc

Bob (Robert) Cavanaugh:
> Native to what? Processor, OS?
> 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.
> For you to request that the interface be changed can be likened to someone 
> requesting that I2C be changed because you have a hard time implementing it. 
> This is pretty much a non-starter IMHO. Implementing interfaces to existing 
> infrastructures is bread-and-butter to software development. Stop asking for 
> fundamental infrastructure changes and start solving your problem. The group 
> has literally hundreds of m-y that can be used productively to help you do 
> this, but harness the group's power in a constructive manner.
> 
> Bob Cavanaugh
> 
> 
> 
> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Hans of 
> Guardian
> Sent: Tuesday, March 03, 2015 3:55 PM
> To: Peter Lebbing
> Cc: gnupg
> Subject: Re: Thoughts on GnuPG and automation
> 
> 
> On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:
> 
> 
> In Android, you can't really have shared libraries.  Apps share functionality 
> at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ 
> the shared library in effect, since it provides OpenPGP via Activities.
> 
> No one is saying that each app should have a custom wrapper for GnuPG.  What 
> I think mailpile is saying, and 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.
> 
> .hc
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Thoughts on GnuPG and automation

[Bob (Robert) Cavanaugh]

Hi Hans,
Wanted to respond to your post wondering why you are getting the responses you 
are. 

In another thread you write:
"There are other C-Python wrappers of GPGME, like pyme.  I hope you're aware of 
those, and have studied them.  One thing that GnuPG suffers from is many people 
starting their own wrappers, but few people finishing them or contributing to 
existing ones.  That is not a sustainable situation."

This is the problem. You frame the dialog as blaming GnuPG and the design 
choices made in its implementation. Direct case in point: It is certainly not 
Werner's or any other principal GnuPG developer's issue if and when someone 
else independently took on a project to wrap GnuPG or GPGME. The fact that  
these people might have bitten off more than they can chew is completely 
irrelevant to the canonical implementation and frankly should be irrelevant to 
this discussion. When I said approach this in a constructive manner I meant 
this: You have some requirements. In your estimation these requirements are not 
met with the current toolset. Then instead of explicitly expecting this group 
to implement a paradigm shift (and forgive me if I misunderstand you, but that 
is what I infer you are asking for) generate a proposal for an Android-centric 
API. Or, if you feel that the infrastructure cannot support it, take the 
completely open sources Werner and group have provided and generate your own 
 system that meets your needs. If possible,  (and here again I am clarifying my 
original post) work with the people on this group to help you use the existing 
tools to get your requirements met. But speaking as a professional engineer of 
25+ years experience, you will not get your desired results by starting the 
conversation impuning the work that went before and claiming that what you are 
asking for is far superior. If it is not your intent to convey that message 
then please review what you write before you send it, because that message was 
received loud and clear.

Thanks,
 
Bob Cavanaugh


> -Original Message-
> From: Hans-Christoph Steiner [mailto:h...@guardianproject.info]
> Sent: Monday, March 09, 2015 12:08 PM
> To: Bob (Robert) Cavanaugh; Peter Lebbing
> Cc: gnupg
> Subject: Re: Thoughts on GnuPG and automation
> 
> 
> Why do I get so many responses like this on this list?  I've spent a ton of 
> time
> solving our own problems with the Android port, we also made sure to take
> out a support contract with Werner to pay him to answer our questions.  I
> only wish we'd had more so we could pay him for all the work he has done,
> but we have long since run out of money for working on GnuPG.  I continue
> this on my own time because I believe it is important.
> 
> The point of this discussion is to talk about an shared architecture for using
> GnuPG outside of C/C++ on UNIX.  That's why Bjarni started it, and that's
> why I've joined in here.  It seems that half of this thread has been griping
> about the discussion process.  We need a little more faith in each other so we
> can have productive discussions and further our shared goals.
> 
> .hc
> 
> Bob (Robert) Cavanaugh:
> > Native to what? Processor, OS?
> > 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.
> > For you to request that the interface be changed can be likened to
> someone requesting that I2C be changed because you have a hard time
> implementing it. This is pretty much a non-starter IMHO. Implementing
> interfaces to existing infrastructures is bread-and-butter to software
> development. Stop asking for fundamental infrastructure changes and start
> solving your problem. The group has literally hundreds of m-y that can be
> used productively to help you do this, but harness the group's power in a
> constructive manner.
> >
> > Bob Cavanaugh
> >
> >
> >
> > -Original Message-
> > From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf
> Of
> > Hans of Guardian
> > Sent: Tuesday, March 03, 2015 3:55 PM
> > To: Peter Lebbing
> > Cc: gnupg
> > Subject: Re: Thoughts on GnuPG and automation
> >
> >
> > On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:
> >
> >
> > In Android, you can't really have shared libraries.  Apps share 
> > functionality
> at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ 
> the
> shared library in effect, since it provides OpenPGP via Activities.
> >
> > No one is saying that each app should have a custom wrapper for GnuPG.
> What I think mailpile is saying, and what I'm

RE: Thoughts on GnuPG and automation

[Bob (Robert) Cavanaugh]

If that is the goal, that is a fair one.

Thanks,
 
Bob Cavanaugh


> -Original Message-
> From: Hans-Christoph Steiner [mailto:h...@guardianproject.info]
> Sent: Monday, March 09, 2015 2:22 PM
> To: Bob (Robert) Cavanaugh; Peter Lebbing
> Cc: gnupg
> Subject: Re: Thoughts on GnuPG and automation
> 
> 
> I expect a discussion about what is working and what is not working with
> GPGME and various GnuPG APIs.  I'm just trying to convey my experience
> with GnuPG-for-Android, gnupg-for-java, and a little bit with Python.  I hope
> this will spur people to offer their experience, and generate new ideas and
> approaches.  gpgme-tool is one version of that, `gpg --json` is another.
> 
> .hc
> 
> Bob (Robert) Cavanaugh:
> > Hi Hans,
> > Wanted to respond to your post wondering why you are getting the
> responses you are.
> >
> > In another thread you write:
> > "There are other C-Python wrappers of GPGME, like pyme.  I hope you're
> aware of those, and have studied them.  One thing that GnuPG suffers from
> is many people starting their own wrappers, but few people finishing them
> or contributing to existing ones.  That is not a sustainable situation."
> >
> > This is the problem. You frame the dialog as blaming GnuPG and the
> > design choices made in its implementation. Direct case in point: It is
> > certainly not Werner's or any other principal GnuPG developer's issue
> > if and when someone else independently took on a project to wrap GnuPG
> > or GPGME. The fact that  these people might have bitten off more than
> > they can chew is completely irrelevant to the canonical implementation
> > and frankly should be irrelevant to this discussion. When I said
> > approach this in a constructive manner I meant this: You have some
> > requirements. In your estimation these requirements are not met with
> > the current toolset. Then instead of explicitly expecting this group
> > to implement a paradigm shift (and forgive me if I misunderstand you,
> > but that is what I infer you are asking for) generate a proposal for
> > an Android-centric API. Or, if you feel that the infrastructure cannot
> > support it, take the completely open sources Werner and group have
> > provided and generate your ow
>  n
>  system that meets your needs. If possible,  (and here again I am clarifying
> my original post) work with the people on this group to help you use the
> existing tools to get your requirements met. But speaking as a professional
> engineer of 25+ years experience, you will not get your desired results by
> starting the conversation impuning the work that went before and claiming
> that what you are asking for is far superior. If it is not your intent to 
> convey
> that message then please review what you write before you send it, because
> that message was received loud and clear.
> >
> > Thanks,
> >
> > Bob Cavanaugh
> >
> >
> >> -Original Message-
> >> From: Hans-Christoph Steiner [mailto:h...@guardianproject.info]
> >> Sent: Monday, March 09, 2015 12:08 PM
> >> To: Bob (Robert) Cavanaugh; Peter Lebbing
> >> Cc: gnupg
> >> Subject: Re: Thoughts on GnuPG and automation
> >>
> >>
> >> Why do I get so many responses like this on this list?  I've spent a
> >> ton of time solving our own problems with the Android port, we also
> >> made sure to take out a support contract with Werner to pay him to
> >> answer our questions.  I only wish we'd had more so we could pay him
> >> for all the work he has done, but we have long since run out of money
> >> for working on GnuPG.  I continue this on my own time because I believe
> it is important.
> >>
> >> The point of this discussion is to talk about an shared architecture
> >> for using GnuPG outside of C/C++ on UNIX.  That's why Bjarni started
> >> it, and that's why I've joined in here.  It seems that half of this
> >> thread has been griping about the discussion process.  We need a
> >> little more faith in each other so we can have productive discussions and
> further our shared goals.
> >>
> >> .hc
> >>
> >> Bob (Robert) Cavanaugh:
> >>> Native to what? Processor, OS?
> >>> 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.
> >>> For you to request that the interface be changed can be likened to
>

Re: Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

I expect a discussion about what is working and what is not working with GPGME
and various GnuPG APIs.  I'm just trying to convey my experience with
GnuPG-for-Android, gnupg-for-java, and a little bit with Python.  I hope this
will spur people to offer their experience, and generate new ideas and
approaches.  gpgme-tool is one version of that, `gpg --json` is another.

.hc

Bob (Robert) Cavanaugh:
> Hi Hans,
> Wanted to respond to your post wondering why you are getting the responses 
> you are. 
> 
> In another thread you write:
> "There are other C-Python wrappers of GPGME, like pyme.  I hope you're aware 
> of those, and have studied them.  One thing that GnuPG suffers from is many 
> people starting their own wrappers, but few people finishing them or 
> contributing to existing ones.  That is not a sustainable situation."
> 
> This is the problem. You frame the dialog as blaming GnuPG and the design 
> choices made in its implementation. Direct case in point: It is certainly not 
> Werner's or any other principal GnuPG developer's issue if and when someone 
> else independently took on a project to wrap GnuPG or GPGME. The fact that  
> these people might have bitten off more than they can chew is completely 
> irrelevant to the canonical implementation and frankly should be irrelevant 
> to this discussion. When I said approach this in a constructive manner I 
> meant this: You have some requirements. In your estimation these requirements 
> are not met with the current toolset. Then instead of explicitly expecting 
> this group to implement a paradigm shift (and forgive me if I misunderstand 
> you, but that is what I infer you are asking for) generate a proposal for an 
> Android-centric API. Or, if you feel that the infrastructure cannot support 
> it, take the completely open sources Werner and group have provided and 
> generate your ow
 n
 system that meets your needs. If possible,  (and here again I am clarifying my 
original post) work with the people on this group to help you use the existing 
tools to get your requirements met. But speaking as a professional engineer of 
25+ years experience, you will not get your desired results by starting the 
conversation impuning the work that went before and claiming that what you are 
asking for is far superior. If it is not your intent to convey that message 
then please review what you write before you send it, because that message was 
received loud and clear.
> 
> Thanks,
>  
> Bob Cavanaugh
> 
> 
>> -Original Message-
>> From: Hans-Christoph Steiner [mailto:h...@guardianproject.info]
>> Sent: Monday, March 09, 2015 12:08 PM
>> To: Bob (Robert) Cavanaugh; Peter Lebbing
>> Cc: gnupg
>> Subject: Re: Thoughts on GnuPG and automation
>>
>>
>> Why do I get so many responses like this on this list?  I've spent a ton of 
>> time
>> solving our own problems with the Android port, we also made sure to take
>> out a support contract with Werner to pay him to answer our questions.  I
>> only wish we'd had more so we could pay him for all the work he has done,
>> but we have long since run out of money for working on GnuPG.  I continue
>> this on my own time because I believe it is important.
>>
>> The point of this discussion is to talk about an shared architecture for 
>> using
>> GnuPG outside of C/C++ on UNIX.  That's why Bjarni started it, and that's
>> why I've joined in here.  It seems that half of this thread has been griping
>> about the discussion process.  We need a little more faith in each other so 
>> we
>> can have productive discussions and further our shared goals.
>>
>> .hc
>>
>> Bob (Robert) Cavanaugh:
>>> Native to what? Processor, OS?
>>> 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.
>>> For you to request that the interface be changed can be likened to
>> someone requesting that I2C be changed because you have a hard time
>> implementing it. This is pretty much a non-starter IMHO. Implementing
>> interfaces to existing infrastructures is bread-and-butter to software
>> development. Stop asking for fundamental infrastructure changes and start
>> solving your problem. The group has literally hundreds of m-y that can be
>> used productively to help you do this, but harness the group's power in a
>> constructive manner.
>>>
>>> Bob Cavanaugh
>>>
>>>
>>>
>>> -Original Message-
>>> From: Gnupg-users [mailto:gnu

Re: Thoughts on GnuPG and automation

[Doug Barton]

On 3/9/15 2:10 PM, Bob (Robert) Cavanaugh wrote:

you will not get your desired results by starting the conversation impuning the 
work that went before and claiming that what you are asking for is far superior


OTOH, it's often useful when talking about a possible direction for new 
projects to have a frank and honest discussion about what did and did 
not work in old ones.


Just as you pointed out that the slights you perceived Hans-Christoph 
offering on GnuPG are unfair because it's not responsible for what other 
project teams have started and failed to complete; it's equally 
unreasonable for you to infer that he was offering that slight, and for 
the same reason.


The way I read Hans-Christoph's message was that there is a lack of 
coordination amongst various teams who have started API, wrapper, or 
other projects based on GnuPG tools, and that this fragmentation has 
harmed those efforts in various ways (including diverting precious 
resources to projects with little or no chance of success). And that it 
would be nice if we could take a hard look at what the real world 
requirements are for APIs and/or wrappers for various platforms, and 
have some coordinated effort put into work in this area.


Both of those sound like perfectly reasonable observations to me, and I 
did not perceive any suggested slight by Hans-Christoph at any point in 
the conversation.


FWIW,

Doug


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re: Thoughts on GnuPG and automation

[Bjarni Runar Einarsson]

Hey Werner,

Yes, please do take your time.

I'm happy to hear you consider automation an important thing. I assume
that means the current limitations on that front are largely due to a
lack of developer resources - which I don't intend to badger you about,
my project suffers from the same.

Related to that though, I'll add one question to your backlog: does the
GnuPG 2.1 cycle hope to bridge the 2.0/1.4 divide, so 1.4 can retire and
everyone can move to 2.1? If not, why not?

In the meantime, I'll go see if I can find information about this kludge
you speak of.

Take care,
 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re: Thoughts on GnuPG and automation

[Bjarni Runar Einarsson]

Hi Hans-Christoph!

Hans-Christoph Steiner  wrote:
> With all the recent attention to GnuPG and Werner's work, I have begun to
> think about things differently.  GnuPG has an amazing security track record.
> It has had few serious security bugs, nothing even close to heartbleed that I
> know of, and yet it is core to providing security to GNU/Linux distros, as
> well as protecting people like Laura Poitras and Edward Snowden. So instead
> of complaining about the difficulties, I now try to think about whether such
> difficulties might actually be related to what makes GnuPG so solid.

Some of the more jaded will call this Stockholm syndrome. :-P

I don't agree with the voices that want to discard PGP and start from
scratch. There is valuable experience and maturity in this project,
which is why we care enough to complain when it is hard to work with.

> anyone interested in providing usable security needs to think hard about this.
> Sure we can make things easier to use, but it is a very slippery slope
> towards reducing security.

I really disagree with this. If a security tool is too hard to
understand, whether for a developer or user, then insecurity will be the
inevitable result: people will use it wrong. This is only in part
GnuPG's resposibility, most of the complexity is inherited from OpenPGP
and the fact that public/private key crypto and key management are just
very complex topics.

This is the one point where I agree with the voices calling for
abandoning OpenPGP entirely. It can well be argued that the whole
cryptoscheme has been field tested and proven too complex for humans to
use correctly. That's not exactly GnuPG's problem either, but these
voices are becoming louder and, increasingly, there is finally
competition in this space. The project will get marginalized if
usability is ignored completely.

Mailpile's attempt to make OpenPGP easy to use is us stubbornly trying
to prove that it can be done. But I'm only somewhat optimistic that
we'll succeed, and we'll only do so if we face reality and drop a large
number of the features that make PGP what it is - in particular the web
of trust and default trust model, and who knows what else. I don't mind
if that code exists inside GnuPG, but Mailpile is absolutely not going
to be using it.

> I also have to call out that part of the problem that mailpile is continuing:
> it is generally more fun to write code, rather than figure out someone else's
> library. That is especially true when its a complicated thing like GnuPG.
> But in order to have shared maintenance and work, we all need to take
> responsibility and try to build upon the work of others whenever possible.
> Mailpile did not do that, and instead wrote yet another incomplete
> python API for GnuPG.

Fair enough. We were in a hurry, and we probably did make a mistake
here. There is a reason why we haven't broken our library out and
published separately though: we do hope to tear it out and replace it
with something more standard down the line.

However, having done the work, I can now state with confidence that the
complexity of our library is not because GnuPG is doing complex things.
It is because the GnuPG command line interfaces for automation are
incomplete and very hard to work with. Libraries might be able to hide
this fact, but that doesn't make the problem go away - sysadmins and
scripters everywhere have to deal with this all the time. It's a real
burden and the source of many, many posts to this list and others.

It's easy for developers to lose sight of the fact that no matter how
many libraries exist, most people first encounter gpg at the command
line. Slowly expanding on that and automating what you have learned is
the Unix way, and it's a wonderful thing. Whatever the reason, GnuPG is
not very good at this today.

Unfortunately lots of existing code depends on these things staying
unchanged, quirks and all. So it may be too late to fix, realistically
speaking. Missing flags could be added, but cleaning up the stuff that
already exists may be impossible. If that's Werner's verdict, then I
totally understand and promise to stop complaining about it.

> Another possibility is making ASSUAN, the internal protocol between GnuPG
> components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as
> far as I understand it, since in 2.1, even commands like gpg communicate with
> gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work.

FWIW, I took a lok at Assuan a while back, and I really like it.
Replacing Assuan with JSON might help the project interface with the
rest of the world, but that's the only argument in its favour; Assuan is
definitely more suited to the things that GPG has to do. There is also a
nice little Python library for interacting with it, so if gpg-agent ends
up exposing an Assuan interface which can do all the stuff people do
with GPGME, then I'll be very happy to switch to that.

Very happy! :-)

> Contrary to the mailpile w

Re: Re: Thoughts on GnuPG and automation

[Daniel Kahn Gillmor]

On Fri 2015-02-27 07:19:41 -0500, Bjarni Runar Einarsson  
wrote:
> I think you misunderstood my complaint. I don't mind if the agent is a
> persistance daemon that provides GPG-related services, that's all well
> and good. It's good process separation and I have no problem with that.
>
> My gripe with the agent, is the agent is controlling the UI of
> authentication. This breaks Mailpile, and this is one of the key areas
> where GnuPG crosses the imaginary line between library/utility and
> "application". Fixing this was point 1. in my list of suggestions and
> explaining why it was necessary was the bulk of the post.

The only part of the UI that the agent controls is prompting the user
for use of the key, and passphrase entry upon unlock.

Why does this break mailpile?  I prefer the agent to have separate UI
from the tool that uses the agent, because i want don't want tools that
use the agent to be able to mask the agent's UI.

I'm quite happy that enigmail (for example) appears to be dropping plans
for non-agent use of secret key material.  this should be a simplifying
change, and it should make it easier for systems to integrate OS-level
prompting and feedback to the user independent of which application uses
the secret key store.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re: Thoughts on GnuPG and automation

[Bjarni Rúnar Einarsson]

Hi Dan,

I dedicated an most of the blog post to answering that question (why it
breaks Mailpile), did you not read it or did I fail to communicate?

- Bjarni
On 28 Feb 2015 12:44, "Daniel Kahn Gillmor"  wrote:

> On Fri 2015-02-27 07:19:41 -0500, Bjarni Runar Einarsson 
> wrote:
> > I think you misunderstood my complaint. I don't mind if the agent is a
> > persistance daemon that provides GPG-related services, that's all well
> > and good. It's good process separation and I have no problem with that.
> >
> > My gripe with the agent, is the agent is controlling the UI of
> > authentication. This breaks Mailpile, and this is one of the key areas
> > where GnuPG crosses the imaginary line between library/utility and
> > "application". Fixing this was point 1. in my list of suggestions and
> > explaining why it was necessary was the bulk of the post.
>
> The only part of the UI that the agent controls is prompting the user
> for use of the key, and passphrase entry upon unlock.
>
> Why does this break mailpile?  I prefer the agent to have separate UI
> from the tool that uses the agent, because i want don't want tools that
> use the agent to be able to mask the agent's UI.
>
> I'm quite happy that enigmail (for example) appears to be dropping plans
> for non-agent use of secret key material.  this should be a simplifying
> change, and it should make it easier for systems to integrate OS-level
> prompting and feedback to the user independent of which application uses
> the secret key store.
>
> --dkg
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re: Thoughts on GnuPG and automation

[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 would
> be easy to extend it in a way that gpg can tell gpg-agent to act as if
> it was used via --extra-socket.

Hi Werner!

In order to use that in current releases of GnuPG, then Mailpile needs
to run its own gpg-agent, correct? And in order to use a custom pinentry
as discussed elsewhere? Can I run multiple agents off the same keychain,
or do I also need to create a separate gpg home dir for each one?

I ask, because although current users of GnuPG are proportionally very
few, they are still a group I consider important. I expect many such
users to become quite annoyed if Mailpile doesn't integrate cleanly with
their existing keychain.

Regarding other topics broached on this thread, I think it is very
interesting to hear that GPGME is basically the "official"
implementation of something that wraps the gpg binary. I hadn't looked
deeply enough into GPGME to be aware of this.

I will probably take a peek at the GPGME source to see if I missed some
more elegant ways to solve things. In particular, both generating keys
and editing the UID list on a key are quite gross in Mailpile's wrapper
and I wonder if GPGME offers a better implementation?

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 supposedly such layers are supposed to help
developers (and people will continue to accuse me of NIH and whatnot),
in my experience on other projects, they've more often than not been
sources of additional architectural constraints and bugs of their own.
OpenSSL wrapper libraries for Python are a prime example, for one. More
code: more bugs.

This is one of the reasons having a native "protocol" such as JSON or
Assuan in the gpg binary itself (or the gpg-agent if things move there)
appeals to me so much.

With a well designed protocol, wrapper libraries almost become
unnecessary and layers and layers of code can just be stripped away and
discarded. Consider that with a protocol approach, new features in gpg
become available immediately to all applications speaking the protocol.
With two layers of wrappers, we have to wait for GPGME to get updated
and THEN wait for the Python wrappers to get updated. We're all
overworked, so removing layers that need to be kept up-to-date and in
lockstep is a hugely valuable investment. A well defined protocol also
has the potential to eliminate mountains of platform-specific hacks - if
you can talk to the protocol server, things work, no matter whether it's
a fifo in the file system, stdio or a TCP/IP connection to a remote box.
So people can choose the transport that best suits their platform and
just get on with "real work".

Anyway, I'm very glad this discussion is taking place. In my opinion, if
GnuPG wants to be a platform other apps can build on, these interfaces
matter a great deal. Whether there are hacks or workarounds is kind of
irrelevant; if developers are unhappy they'll just go develop something
else. This stuff matters.

Thanks for the comments,
 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is

signature.asc
Description: OpenPGP Digital Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Newspeek, (was: Re: Thoughts on GnuPG and automation)

[Matthias Mansfeld]

On 3 Mar 2015 at 21:24, Ingo Klöcker wrote:

[..]
> After the recent terrorist attacks in Paris and Brussels some German
> politicians are again arguing that we need Vorratsdatenspeicherung
> (data retention, i.e. storage of all communication meta data for 6
> months) in Germany to prevent such attacks. 

We here in Germany use newspeek and call this now "Digitale 
Spurensicherung" = "digital forensics"

See https://www.youtube.com/watch?v=ZCSei796yHA
made by our CSU here in Bavaria. Only in German language, but there 
is no difference with or without text. Simplification beyond 
recognition, and everything is fine, just fine and easy... :-/

Regards
Matthias
--
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users