Add a test for the reordering attack on BinaryAgreement #270

d33a94975ba60d59 · 2018-10-16T04:50:47Z

Fixes #228

afck · 2018-10-16T07:23:52Z

tests/binary_agreement.rs

+        if !self.sent_attack {
+            self.sent_attack = true;
+            for &our_node_id in &self.known_adversarial_ids {
+                let f = self.known_node_ids.len() / 3;


self.known_node_ids doesn't change inside the loop, I think? Then computing f could be moved outside of the loop.

afck · 2018-10-16T07:30:38Z

tests/binary_agreement.rs

+#[test]
+fn test_binary_agreement_reordering() {
+    let new_adversary = |_: usize, _: usize| ReorderingAdversary::default();
+    test_binary_agreement_different_sizes(new_adversary);


Does it really make sense for this particular test to run with InputConfigs other than Split?

afck · 2018-10-16T07:32:14Z

tests/binary_agreement.rs

+        let value = match input {
+            InputConfig::Fixed(b) => b,
+            InputConfig::Random => rand::random(),
+            InputConfig::Split => i < (2 * network.nodes.len() / 3),


Won't this input true for the first third? The comment and the code above suggest it should be the other way round.

afck · 2018-10-16T07:39:25Z

tests/binary_agreement.rs

-use network::{Adversary, MessageScheduler, NodeId, SilentAdversary, TestNetwork, TestNode};
+use network::{
+    Adversary, MessageScheduler, MessageWithSender, NodeId, SilentAdversary, TestNetwork, TestNode,
+};


We're currently in the process of transitioning from the old (network) to the new (net) test framework. I'm not sure how complicated it would be to port this to the new one?

afck · 2018-10-16T07:52:01Z

tests/binary_agreement.rs

+                }
+            }
+        }
+        messages


This doesn't really reorder any messages, it just forges new messages from correct nodes, which the adversary can't do in reality. These messages may then arrive in any order (in addition to the original ones, sent by the correct nodes themselves), so I don't think it reliably replicates the attack.

I think the new net framework provides better controls over message reordering. (Please correct me if I'm wrong, @mbr.)

Also, the attacker needs to reconstruct the coin value before anyone else, and then send the Aux messages accordingly.

Once the test is complete, please try (without checking it in, or maybe just in a separate temporary branch) disabling the Conf messages in binary_agreement, and use aux_vals itself instead of conf_values to try and update the epoch. With that change, this test should fail (i.e. the attack works) but all the other tests should still pass (i.e. binary_agreement is still working as originally described in the paper).

afck · 2018-10-16T07:55:04Z

Ah, sorry, you already wrote that it's not an MITM adversary.
I do think it should be, though. I'd like to avoid merging "cheating" adversaries, that forge correct nodes' messages.

vkomenda

Thanks for taking this issue! Further to @afck's comments. I'm also not convinced the First message scheduler is enough. I'd like you to continue adding stages of the attack which are not yet present:

After A0 and A1 broadcast Aux(_) and messages within A are delivered, x sends both BVal(false) and BVal(true) to every node in A.
x attempts to compute the random coin value. This may be possible without Conf messages which were added as a defence agains this attack.
Also, I believe the divergence check can be done by finding repeated outputs rather than by counting up to a large number.

vkomenda · 2018-10-16T07:33:22Z

tests/binary_agreement.rs

+        let value = match input {
+            InputConfig::Fixed(b) => b,
+            InputConfig::Random => rand::random(),
+            InputConfig::Split => i < (2 * network.nodes.len() / 3),


This will only test constant input: true for the set A and false for the set B. There can be a second attack with these values negated. That possible attack is not covered here.

d33a94975ba60d59 · 2018-10-16T14:07:46Z

I'll rewrite this as a MITM adversary using the net framework if possible. I don't believe this is currently a cheating adversary, though.

d33a94975ba60d59 · 2018-10-16T14:26:29Z

src/binary_agreement/mod.rs

@@ -66,7 +66,7 @@
 mod binary_agreement;
 mod bool_multimap;
 pub mod bool_set;
-mod sbv_broadcast;
+pub mod sbv_broadcast;


One thing I was expecting you to comment on was this. It's necessary for my test, but I'm not sure if its API should normally be exposed. Should I do #[cfg_attr(test, pub)] or something?

Yes, I don't think that algorithm on its own is generally useful and maybe it would just be confusing to expose it. Maybe we should just re-export sbv_broadcast::Message as SbvMessage from binary_agreement?

afck

Well, I think it's "potentially cheating" in the sense that it creates messages with correct nodes as their senders without verifying that those messages were actually sent.

Anyway, ideally it shouldn't create those messages, and instead just reorder the ones that are already pending.

If I understand correctly, net should already support this kind of reordering, but possibly it may need slight extensions. Let me and @mbr know if you have any questions.

afck · 2018-10-16T15:31:30Z

src/binary_agreement/mod.rs

@@ -66,7 +66,7 @@
 mod binary_agreement;
 mod bool_multimap;
 pub mod bool_set;
-mod sbv_broadcast;
+pub mod sbv_broadcast;


Yes, I don't think that algorithm on its own is generally useful and maybe it would just be confusing to expose it. Maybe we should just re-export sbv_broadcast::Message as SbvMessage from binary_agreement?

d33a94975ba60d59 · 2018-10-16T17:32:18Z

I rewrote the test using the net framework. I'll attempt to verify that it's working next (there's a good chance I still messed something up).

d33a94975ba60d59 · 2018-10-16T21:12:34Z

I've fixed the test, and verified that it's working properly. If you apply this patch to disable the Conf round, the other binary agreement tests pass, but this test fails:

diff --git a/src/binary_agreement/sbv_broadcast.rs b/src/binary_agreement/sbv_broadcast.rs
index 4829383..342cadf 100644
--- a/src/binary_agreement/sbv_broadcast.rs
+++ b/src/binary_agreement/sbv_broadcast.rs
@@ -123,11 +123,7 @@ impl<N: NodeIdT> SbvBroadcast<N> {
         if count_bval == 2 * self.netinfo.num_faulty() + 1 {
             self.bin_values.insert(b);
 
-            if self.bin_values != bool_set::BOTH {
-                step.extend(self.send(Message::Aux(b))?) // First entry: send `Aux(b)`.
-            } else {
-                step.extend(self.try_output()?); // Otherwise just check for `Conf` condition.
-            }
+            step.extend(self.send(Message::Aux(b))?);
         }
 
         if count_bval == self.netinfo.num_faulty() + 1 {

vkomenda

I disabled the Conf round differently and the test passed. Can you please check with the diff below?

diff --git a/src/binary_agreement/binary_agreement.rs b/src/binary_agreement/binary_agreement.rs
index 5beac06..f28e4c6 100644
--- a/src/binary_agreement/binary_agreement.rs
+++ b/src/binary_agreement/binary_agreement.rs
@@ -186,8 +186,8 @@ impl<N: NodeIdT> BinaryAgreement<N> {
                     step.extend(self.try_update_epoch()?)
                 }
                 CoinState::InProgress(_) => {
-                    // Start the `Conf` message round.
-                    step.extend(self.send_conf(aux_vals)?)
+                    // Bypass the `Conf` message round.
+                    step.extend(self.try_finish_conf_round()?)
                 }
             }
         }
@@ -347,10 +347,6 @@ impl<N: NodeIdT> BinaryAgreement<N> {
 
     /// Checks whether the _N - f_ `Conf` messages have arrived, and if so, activates the coin.
     fn try_finish_conf_round(&mut self) -> Result<Step<N>> {
-        if self.conf_values.is_none() || self.count_conf() < self.netinfo.num_correct() {
-            return Ok(Step::default());
-        }
-
         // Invoke the coin.
         let coin_step = match self.coin_state {
             CoinState::Decided(_) => return Ok(Step::default()), // Coin has already decided.

vkomenda · 2018-10-17T08:40:16Z

tests/binary_agreement_mitm.rs

+    sent_final_messages: bool,
+}
+
+const NODES_PER_GROUP: usize = 10;


Can this value be randomized? For example, sampled randomly from a given range?

On the other hand this is just a regression test for one specific case. I wonder whether we should just set this to 1?

In that case, making it random will answer both questions :P

afck

Looks good, but it's a pretty complicated attack, and I think most steps of it are still missing from the implementation.

I agree with @vkomenda: The above diff doesn't disable the Conf messages, but just sends the Aux earlier. I think sbv_broadcast doesn't need to be changed. @vkomenda's diff looks right to me, except I think we need self.conf_values = Some(aux_vals) before calling try_finish_conf_round?

afck · 2018-10-17T09:33:40Z

tests/binary_agreement_mitm.rs

+        const BVAL_TRUE_MSG: Message = Message {
+            epoch: 0,
+            content: MessageContent::SbvBroadcast(SbvMessage::BVal(true)),
+        };


I think you can also write:

MessageContent::SbvBroadcast(SbvMessage::BVal(false)).with_epoch(epoch)

afck · 2018-10-17T09:34:42Z

tests/binary_agreement_mitm.rs

+        _: NetMessage<BinaryAgreement<NodeId>>,
+    ) -> Result<Step<BinaryAgreement<NodeId>>, CrankError<BinaryAgreement<NodeId>>> {
+        const BVAL_FALSE_MSG: Message = Message {
+            epoch: 0,


I think this attack needs to be repeated in every epoch, not just 0.

afck · 2018-10-17T09:36:55Z

tests/binary_agreement_mitm.rs

+    sent_final_messages: bool,
+}
+
+const NODES_PER_GROUP: usize = 10;


On the other hand this is just a regression test for one specific case. I wonder whether we should just set this to 1?

vkomenda · 2018-10-17T10:01:59Z

I agree with @afck, we possibly need self.conf_values = Some(aux_vals) before the call to try_finish_conf_round. This is what send_conf would have done. Thanks for the correction!

In that case changing send_conf instead is better. Just remove the last line self.send(MessageContent::Conf(values)) and adjust the returned Result value accordingly.

afck · 2018-10-19T17:40:27Z

tests/binary_agreement_mitm.rs

+        .adversary(ReorderingAdversary::default())
+        .crank_limit(10000)
+        .using(|info| {
+            BinaryAgreement::new(Arc::new(info.netinfo), 0, info.id)


The third argument ("proposer_id") needs to be the same in all nodes.

That's indeed a confusing API, of course, and we should definitely change it. But for now, you can just replace info.id with 0.

d33a94975ba60d59 · 2018-10-19T18:31:14Z

It's now passing, but failing with this patch:

diff --git a/src/binary_agreement/binary_agreement.rs b/src/binary_agreement/binary_agreement.rs
index 5beac06..e1c1265 100644
--- a/src/binary_agreement/binary_agreement.rs
+++ b/src/binary_agreement/binary_agreement.rs
@@ -247,7 +247,8 @@ impl<N: NodeIdT> BinaryAgreement<N> {
             return Ok(self.try_finish_conf_round()?);
         }

-        self.send(MessageContent::Conf(values))
+        //self.send(MessageContent::Conf(values))
+        Ok(Step::default())
     }

     /// Multicasts and handles a message. Does nothing if we are only an observer.

@afck pointed out that I'm still missing the last part of the attack, so I'm not sure why this is happening.

afck · 2018-10-20T10:38:56Z

Just not sending the Conf messages will make it always fail. You have to make @vkomenda's change and in addition set self.conf_values = Some(aux_vals), as discussed above. (I.e. you need to change it so it implements ABA as described in the paper.)

d33a94975ba60d59 · 2018-10-21T00:45:24Z

@afck The function send_conf sets those values right above the line I commented out :)

As @vkomenda said,

In that case changing send_conf instead is better. Just remove the last line self.send(MessageContent::Conf(values)) and adjust the returned Result value accordingly

And that's what I did

afck · 2018-10-22T07:56:41Z

But if you apply only the above 1-line patch, without adding the try_finish_conf_round, doesn't that make all tests fail? Doesn't it simply make BinaryAgreement never output?

vkomenda · 2018-10-22T08:35:03Z

@d33a94975ba60d59 , sorry for confusion. I wasn't descriptive enough. You would need to return Ok(self.try_finish_conf_round() from send_conf, not the empty Step as you did. Alternatively you can use the patch I sent with the correction made by @afck.

vkomenda · 2018-10-22T08:46:57Z

@d33a94975ba60d59 , sorry for confusion. I wasn't descriptive enough. You would need to return Ok(self.try_finish_conf_round() from send_conf, not the empty Step as you did. Alternatively you can use the patch I sent with the correction made by @afck.

d33a94975ba60d59 · 2018-10-27T19:36:58Z

This has been much more complicated than I expected, but once again, I think it's working. It's passing, but failing with crank: node failed to process step: CrankLimitExceeded(10000) with this patch:

diff --git a/src/binary_agreement/binary_agreement.rs b/src/binary_agreement/binary_agreement.rs
index 61ac175..0db9e40 100644
--- a/src/binary_agreement/binary_agreement.rs
+++ b/src/binary_agreement/binary_agreement.rs
@@ -204,7 +204,9 @@ impl<N: NodeIdT> BinaryAgreement<N> {
                 }
                 CoinState::InProgress(_) => {
                     // Start the `Conf` message round.
-                    step.extend(self.send_conf(aux_vals)?)
+                    //step.extend(self.send_conf(aux_vals)?)
+                    self.conf_values = Some(aux_vals);
+                    step.extend(self.try_finish_conf_round()?)
                 }
             }
         }
@@ -363,9 +365,11 @@ impl<N: NodeIdT> BinaryAgreement<N> {
 
     /// Checks whether the _N - f_ `Conf` messages have arrived, and if so, activates the coin.
     fn try_finish_conf_round(&mut self) -> Result<Step<N>> {
+        /*
         if self.conf_values.is_none() || self.count_conf() < self.netinfo.num_correct() {
             return Ok(Step::default());
         }
+        */
 
         // Invoke the coin.
         let ts_step = match self.coin_state {

With that patch, the BinaryAgreement gets to around epoch 50 before the crank limit is exceeded, and logging the estimated values for each node, it seems clear to me that the attack is now working.

I've also rewritten this to use a much more modular/configurable system. The STAGES array defines the attack, and the rest of the code just carries it out.

afck · 2018-10-29T07:50:28Z

tests/binary_agreement_mitm.rs

+        msg_count: NODES_PER_GROUP * (NODES_PER_GROUP * 2),
+    },
+    // Messages within A0 are delivered.
+    // Thus nodes in A0 see |B|+|F|=f+1 votes for \neg v; so all nodes in A0 broadcast BVAL(\neg v) and all nodes in A0 see |A0|+|B|+|F|=2f+1 votes for \neg v; so all nodes in A0 broadcast AUX(\neg v).


Let's break the lines into fewer than 100 characters. (Also below.)

afck · 2018-10-29T07:51:15Z

tests/binary_agreement_mitm.rs

+    // x sends BVAL(\neg v) to the nodes in A0
+    Stage {
+        source_groups: &[3],
+        dest_groups: &[0],


It would be more readable to make the group numbers constants: &[F], &[A0], etc.

afck · 2018-10-29T07:59:42Z

tests/binary_agreement_mitm.rs

+        msg_count: NODES_PER_GROUP * 2,
+    },
+    // !! Not mentioned in the GitHub issue, but seems necessary.
+    // F sends Aux(_) to A, because nodes in A need 2f+1 Aux messages before they broadcasts their coins.


(Typo: "they broadcast")

afck · 2018-10-29T08:03:15Z

tests/binary_agreement_mitm.rs

+/// Described here: https://github.com/amiller/HoneyBadgerBFT/issues/59#issue-310368284
+/// Excluding the first node, which is F,
+/// A0 is the first third of nodes, A1 is the second third, and the rest are B.
+struct ReorderingAdversary {


Let's give this a more specific name (also the test function below); there's a general random ReorderingAdversary now, too.
Can't really think of a good one… maybe AbaCommonCoinAdversary?

afck · 2018-10-29T08:05:03Z

tests/binary_agreement_mitm.rs

+    /// The estimated value for nodes in A.
+    a_estimated: bool,
+    // TODO this is really hacky but there's no better way to get this value
+    netinfo_mutex: Arc<Mutex<Option<Arc<NetworkInfo<NodeId>>>>>,


The network info shouldn't even change over the course of this test, and I think it's also clonable? Option<Arc<NetworkInfo<NodeId>>> or even Option<NetworkInfo<NodeId>> should work…?

Getting the networkinfo into the adversary is a surprisingly difficult task. The closure that gets the netinfo must be created after the adversary is created, but cannot have a mutable reference to the adversary because it needs to be moved into the NetBuilder. I tried to extract the adversary from the NetBuilder in the closure, but with only a mutable reference to a box I can't downcast it to my adversary type. If I could convert it to an Any it'd work, but even making Adversary a super-trait requiring Any, I run into https://github.com/rust-lang/rust/issues/5665

Another option is having the Adversary type as a type parameter of NetBuilder. This would make creating a network without an adversary more difficult, though we could just have a helper for that using NullAdversary. What do you think about that?

@mbr: Have you encountered this problem before? It sounds like making the adversary a parameter of NetBuilder would be a decent solution?
(Anyway, that can certainly be cleaned up in a later PR.)

Is netinfo_mutex only used to get the invocation_id? If so, don't use NetworkInfo inside the adversary. Pass only data that are needed to construct the nonce, or, in the current master, coin_id.

Nope, its primary usage is the line after that, where it's passed to ThresholdSign. I don't know what ThresholdSign does with it but it's probably not worth changing the API.

Yes, you are right. Another option would be to clone the NetworkInfo of the NewNodeInfo. It's read-only in BinaryAgreement, so it should be fine to clone it at the time of building the VirtualNet.

That's what's currently done :)

If you clone, you don't need the enclosing Arc<Mutex<Option<_>>> in the constructor argument of the adversary.

I do, because the adversary has to be created before the NewNodeInfo is present, unless we change the NetBuilder API.

afck · 2018-10-29T08:06:26Z

src/binary_agreement/binary_agreement.rs

@@ -11,7 +11,7 @@ use {DistAlgorithm, NetworkInfo, NodeIdT, Target};
 /// The state of the current epoch's coin. In some epochs this is fixed, in others it starts
 /// with in `InProgress`.
 #[derive(Debug)]
-enum CoinState<N> {
+pub enum CoinState<N> {


I'd almost prefer duplicating the CoinState in the test, if necessary, rather than exposing this implementation feature.

afck · 2018-10-29T08:08:05Z

src/binary_agreement/mod.rs

@@ -146,7 +147,7 @@ impl rand::Rand for MessageContent {
 }

 #[derive(Clone, Debug)]
-struct Nonce(Vec<u8>);
+pub struct Nonce(Vec<u8>);


Sorry for the merge conflict! 😬
The new session ID can also just be 0, though, so it shouldn't make a difference.

afck · 2018-10-29T08:15:08Z

tests/binary_agreement_mitm.rs

+            let src_group = if from == 0 {
+                3
+            } else {
+                (from - 1) / NODES_PER_GROUP


That would be simpler if the adversary were the last node, not the first.
(Not sure if it's worth changing.)

It makes other parts a bit more complicated, like iterating over the correct algorithms. I think having the faulty node first is fine.

afck

Looks good to me!
@mbr, @vkomenda: Please also take another look.

afck · 2018-10-30T07:20:33Z

tests/binary_agreement_mitm.rs

+    /// The estimated value for nodes in A.
+    a_estimated: bool,
+    // TODO this is really hacky but there's no better way to get this value
+    netinfo_mutex: Arc<Mutex<Option<Arc<NetworkInfo<NodeId>>>>>,


@mbr: Have you encountered this problem before? It sounds like making the adversary a parameter of NetBuilder would be a decent solution?
(Anyway, that can certainly be cleaned up in a later PR.)

afck · 2018-10-30T07:22:27Z

tests/binary_agreement_mitm.rs

+/// The state of the current epoch's coin. In some epochs this is fixed, in others it starts
+/// with in `InProgress`.
+#[derive(Debug)]
+pub enum CoinState<N> {


That probably doesn't need to be public.

tests/binary_agreement_mitm.rs

d33a94975ba60d59 · 2018-10-30T15:35:38Z

Rebased. I added Algo and SessionId typedefs in the process.

vkomenda · 2018-10-30T16:29:05Z

Looks fine by me. Please update to Rust 1.30.0.

d33a94975ba60d59 · 2018-10-30T16:35:07Z

Please update to Rust 1.30.0.

What do you mean by that? Did I miss a dyn or something? I'm on Rust 1.30.0. The Travis failure was a formatting error from my rebase.

vkomenda · 2018-10-30T16:55:47Z

Sorry, I meant the formatting errors. The PR is ready for merging :)

afck requested changes Oct 16, 2018

View reviewed changes

vkomenda suggested changes Oct 16, 2018

View reviewed changes

d33a94975ba60d59 commented Oct 16, 2018

View reviewed changes

afck reviewed Oct 16, 2018

View reviewed changes

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 3ad7a8d to 0fb454b Compare October 16, 2018 17:31

d33a94975ba60d59 force-pushed the reordering-attack-test branch 3 times, most recently from 86bd011 to 12d2436 Compare October 16, 2018 21:12

d33a94975ba60d59 mentioned this pull request Oct 16, 2018

Create a type of test adversary that can perform Man-in-the-Middle attacks #45

Closed

d33a94975ba60d59 force-pushed the reordering-attack-test branch 2 times, most recently from 26352ef to 9d5996d Compare October 16, 2018 23:53

vkomenda suggested changes Oct 17, 2018

View reviewed changes

afck requested changes Oct 17, 2018

View reviewed changes

afck reviewed Oct 19, 2018

View reviewed changes

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 9d5996d to 55d4ff7 Compare October 19, 2018 18:26

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 55d4ff7 to 9f6a519 Compare October 27, 2018 19:32

d33a94975ba60d59 force-pushed the reordering-attack-test branch 2 times, most recently from f9f9349 to 459c428 Compare October 27, 2018 20:50

d33a94975ba60d59 force-pushed the reordering-attack-test branch 3 times, most recently from 04b224e to 5aaf89a Compare October 27, 2018 22:48

afck reviewed Oct 29, 2018

View reviewed changes

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 5aaf89a to f5b3bc8 Compare October 29, 2018 16:19

afck approved these changes Oct 30, 2018

View reviewed changes

afck reviewed Oct 30, 2018

View reviewed changes

d33a94975ba60d59 force-pushed the reordering-attack-test branch from f5b3bc8 to 4578967 Compare October 30, 2018 14:07

vkomenda reviewed Oct 30, 2018

View reviewed changes

tests/binary_agreement_mitm.rs Show resolved Hide resolved

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 4578967 to 1f591bd Compare October 30, 2018 15:34

vkomenda approved these changes Oct 30, 2018

View reviewed changes

Test the reordering attack on BinaryAgreement using net framework

c132751

d33a94975ba60d59 force-pushed the reordering-attack-test branch from 1f591bd to c132751 Compare October 30, 2018 16:33

vkomenda merged commit 2fed831 into poanetwork:master Oct 30, 2018

Add a test for the reordering attack on BinaryAgreement #270

Add a test for the reordering attack on BinaryAgreement #270

Conversation

d33a94975ba60d59 commented Oct 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afck commented Oct 16, 2018

vkomenda left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

d33a94975ba60d59 commented Oct 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

d33a94975ba60d59 commented Oct 16, 2018

d33a94975ba60d59 commented Oct 16, 2018

vkomenda left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vkomenda commented Oct 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

d33a94975ba60d59 commented Oct 19, 2018

afck commented Oct 20, 2018

d33a94975ba60d59 commented Oct 21, 2018

afck commented Oct 22, 2018

vkomenda commented Oct 22, 2018

vkomenda commented Oct 22, 2018

d33a94975ba60d59 commented Oct 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

d33a94975ba60d59 Oct 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

d33a94975ba60d59 commented Oct 30, 2018

vkomenda commented Oct 30, 2018

d33a94975ba60d59 commented Oct 30, 2018

vkomenda commented Oct 30, 2018

d33a94975ba60d59 commented Oct 16, 2018 •

edited

Loading

d33a94975ba60d59 commented Oct 27, 2018 •

edited

Loading

d33a94975ba60d59 Oct 30, 2018 •

edited

Loading