Disappointed Cat

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Disappointed Cat

  1. If you ask me, it's borderline insane to use Git for general storage purposes. Git is not meant for "large" binary files. Also it's performance drops drastically over millions of lines commited which is not hard to exceed in this case. Not to mention it's hard to manage old commits - i.e. delete - because it has a strict tree structure. I've never used Sparkleshare and from what I just learned, I never will.

    BTSync is rapidly evolving and already proved that it's very capable. Indeed, opensourcing it would be great but I'm happy either way and after the devs introduce an API a lot of possibilities open up.

    BTW, FSF is working on something. Link.

  2. But that only forwards /gui/ to BTSync's webserver. There probably will be other pages like /proxy, /api, etc.

    The problem when you try to pass-through everything is that Apache loads the proxy directive before the redirect directive.

    I tried ProxyPassMatch, RewriteRule [P], and who knows what else. The final solution was this:

    <Location /btsync>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} ^/btsync(/|/gui)?$
    RewriteRule ^ /btsync/gui/ [L,R=301]
    # Auth, etc, ....

    This way /btsync, /btsync/, /btsync/gui, /btsync/gui/ all work while forwarding everything.

    Can you make it nicer? :)

  3. 1. Whatever you want. Consider every line a path or pattern that applies to both directories and files.

    2. Modify the generated file unless you want remove the default rules.

    3. Correct and for now you manually have to copy the SyncIgnore files to each and every client. The devs still haven't decided if they'd just sync it or make it client specific and apply it to incoming files too (selective sync).

    There are topics that even have examples for the patterns you can use. Think of it as unix glob paths.

    Please use the search box to find out more.

  4. It does support SSL. You can specify the https protocol in the URL. However setting up your own certificate can be tricky so instead I recommend using a reverse proxy which comes with additional benefits. Here's a topic for apace reverse proxy.

    This way you get to set up your own authetication, SSL ciphers, and be sure that the web server supports DHE+ECDHE.

  5. You also have to give up SyncIgnore unless you use the encrypted paths in it, have fun with that.. Not to mention getting EncFS to work on Windows 8 is a hackathon. You also loose a lot of I/O performance with file level encryption. I say go with disk encryption and sync decrypted folders. If you want untrusted seeding nodes, you're gonna have to wait until there is such feature in BTSync natively or over an API.

  6. But why? You're not really protecting anything, once the attacker got in... A 'secret' isn't a password that you can match against a salted hash, it's needed in plain text. If you're worried about local users there are file permissions for that.

    If offline security - disk encryption - is not good enough for you then you probably don't want to store those so sensitive files on your disk unencrypted and always mounted anyway.

  7. What's with the attitude? Like Harold said, if the settings file is readable by the attacker they'll probably also have access to the files that the app is syncing. Fine, maybe not write access which they could gain remotely with the secrets. Furthermore how would you secure the secrets without having to type in a passphrase at start? With something that's available without user interacton? Also useless... Security through obscurity is not a good road to go down on.

    BTW, there are multiple solutions to this problem. On of them is disk encryption, another is file level encryption.

    There's is no need to reinvent the wheel in every app.

  8. Backupsy provides custom $5 plans with 100G storage (in NL too). Can you beat that?

    Although I'll wait for encrypted nodes before I trust anybody with my sync shares.

    I'm considering renting a VPS mainly for BTSync but also for a low-traffic webserver which currently runs on a company server but I have no root access. So I'm really going for a cheap VPS - preferably in EU with good bandwith - because I could set up multiple sync servers with friends instead and already have a webserver for free.

  9. The devs could release the source code but not license it under a free license like GPL. Kind of like what the Truecrypt team did. This would allow for vetting and making builds for any architecture with the copyright that they're comfortable with. Anyway, the app is only fresh out of alpha so it's too early. If it were me, I wouldn't release it. Yet.

    Also keep in mind that open-source is only as trustworthy as the people making and reviewing it; and even if the code is perfect most people won't compile it from source so they'll be exposed to all kinds of fraud.

    On more thing: No matter how secure the app is the weekest link is always the human factor and poorly setup systems.

  10. Actually the deleted files are stored on the same physical drive in a system folder called $RECYCLE.BIN. So I guess it would also show up in an other PC, or not. But the recycle bin has other limitations, for example you can't open files in it. Anyway, I'm happy with the hidden .Sync* folder, it's the best soluion. The only thing missing is compression or rdiff style storage.

    As for HTTPS: You should use apache or nginx reverse proxy, that will give you freedom over what kind of ciphers, certificates, authetication, whatever you want to use.

  11. I'd like to propose a few WebUI changes:

    Plese remove the 'Connected devices and status' column, it makes the page chaotic if there are many connections.

    Instead you could make another page like the devices tab in the GUI, or make jQuery popups for each share.

    Also deletion confirmation could be nice here too.

    But most importantly it would be great if we could modify the WebUI in a way so it would keep working after updates.