Re: How to deal with a 2nd OpenPGP Summit?

[Hans-Christoph Steiner]

I've attended all manner of conferences/meetings from big to small,
invite-only to open doors, expensive to free, heavily organized to improvised.
 I think far and away the most productive conferences for groups of 20+ people
are Unconference/Barcamp/"Gunner-style" conferences, which are totally open,
have no fixed agenda, and have 1-4 moderators to run the intro sections of the
day where the day's agenda is created.  These kinds of events have also been
the most fun conferences/meetings that I've attended.

What such an event does require is that people as a group have enough social
skills to know when it is appropriate to talk, and also to know when it is
appropriate to ask someone to stop talking until another time/place.  Good
moderators help a lot with that task.  Then we can have focused, productive
meetings without having to manage who can attend.  It also takes much less
pre-planning to run such an event, since the organizers do not need to work
out topics, schedules, etc.  Just space and overall timing (i.e. 5 rooms from
9am-6pm).

I am willing to serve as a moderator, though I can't say I'm the best at it.
I've helped organized and run DrupalCamp, MySQLCamp, iPhoneDevCamp, PdCon, and
more.

If there is a budget for this event, then Allen Gunn/Aspiration Tech could be
hired to run the event.  He's an excellent moderator, especially for groups of
people that are unfamiliar with this format.

.hc

Bob (Robert) Cavanaugh:
> Hi,
> Just a thought: Have a "Star chamber" meeting for the technical group, 
> invitation only. After that have a 1/2 to 1 hour session open to all where 
> the technical people can present their progress and invite comment. This way 
> you have a focused working session with the key people, but maintain 
> community trust by allowing general input.
> 
> Thanks,
>  
> Bob Cavanaugh
> 
>> -Original Message-
>> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of
>> fmv1...@gmail.com
>> Sent: Wednesday, August 12, 2015 5:24 AM
>> To: gnupg-users@gnupg.org; n...@enigmail.net
>> Subject: Re: How to deal with a 2nd OpenPGP Summit?
>>
>>
>>> --
>>>
>>> Message: 3
>>> Date: Wed, 12 Aug 2015 07:44:24 +0200
>>> From: "n...@enigmail.net" 
>>> To: GnuPG-Users 
>>> Subject: How to deal with a 2nd OpenPGP Summit?
>>> Message-ID: <55cadd38.5030...@enigmail.net>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> Hi all,
>>>
>>> in April 2015 we had a first OpenPGP summit.
>>> It was a meeting where the technical experts of projects and tools
>>> dealing with OpenPGP with a focus on email encryption met to getting
>>> to know each other personally and discuss several issues.
>>> For details, see e.g.
>>> - https://www.gnupg.org/blog/20150426-openpgp-summit.html
>>> - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html
>>>
>>> The meting initially was organized by me to bring together a few
>>> guys/projects working in that area, but it became pretty big (about 30
>>> people). This caused some problems, because we had a host with limited
>>> space (so I finally even had to reject some people wanting to attend).
>>>
>>> We also discussed there how to continue.
>>> On one hand we wanted to have the meeting open so that anybody
>> wanting
>>> to attend could do that and to give trust by transparency.
>>> On the other hand we want to be able to continue to focus on technical
>>> issues (having a well signal to noise ratio) in a not-too-large group
>>> of "experts".
>>> We didn't find an appropriate way yet to deal with both interests.
>>>
>>> Now, I am about to organize a second meeting at the end of this year.
>>> And I want to take the "wisdom" of this crowd to discuss this issue.
>>>
>>> What I currently have in mind is a meeting open to the public but with
>>> some limitations (one reason is to focus the work, another is simply
>>> limited space although I don't know where we can meet this time).
>>> For example:
>>> - Some priority for those who did attend the first meeting
>>> - Some priority for "other experts", which didn't join
>>>   the first meeting
>>>   (but how do we handle that?)
>>> - Some limitations that a person plays a "significant role"
>>>   in the community
>>> - Some limitation so that a tool/project should normally
>>>   send only 1 or 2 guys
>>>
>>> The obvious other option is to open the meeting to everybody willing
>>> to come, which raises a couple of risks (simply too many people, too
>>> many non-experts or people  who want to change the focus, ...).
>>>
>>> So, my questions are:
>>> =
>>>
>>> Is it OK for the public/community, if we meet in a way that is limited
>>> as describe above (just for practical reasons)?
>>>
>>> Is it OK even if we can't promise full transparency (e.g. by video
>>> taping sessions)?
>>>
>>> Would it even be OK, if we meet and constraint what is spoken there to
>>> the Chatham House Rule (see
>>> 

Re: gnupg-for-java

[Hans-Christoph Steiner]

Antony Prince:
> On 09/10/2015 05:17 PM, Antony Prince wrote:
>> without gpgme installed). I'm not 100% sure how to test the
>> functionality of the binary and library, so if anyone wants to give it a
>> go, I'd be glad to hear the results. The ftp server[2] allows for
>> anonymous download.
>> [2]ftp://blazrsoft.com/
>>
> 
> As an update on this, I've written a very short program to invoke the
> test functions of the library. This is more of a learning exercise for
> me, but I figured I'd let anyone interested know that I was still
> pursuing it. It doesn't work 100% yet and I'm working towards figuring
> it out, but at the very least, I've got the suite() method in
> com.freiheit.gnupg.tests.GnuPGTestSuite to start attempting its key
> creation tests. The results are:
> 
> suite()
> genKey: " 
> Key-Type: DSA
> Key-Length: 1024
> Subkey-Type: ELG-E
> Subkey-Length: 1024
> Name-Real: alpha
> Name-Comment: just a test
> Name-Email: al...@alpha.org
> Expire-Date: 0
> Passphrase: alpha
> "
> Exception in thread "main" com.freiheit.gnupg.GnuPGException: 117440513:
> General error
>   at com.freiheit.gnupg.GnuPGContext.gpgmeOpGenKey(Native Method)
>   at com.freiheit.gnupg.GnuPGContext.genKey(GnuPGContext.java:748)
>   at com.freiheit.gnupg.tests.GnuPGTestSuite.suite(GnuPGTestSuite.java:66)
>   at com.blazrsoft.gnupg4javatester.MainClass.main(MainClass.java:8)
> 
> It is failing at the call to genKey(). I'll figure it out eventually I'm
> sure. This is using the .jar and .so files created by the Travis CI
> builds that I mentioned earlier. I'll likely perform tests with natively
> built files to see if the issue lies there, etc. If I can maintain the
> motivation, I may eventually work on my own Java front-end for the
> library, just to see if I can do it.
>

