nectar

Members
 View Profile  See their activity

  • Posts

    6

  • Joined

  • Last visited

 Content Type 

Posts posted by nectar

  2. Sync Crash On Mac

    in Sync Troubleshooting

    Posted

    I’m experiencing the same issue, suddenly. All with 1.3.94 on OS X 13C64 and 13C1021. Crashing thread always has a backtrace like:

     

    Thread 2 Crashed:
    0   com.googlecode.google-breakpad 0x003066ac google_breakpad::ExceptionHandler::UninstallHandler(bool) + 190
    1   com.googlecode.google-breakpad 0x00307098 google_breakpad::ExceptionHandler::WaitForMessage(void*) + 426
    2   libsystem_pthread.dylib       0x95b965fb _pthread_body + 144
    3   libsystem_pthread.dylib       0x95b96485 _pthread_start + 130
    4   libsystem_pthread.dylib       0x95b9bcf2 thread_start + 34
     
    Full crash report:  http://spo.onl/btsync.crash

    And I down-revved to 1.3.77 and now I am experiencing the same crash. So it appears to have to do with the content I’m syncing, and not the BTSync version.


    I’ve now removed all my sync folders from BitTorrent Sync, and started adding them back one by one. I’ve re-added about half of them, and all seems OK for the moment— the crashes have stopped. Unfortunately I am out of time this morning, but I’ll continue later in the day.

  3. Security

    in Sync General Discussion

    Posted

    Asymmetric key lengths must be longer to match symmetric key security. See for example Table 2 in http://www.rsa.com/rsalabs/node.asp?id=2088 , and read the whole thing for a better understanding.

    32 characters in base 32 = 32^32 = 2^160

    That’s a potential key length of 160 bits, more than enough for AES-128.

    The recommended minimum RSA public_key length is going up from 1024 to 2048 after 31st December 2013[1]. Also RSA is an asymmetric system. Yours is symmetric afaik.

    This indicates that your 32 char length is not secure in any way.[2]

    [1]See here: http://news.netcraft...s-or-rules.html

    [2]More to read: http://en.wikipedia....thm_key_lengths

  5. Read-only client overwrote a file!

    in Sync General Discussion

    Posted

    Hi,

    I have two machines each with a collection of about 124GB of media. They were previously in sync using “rsync”. One machine (let’s call it the backup) was about a week out of date relative to the other machine (let’s call it the master).

    I set up Bittorrent Sync on the master, and let it completely index (this took a really long time). Then I used a one-time read-only key to set up the backup. Almost immediately I received a notification on the master that a file upload was completed. Checking history on the master, I saw:

    4/25/13 2:39PM Finished syncing file 2013/2013-04/2013-04-21/JV20130421_24375_DSC_0447.xmp added by backup

    4/25/13 2:39PM backup added file 2013/2013-04/2013-04-21/JV20130421_24375_DSC_0447.xmp

    Sure enough, the master now had a week out-of-date version of this file! I stopped the sync immediately.

    I double-checked the backup to ensure that it was read-only. In the “Advanced” tab for the folder on backup, it reads “Advanced Preferences are not available with read only secret”.

    This seems like a pretty serious flaw. How can I debug where things went wrong?