Skip to content
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

Implement integration tests for the federation messages receive feature #6539

Closed
wants to merge 4 commits into from

Conversation

cmrd-senya
Copy link
Member

This is some initial tests, more to come.

refs #5114 #6479

@@ -0,0 +1,93 @@
require 'spec_helper'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.

@cmrd-senya
Copy link
Member Author

This new version of the patch utilizes the latest changes in the diaspora_federation gem and does an integration test on comments receive. More tests to come.

@cmrd-senya
Copy link
Member Author

@jhass, this contains fix to the security issue with signatures we discovered before. I put it here, because here I test it using the integration tests.

I propose to merge it all together, what do you think?

There is to major things to do, before we can merge it:

  • Do something to factories.rb in this patch
  • Release the diaspora_federation gem with the latest changes

factories.rb here merged from the diaspora_federation gem and has some changes. I think it is bad idea to duplicate code, so it would be nice if we could managed to reuse it somehow. Maybe we can ship this factory definitions with the diaspora_federation gem? What do you think, @SuperTux88?

@@ -61,5 +35,26 @@

person_entity.save!
end

on :fetch_private_key_by_id do |diaspora_id|
Person.find_by(diaspora_handle: diaspora_id).owner.encryption_key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't need to allocate AR objects here, the right combination of pluck and joins should do it.

Workers::ReceiveEncryptedSalmon.new.perform(@user.id, generate_xml(entity, @remote_user, @user))

expect(@user.contacts.count).to eq(2)
new_contact = @user.contacts.last
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not guaranteed to be stable, add an order clause.

Workers::ReceiveEncryptedSalmon.new.perform(user.id, generate_xml(entity, remote_user, user))
received_entity = klass.find_by(guid: entity.guid)
expect(received_entity).not_to be_nil
expect(received_entity.author.diaspora_handle).to eq(remote_user.person.diaspora_handle)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jhass, do I need to avoid AR object here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it's okay if you access multiple properties. It's more critical in non test code anyway.

@cmrd-senya
Copy link
Member Author

I'm kinda finished, it's left to make a release of the diaspora_federation.

It covers only a few cases of federation receive, but I think it's better to merge it and then add more tests in further commits, so we don't stay with the opened vulnerability.


on :post_author_is_local? do |guid|
id_array = Post.where(guid: guid).joins(:author).pluck(:owner_id)
!id_array.first.nil? unless id_array.empty?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't something like Post.joins(:author).where(guid: guid).not(owner_id: nil).exists? work?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look at the spec. There is three different cases, and I made it to return nil if guid is not found. With what you offered it would be false in that case, which isn't true strictly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then this shouldn't be a predicate (foo?), they should only return true or false, but rather post_author_type with the possible outcomes :post_not_found, :local, :remote and theoretically :author_not_found. The third possibility would be to raise in the post not found case.

I think I do prefer to consider the post not found case false.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that would be simpler then.

@cmrd-senya
Copy link
Member Author

I realized that some of situations tested here are artificial (e.g. here). In real life, it's not possible, or just doesn't make sense, that sender makes right signature for Salmon and then fails to make a signature for the payload using the same key. Thus, I'll rewrite tests in consideration that we only test situations where the both signatures (Salmon and in-payload, like in relayables) are correct or both signatures are wrong.

@Flaburgan
Copy link
Member

Also consider the situation of a malicious user and pod owner ;)

@cmrd-senya
Copy link
Member Author

Sure, it is considered, it is the only reason why we need signatures at
all :)

ATM we have a situation where entity in payload, for example comment
gets signed by the key of a user, and then packed in Salmon, and Salmon
gets signed with the same key again. There isn't much sense to check
cases, when one signature is ok and the other is broken (moreover, we
probably just don't need these duplicating signatures at all, see #6566).

The fun is that the only case when a signature in the entity is in fact
useful
(this
is the one where we don't check it now :)

I guess that there maybe was some idea behind it, like they wanted, for
example, to make pods exchange messages in P2P style, like pod A posted
a status, pod B fetched the status and resent it to pod C, which resent
it to pod D. That would explain why they duplicated signatures in the
payloads but not only in signed envelopes, and that would explain why
they wanted to keep signatures in the database. But we don't do that, so
most of this signatures code is redundant for us.

@cmrd-senya
Copy link
Member Author

Please, review.

These are some initial tests, more to come.

It tests some features of Request, StatusMessage, Comment, Like,
Participation, Retraction, SignedRetraction, RelayableRetraction entities
receive process.
@cmrd-senya cmrd-senya changed the title [WIP] Implement integration tests for the federation messages receive feature Implement integration tests for the federation messages receive feature Dec 13, 2015
@cmrd-senya
Copy link
Member Author

diaspora_federation 0.0.9 is released, I guess this one is therefore ready.

…ownstream

receive of a federated relayable entity, allowing to forge relayables if you are
an owner of the pod where a parent object is stored.
@jhass
Copy link
Member

jhass commented Dec 13, 2015

Merged as 4e41b8d 08b910b 922d26f f0fc62e

Thank you!

@jhass jhass closed this in f0fc62e Dec 13, 2015
@cmrd-senya cmrd-senya deleted the receive-tests branch December 13, 2015 13:33
@cmrd-senya
Copy link
Member Author

Wow, cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants