http://permalink.gmane.org/gmane.comp.security.monkeysphere hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.monkeysphere/1065 <pre> I think it was a combination of two things: a. I think some sort of generic socket server setup code should live in libassuan and be shared by gpgme-tool and gpg-agent. Werner feels that few other tools would use such utility code [1], but may be open to convincing. b. I don't have any Windows access or experience, so writing a cross platform socket server is outside my reach. Werner doesn't like the idea of a gpgme-tool server that only works on POSIX [1]. Between these two barriers, the way forward looked difficult ;). I had something that worked for me, and not enough time to push through to something that satisfied both of us. I'd be happy to pick this up again (or hand it off to someone else) but it's not high on my priority list at the moment. I think something along these lines will land *eventually* ;). Cheers, Trevor [1]: http://article.gmane.org/gmane.comp.encryption.gpg.devel/17164 </pre> W. Trevor King 2013-05-09T16:07:49 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1064 <pre> On 05/08/2013 07:02 PM, W. Trevor King wrote: We're quite interested in your pyassuan approach for our GnuPG for Android work. What are the issues that Werner has with those commits? .hc </pre> Hans-Christoph Steiner 2013-05-09T15:28:17 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1063 <pre> I haven't chimed in on the monkeysphere front in a while, but this sounds like a good time to shamelessly plug my pgp-mime package [1], which uses my pyassuan [2] implementation to talk to a gpgme-tool server [3] over a local socket. I haven't been able to convince Werner to accept my patched server [4], but it's a fairly small series [5]. I think the API in pgp_mime.crypt is pretty reasonable. The whole structure has been running well under my pygrader [6] for more than a year now. Just throwing another option on the table ;). Cheers, Trevor [1]: https://pypi.python.org/pypi/pgp-mime/ [2]: https://pypi.python.org/pypi/pyassuan/ [3]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=src/gpgme-tool.c;hb=HEAD [4]: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/16843 [5]: http://git.tremily.us/?p=gpgme.git;a=shortlog;h=refs/heads/socket [6]: https://pypi.python.org/pypi/pygrader/ </pre> W. Trevor King 2013-05-08T23:02:22 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1062 <pre> First, I'm biased, because I've only used python-gnupg (in FreedomBuddy). However, it's really simple to use [0]. Therefore, my recommendation is 1. Maybe 2, but it feels unfriendly, and the developer's promised to fix that really unfriendly bug, someday. The biggest trick to remember is that the data has to be manually stringified. Using python-gnupg, it was really simple to create an decryptor iterator (decryptorators?) which could unwrap multiply-encrypted messages [1]. Nick 0: https://github.com/NickDaly/FreedomBuddy/blob/master/src/tests/test_gnupg.py 1: The first link is the unwrapper, the second is an example of its use: - https://github.com/NickDaly/FreedomBuddy/blob/master/src/pgpprocessor.py - https://github.com/NickDaly/FreedomBuddy/blob/master/src/santiago.py#L281 -- If you need to get in touch with me, try any of these methods: https://www.betweennowhere.net/nick-daly.asc.txt </pre> Nick M. Daly 2013-05-09T00:20:38 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1061 <pre> The Python library we use is not a binding to gpgme, it's a binding to the gpg binary itself. By the way, gpgme is also a binding to the gpg binary which totally boggles my mind. A. </pre> anarcat 2013-05-08T22:39:04 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1060 <pre> These sounds like general issues with gpgme, not with any python bindings in particular. There are multiple python gpgme interfaces that I know of: python-gpgme and python-pyme. I was referring to python-gpgme only, which has a very simple and straightforward pythonic interface. I definitely recommend it for basic encryption/decryption and signing/verifying. It also has some amount of key management tools, but I haven't experimented with it much. jamie. </pre> Jameson Graef Rollins 2013-05-08T21:07:28 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1059 <pre> [...] It's worth noting that gpg 2.1 (currently in beta) is supposed to remove all private key handling from gpg itself, delegating that to gpg-agent. I don't know if the reason for gpgme's limitation in this area is related to these plans, but it might be; if that's the case, it's conceivable that code that works for gpg 1.4.x and 2.0.x won't work for gpg 2.1 :/ I haven't tried this myself, though. I had a discussion with some of the gpg maintainers for debian a couple months ago about how we can move forward toward having gpg 2.1 in debian experimental so that we can "safely" experiment with this sort of thing. i will try to push that along further to get some clarity on it. that said, i don't think you should block on this investigation. we can always fix future incompatibilities in the future, and it's more important that we get things working now :) Regards, --dkg </pre> Daniel Kahn Gillmor 2013-05-08T19:32:48 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1058 <pre> Hey, sorry. I should have included another part of anarcat's comments in gpg.py. He explains it better than I can: """ This API was written to replace the GPGME bindings because the GPGME API has a few problems: 1. it is arcane and difficult to grasp 2. it is very closely bound to the internal GPG data and commandline structures, which are quite confusing </pre> Simon Fondrie-Teitler 2013-05-08T19:02:36 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1057 <pre> Hey, Simon. Just to throw in some extra confusion here, I should mention that I am using python-gpgme for a different project and find it to have a very nice, naturally pythonic interface. Unfortunately it is almost entirely undocumented, but it comes with lots of test code from which one can learn by example. Overall I would say it is a very good python gpg interface. jamie. </pre> Jameson Graef Rollins 2013-05-08T15:55:50 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1056 <pre> If you have the time and energy, I would prefer 1 and even 2, if necessary. 0 is the current status quo and is not really satisfactory, especially since there are still bugs in the codebase and corner cases that are not correctly handled. Note the TODO items related to merging (tasks 1): - add key signing support - split the "context" and "keyring" classes - port monkeysign to python-gnupg To which I would add: - make sure python-gnupg is secure (ie. that it doesn't use popen([...], shell=True), see https://github.com/isislovecruft/python-gnupg In fact, that latter codebase *could* be the public fork we are talking about here... A. </pre> anarcat 2013-05-08T13:02:51 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1055 <pre> That's great! Can't wait to see OTR bridged with GPG - and it's what Monkeysphere is all about! That seems reasonable! I am sure you will find a mentor here that will sponsor that package if necessary. [ 6 more citation lines. Click/Enter to show. ] Yes... error handling isn't exactly great. In fact, that's a bug right there... (We should probably generate our own exceptions for such errors and catch them higher in the UI so that those kind of stuff doesn't happen anymore, regardless of the coding errors in the backend...) Thanks for looking into this! </pre> anarcat 2013-05-08T13:02:32 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1054 <pre>I've been looking through the monkeysign source code and getting a better understanding of it. I started working on a couple of issues with it, but realized that before I go any further it's probably a good idea to decide what to do about the library used for gpg interaction. To quote from the source code: A problem with the project not listed is that it's not really community driven, instead it's a dump of a part of a larger project, with no version control history. For more see here: https://code.google.com/p/python-gnupg/issues/detail?id=20 Quote: Does anyone have ideas of what to do? I see three options: 0. Continue with the gpg.py currently in the project 1. Add key signing support to python-gnupg and send the changes back to them 2. Fork python-gnupg and develop it separately, either under monkeysign or separately. Thoughts? --simonft </pre> Simon Fondrie-Teitler 2013-05-07T23:10:40 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1053 <pre> I'm very happy to see that this is written in Python :) We're working on parallel stuff for OTR keys, including QRCode-based fingerprint. We should definitely talk about how to collaborate since we are planning GPG integration. https://github.com/guardianproject/otrfileconverter/ We're using the pure Python python-qrcode lib to generate QRCodes because its really easy to use, and it can print out QRCode to the terminal. I'm working with the packager to get it into Debian via the mentors.debian.net process http://mentors.debian.net/package/qrcode I just tried the scanning with monkeysign, but using a OTR fingerprint from Gibberbot. It scanned successfully, then started trying to fetch it from the keyserver, which will most likely fail since its an OTR key, and I got this: monkeysign $ ./msign Traceback (most recent call last): File "./msign", line 372, in watch_out_callback self.msui.find_key() File "/media/share/code/monkeysphere/monkeysign/ui.py", line 214, in find_key self.log('failed t</pre> Hans-Christoph Steiner 2013-05-06T15:30:28 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1052 <pre>Hi, Simon and Monkeysphere Developers, My apologies for the delay in responding. We had an unexpectedly high number of applicants this round (more than triple compared to the previous round) and that has caused a backlog in sending out responses. With great reluctance, we decided not to fund the Monkeysign improvements this round. We do think it's an important project, and if we had more funds available we might well have chosen differently. The proposal was a strong finalist, even among the many good proposals we received. ("Finalist" is a more or less official category here, meaning basically "We wish we had just a bit more money so we could fund this one too". You can refer to it to when soliciting funding elsewhere -- e.g., if someone contacted us to ask if the Monkeysign proposal was one of our finalists, we would confirm it and tell them why.) I regret that I can't give you better news this time, but the proposal is an excellent one and we very much hope you'll be able to implement it. Sincerel</pre> Karl Fogel 2013-05-02T16:56:30 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1051 <pre>I've looked into this some more. Originally the code had keyid()[8:], which I was reading as getting everything before the 8th char. However, it actually gets everything /after/ the 8th char. keyid() by default returns 8 chars, which is why nothing was showing up. What keyid() is doing in gpg.py is taking the fingerprint (fpr), and returning the last x (or in this case l) chars in the fingerprint. Note that is an L, not a one. This is the correct way to get the short keyid, however I'm not sure if it makes sense to pass in the number of chars from the end to return. As dkg stated, the gpg command has --keyid-format (short|long), which allows you to choose whether you want a keyid of length 8 or 16. Perhaps we should add a choice more similar to this in gpg.py? I also like the idea of a more readable fingerprint. Perhaps use the email address? Do people have more than one key per email address? Regardless, the [:8] can be taken out. --Simon </pre> Simon Fondrie-Teitler 2013-03-29T00:44:28 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1050 <pre> the last 8 hex digits of the full fingerprint are the traditional short keyid. the last 16 hex digits are the traditional long keyid: https://tools.ietf.org/html/rfc4880#section-12.2 the short keyid is trivially spoofable and should not be relied on: http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html I agree with anarcat that if we're going to use a short keyid, we should use the canonical form. however, i think that exposing keyids and fingerprints to the user is a bad idea -- one of the things that is so great about monkeysign is that people shouldn't ever need to see or think about the unintelligible fingerprint. Is there a way to choose a more sensible file name that doesn't expose the user to gibberish? for example, what if we were to name the file with some reasonable flattening of the primary User ID and the creation date of the primary key? --dkg </pre> Daniel Kahn Gillmor 2013-03-28T23:51:49 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1049 <pre> Hum really? I would have thought the keyid would be more recognizable.. If python fails to get the last 8, maybe we should fix that instead... In fact, why doesn't keyid() return... the keyid? Ie. why do we need to do a [8:] splice there? A. </pre> anarcat 2013-03-28T22:48:15 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1048 <pre>From: Simon &lt;simonft&lt; at &gt;riseup.net&gt; The methods to print the qr code for the key were not in sync with the gpg.py module. They have been updated to match --- msign | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/msign b/msign index 2ef2b3d..84df333 100755 --- a/msign +++ b/msign &lt; at &gt;&lt; at &gt; -304,7 +304,7 &lt; at &gt;&lt; at &gt; class MonkeysignScan(gtk.Window): self.clip.set_image(self.pixbuf) def print_op(self, widget=None): -keyid = self.ultimate_keys[self.mykey.get_active()].subkeys[0].keyid[8:] +keyid = self.ultimate_keys[self.mykey.get_active()].keyid()[8:] print_op = gtk.PrintOperation() print_op.set_job_name('Monkeysign-'+keyid) print_op.set_n_pages(1) </pre> Simon Fondrie-Teitler 2013-03-28T02:46:13 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1047 <pre>From: Simon &lt;simonft&lt; at &gt;riseup.net&gt; When saving the qrcode of the key fingerprint, use the first 8 chars of the key id and not the last 8. This first 8 are more easily recognisable, and python was failing when trying to get the last 8. Note that in most cases the first 8 and last eight will be the same (i.e. the key will only have 8 chars in the keyid). --- msign | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/msign b/msign index 59f8673..0ce0dce 100755 --- a/msign +++ b/msign &lt; at &gt;&lt; at &gt; -289,7 +289,7 &lt; at &gt;&lt; at &gt; class MonkeysignScan(gtk.Window): image = self.make_qrcode(key.fpr) dialog = gtk.FileChooserDialog("Save QR code", None, gtk.FILE_CHOOSER_ACTION_SAVE, (gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, gtk.STOCK_SAVE, gtk.RESPONSE_OK)) dialog.set_default_response(gtk.RESPONSE_OK) -dialog.set_current_name(key.keyid()[8:] + '.png') +dialog.set_current_name(key.keyid()[:8] + '.png') dialog.show() response = dialog.run() if response == gtk.RESPONSE_OK: </pre> Simon Fondrie-Teitler 2013-03-28T02:46:15 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1046 <pre>From: Simon &lt;simonft&lt; at &gt;riseup.net&gt; key.keyid is a function, not a variable, and should be treated as such. This gits rid of errors when trying to save a generated image of a key. --- msign | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/msign b/msign index 84df333..59f8673 100755 --- a/msign +++ b/msign &lt; at &gt;&lt; at &gt; -289,7 +289,7 &lt; at &gt;&lt; at &gt; class MonkeysignScan(gtk.Window): image = self.make_qrcode(key.fpr) dialog = gtk.FileChooserDialog("Save QR code", None, gtk.FILE_CHOOSER_ACTION_SAVE, (gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, gtk.STOCK_SAVE, gtk.RESPONSE_OK)) dialog.set_default_response(gtk.RESPONSE_OK) -dialog.set_current_name(key.keyid[8:] + '.png') +dialog.set_current_name(key.keyid()[8:] + '.png') dialog.show() response = dialog.run() if response == gtk.RESPONSE_OK: </pre> Simon Fondrie-Teitler 2013-03-28T02:46:14 http://permalink.gmane.org/gmane.comp.security.monkeysphere/1045 <pre> Thank you, Simon! I'm CC'ing the OpenITP team internal list on this response, mainly to get the proposal into our archives where we can track it (so please keep that list CC'd on any followup). I assume the below is the full text of the proposal? There were no attachments on your mail, but I always ask just to make sure... Best, -Karl </pre> Karl Fogel 2013-03-27T00:26:28 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.monkeysphere