hello, I'd like to create an encrypted and unified remote as based on a few of my other standard remotes.
I know the revamped union command is in beta, and that's what I'm using, but I also know it has several limitations.
on the other hand, I've successfully experimented with the crypt remote, and I know it has at least a couple of important parameters: password and salt.
the question is: what's the suggested order for this operation? crypting a single unionized remote?
or unionizing several encrypted remotes?
in the latter case, do I need to use the same password and salt for the encryption layer on the several original remotes?
the remotes in questions are hierarchically similar, with similar quotas etc, and I plan to fill them up with a randomized policy like eprand (unless it doesn't make sense).
any suggestion? thanks!
A good question that I don't think anyone has asked before!
I think you'll get the same files on disk either way so I'd go for the simplest namely crypt the union. Then you can check if the underlying union mount works properly for you too.
as an experiment, I have already tried the opposite, that is, encrypted each remote separately, and then formed a union.
I've not tested thoroughly, and I'm not an expert user -- yet! -- , but... it seems to be working fine.
could you explain why you think that order is the simplest?
I went for the other way around so that, even if a single remote is "compromised", all the others retain their cryptographic strength because they use different pass/salt combinations.
if the opposite was true, the compromise of the (unique) pass/salt pair would endanger all of the remotes.
that's my reasoning, at least!
It really doesn't matter what the remote is as you are presenting files. If the files are crypted on the crypt remote, not encrypted on a box remote, it really doesn't matter. You can encrypt 10 different remotes with 10 different passwords as rclone is decrypting it and presenting you the decrypted contents. If you union those 10, it's fine.
If someone comprises your rclone.conf, they can access what was in there. If you have 10 separate configs, that helps to mitigate that.
yes, sure, but I don't understand what's your point.
to which question are you replying with this answer?
once again, that's not my point.
if my config file gets compromised then my local files are also compromised, so... game over.
I was hoping for @ncw to chime in about what he sees as the main differences in crypt -> union vs union -> crypt, so I can understand limitations and future impacts of my current design choices.
There is an issue with wrapping the remotes in this order: cloud remote -> crypt -> cache
as a new user, I'm asking whether the guru sees any issues in the order of union/crypt.
please, respect my doubts! let him write a reply, if he has any valuable suggestion on this.
let's just not go in circles... thanks.
That's a deprecated backend that's going on and the reason for that was because of previous issue 2 years plus ago with chunked reading and Google Drive. I'm intimately familiar with the issue and the fix.
Huh? I'm just trying to help you get to an answer on your question by telling you how it works. I use a union remote so in this case, I'm probably more versed than @ncw in use.
A union combines remotes together so you have any number of other remotes underneath it. You could have a box remote, a crypt remote, a google drive remote, etc. You can't go union->crypt or union->box or union-> any other remote as that goes against the purpose of a union remote.
Rest assured, if I don't know an answer, I ask, but in this case, I do.
I don't think it matters too much - at least I can't think of a reason why...
Making one crypt over the unions will use fewer backend instantiations at once which will use less memory, but I don't think it will make a lot of difference.
I just read on the current docs that for cache and crypt the commutative property is not valid, so I was mentioning that as a cause of my doubt, that's all. no need to digress on that unrelated issue.
not really, you are just re-iterating on the union concept without need.
I was not asking how union works (not in this thread, at least), I was asking about possible complications with using union and crypt.
no need to repeat the same thing over and over.
what? oO
you sure can go either crypt -> union or union -> crypt, that's the whole point of this thread!
okay, thanks!
when you wrote "simplest" I was kind of confused, but I guess crypting the union is the simplest choice in terms of sheer number of config parameters.
I'm not following on the difference about the "fewer backend instantiations", and I'd appreciated if you had time to clarify, but ncw's answers are good enough for me as it is! thanks.
still, I'll probably keep my design choice of uniting individually-encrypted remotes and I'll see how that goes.
It's valid, but not recommended as it was written prior to chunked downloading so it caused download quota issues. You can change the order now as it would have no issue. Since the backend is maintainer free, the docs have been left a bit in the wind.
ncw wrote that it does not really matter the order with which you do stuff.
so you can:
create a bunch of remotes, their relative crypt counterparts, and then create a union of those (this is what I did).
create a bunch of remotes, create a union of those, then create a single crypt remote encrypting the union.
there aren't really config files to share.
are you comfortable creating a single remote (e.g. Goole Drive, Mega, etc)?
are you comfortable creating a single crypt remote?
have you decided what to unite? then it's relatively straightforward.
big thing is: rclone union got revamped and is currently in the beta.
so, take a look at the beta docs: https://tip.rclone.org/union/
fetch a beta package and try it out.
feel free to ask for more help, possibly open up a new issue to avoid clogging this one!
cheers