This is all great work, Antony!  We'd be happy to include it in our repo.
We've basically only used gnupg-for-java in our Android app GnuPG for Android,
so it is not so polished on desktop, as you saw.

.hc

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



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

Re: gnupg-for-java

[Hans-Christoph Steiner]

For the record, my work on GnuPG was largely funded by the US Government, via
the State Department/Radio Free Asia/Open Technology Fund.  So are other
projects like Tor Project, Mailvelope, crypto.cat, NoScript, and many more.  I
don't think that being associated with the US Government automatically
disqualifies your contributions of free software.

.hc

Robert J. Hansen:
> A while ago, the fellows at the Guardian Project released Java bindings
> for GnuPG.  A project's come along where I could make use of them, and
> thought I'd give them a spin.  I was quite surprised to discover that,
> as of this writing, they don't even build.
> 
> The offender seems to be jUnit.  The gnupg-for-java code uses a lot of
> imports like "junit.framework", and the current jUnit drops everything
> in the org.junit namespace.  On top of that, old test methods like
> TestSuite from jUnit 3.8 have been deprecated in favor of Suite, from
> more modern jUnits.
> 
> This doesn't appear to be hard work.  The test suite is about 250 lines
> of code, most of it fairly clear.  If you know Java and would like to
> contribute to GnuPG but don't quite know where, this would seem to be an
> excellent "bite-sized" project to take on.
> 
> 
> 
> (If anyone's wondering why I'm not doing it: following my long-standing
> rule, I don't contribute code patches for either GnuPG or Enigmail.
> Although I'm not an employee of the U.S. government, I have a lot of
> friends and family who are.  If I contributed code, some people would
> make a ruckus about how GnuPG was now 'tainted'.  To prevent this, and
> to maintain the community's trust in GnuPG, I don't touch the code.)
> 
> ___
> 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=0x9F0FE587374BBE81

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

