Re: How to deal with a 2nd OpenPGP Summit?
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 >>> https://en.wikipedia.org/wiki/Chatham_House_Rule). >>> Some p
Re: gnupg-for-java
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&search=0x9F0FE587374BBE81 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg-for-java
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&search=0x9F0FE587374BBE81 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Facebook and OpenPGP
MFPA: > > > On Monday 1 June 2015 at 5:37:33 PM, in > , > 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=vindex&search=0x9F0FE587374BBE81 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
Werner Koch: > On Mon, 27 Apr 2015 01:31, b...@pagekite.net said: >> Thanks for the write-up, Werner! :-) > > Actually you have been much faster with your report > https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html > >>> disappointed that many of the participants favored this closed >>> invitation-only style summit and want the next meeting to happen the > >> On the one hand, I suspect it would be very hard to maintain the >> excellent signal/noise ratio we had, in a completely open summit. On > > Maybe. We are used to work on mailing list and I would bet that in most > cases it is easier to ask too noisy participants to behave well during a > physical meeting than on mailing lists. The IETF has quite some > experience with that and requires physical meetings for important tasks. In my 20 years of experience attending and organizing all sorts of tech conferences, I find that open conferences tend to better than closed ones. But mostly, the open- or closedness is not the biggest factor in the signal to noise ratio. Instead, it is the level of organization. The best conferences I've been to have been completely open and mostly self-organized (aka Barcamp aka Unconference). But that requires a specific audience that is well practiced in self-organization. I have been to very good conferences that were semi-self-organized, i.e. barcamp-style with some well practiced moderators really guiding the whole process (for example, a "Gunner Event" run by Aspiration Tech). And as Werner says, it is much easier to tell people in person to reduce the noise than it is on all of the various open internet forums we operate on. I really think it is quite important that these summits are open to anyone who wants to attend. I have run a number of barcamps with small groups, so I'm happy to help moderate if I can attend. .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
GnuPG Summit news?
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=vindex&search=0x9F0FE587374BBE81 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Article in Forbes.
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=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
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
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
cython wrapping gpgme WAS: 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). 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. http://pyme.sourceforge.net/ https://launchpad.net/pygpgme http://www.red-dove.com/python_gnupg/ https://bitbucket.org/vinay.sajip/python-gnupg https://github.com/isislovecruft/python-gnupg .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
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: gpgme and Java
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=vindex&search=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
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=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
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: [Announce] A new Beta of GnuPG 2.1 is now available
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
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!
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!
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
Good point. I forgot about the iTunes restrictions, they are not compatible with the GPL for sure, and probably not the LGPL, so a GnuPG port cannot be legally distributed in Apple iTunes. .hc On 02/18/2014 03:11 PM, sys...@ioioioio.eu wrote: > consider *cydia* for jailbreak/iphone, as it uses apt-get routines to deliver > software somehow. that could help understanding the mechanics behind the > itunes/wall. some sort of software is prohibited for/from apple, so check > usage of encryption software as well on us.import/export rules as well to safe > energy for this project. > > a browser based piece of software would be more in the focus, i mentioned some > weeks ago. > > anyhow, good luck with xcode ( dev. enviroment for iphone/ios ) > https://developer.apple.com/xcode/ > > regards > > Am 18.02.2014 21:05, schrieb mercuryrising: >> And how would you make >> A GUI. What >> Programming would I have to learn. I used to program in basic Between 37 and >> 25 years ago. On a GRS 80 laptop. Are we talking a degree in software >> engineering? >> Sent from my iPhone >> >>> On Feb 18, 2014, at 6:27 AM, Hans-Christoph Steiner >>> wrote: >>> >>> >>> 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 >> ___ >> 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: Newbie: Search for iphone method
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
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)
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)
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
Re: using an OpenPGP card with Java (keytool and jarsigner)
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_UNAVAILA
Re: using an OpenPGP card with Java (keytool and jarsigner)
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
using an OpenPGP card with Java (keytool and jarsigner)
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
GnuPG Command line: now in the Play Store!
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
