rdebath

Except, you probably don't have another application like this. You see the applications you've had contact with are pure client. They do absolutely nothing unless you are there to push the button. OTOH BTSync is a server application it must run continuously and must be able to authenticate itself to the other peers so it needs permanent access to it's secrets. The closest that I can think off offhand is the SSL certificates of a web server like Apache. Normally these are stored unencrypted in the file /etc/apache/ssl.key. The (standardised) file format that they are in does have the ability to use encryption but it's almost never used for this certificate because it requires the web server to stop during startup and ask for a key from the user. Normally the user will be miles away at this point in time. In addition, even if the certificate is encrypted on disk it still has to exist in plaintext in memory and if the security of the box is subverted to the extent that an attacker has access to the "ssl.key" file they probably also have access to the memory of the Apache process, (eg: using ptrace) making the encryption useless. I've put a message on the wishlist thread for this, as it is a facility that comparable software (Apache) has, but even if it's implemented I'd bet you'd end up not using it.

In relation to my earlier btsync --config config.json --reload request. If I could offer an implementation detail request. Can all the (semi) static configuration data be moved out of the sync.dat file and into a distinct config.dat file. Bascially I mean everything that's in the config.json file (perhaps that file should be json not bencode). The idea being that this can be used to export the configuration of a client (just grab it) and load it into another one. It seems that some people would also like the ability to encrypt this configuration so that BTSync decrypts it on startup and loads the data into memory. This obviously means that unattended startup is impossible.

The secrets are stored in the sync.dat file along with all the other major data about the share. If you want to see you can do a Google search for a "bencode editor", one of these will be able to open, view and edit the sync.dat file. (WARNING: No user serviceable parts inside)

Filtering the .sync directory is just a protection against a bonehead mistake. Once you let a virus only your system your machine is owned, there is nothing an application like BTsync can do to protect you after that. If you "all of his data" you mean all the data in the share, then yes. That exactly what the secret is for, to give access to the share to those people you give the key to. Either directly or by running their virus software. So don't run the virus. If you want more you'll have to be very specific, and give reasons.

I monitored this config for a while and it initiated no connections. Only when another peer connected using the known peers list did it respond to that peer. The other peer was the only one in the swarm so I didn't check if BTSync does peer exchange. Blocking the normal UDP port seems to prevent a peer connecting (even with lan_use_tcp) but the search_lan uses multicast to port 3838 which may need a different rule. ,"check_for_updates" : false ,"use_upnp" : false //... { "secret" : "OO7AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" // * required field ,"dir" : "/home/btsync/quiettest" // * required field ,"use_relay_server" : false ,"use_tracker" : false ,"use_dht" : false ,"search_lan" : false ,"use_sync_trash" : false }

You guys! Okay try this, it's a javascript application (ie: run totally in your browser; even offline) that takes your wonderful truecrypt passphrase applies the same conversion truecrypt does to get a key and converts the key into a form acceptable to BTSync. Truecrypt hashes it's passphrase into a fixed length key, just like the BTSync key. Happy ? http://www.debath.co.uk/MakeAKey.html PS: Ooops, should have looked first. Truecrypt uses RIPEMD-160 not SHA1 (160) ... close enough.

Is the CPU utilisation high ? Is the network utilisation higher than expected ? Does it get better if there's a third peer ? Also debug logs are good: http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/

Sounds like unrar might be doing something odd, at a guess it's setting a future date on the files. Can you do this command on the files: $ ls -l --full-time Also I expect this should be logged as a bug ... http://forum.bittorr...-syncapp-issue/ But not before you try it on the most recent version. BTW: There is an Edit button on your posts; if you want to add more to a post you can do it directly.

You're welcome. I'll put the actual problem howto up when they turn on push for the next version; will be soon now.

heh, heh. DHT Chatty! Look at the packets, it's positively laconic compared to the rest of BTSync. BTSync really has a network motormouth at the moment.