Re: Facebook and OpenPGP

[Hans-Christoph Steiner]

MFPA:
 
 
 On Monday 1 June 2015 at 5:37:33 PM, in
 mid:20150601183733.3fc5b...@frustcomp.home.hnjs.ch,
 gnupg-us...@henk.geekmail.org wrote:
 
 
 A comment worth reading in case one does not see it
 oneself IMHO:
 https://blogs.fsfe.org/gerloff/2015/06/01/facebook-offers-to-send-you-encrypted-emails-this-wont-help-you/
 
 Whatever Facebook's motivation, doesn't anything that increases the
 proportion of emails that are encrypted during transit count as a Good
 Thing?

Yeah, I think it sets a great precedent for other large organizations to
follow.  Plus it increases the amount of PGP-encrypted email flowing around,
which reduces PGP as a marker for secret messages.

.hc


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

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

GnuPG Summit news?

[Hans-Christoph Steiner]

Hey all,

I was sorry to miss the GnuPG Summit.  Now I'm eager to hear any news from it :)

.hc

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

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

Re: Article in Forbes.

[Hans-Christoph Steiner]

Sounds like you should report it directly to GPGTools.org.  I'm sure they have
a bug tracker or mailing address somewhere.

Have you seen any technical details on this attack?  Its hard to tell exactly
what's happening from that article.

.hc

Eric F:
 Perhaps not directly gnupg related, more OS X related. But, with both
 GPGtools an GnuPG for OS X I'll post it here... (and there was this OS X
 sec. discussion the other week) :)
 
 It's seem like “Gatekeeper” is only using http if I read it correctly.
 
 Ex-NSA Researcher Finds Sneaky Way Past Apple Mac's Gatekeeper
 http://www.forbes.com/sites/thomasbrewster/2015/03/17/apple-mac-gatekeeper-bypass-exacerbated-by-unencrypted-av-downloads/
 
 “He found around 150 on his own machine, including hugely popular
 software like Microsoft Word and Excel, Apple’s own iCloud Photos and
 Dropbox. The list also included Apple’s developer tool *XCODE and email
 encryption key management software GPG Keychain, both of which he abused
 in his proof of concept attacks*.”
 
 
 I have no idea how this works, but one question that came in mind was if
 a hijacked “GPG Keychain” on a Mac computer could form a threat to gpg
 on other platforms?
 
 Anyway, interesting reading. Just wanted to share.
 
 /Eric
 
 
 
 ___
 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=vindexsearch=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=vindexsearch=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]

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=vindexsearch=0x9F0FE587374BBE81

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

Re: gpgme and Java

[Hans-Christoph Steiner]

Werner Koch:
 On Wed,  4 Mar 2015 00:57, h...@guardianproject.info said:
 
 thread at this point.  The bizarre Java wrapper of GPGME was not the
 biggest part of the problem of the GnuPG-for-Android port, but it was
 nonetheless a real problem.  Sure it is possible to use GPGME with
 
 You mean Stefan's decade old Java binding?  Well, there was not much
 interest in it for years and if there is now a need for a proper Java
 binding, it should be done.

I guess you forget that we worked a lot on it, ported it to GnuPG 2.1 and
recent GPGME versions, and added features.  There have been some other
projects starting to use our version as well.

https://github.com/guardianproject/gnupg-for-java


 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
 
 Please describe the problems you have with the API so that we actually
 have something to talk about.

Its been a long while since I was working on the guts of this, so the details
escape me.  I can only say now what I remember without digging into the code
again.  One thing that is very clear to me: we spent a ton of time figuring
out how to debug on Android, then actually running the debugging processes.
That would have been drastically easier if we had been working with pure Java
code that talked to the GnuPG processes.  The Android tools are all about
Java.  And having all those layers of code wrapping code makes debugging also
much harder.

Another thing I remember clearly is that I had to first thing about
implementing new features in JNI, then in Java.  There are also a lot of times
where data structures should be passed between Java and JNI, and that is
generally a painful process in JNI.  A pure Java interface to the GnuPG
processes would totally eliminate that.

