Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My one-liner Linux Dropbox client

lpan.io

Post reply on HN
Print view View original

101–110 of 165 posts

Re: My one-liner Linux Dropbox client

#101

Post by btown »

wereHamster wrote: post #71
jkaplowitz wrote: post #68

Earlier quoted context omitted.

Full-disk encryption usually means encryption at the block layer below the filesystem. It doesn't actually have to cover the full disk. There is almost always at least one unencrypted partition on machines with full-disk encryption, since the boot loader and then the decryption routine have to be launched from somewhere. And yes, OEM recovery partitions or similar laptop-specific needs are another case. Full-partitio…

I use full-disk encryption on my old thinkpad. As in, the whole disk is encrypted, from first sector to last. There isn't even a MBR or a partition table on it! I boot the laptop from my USB stick which contains the kernel and initrd. That's what I call full-disk encryption ;)

Just make sure nobody swaps out your stick :)

Re: My one-liner Linux Dropbox client

#102

Post by zipperhead »

whitepoplar wrote: post #33
conanthe wrote: post #12

Dropbox is a no no for one simple reason - there is no end to end encryption. Unless I don't know something? I wouldn't want a disgruntled employee to fiddle with my files.

Is there any Dropbox-like service that lets you control your own private keys, without resorting to the ugliness of uploading an encrypted image to Dropbox?

I use a cryfs mount stored in Dropbox. It's been quite painless.

Re: My one-liner Linux Dropbox client

#103

Post by geofft »

discordianfish wrote: post #27
lloeki wrote: post #13

> Recently, the proprietary Dropbox Linux client dropped support for all Linux file systems except unencrypted ext4. What the heck. Anyone has more information about that? Any announcement? And why would it fail to work on an encrypted (LUKS?) ext4 FS when encryption seemed to me to sit below the filesystem (since AFAIK ext4 doesn't support encryption itself)?

It's FUD. ext4 with LUKS, which is what pretty much everyone is using on a desktop, is still working and the client supported.

Ubuntu's installer for a long while set up an "encrypted home directory" using eCryptFS, i.e., file-level encryption on top of ext4. That's the thing Dropbox is finding painful to support.

Migrating away from that to block-level "full disk" encryption basically requires copying all your files. If you're using <50% of your disk and you feel comfortable doing tricks with partition resizing you can do it, otherwise the best approach is to back up your files (hopefully to encrypted media...) and restore them.

Re: My one-liner Linux Dropbox client

#104

Post by geofft »

pmlnr wrote: post #50
discordianfish wrote: post #27

Earlier quoted context omitted.

It's FUD. ext4 with LUKS, which is what pretty much everyone is using on a desktop, is still working and the client supported.

No, it's not FUD. encrypted ext4 is encfs and ecryptfs, not xy on LUKs, and yes, they did drop support.

It's potentially misleading phrasing. "Unencrypted ext4" means that the filesystem Dropbox sees has to be actual ext4, not an encryption layer on top. There can be an encryption layer under it, and generally full-disk encryption works that way, by encrypting a block device and letting you run whatever filesystem you want on top.

"Unencrypted or decrypted ext4" might be slightly more accurate (although I guess it maybe sounds like you need to remove encryption, not that you just need to decrypt files in memory).

Re: My one-liner Linux Dropbox client

#105

Post by bennofs »

catacombs wrote: post #99
panzerklein wrote: post #25

I setup Syncthing [1] to do the same for my vimwiki folder. It was surprisingly easy, and doesn't require any external storage services. And it can even automatically sync files without internet, over the local network. [1] https://syncthing.net/

I'm sorry if this is a stupid question: If I have my desktop and my laptop, both using syncthing, does one (my desktop) need to always be online for me to sync files from my other device (my laptop)? I'd love to use something else besides Dropbox, but it's convenient that Dropbox works as the middleman that is always operating.

It can only sync data between devices that are operating of course. But if you have three devices A,B,C then it can also sync A-B and later sync B-C, or sync A-C directly if both are running.

Re: My one-liner Linux Dropbox client

#106

Post by licebmi__at__ »

Operyl wrote: post #94
yorwba wrote: post #81

Earlier quoted context omitted.

Syncthing does have a mobile app https://f-droid.org/packages/com.nutomic.syncthingandroid/

For Android yes, but the GP is likely using iOS where no such client seems to exist.

I used fsync when using I bought an apple device https://itunes.apple.com/us/app/fsync/id964427882

It's lacking and has a weird workflow, but at least it worked for me. Didn't test it too much as I hated the apple experience and gave away the device.

Re: My one-liner Linux Dropbox client

#107

Post by geofft »

userbinator wrote: post #88
int0x80 wrote: post #87

Earlier quoted context omitted.

In principle I agree with you, and many could argue the the app is broken. But in all fairness it is not so easy. Then there are lots of little details and corner cases where filesystems that implement a POSIX fs have slightly different semantics. This is important for example when dealing with sync'ing files to disk/backend. Encryption is another problem. Error handling. See for an example the annoying details here:…

Encryption is another problem. I thought the whole point of an encrypting filesystem was that applications using it would not need to care about such things? Unless you're going below the FS abstraction and actually accessing blocks of the device directly, it shouldn't matter.

One of the weird things about an encryption layer on top of a filesystem like eCryptFS (as opposed to encrypted block storage) is that it needs to encrypt and MAC the filenames somehow, but the underlying filesystem has maximum lengths on the filenames, so whatever space you're using for padding and authentication code needs to be squeezed in. And you also need to potentially find an encoding of the encrypted data in case the underlying filesystem doesn't treat filenames as bytes-except-for-ASCII-slash (e.g., common Mac and Windows filesystems treat filenames as Unicode of some form, and Mac ones even do canonicalization). So, your encrypted filenames end up being longer than your decrypted filenames, which means that your maximum filename length is shorter than the underlying filesystem's maximum length.

For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.

Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)

Re: My one-liner Linux Dropbox client

#108

Post by geofft »

zipperhead wrote: post #100
cheez wrote: post #93

Earlier quoted context omitted.

I do this, but 90% of the time I forget to pull on the other machine and have to deal with conflicts.

Yes, you'd have to automate the pull for this to work, and then you'd have a way to notify on conflicts so that they are resolved ASAP. Come to think of it, Dropbox isn't really so great at the notification aspect of this either. It creates a 'conflicted' file but there is no notification that I'm aware of. I have to remind myself to periodically check for conflicts.

Is there a standard-ish git merge driver that resolves all merges with a Dropbox-style "conflicted copy", so you can unconditionally git pull in a cronjob and it never leaves the repo in an unmerged state?

Re: My one-liner Linux Dropbox client

#109

Post by geofft »

conanthe wrote: post #12

Dropbox is a no no for one simple reason - there is no end to end encryption. Unless I don't know something? I wouldn't want a disgruntled employee to fiddle with my files.

Actually, hm, you could point Dropbox at the layer under eCryptFS and have it work (for some value of work) and get e2e that way, right?

Re: My one-liner Linux Dropbox client

#110

Post by rsync »

ekianjo wrote: post #23

It's kind of funny to replace a proprietary client for a proprietary service with FOSS tools when you could completely replace Dropbox with FOSS alternatives instead and enjoy Freedom: Syncthing works very well, and while syncing is not its main feature you could also work with nextcloud.

If only there was a platform agnostic, standards-based, cloud platform that you could point any old SSH tool at.

Imagine if such a provider existed and was running on top of ZFS and maintained the current, stable version of 'borg[1]' on the server side ...

Probably too much to ask.

[1] https://www.stavros.io/posts/holy-grail-backups/

Post reply on HN