Okay, I just tried it; it looks like we get a mixture of UDP and TCP connections while it's got something to do then it settles down (!) to a continuous stream of UDP packets once the connection goes idle. If I block UDP the connection times out, the peer disappears from the GUI and doesn't come back. Even if I restart the clients. It's very persistent at hammering at the firewall rule though. So, yes, predefined hosts appear to be treated as local, but no it doesn't help because UDP is still required. As an aside I can also confirm that this config doesn't initiate any connections: ,"check_for_updates" : false ,"use_upnp" : false //... { "secret" : "OO7AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" // * required field ,"dir" : "/home/btsync/quiettest" // * required field ,"use_relay_server" : false ,"use_tracker" : false ,"use_dht" : false ,"search_lan" : false ,"use_sync_trash" : false }

Actually, it's not perfect at the moment, I'd want symlinks transferred to the Windows client too.

There seem to be some difficult bugs where BTsync is picking the wrong file when there is (or it sees) a conflict. Personally I would like to have a mode where a change conflict causes BOTH the modified files to be created, the older one with a different name (say). BUT, I suspect this has a wider use in the realm of debugging because it will make every conflict very obvious and if some of them aren't actually real conflicts (but something manufactured by network effects) this will be much easier to detect and hopefully debug. So can I request a version then NEVER deletes a file due to a change conflict.

It does on linux; and yes a second port is required. Loopback is also not the LAN, though it MIGHT be detected as such. (ie: not if the detection is via multicast) And the encryption was just the first example; the whole mode of operation is different if you have fast local interaction between the two directories. I suppose BT are going to have to make the command line version available on Windows too at some point, then you'll be able to try this for yourself. Though, frankly you can probably run two copies right now by using fast user switching. But personally; I'd much prefer for BTSync to automatically sync over Wifi with my NAS box as soon as I'm in range without having to remember to plug in some USB drive. Or to sync over the VPN as soon as I make the change (and before the laptop is stolen from the car )

http://forum.bittorr...8786#entry48786 Can we please have a control to say how a particular known host is to be connected to. Currently it would be "TCP or UDP". This way a known host could be an SSH/Zebedee/TCPredir/etc tunnel using TCP rather then UDP to anywhere, not just the lan. In addition other connection types would be nice: SOCKS4: SOCKS5-BIND-UDP HTTP-CONNECT etc. ie: TCP connects through a proxy and SOCKS5 connections to bind an external UDP port. PS: Encryption should be controllable in the same way.

No, but you do have to "complicatedly route TCP traffic". You don't notice it in the case of a web browser because all you see is what the server feeds you and NAT is good at making you a simple consumer. But if you want to connect TCP through back to back NATs you have to arrange for one of the NATs to be of a type that allows a SYN response to a SYN packet (rather than the normal SYN-ACK) and for BOTH the clients to attempt a connection at the same time with a very short timeout. It's rather unreliable to put it mildly. Having said that, I don't know offhand what BTSync uses as it's "on the LAN" criteria; it might be "found this host with multicast" which wouldn't work at all. But you're not wrong, it is easier to tunnel TCP traffic because there are more tools available to do it. So I'll put something on the wishlist thread.

If I connect to the Web GUI from a little laptop (with a Intel Atom N470 1.83GHz dual core) one single key with only three or four peers takes 10% of the CPU. Add more keys or more peers and the CPU quickly peaks at 100% of a single CPU. NOTE: This is the CPU of the machine running the web browser. From a quick glance at the javascript it appears that you're recreating a single huge table every second rather than (perhaps) using smaller tables or only updating parts of the table or fixing the size of the table. This occurs with both Firefox and Chrome. While I'm here; if one (or more) of the local paths to shares is long it really messes up the layout.

As the .sync directory is never stored in the shared area this is not a problem ... is it. Having said that, lots of users seem to make the silly mistake of putting the .sync directory in the shared area so filtering it out is on the TODO list.