At this point, I've done a lot of various things on Android, including running
native processes, and JNI code.  Working with a Java wrapper of GPGME made
implementing things take many more hours, probably like 3-4 times as much, as
I would expect from more native Android development.

.hc

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

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

Re: German ct magazine postulates death of pgp encryption

[Hans-Christoph Steiner]

First, most of these let PGP die rants only really apply to OpenPGP email.
GPG does a wonderful job of signing and verifying packages for Debian, Ubuntu,
Fedora, etc.

Second, OpenPGP email exists now, can be installed and used right now, and
provides proven protection for the body of an email message.  Millions of
people know how to use it, and can teach others.

That said, yes, I agree that OpenPGP email is a very flawed system, and we
should also be working on a modern replacement.  But that does not exist, not
really even close.  So if you need privacy in email now, OpenPGP email is the
main realistic choice.

.hc

gnupgpacker:
 Hello,
 
 there is a discussion ongoing regarding future of pgp/gpg encryption.
 
 German ct magazine has postulated in their last edition that our pgp
 handling seems to be too difficult for mass usage, keyserver infrastructure
 seems to be vulnerable for faked keys, published mail addresses are
 collected from keyservers and so on...
 
 Pls refer to:
 Massentaugliche E-Mail-Verschlüsselung gesucht
 http://heise.de/-2557237 
 
 Editorial: Lasst PGP sterben!
 http://heise.de/-2551008 
 
 M.Marlinspike Blog: GPG And Me
 http://www.thoughtcrime.org/blog/gpg-and-me/ 
 
 I am a little bit unhappy about this discussion because pgp still offers
 secure end-to-end encryption without the need of a superior CA, no
 compromising had been detected so far.
 
 Your positions to this ct approach?
 
 Regards, Chris
 
 
 
 ___
 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=vindexsearch=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]

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=vindexsearch=0x9F0FE587374BBE81

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

Re: [Announce] A new Beta of GnuPG 2.1 is now available

[Hans-Christoph Steiner]

After working with GnuPG 2.1 for over a year now, its great to see it in beta!
 Let's try to sync up the Android build with the official 2.1 release, so the
2.1 final release can include new support for a very popular platform :)

That should be pretty straightforward since it has been building fine on our
jenkins server.  So it will hopefully mostly about communicating the timing so
I can get an official Android build out.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81



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

Re: GnuPG class throwing null pointer exception

[Hans-Christoph Steiner]

You might consider using gnupg-for java, we've put a lot of work into it
recently since it is the basis for GnuPG for Android:

https://github.com/guardianproject/gnupg-for-java

.hc

On 05/27/2014 05:26 AM, winifred quartey-papafio wrote:
 Hello
 I'm having a problem encrypting a String text using the GnuPG class. I'm 
 using the encrypt and decrypt class from 
 http://www.macnews.co.il/mageworks/java/gnupg/sample-code.shtml which is 
 based on the GnuPG class from 
 http://lists.gnupg.org/pipermail/gnupg-devel/2002-February/018098.html. 
 However I keep getting a null pointer exception. I don't know what I'm doing 
 wrong. I'd appreciate your help with this
 
 
 this is my code:
 GnuPG pgp = new GnuPG (); result = pgp.encrypt (text, keyID);and this is what 
 throws the null pointer exception in the GnuPG class:public void 
 encrypt(String str, String rcpt) { System.out.print(Encrypting... ); try {
 p= Runtime.getRuntime().exec((gpg --armor --batch --encrypt -r + 
 rcpt).split(\\s+)); } catch (IOException io) { System.out.println(Error 
 creating process.); } ProcessStreamReader psr_stdout = new 
 ProcessStreamReader(STDIN, p.getInputStream()); ProcessStreamReader 
 psr_stderr = new ProcessStreamReader(STDERR, p.getErrorStream()); 
 
 }
 
 
 
 ___
 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

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

Re: GnuPrivacyGuard for Android v0.3 released!

[Hans-Christoph Steiner]

