Limited by UDP packet size (64KiB), so can't DoS through memory usage with a single sent object; but can by sending n objects (for some large n). Here the attacker is constrained by network; need to send many MB over network, so need to use either cheap network or someone else's network.
The `trust' measure might be used to reduce this source of DoS: giving priority to using memory for things sent by people trusted more.
Can't send executable code as python object: can only send python
objects that can be created through safe_pickle.safe_load
.
Circle uses a public/private key pair for some things. [Can someone be more specific? Is every single packet signed and signature-checked?]
There is no associated passphrase, so anyone who can access the private_key file data can circumvent this measure.
Currently the ~/.circle directory and ~/.circle/private_key file are created with the default umask; presumably at least private_key ought to be chmod'ed to 0600 or 0400.
Even if chmod'ed to 0400, the file can still be accessed by any process with either root privilege or access to the device file. Many setuid programs have at some point had a vulnerability allowing access to files.
If ~/.circle/private_key is network-mounted, then even packet-sniffing suffices to see the file.