No. The infohash sent to the tracker is the SHA?(secret) you would have the "reverse" the sha function. This is only possible if the secret key has a very low entropy. (easy to guess) I did a little test; we seem to be okay on Linux at least; 4 million keys no duplicates what so ever. A simple frequency test of the file looks fine ... 4859475 2 4863241 3 4860436 4 4859986 5 4857776 6 4857271 7 4858194 A 4856963 B 4857042 C 4859213 D 4859448 E 4860727 F 4856947 G 4858735 H 4863173 I 4856017 J 4858412 K 4864000 L 4858075 M 4859043 N 4859248 O 4854939 P 4857153 Q 4860129 R 4858500 S 4856507 T 4860618 U 4859425 V 4858419 W 4857521 X 4858505 Y 4858702 Z

Version 1.0.130 Looks good. Though the windows client seems to get stuck if you give it bad file names.

I get the number 6616168750430111230.745454119955558193835030312378439183063621313089 ie: 2^160 / 1000000 / 1000000 / 86400 / 365.2422 / 7000000000 Quite a bit bigger. But we have no guarantee of the quality of the random number generator, it looks like it's using OpenSSL and that has a good one. But that's the same one Debian was using when they had their little problem with keys having only 15 bits of entropy...

It's kinda like the first one, no absolute paths, but you don't have to decrypt any packets to do it. The "exploit code" is very very short. Too short for me to give too many hints, without giving people a chance to see this thread.

If you have any public shares running now REMOVE THEM. BTSync will delete directories outside the share. [HOWTO Section Deleted] Is should be possible to use this to delete ANY directory on the windows machine. Bad examples are obvious! THIS IS ALPHA SOFTWARE, IT WILL HAVE SERIOUS BUGS. PS: This applies to versions below 1.0.130

That would be a bug then. If another instance of BTSync can make a change to the file system that causes this copy to destroy data the same change could be made by a third party application. In fact IMO two copies of BTSync running on exactly the same directory should be one of the test cases, if they sync to different keys they should together merge the two secret shares into one. If they are on the same key they should work inefficiently, but correctly. (Efficiently and correctly would be nice but not really worth doing, however, if it comes as a side effect of making two clients behind the same low bandwidth connection work efficiently that's a different matter) The obvious problem is the use of a fixed name *.!sync IN the share for the temp files. IMO this should be outside the share or at least use a random name (IIRC Unison does the former, rsync the latter). It does seem to be a source of corruption right now; if you change the base file while there is a *.!sync file there strange things happen. (The other is the .SyncID file; but that's just a lock file) ... KOS ... I think this might actually be a bug report; or a feature request ... not sure though, it ain't a good one. If you can run multiple btsync's with different keys on the same directory that becomes an easy way of revoking access to one user; just give each user a unique key.

There's no such thing as a BTSync 'server'. For two clients to be able to sync to each other (both directions) they must only be able to make a connection. This means that a UDP packet must be able to get from Client A all the way to Client B. The problem comes with NAT, if the 'server' (Client B.) is behind a NAT (or a normal firewall) it won't receive the packet from Client A unless a port is mapped to allow unsolicited packets from the outside world. This is the second function of the tracker; it tells both Clients about the other so they are both trying to connect and both poke a hole from inside their respective NATs (firewalls) and neither of the NATs thinks the packets are unsolicited. ... OpenVPN doesn't need a router that can do it; There are native clients for Linux and Windows (i86 & x64). But you're right, OpenVPN does need Administrator/root access so a simple Linux web host won't allow it. I like sshfs in that case. Though I have used OpenVPN with VM style hosters for both OSs. (gvpe is basically Linux, but can use OpenVPN's TAP devices with cygwin -- I'm not so keen on that) ... As for stolen hardware; I normally set laptops up so it has one certificate that connects automatically. Had the laptop stolen; revoked the certificate. A couple of days later the laptop comes knocking on the firewall "connection refused, certificate revoked". The IP address went to the police. The perp spent Xmas in jail (and his sister got a night in lockup too, bet she was pleased with him ). Of course, most of the users much prefer to work locally on their laptop, they get FDE so no laptop recovery I just hope BTSync will make for some good backups.