On 03/13/2014 07:01 AM, Mike Cardwell wrote:
 * on the Wed, Mar 12, 2014 at 08:54:01PM -0400, Hans-Christoph Steiner wrote:
 
 GnuPrivacyGuard for Android (GPGA) brings GnuPG, the most trusted name in
 encryption, to Android.  Easily encrypt, decrypt, sign and verify files of 
 any
 kind, just by sharing them to GPGA. This app aims to provide a complete,
 integrated cryptographic toolkit integrated into the Android experience.
 
 Does it supply a system of interaction with other apps via intents, like
 APG does? I'm just wondering if other apps will be able to integrate
 with it in the same way that K-9 Mail integrates with APG to add OpenPGP
 encryption for email...

We tried to provide the same Intent API as APG, but in the process discovered
that in order you use that API, the app had to be pegged to APG anyhow.  So
instead, we've been working with Dominik Schuermann of OpenKeychain and the
K-9 Mail devs to work out a new, better, open API for any app to implement as
a OpenPGP provider, and any app to use for OpenPGP services.

Our notes on the effort are here, feedback welcome:
https://dev.guardianproject.info/projects/gpgandroid/wiki/API_Sketch

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81



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

GnuPrivacyGuard for Android v0.3 released!

[Hans-Christoph Steiner]

GnuPrivacyGuard for Android (GPGA) brings GnuPG, the most trusted name in
encryption, to Android.  Easily encrypt, decrypt, sign and verify files of any
kind, just by sharing them to GPGA. This app aims to provide a complete,
integrated cryptographic toolkit integrated into the Android experience. GPGA
provides solid encryption for files private, and for verifying that files are
who you think they are.  It includes optimizations to make it operate many
times faster than other encryption packages on Android.

GPGA provides an integrated experience, so clicking on OpenPGP files just
works.  You can also share files to GPGA to decrypt, encrypt, sign, or verify
them.  GPGA will respond when you click on a OpenPGP fingerprint URL (one that
starts with openpgp4fpr:).

GPGA also gives you complete command line access to the entire GnuPG suite of
encryption software. It also serves as the test bed for complete Android
integration for all of GnuPG's crypto services, including OpenPGP, symmetric
encryption, and more.

GPGA is available in: Arabic (العربية), English, French (Français), German
(Deutsch), Norwegian (Norsk), Portuguese (Português), Spanish (Español).

Don’t see your language? Join us and help translate the app:
* https://www.transifex.com/projects/p/gpg

For a list of issues addressed in this version:
* https://dev.guardianproject.info/versions/90

For more info:
* https://guardianproject.info/code/gnupg/
* https://dev.guardianproject.info/projects/gpgandroid/wiki


***Download***

* Google Play:
https://play.google.com/store/apps/details?id=info.guardianproject.gpg
* FDroid: https://f-droid.org/repository/browse/?fdid=info.guardianproject.gpg
* direct download:
** https://guardianproject.info/releases/GnuPrivacyGuard-release-0.3.apk
** https://guardianproject.info/releases/GnuPrivacyGuard-release-0.3.apk.sig
** SHA1: dd36d1c8ea933d11a40586302376feaa4da28b0d


***Setup***
Before using GPGA, be sure to launch the app and let it finish its
installation process.  Once it has completed, then you're ready to use it!

If you want to use the command line, the easiest way to get started with GPGA
is to install Android Terminal Emulator. GPGA will automatically configure
Android Terminal Emulator as long as you have the Allow PATH extensions
settings enabled. Get the Android Terminal Emulator at
https://play.google.com/store/apps/details?id=jackpal.androidterm


***Please Report Bugs***
This is a big project, so there will inevitably be bugs.  Help us improve this
software by filing bug reports about any problem that you encounter. Feature
requests are also welcome!
https://dev.guardianproject.info/projects/gpgandroid/issues



-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81



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

Re: Newbie: Search for iphone method

[Hans-Christoph Steiner]

Since GnuPG has run on Mac OS X and FreeBSD for a long time now, it should be
a pretty easy port to get GnuPG running on iPhone.  Someone would have to make
a GUI tho.

.hc

On 02/18/2014 04:00 AM, Jürgen Polster wrote:
 Hmm,
 One of the options for IOS user is oPenGp, which interacts nicely. But to
 answer correctly: no.
 
 *JP*
 
 
 
 ___
 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

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

