-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test JS to Go connections with both RSA and Secp256k1 keys #21
Conversation
2e718c4
to
3558e77
Compare
test/connect/js2go.js
Outdated
// Start Daemons | ||
before(async function () { | ||
this.timeout(20 * 1000) | ||
return spawnDaemons(2, [{type: 'js', keyType}, {type: 'go', keyType}]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we change how start
is called we can leverage the third param of spawnDaemons
to pass { id: keyPath }
3558e77
to
235aa5a
Compare
@jacobheun In my master branch, where I use my own versions of various libp2p dependencies (due to bugs I've fixed), I've got to the point of being able to launch JS and Go daemons, but the RSA test fails in a way I don't understand:
Are you able to understand what would cause this issue? I'm guessing the Go daemon key is the problematic one, but I've generated it with |
@jacobheun Also if you don't mind, I can update this PR to use my forked dependencies, so you we can get the tests running. We should revert to non-forked dependencies before merging this PR of course. |
@aknuds1 yes, feel free to install in |
@jacobheun @vasco-santos I pushed package.json with my forked dependencies. I would suggest you check the RSA test in test/connect/js2go.js in isolation, to figure out why the RSA key error occurs. |
@vasco-santos @jacobheun Never mind, I found out what the issue was with the RSA key - I had messed up in my key generator and used 256 bits for both RSA and ECDSA :/ Sorry! |
My current problem is that the test client can't connect to the JS daemon in the RSA test, although connecting to the Go daemon works. It seems to hang on trying to obtain a connection to /tmp/p2pd-0.sock. Have to go now, so will have to pick up debugging again later. |
4748b9f
to
d27a4c3
Compare
Fixed the issue I was having, so the RSA test works. ECDSA test fails, but the response is empty so can't tell why yet. |
FYI, if you rebase CI should stop failing commitlint for you, I removed that from the build since it's annoying :) I assume ECDSA is likely failing because JS probably just assumes it's being given an RSA key at the moment, so when it goes to do actual encryption it fails. |
5779d72
to
224c829
Compare
@jacobheun @vasco-santos I figured out what makes SECP256k1 keys incompatible between Go and JS daemons. The Go daemon calculates a different peer ID, due to the When the JS daemon calculates a different peer ID from the Go daemon, on SECIO handshake, it produces an error (dialed to the wrong peer, Ids do not match). What do you think, is it a bug that the Go and JS daemons don't agree on the logic for producing peer IDs? |
Hi hi, Adding this for context too: libp2p/specs#138 |
a1b072c
to
1720541
Compare
@vasco-santos @jacobheun I worked around the problem I found of the Go daemon producing incompatible peer IDs by forking go-libp2p-dep, and making it use a version of go-libp2p-daemon that allows you to disable PK inlined peer IDs. The secp256k1 test now works :) The tests fail on Windows, due to what looks like a timeout getting the go-libp2p-daemon archive for Windows off of IPFS. I am serving it from a DigitalOcean VM, but it's really slow to get hold of for some reason. |
1720541
to
616e741
Compare
@Stebalien @raulk did we come to a resolution on key inlining in go? I know js will need some updates for non RSA keys, but I'm not sure where/if we came to a resolution for handling inlining going forward. |
@jacobheun On our side (Quorum Control) in the meantime, I made another workaround by modifying libp2p-secio to handle also peer IDs with inlined public key on protocol handshake (i.e. if the remote ID doesn't match, it tries also inlining the PK). This seems to work! Is this a possible (transitional) fix, instead of changing the Go logic? |
@aknuds1 can you open up a Draft PR of that over at libp2p-secio and we can talk through that potential solution there? |
@jacobheun Will do! |
616e741
to
4996f42
Compare
@jacobheun @vasco-santos I could use your advice on what's the best solution to harmonize Go and JS implementations of libp2p with regards to calculation of peer ID in case of Secp256k1 keys? So far I tried to build robustness into both libraries, so that on connection JS libp2p will test if the remote's peer ID is calculated with the identity scheme and vice versa for Go libp2p. However, it doesn't work perfectly since for example when you connect a JS peer to a Go peer and you list the peers of the Go peer, it will give you a different ID for the JS peer (since it uses the identity scheme to calculate it from the given public key). Given the problem described above, I wonder if it would be best to modify JS libp2p to also calculate peer IDs with identity scheme if the PK is shorter than 43 bytes, since it would then behave the same as the Go implementation. |
I think we'll need to do this for now so that we match go and can leverage the keys. This may cause issues in the future if/when we upgrade how this is calculated, but this will need to be done in go anyway. I'd rather us having a working implementation now and cross that bridge when we come to it than to delay this until that change happens, since that is currently an unknown. |
@jacobheun Thanks for the helpful answer! I'm going to prototype porting Go's peer ID algorithm to JS and see how it goes. |
Using my modified peer-id package, this scenario looks to be fixed for me locally at least. |
42aa66b
to
30e7d26
Compare
@vasco-santos @jacobheun Can you please blow away the Travis dependency cache? It works locally, but I think the dependencies must be updated. |
@jacobheun my current plan is to leave it as it is and to try to find a way to help OpenBazaar upgrade. At this point, too many are relying on key inlining to easily revert it. Thoughts @raulk? |
@aknuds1 cache cleared and tests are passing here now 👍 |
Yay!!!
…On Thu, Jul 11, 2019, 21:49 Jacob Heun ***@***.***> wrote:
@aknuds1 <https://github.com/aknuds1> cache cleared and tests are passing
here now 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21?email_source=notifications&email_token=AACEVV72C4UG3YG7KLDEC4DP66FFHA5CNFSM4H5HCIP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZXZIEQ#issuecomment-510628882>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACEVV6BUMGZFAVFQYIBVZ3P66FFHANCNFSM4H5HCIPQ>
.
|
30e7d26
to
7ba851b
Compare
I revised according to @jacobheun's suggestions, please have another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just two nits that I think could be helpful for readability if the tests are expanded in the future. Other than that, this LGTM.
Co-Authored-By: Jacob Heun <jacobheun@gmail.com>
Co-Authored-By: Jacob Heun <jacobheun@gmail.com>
@jacobheun Cool, committed your suggestions. |
daemon.stderr.on('data', (data) => { | ||
if (!data.toString().includes('Warning')) { | ||
return reject(data.toString()) | ||
daemon.on('exit', (code, signal) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figure it's more robust to fail if the daemon fails, instead of when it simply prints a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with that!
@aknuds1 I will not merge this PR yet because I have been experiencing issues with the CI for Can you have a look as that might have impact on this PR? |
@vasco-santos Please have a look at this PR. |
I haven't noticed your PR! We are good to go here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
As a starting point for solving #20, test JS -> Go connections for both RSA and ECDSA keys.
I'm open to discuss alternative ways of parameterizing the tests over key type. I'm used to testing with AVA, so not sure how to best implement data driven testing with Mocha :)