http://blog.gmane.org/gmane.comp.web.salmon hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.salmon/197 <pre>hi all! i've been slowly building facebook and twitter bridges for the ostatus component protocols, and i'm starting on the one for salmon now. i wanted to give you all a heads up and solicit any thoughts or feedback you might have. background: http://snarfed.org/2012-03-12_activitystreams_for_facebook_and_twitter http://snarfed.org/2012-02-22_portablecontacts_for_facebook_and_twitter http://snarfed.org/2012-01-16_webfinger_for_facebook_and_twitter i also wanted to check on the status of python libraries. i've looked at the reference code in http://code.google.com/p/salmon-protocol/ and a django library, https://github.com/paulosman/django-salmon/tree/master/django_salmon , from paul osman, who i've cc'ed and talked with offline . they're both good starting points, but reference lib is a bit incomplete, the magic sig part has two branches :/, and paul's lib is tightly integrated with django. do i have that all right? any recommendations on specific code to reuse or avoid? btw, the code for this project is in https://github.com/snarfed/salmon-unofficial , alongside the other bridges. thanks in advance! </pre> Ryan B 2012-05-27T20:34:24 http://comments.gmane.org/gmane.comp.web.salmon/196 <pre>Status: New Owner: johnrobertpanzer New issue 36 by heaven: PATCH: minor bug fix to magic signatures spec http://code.google.com/p/salmon-protocol/issues/detail?id=36 ...specifically, s/"data" parameter/"value" parameter/. Attachments: magicsigs_spec_fix.patch 2.5 KB </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2012-05-29T03:06:00 http://comments.gmane.org/gmane.comp.web.salmon/191 <pre>Hi everyone, I am afraid, I need some help with my MagicSignatures implementation in Perl. I started following the textbooks pretty straight and then adjusted it to come closer to real world examples I found in some test suites of other implementations. However, verification does not work - either because the final encoding messages do not match or the length of the signature is not equivalent to the length of the RSA modulus. It would be great to have an example with traces of all function input- outputs for the signing and verification flows following https://www.ietf.org/rfc/rfc3447.txt so an implementor could see where he or she is wrong (with base64enc for binary data of course)! Is there something available like that? Or is there a canonical test suite an implementation has to pass? I read that there are lots of broken (against the spec) implementations out there which makes testing especially hard as you don't know, if the signature should really be verified. Oh - and ... well - it would be GREAT if someone could look in to the code and help me ... (the documentation should be okay, I believe). The signing/verification and the envelope construction can be found here: https://github.com/Akron/Sojolicious/blob/master/lib/Mojolicious/Plugin/MagicSignatures/Key.pm https://github.com/Akron/Sojolicious/blob/master/lib/Mojolicious/Plugin/MagicSignatures/Envelope.pm The (failing) test suites can be found here: https://github.com/Akron/Sojolicious/blob/master/t/MagicKey.t https://github.com/Akron/Sojolicious/blob/master/t/MagicEnvelope.t Thank you all! Nils </pre> Nils D. 2011-10-25T14:05:54 http://comments.gmane.org/gmane.comp.web.salmon/190 <pre>Status: New Owner: johnrobertpanzer New issue 35 by mimecuv...-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org: signing unicode fails in Envelope http://code.google.com/p/salmon-protocol/issues/detail?id=35 The problem is in magicsig/__init__.py It seems that all places where it does et.XML(data) should be et.XML(data.encode('utf8')) </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-09-02T00:38:47 http://comments.gmane.org/gmane.comp.web.salmon/189 <pre>Status: New Owner: johnrobertpanzer New issue 34 by mimecuv...-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org: test_salmon fails http://code.google.com/p/salmon-protocol/issues/detail?id=34 Traceback (most recent call last): File "test_salmon.py", line 36, in &lt;module&gt; class TestSalmonProtocol(unittest.TestCase): File "test_salmon.py", line 39, in TestSalmonProtocol class MockKeyRetriever(magicsig.PublicKeyRetriever): AttributeError: 'module' object has no attribute 'PublicKeyRetriever' Should be changed to KeyRetriever. Then, this error: Traceback (most recent call last): File "test_salmon.py", line 80, in testSignSalmon 'acct:test-hcDgGtZH8xNBDgjK7y7TUQ&lt; at &gt;public.gmane.org') File "/Users/mime/Sites/helloworld/packages/salmon/../salmon/__init__.py", line 61, in SignSalmon if not self.magicenv.CheckAuthorship(text, AttributeError: 'MagicEnvelopeProtocol' object has no attribute 'CheckAuthorship' Should be changed to IsAllowedSigner and then some more errors - not sure if the file just needs to be rewritten completely... </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-08-26T20:36:43 http://comments.gmane.org/gmane.comp.web.salmon/187 <pre>In the latest experimental draft, &lt;Property type="ns:magic_key" mpk:key_id="1"&gt; RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB &lt;/Property&gt; &lt;Property type="ns:magic_key" mpk:key_id="2"&gt; RSA.wvwmdK0eeUPe2hURBTstndvmUUPb4UZTd6wvwmddSrrC89yN8k6FilGwvwmddSKE5z_jvKUEKj9f4Pj-5CmHww.AQAB &lt;/Property&gt; So that I may parse this correctly, what is the XML namespace attached to 'mpk'? </pre> Mike Macgirvin 2011-08-26T01:55:48 http://comments.gmane.org/gmane.comp.web.salmon/180 <pre>Hi (Apologies for cross-posting, but the issue is pertaining to implementers, which are more likely interested in the full OStatus suite.) Today I was pointed to a microblog entry[1] claiming that almost all implementations of the RSASSA-PKCS1-v1_5 padding are broken. This is a confirmation of my own experience, having unsuccessfully tried to implement it both with OpenSSL[2] and manually[3]. I propose a few things we could do about this: * Decide whether to stick with real PKCS padding, or to keep the different but already-implemented padding * Fix the examples in the Salmon protocol specification (known issue[4] if you discover it after wondering why your own tests fail) * Appoint a reference (or known-to-work) implementation for developers to test against. I was happy to have had a VM image w/ StatusNet from FSW2011, but the OStatus plugin I tested against came with its own PHP RSA implementation that hasn't been reviewed as much as OpenSSL has. Hence, the potential location of errors isn't as narrow. [1] http://macgirvin.com/display/mike/22042 [2] https://github.com/astro/node-ostatus/blob/dev-salmon/src/provenance.cc [3] https://github.com/astro/node-ostatus/blob/dev-salmon-manual-emsa/src/provenance.cc [4] http://code.google.com/p/salmon-protocol/issues/detail?id=8 </pre> Astro 2011-07-25T15:33:05 http://comments.gmane.org/gmane.comp.web.salmon/170 <pre>Status: New Owner: johnrobertpanzer New issue 33 by johnrobertpanzer: RSA PKCS algorithm summary is misleading http://code.google.com/p/salmon-protocol/issues/detail?id=33 In the magic signature spec, the final step of the signing algorithm description is misleading at best: 6. RSA sign the emsa byte sequence This should read something like "encrypt the emsa byte sequence with the RSA private key; the resulting byte sequence is the magic signature in binary form". (Some libraries call this "sign()" and others call something else "sign()" so it's much much better to be explicit here.) </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-08-04T00:47:55 http://comments.gmane.org/gmane.comp.web.salmon/162 <pre>Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 32 by m...-eLTliElJQQs&lt; at &gt;public.gmane.org: public key modulus bytes count http://code.google.com/p/salmon-protocol/issues/detail?id=32 shouldn't http://code.google.com/p/salmon-protocol/source/browse/trunk/lib/python/magicsig_hjfreyer/magicsigalg.py#225 be pad_string = chr(0xFF) * (msg_size_bits - len(encoded) - 3) instead of pad_string = chr(0xFF) * (msg_size_bits / 8 - len(encoded) - 3) ? You did the /8 one line above: msg_size_bits = modulus_size + 8-(modulus_size % 8) # Round up to next byte I had problems running this reference implementation agains Status.Net and this one fixed this issue. </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-06-08T20:41:51 http://comments.gmane.org/gmane.comp.web.salmon/161 <pre>Hello, I would like to invite you to join us for the upcoming Federated Social Web Europe Conference - June 3-5th in Berlin http://d-cent.org/fsw2011/ And also consider joining W3C Federated Social Web incubator group (soon changing into community group) http://www.w3.org/2005/Incubator/federatedsocialweb/ We send invites to various projects working on protocols for federated social networking and developers of open source platforms implementing them. You can see growing list of invites here: http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/FSWE2011_-_Sent_Invitations If you would like to join us for the conference but need help with organizing your travel and stay in Berlin, please add yourself to the list on this page: http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/FSWE2011_-_Travel_Support_Requests Please also feel invited to take a closer look on the wiki of our group, still in it's early stage but already providing some information about group participants, related protocols and software - including list of open source platforms where developers already work on implementing federation or consider implementing it: http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Main_Page Last but not least, our public mailing list with its archives stays available here: http://lists.w3.org/Archives/Public/public-xg-federatedsocialweb/ Looking forward to work together with you on improving interoperability of social networking platforms and increasing freedom of all of us using them! elf Pavlik Participant of W3C Federated Social Web Incubator Group </pre> elf Pavlik 2011-05-03T16:02:38 http://comments.gmane.org/gmane.comp.web.salmon/157 <pre>In terms of HTTP response codes, Salmon shouldn't care whether or not it receives back a 200, 201 or 202 response. From the spec&lt;http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html&gt; : "The server MAY provisionally accept the salmon at this point and return a 202 Accepted response. This allows the server to perform the subsequent steps asynchronously." This assumes that the server is going to complete the request asynchronously. If the server actually completes the request synchronously it has to lie and return 202 even though the accurate response would be 200/201. This came to my attention as I was implementing Salmon on CouchDB. In Couch there is a synchronous document storage handler that you could configure to accept and store Salmon updates. Because it is synchronous (from the Couch docs:) "the status code for an update function response is hardcoded to be 200/201 unless an error occurs."[source&lt;http://wiki.apache.org/couchdb/Document_Update_Handlers#Response&gt; ] Thanks, Max Ogden </pre> Max Ogden 2011-03-27T23:00:13 http://comments.gmane.org/gmane.comp.web.salmon/154 <pre>Hi everyone, While implementing Salmon Magic Signatures in my node-ostatus library [1], I realized there was no easy way to test and debug interoperability. It seems that some Python code is available but I'm not sure on how to use it and if it has been updated to the latest spec. So, I hacked a bash script [2] to perform signature in command line using OpenSSL. It is simple to understand and a good peak at how the signature flow goes. Since it uses only command line tools available in every Linux distro, it makes it a good tool to debug your implementations. You just need to generate a RSA key pair (see the documentation on Github) and then you can sign any file: ./sign.sh input.txt key.pem It will output the signature as it would appear in me.sign (base64 etc) as well as the key that can be used in the user XRD and plenty of useful stuff. Now... if some of you could have a quick look at test it with your implementation, I would appreciate. I'm still wondering if I got it right :-) Thanks, Laurent [1] https://github.com/eschnou/node-ostatus [2] https://github.com/eschnou/salmon-bash </pre> < at >eschnou 2011-03-15T21:00:53 http://comments.gmane.org/gmane.comp.web.salmon/153 <pre>Status: New Owner: johnrobertpanzer New issue 31 by laurent....-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org: Example in section 7.1 should not contain padding. http://code.google.com/p/salmon-protocol/issues/detail?id=31 Section 7.1 (Signing Messages with RSA-SHA256) contains an example on how to build the string M used to compute the hash. In this example, the base64url encoding of "application/atom+xml" is shown to be "YXBwbGljYXRpb24vYXRvbSt4bWw=" but I understand from section 3.1 that padding should be removed and it should read "YXBwbGljYXRpb24vYXRvbSt4bWw" The string M should therefore read: "Tm90IHJlYWxseSBBdG9t.YXBwbGljYXRpb24vYXRvbSt4bWw.YmFzZTY0dXJs.UlNBLVNIQTI1Ng" </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-03-15T14:41:44 http://comments.gmane.org/gmane.comp.web.salmon/150 <pre>Status: New Owner: johnrobertpanzer New issue 30 by charlie....-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org: magic_public_keys should be changed to magic_keys http://code.google.com/p/salmon-protocol/issues/detail?id=30 section 8.2.3, '"magic_public_keys" array' is referenced instead of '"magic_keys" array' </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-20T22:03:43 http://comments.gmane.org/gmane.comp.web.salmon/149 <pre>See https://sites.google.com/site/salmonprotocol/news/finalspecdraftsavailable; I've just merged the experimental Magic Signatures draft into the new -01 version, and updated documents per discussions (see commit notes for details). Best as I know, these are the final edits, barring new issues, though the examples will likely need updating to match the final draft once we verify the code that generates them. In particular, http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.htmlis a fairly big change from the older -00 version, but of library implementors have been working towards -01 for the past several weeks. Anyone who is still on -00, please upgrade your code to the -01 spec; the -00 spec is now obsolete. This should be the last breaking change for Magic Signatures and Salmon for the forseeable future. Best, -- John Panzer / Google jpanzer-hpIqsD4AKlfQT0dZR+AlfA&lt; at &gt;public.gmane.org / abstractioneer.org &lt;http://www.abstractioneer.org/&gt; / &lt; at &gt;jpanzer </pre> John Panzer 2011-01-08T07:48:11 http://comments.gmane.org/gmane.comp.web.salmon/148 <pre>Revision: 127 Author: johnrobertpanzer Date: Fri Jan 7 23:19:28 2011 Log: Adding the HTML version of the new Magic Signature specification. http://code.google.com/p/salmon-protocol/source/detail?r=127 Added: /trunk/draft-panzer-magicsig-01.html </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-08T07:20:20 http://comments.gmane.org/gmane.comp.web.salmon/147 <pre>Revision: 126 Author: johnrobertpanzer Date: Fri Jan 7 23:12:47 2011 Log: (1) Removing -experimental Magic Signatures draft, as it's been moved to mainline -01 (2) Updating dates (3) Updating -00 Magic Signatures draft to reflect obsolesence. http://code.google.com/p/salmon-protocol/source/detail?r=126 Deleted: /trunk/draft-panzer-magicsig-experimental-00.html /trunk/draft-panzer-magicsig-experimental-00.xml Modified: /trunk/draft-panzer-magicsig-00.html /trunk/draft-panzer-magicsig-00.xml /trunk/draft-panzer-magicsig-01.xml /trunk/draft-panzer-salmon-00.html /trunk/draft-panzer-salmon-00.xml /trunk/makedocs.sh </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-08T07:13:13 http://comments.gmane.org/gmane.comp.web.salmon/146 <pre>Revision: 125 Author: johnrobertpanzer Date: Fri Jan 7 23:03:08 2011 Log: 1. Moving Magic Signatures experimental draft to new -01 mainline, adjusting references. 2. Final edits &amp; acknowledgements sections for both documents. 3. Moving the "provenance" specification text from Magic Signatures to Salmon (as it is fairly Salmon specific) 4. Fixing the base64url padding issue to reflect consensus &amp; align w/JWT &amp; other usage. Only known open issue is double checking all examples &amp; likely updating based on final code cross-checked across multiple libraries. http://code.google.com/p/salmon-protocol/source/detail?r=125 Added: /trunk/draft-panzer-magicsig-01.xml Modified: /trunk/draft-panzer-magicsig-experimental-00.html /trunk/draft-panzer-magicsig-experimental-00.xml /trunk/draft-panzer-salmon-00.html /trunk/draft-panzer-salmon-00.xml /trunk/makedocs.sh </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-08T07:04:12 http://comments.gmane.org/gmane.comp.web.salmon/145 <pre>Revision: 124 Author: johnrobertpanzer Date: Fri Jan 7 16:56:52 2011 Log: Fixing issue #21, "mentioned" link relation typo. http://code.google.com/p/salmon-protocol/source/detail?r=124 Modified: /trunk/draft-panzer-salmon-00.xml </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-08T01:06:45 http://comments.gmane.org/gmane.comp.web.salmon/142 <pre>Revision: 123 Author: johnrobertpanzer Date: Fri Jan 7 16:53:39 2011 Log: Fix for issue #29, leading zero bytes. http://code.google.com/p/salmon-protocol/source/detail?r=123 Modified: /trunk/draft-panzer-magicsig-experimental-00.xml </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2011-01-08T00:54:38 http://comments.gmane.org/gmane.comp.web.salmon/140 <pre>Status: Accepted Owner: johnrobertpanzer New issue 29 by johnrobertpanzer: Mention need to remove leading zero bytes from modulus &amp; exponent binary serializations http://code.google.com/p/salmon-protocol/issues/detail?id=29 In the RSA key serialization, a first step is convert from an internal integer representation of modulus and exponent to the standard network byte order representations. This is ambiguous since it does not specify how to handle leading zero bytes -- there are an infinite number of network byte order serializations for any number (42, 042, 0042, 000042...). This is important because we do bytewise comparison of keys and also in some cases sha256 hashes. Existing code assumes no leading zero bytes (all network byte order representations are normalized so the first, leftmost, byte is always nonzero). The specification should state this requirement explicitly. (At least one Ruby library implementation sometimes generates leading zero bytes due to processing data in larger-than-byte-sized-chunks, which is why this issue came up.) </pre> salmon-protocol-lfE9kUnURqGlQ9BUahrlcQ< at >public.gmane.org 2010-12-09T22:39:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.salmon