Re: Non email addresses in UID

[Hans-Christoph Steiner]

I think it makes a lot of sense to be able to associate more things with
OpenPGP keys.  I'm particularly interested in seeing OTR keys and XMPP
identities in OpenPGP keys.

.hc

On 01/23/2014 05:50 PM, Steve Jones wrote:
 I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by 
 convention a UID is an rfc2822 email address but this is not a 
 requirement[1]. Gnupg does enforce that restriction unless you explicitly 
 disable it. It would seem to make sense to include other strings that can 
 identify a user, many people have various URLs which could be said to relate 
 to their identity, Facebook accounts, blogs etc... It could potentially be 
 useful to be able to associate a key with these other identities, i.e. if you 
 get an email purporting to be from someone you only know on a webforum it 
 would be useful to be able to verify this. I'm curious what other people on 
 this list think of this.
 
 
 [1] http://tools.ietf.org/html/rfc4880#section-5.11
 
 
 
 ___
 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



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

Re: using an OpenPGP card with Java (keytool and jarsigner)

[Hans-Christoph Steiner]

On 01/17/2014 03:05 AM, Werner Koch wrote:
 On Fri, 17 Jan 2014 02:24, se...@literati.org said:
 
 Scute works great with Firefox, but keep in mind it requires gpg-agent (or
 
 Sure.  That is the whole point of the exercise.
 
 at least scdaemon). AFAIK it's not intended to work with anything other
 than Firefox right now. I've been meaning to try it out with wpa_supplicant
 
 Well, it has not been tested with anything else.  However, it implements
 the pkcs#11 interface properly for signature keys and Marcus even came
 up with a free and readable implementation of the pkcs11 header file.
 
 The code seems fairly straightforward and it comes with documentation for
 spying on the PKCS#11 calls to help troubleshoot the implementation, so
 even if it doesn't work it may not require too much hacking to make it
 
 Right.  I would love to see a new maintainer for it.  If there are any
 GnuPG related problems I will for sure help with it.

How does scute's PKCS#11 support differ from OpenSC's?  If the OpenPGP card is
supported by opensc, is that providing the same thing as scute?  I already
have Java's keytool talking to the OpenPGP card via OpenSC, I just can't get
it to sign something yet.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

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

Re: using an OpenPGP card with Java (keytool and jarsigner)

[Hans-Christoph Steiner]

On 01/08/2014 07:02 AM, Werner Koch wrote:
 On Tue,  7 Jan 2014 15:32, h...@guardianproject.info said:
 
 OpenPGP card as a PKCS11 keystore.  It seems that things are close: Java can
 use NSS as a provider of PKCS11.  I guess the question is whether opensc is
 making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't
 
 Scute also provides an pkcs#11 interface to NSS.  Thus you should be
 able to use it also with Java.

I haven't tried scute, but it seems that opensc v0.13 provides a PKCS#11
interface to the OpenPGP card.  I am able to get keytool to report the
certificate in key position #3, but the question I have now is that given that
key #3 is for authentication, is there some restriction in the OpenPGP card
that would prevent the certificate/key combo in position #3 from being used
for signing?

I did read about using opensc with an OpenPGP card to provide S/MIME services.
 What I read there is that in order to use the certificate/key combo in
position #3 for decrypting emails, the key in position #2 (decryption) must
match the key in position number #3.  Is there a similar restriction for 
signing?

I forget if I mentioned this, but the grand goal is to have a single hardware
security module that can sign the Android APK using jarsigner, then make a
OpenPGP signature on the APK, then optionally provide authentication for
scp'ing the resulting files to the release server.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

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

using an OpenPGP card with Java (keytool and jarsigner)

[Hans-Christoph Steiner]

Hey all,

Does anyone know if there is any chance of using an OpenPGP smart card for
Java?  I know that GnuPG doesn't support PKCS#11, but I was wondering if
things work the otherway around: java using the OpenPGP card.  It would be
super useful to be able to use the same smartcard for both Android APK signing
and OpenPGP signing.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

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

Re: using an OpenPGP card with Java (keytool and jarsigner)

