They verified it and contacted Dropbox support support told them "we don't support XFS" and uh, two months later this thread happened. Later on, I mentioned this on the Dropbox forums where another user was having the same problem (client mysteriously unlinking after reboot). Wrote my own tool, which decrypted the config using the old key and reencrypted with the new one – and it magically relinked. After some tracing and searching, found one of those "dropbox hostkey forensic tool" GitHub repos which revealed how everything works. Be careful what you ask for – you might just get it.)įound this out the hard way several months ago, after moving $HOME to another disk (yes, including xattrs – I double-checked those) and having the client mysteriously unlink from the account. If you dont know what to choose here, the default ext4 is recommended in. (Just in case you were wondering why Dropbox felt the need to encrypt the config in the first place, well, this blog post and the resulting outrage made it happen. For an MX Linux system installed on a hard drive, you would normally need the. This isn't used for anything else besides encrypting hostkeys and so could be easily replaced with only the inode number, or an xattr, or libsecret, or python-keyring, or even /etc/machine-id. If the fsid or the inode number changes, the key won't fit, so the client discards all configuration and tells you to re-link the account. On ext4 this fsid is static, but on XFS it is dynamic (based on the major:minor device number, which can change if you e.g. The Dropbox client uses an unrelated feature – the f_fsid field in statvfs() – as an encryption key for your account credentials (hostkeys).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |