affinity

Also, can you put dates next to the version numbers in the first post? I saw 1.1.12 and thought May 8 ?????? The same thread has been re-used with various versions, so dates next to the version number will help (especially with the re-use of the thread).

So, because of incompatibility from 1.0.x vs 1.1.x ... the public shares that people are using (let's say like the cats one for instance), what will happen with them if we update and they don't or vice versa?

Steve was responding to myself during the podcast, but he said something that I think has a solution rather than being a problem. Let's say with ssh for instance that you can accept protocol 1 and protocol 2 -- you would want protocol 2 as an improved protocol for ssh. Now a protocol 2 for BTSync.... let every installation have a long generated "secret" for the client, such secret should be able to be set specifically, just like changing ports. Using protocol 2 of BTSync, you send the secret for the sync AND also send the user's own "installation" secret -- so a double length secret now. Set your BTSync to only accept protocol 2 so it requires 2 keys, the sync secret plus the unique "installation or personal" secret. You never do the WPS security flaw of saying, right, the secret is correct, now what is the next auth key? You only accept the remote connection IF both the secret and personal key are correct and you give no indication if one or the other is incorrect -- you simply drop the connection and stop it from proceeding any further; that is you don't accept or reject it, but just drop it. When a connection fails due to being dropped, it should have the same effect as having never found the secret in the first place. To further secure the installation secret, the user should be able to supply the sha256 of the secret to the approver, by whatever means to help identify themselves -- their own secret is never known by any other party, but the sha256 of the secret is sent.

Am I wrong here? You need those wanting iOS trial to reply here and subscribe to the given link; those wanting to do Android trial need not write in here at all, but only need to subscribe via the given link.

No, clever is out, it is not as /easily/ attack-able with a dictionary, but mis-spellings become part of any good dictionary attack, as does replacing letters with number or symbols.... just a larger dictionary, that's all. Targeted attack is out of the question on the whole, but random attack isn't /as difficult/, still difficult though. Oh and from another post, you can run as many iterations as you like to a secret to strengthen it, but at the end of the day, you still only have so many bits to work with. If the attack was done using just the final bits with custom code, then the strengthening wouldn't even count for anything here.

Duplicate it on the other machine, carefully to make sure it is all good. BTSync is a great syncing tool, but it is not a backup tool; use it wisely and you'll be able to get the benefits of both sync and backup, just think about it and make sure you cover your bases properly.

Don't consider BTSync as a backup tool, that it is not. In some respects it can be though..... it is handy that deleted files go to a deleted folder -- but that isn't perfect either; what happens if the same file is repeatedly added and deleted? You may end up with bad files only.

I was sure that I had seen it, at least for freebsd, but I'm not going to search for it now -- besides, it might be outdated information now with program updates changing things.

Android has enough problems with side-loading and now some problems with apps gone rogue over time. Needing root is just one thing, how can you know that the program itself isn't in any way malicious? If it is malicious, then having root makes it even more dangerous.

In the windows world, I often use junctions to "enable" longer paths to work, ie a folder name is shortened and the shorter name brings the path within limits. The Windows tool is mklink, run it as administrator with no params to see how it works.

I think better to read this thread, particularly the last post -- not sure if things have changed, but read the thread.

NO, DON'T DO IT, it is not official -- do so at your own risk, seriously.

Hey, someone who says "cut, then copy" big plus 1 there!!!! Most people say copy and paste when they do cut and paste anyway. Thanks for that. Otherwise, the video was pretty much basic stuff, but good just the same.

I don't get it, what could be simpler, a tgz file with two files in it, one a license file. You create a config file, if you want, then secure the login and you are just about done. Autostart if you need it, but if you've got a server that never stops, then neither does btsync. It's about as simple as you can get. Automating startup is trivial for any sysadmin and not much harder for non-sysadmins.

I believe that you are currently stuck with 10 minute updates for your build, so 3 minutes is well within that period.

Display folder names can be different to actual folder names, check for the hidden desktop.ini files....

The UUID needn't be a "standard" type, it can be another full secret. Again, maths is maths, people win Lotto -- not many, but they do win. Relying on pure random chance, you would be extremely unlikely to ever be compromised (unless the random generator is somehow flawed, then you are more likely to be compromised), but it is still possible; big numbers don't mean impossible, just extremely unlikely.

Not official, as per other thread:

I would think NOT, 116 is also behind the times, it should now be 1.0.132 I believe .... 1.0.116 had some vulnerability issues, perhaps only in the Windows world, but I'm not sure. Definitely avoid the Google Play link you found, I wouldn't trust it.

Facts are facts, whilst a random collision is possible, there isn't much choice if you must secure your data. Still.... lock / unlock would go a long way to fixing the potential, even if extremely unlikely, possible hole.

So, iow, if anyone gets hold of your sync.dat file then they can read all your secrets clearly! https://sites.google.com/site/ultimasites/bencode-editor

If you have a long secret, and I mean really long, say 80+ Base64 chars..... then trying that with a UUID is even more "virtually impossible", but yes it is possible for a lotto winner, however unlikely. If the UUID is long enough, then it would likely be safe even if the secret was accidentally leaked -- the UUID could just as easily be another 80+ Base64 chars, so effectively two secrets to find, doubly secure against random discovery. In any case, it is clear that secure data needs to be secured in other ways than just a single secret (no matter how long the secret is).

It doesn't matter how good your secret is, if you can create it, so can a lotto winner. Lock / Unlock .....this will fix the problem Of course, you will be much better off with your own generated key, provided it is long enough and not the standard Base32 32 char one.

The combination of username (email address), password _should_ be tough if you use strong passwords; the TOTP code cycles over time, so long as you never broadcast your code at a guessable time (like on a video blog), then your 16 character code used to "secure" the TOTP installation will be safe. Guessing the TOTP code will be harder for the lotto player to succeed as the code is specific to the user account and time based. The randomness of a true lotto winner is quite different, it targets ANY potential secret, not a specific one. Guessing the UUID is a similar problem space, you first need to know you have a hit with the secret -- then you either guess of brute force the UUID; so again, a very targeted approach, rather than a purely random, find a winner for any secret. Truecrypt can be well secured with a very long pass phrease AND you can use key file(s) too; so long as you do use a suitably long pass phrase and you use a suitable key file, then you should be very safe from a targeted attack particularly.

The size of the secret is almost irrelevant, if people use the standard 32 character Base32 set and don't opt to use >40 character Base64, then they will /always/ be at risk of a lotto winner. A properly implemented two factor auth will not accept one factor unless both factors are correct -- using Google signin with GA will accept your login first, then it will ask for the simple 6 digit TOTP code; of course that is better than not using any two factor (although you already have somewhat two factor with username and password before you get to the 6 digit factor, that is time limited, but only protected by a 16 alphabetic character string). Anyway, what I've proposed in another thread is that you should have the ability to "lock" the system and only allow new connections when the system is unlocked and you can watch for each new connection -- each new connection gives a UUID number that, once authorized, will be able to get in when the system is re-locked again. It solves the lotto winner problem. Without such a mechanism, then lotto winners will arise, no matter how unlikely, it will always remain possible -- so you need to encrypt all your files before you place them into a sync folder or use a Truecrypt (or similar) container.