[Hans-Christoph Steiner]

NdK wrote:
 Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto:
 
 Does anyone know if there is any chance of using an OpenPGP smart card for
 Java?  I know that GnuPG doesn't support PKCS#11, but I was wondering if
 things work the otherway around: java using the OpenPGP card.  It would be
 super useful to be able to use the same smartcard for both Android APK 
 signing
 and OpenPGP signing.
 IIRC there is an OpenSC driver for OpenPGP cards, that makes 'em
 accessible throught PKCS#11.
 
 https://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg06206.html
 
 Seems it's quite old... Maybe if you want to take over developement...
 
 BYtE,
  Diego.

opensc's support for the OpenPGP card has improved quite a bit in 0.13, it
seems.  There is now full write support and a specific 'openpgp-tool' even:
https://www.opensc-project.org/opensc/wiki/OpenPGP

I don't need write support at all, I just want to get keytool to use the
OpenPGP card as a PKCS11 keystore.  It seems that things are close: Java can
use NSS as a provider of PKCS11.  I guess the question is whether opensc is
making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't
fully understand.

Once I figure this out, my plan is to integrate my work into the relevant
Debian packages, and then promote the use of the OpenPGP card for Android APK
signing keys.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

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

Re: using an OpenPGP card with Java (keytool and jarsigner)

[Hans-Christoph Steiner]

On 01/07/2014 09:32 AM, Hans-Christoph Steiner wrote:
 
 NdK wrote:
 Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto:

 Does anyone know if there is any chance of using an OpenPGP smart card for
 Java?  I know that GnuPG doesn't support PKCS#11, but I was wondering if
 things work the otherway around: java using the OpenPGP card.  It would be
 super useful to be able to use the same smartcard for both Android APK 
 signing
 and OpenPGP signing.
 IIRC there is an OpenSC driver for OpenPGP cards, that makes 'em
 accessible throught PKCS#11.

 https://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg06206.html

 Seems it's quite old... Maybe if you want to take over developement...

 BYtE,
  Diego.
 
 opensc's support for the OpenPGP card has improved quite a bit in 0.13, it
 seems.  There is now full write support and a specific 'openpgp-tool' even:
 https://www.opensc-project.org/opensc/wiki/OpenPGP
 
 I don't need write support at all, I just want to get keytool to use the
 OpenPGP card as a PKCS11 keystore.  It seems that things are close: Java can
 use NSS as a provider of PKCS11.  I guess the question is whether opensc is
 making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't
 fully understand.
 
 Once I figure this out, my plan is to integrate my work into the relevant
 Debian packages, and then promote the use of the OpenPGP card for Android APK
 signing keys.
 
 .hc

So now I have it to the point where I can see the certificate on the OpenPGP
card with keytool, but I can't get jarsigner to use it.  Do I have to mark the
key on the card as a signing key somehow?  Is it just not possible to have the
PKCS#11 certificate part of the OpenPGP card be used as a signing key?

Here is the debug transcripts of my keytool and jarsigner commands:


$ keytool -v -keystore NONE -storetype PKCS11 -providerName SunPKCS11-OpenSC 
-list
Enter keystore password:

Keystore type: PKCS11
Keystore provider: SunPKCS11-OpenSC

Your keystore contains 1 entry

Alias name: Cardholder certificate
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: O=Internet Widgits Pty Ltd, L=Brooklny, ST=New York, C=US
Issuer: O=Internet Widgits Pty Ltd, L=Brooklny, ST=New York, C=US
Serial number: d76589b02e0f422a
Valid from: Mon Jan 06 20:09:06 EST 2014 until: Wed Feb 05 20:09:06 EST 2014
Certificate fingerprints:
 MD5:  75:CB:92:5C:F8:4B:F3:0D:54:59:48:D5:4D:8A:08:5B
 SHA1: 57:C1:4B:12:26:55:66:0E:94:5A:D1:53:46:C0:76:6E:D5:3F:08:91
 SHA256:
F6:EC:49:9A:AB:04:1A:E0:EE:89:E2:D1:21:8D:79:42:7F:B5:5F:2E:B2:F7:10:53:38:CD:85:20:92:78:69:9F
 Signature algorithm name: SHA1withRSA
 Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: 85 1F 1B 01 09 3D 12 E2   88 17 0C 91 50 5F 88 1E  .=..P_..
0010: D3 C1 1B D0
]
]

#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 85 1F 1B 01 09 3D 12 E2   88 17 0C 91 50 5F 88 1E  .=..P_..
0010: D3 C1 1B D0
]
]



***
***



$ export OPENSC_DEBUG=2
$ jarsigner -verbose -keystore NONE -storetype PKCS11  -providerClass
sun.security.pkcs11.SunPKCS11 -providerArg
/etc/java-7-openjdk/security/opensc.cfg libs/commons-io-2.2.jar Cardholder
certificate -J-Djava.security.debug=sunpkcs11
SunPKCS11 loading /etc/java-7-openjdk/security/opensc.cfg
sunpkcs11: Initializing PKCS#11 library 
/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Information for provider SunPKCS11-OpenSC
Library info:
  cryptokiVersion: 2.20
  manufacturerID: OpenSC (www.opensc-project.org)
  flags: 0
  libraryDescription: Smart card PKCS#11 API
  libraryVersion: 0.00
All slots: -1, 1, 2
Slots with tokens: 1, 2
Slot info for slot 2:
  slotDescription: Gemalto GemPC Key 00 00

  manufacturerID: OpenSC (www.opensc-project.org)
  flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT
  hardwareVersion: 0.00
  firmwareVersion: 0.00
Token info for token in slot 2:
  label: OpenPGP card (User PIN)
  manufacturerID: ZeitControl
  model: PKCS#15 emulated
  serialNumber: 000514f9
  flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED |
CKF_TOKEN_INITIALIZED
  ulMaxSessionCount: CK_EFFECTIVELY_INFINITE
  ulSessionCount: 0
  ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE
  ulRwSessionCount: 0
  ulMaxPinLen: 32
  ulMinPinLen: 6
  ulTotalPublicMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePublicMemory: CK_UNAVAILABLE_INFORMATION
  ulTotalPrivateMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePrivateMemory: CK_UNAVAILABLE_INFORMATION
  hardwareVersion: 0.00
  firmwareVersion: 0.00
  utcTime:
Mechanism CKM_SHA_1:
  ulMinKeySize: 0
  ulMaxKeySize: 0
  flags: 1024 = CKF_DIGEST
Mechanism

GnuPG Command line: now in the Play Store!

[Hans-Christoph Steiner]

https://play.google.com/store/apps/details?id=info.guardianproject.gpg

This alpha release of our command-line developer tool brings GnuPG to Android
for the first time!

GNU Privacy Guard Command-Line (gpgcli) gives you command line access to
the entire GnuPG suite of encryption software. GPG is GNU’s tool for
end-to-end secure communication and encrypted data storage. This trusted
protocol is the free software alternative to PGP. GnuPG 2.1 is the new
modularized version of GnuPG that now supports OpenPGP and S/MIME.


***Setup***

Before using gpgcli, be sure to launch the app and let it finish its
installation process. Once it has completed, then you're ready to use it.
The easiest way to get started with gpgcli is to install Android Terminal
Emulator. gpgcli will automatically configure Android Terminal Emulator as
long as you have the Allow PATH extensions settings enabled. Get the
Android Terminal Emulator at
https://play.google.com/store/apps/details?id=jackpal.androidterm


***Please Report Bugs***

This is an early release of a big project, so there will inevitable be bugs.
Help us improve this software by filing bug reports about any problem that you
encounter. Feature requests are also welcome!
https://dev.guardianproject.info/projects/gpgandroid/issues


***Coming Soon***

★ SECURITY FOR APPS: We have an API in the works so that developers can
easily embed this into any app to give it state of the art security features.

★ GUI: We’re building a graphical user interface for easy key management.

★ STAY UP TO DATE: Sign up for our low-traffic Guardian-Dev mailing list to
be notified when the API and GUI are released:
https://lists.mayfirst.org/mailman/listinfo/guardian-dev.

★ Find us in IRC, we want feedback!
irc://irc.freenode.net/guardianproject
irc://irc.oftc.net/guardianproject



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