Allow empty passwords

[tyll]

Output of restic version

restic 0.8.3
compiled with go1.10 on linux/amd64

How did you run restic exactly?

echo | restic init --repo /srv/restic/
Fatal: an empty password is not a password

What backend/server/service did you use to store the repository?

filesystem

Expected behavior

Restic should allow empty passwords.

Actual behavior

Does not allow empty password.

Steps to reproduce the behavior

echo | restic init --repo /srv/restic/

Do you have any idea what may have caused this?

it is a design decision.

Do you have an idea how to solve the issue?

Remove the check for emtpy passwords.

Did restic help you or made you happy in any way?

Yes, it is a great product and I love that it helps so many people to do backups.

[fd0]

Restic should allow empty passwords.

Can you elaborate what your use case is? Why should restic allow empty passwords?

it is a design decision.

Indeed, it is. But I'm curious what you're trying to achieve.

A related issue is maybe #1018

[tyll]

I just wanted to backup some directories temporarily on my local system as a quick safety net when changing files in a directory. I did not want to remember a passphrase or be bothered to enter a passphrase everytime I want to create a backup. Since I just used a as a password, there is no real security benefit in using this password compared to not using a password at all. Therefore any low overhead to remember or enter a useless password make the tool less perfect.

[fd0]

Thanks for the explanation. I'd like to keep this check in place, so I'm closing this issue for now. Please feel free to add further comments. Thanks!

[tyll]

When we talked about this a while ago you said there would be a discussion...
Can you maybe explain why you consider this check to be useful? The repository should still be encrypted so that a password could be added afterwards.

[fd0]

I consider this check useful because in my experience, most users will want to set a password. Accepting an empty password, or even having a code path that allows accepting empty passwords, may lead to users accidentally saving their backups to remote locations without proper encryption. One situation where this may happen is when the environment variable RESTIC_PASSWORD is not exported or set to the empty string accidentally.

So, in this case, it feels to me that protecting users from a mistake is better than removing the minor inconvenience of having to set a password :)

There are easy workarounds for this though: Use a password manager, use the string test, export RESTIC_PASSWORD statically via a file e.g. in /etc/profile.d, use the name of the directory you're saving (or the repository) as the password...

[LexSong]

Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.

How could I prevent this happen if I don't want to losing my data forever?

[cfbao]

@LexSong Use a password manager.

[tyll]

On Tue, Jul 03, 2018 at 09:56:56AM -0700, Chenfeng Bao wrote: @LexSong Use a password manager.

How do you propose to backup the password manager database? Do you propose here to use a password manager with a database without a password? Which password manager does restic support to get the password from?

[cfbao]

Password management is a huge topic that I don't want to get into too much details in this thread. Just pointing out that if done properly, passwords shouldn't be a headache. There're numerous resources online.

The database of a password manager should already be properly encrypted, so you can put it anywhere you like without another layer of encryption. There're also many cloud based password manager services, so you don't have to worry about backups yourself.

As for restic's support, you can just put the password in a plaintext file locally and use the --password-file option. Then you don't need to enter the password manually. The password itself should also be put in the password manager for record.

At the end of the day, there's always one complex password/passphrase you have to memorize to keep things truly secure.

[cfbao]

Actually, if you truly don't want a password on a restic repository, why not just use a one-character dummy password?

[tyll]

Using 'a' as a password was actually my workaround but it does not feel to be proper since I cannot be sure that I remember using this when I see this repo for some reason again in a few years in case I forget to delete it when I do not need it anymore. Therefore I might have to implement some kind of brute forcing to figure it out. This is all work that could be avoided.

In the past I already used simple temporary passwords in situations that left me in this state when temporarily protected an external HD with a password to make it easier to delete it afterwards. However I did not delete it so when I wanted to use it the next time I wanted to make sure that there is nothing important on the drive. Unfortunately the password from my password manager did not work anymore since I forgot to update/remove it from there. Therefore when I think of my future self, it seems to be a good idea to make it easier for him by not creating restic repsositories that I cannot decrypt.

I have another idea, how about restic would try to use "restic" as a default password when no password to access a repository and fall back to a error message if it does not work? Then users could use this password to indicate that they do not need encryption and restic would open it without extra magic.

[bjoe2k4]

I'd agree with previous comments to keep the check for protection from user mistakes.

[alphapapa]

Restic needs to support empty passwords for the reasons already stated. I specifically do not want to encrypt my local backups because I do not want to lose access to them. I do not want to risk forgetting the password and not being able to restore data. This is a real risk because users typically restore very rarely, and often run unattended backups for which they do not need to enter the password, making it more likely to be forgotten. Storing the password in a file or script is an error-prone workaround for a problem that should not exist. I agree that care should be taken to prevent accidentally uploading unencrypted data to remote repos. It seems like a simple solution would be to have a command line option, `--allow-empty-password`. Users could set that switch in their scripts and the default could remain to require a password.

[cfbao]

This is a real risk because users typically restore very rarely, and often run unattended backups for which they do not need to enter the password, making it more likely to be forgotten.

Such backup passwords are not meant to be memorized. The only complex encryption password you need to remember is the one for your password manager, which you will use often. And you really should use a password manager.

Storing the password in a file or script is an error-prone workaround for a problem that should not exist.

Sorry, I just don't see how it's an error-prone workaround. It seems like a completely valid way to automate encryption to me. The problem is solved by, again, using a password manager.

It seems like a simple solution would be to have a command line option, --allow-empty-password. Users could set that switch in their scripts and the default could remain to require a password.

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

[alphapapa]

Such backup passwords are not meant to be memorized. The only complex encryption password you need to remember is the one for your password manager, which you will use often. And you really should use a password manager.

A password manager is absolutely not a valid solution to this problem. The whole point of making backups is to backup your files, which includes the password manager's database! How, then, would you recover the password to the backup set when the password is stored inside the encrypted backup set?

When designing a backup system, you must plan for the worst-case scenario, which includes restoring when you have nothing available except your backup. What you evidently do is backup your password manager database separately from your Restic backups. That is fine for you, but it's not for you to impose that system on other users. And it's absurd to say that a password manager is necessary to use Restic, especially when it is not even designed to integrate with one. If it is, please show me the documentation to that effect.

Restic, like much software, is intended to enable users to meet their needs. Your needs do not include a bare-metal, nothing-but-your-Restic-backup restore scenario. Others users' needs do. Please do not dictate other people's needs to them.

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

What specific concerns do you see regarding an increased attack surface caused by the proposed --allow-empty-password option?

[tyll]

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

My other idea was for restic to use a default password to access a repository when no password was specified, for example restic. Then the UI for creating a new repository does not change and only when a user uses the default password restic will automatically be able to access the repository and the user does not need to remember the password.

[tyll]

Sorry, I just don't see how it's an error-prone workaround. It seems like a completely valid way to automate encryption to me. The problem is solved by, again, using a password manager.

As long as there is no integration with the password manager, there is still the danger that the value in the password manager is wrong, outdated or accidentally deleted since there will be a copy of the password outside the password manager.

[fukawi2]

I would also like to see an option to allow an empty password (through the use of the --allow-empty-password flag, or perhaps something more verbose/unique to highlight the risk, like NRPE's --dont-blame-nrpe flag).

My use cases:

• Business: we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).
• Home: I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another).

I understand the need for a passphrase to ensure data integrity as well as encryption. I see the file(s) in the keys directory appear to be a JSON object. Perhaps a psuedo-random key could be generated (rather than no key) and stored in there? This doesn't help the users who are trying to avoid the overhead of encryption for performance reasons though.

[alphapapa]

@fd0 What do you think of the proposed --allow-empty-password command line option? It would require passphrases by default, but allow users to override it when necessary.

And please consider reopening this issue. Many users' needs include backing up non-confidential files without risk of losing access due to forgotten or misplaced passphrases.

[geometryof]

Brand new restic user here -- haven't even created my first repository yet -- but years of experience with other tools -- my favorite being good old "dump". With respect, this is a no-brainer -- of course empty passwords should be allowed. By all means add a flag to minimize the risk of inadvertent error, but please do not dictate use cases to experienced (potential) users who have clearly indicated other needs.
All I'm trying to do is make local backups for safety; security is not an issue, and I am far more likely to lose track of the password than I am to need the backup. And I hate password managers...

[gerroon]

Having password requirement makes it hard to automate backups, and needing to provide the password in an env or a script file renders whole security thing useless in the first place.

[mholt]

needing to provide the password in an env or a script file renders whole security thing useless in the first place.

That's not necessarily true. There are good ways to do that.

[alphapapa]

That's not necessarily true. There are good ways to do that.

Please don't rehash this argument here. Many users need to make unencrypted or empty-password backups. If you're not one of them, good for you.

[gerroon]

@mholt, any recommendations? I would be more than happy to backup my servers with zero interference with maximum security.

[mholt]

Many users need to make unencrypted or empty-password backups.

This is usually an XY problem.

@mholt, any recommendations? I would be more than happy to backup my servers with zero interference with maximum security.

It highly depends on your specific situation, threat model, environment, acceptable risks, and technical and usability objectives. So no, I don't have a blanket set of recommendations for anyone.

[alphapapa]

This is usually an XY problem.

So no, I don't have a blanket set of recommendations for anyone.

That condescending attitude is not helpful. Much worse that after telling us our needs are wrong, you then decline to offer any advice. This is a FOSS project, not Apple, Inc.

For example, I neither need nor want to encrypt my local backups of my already-unencrypted data. If my primary disk fails and I need to recover my backups, the passphrase is stored inside the backup repository with my backup scripts and config files. My primary concern is not to keep others from accessing this non-sensitive data--my primary concern is easy recovery and not being locked out of my data.

This is a common case for many users, and it's not for you to decide what users' needs are.

Software exists to serve users, not to force users to acquiesce to its demands.

[rawtaz]

Yes, those suggestions have already been made, so we're going in circles now.

Yeah, and honestly I still haven't seen an actual explanation to why a dummy password is so hard to handle, I feel I've mostly seen overcomplications of it.

Personally speaking, they are not suitable solutions that I'm comfortable with for my environment and use cases.

This is something I totally respect. Everyone's use case is individual and you have your workflow :)

I guess at some point we will get a --no-password or similar, hopefully that will solve this use case too. Thanks for your input!

[gsauthof]

rawtaz wrote

Just let me say that restic init -r foo --no-password is probably a better flag name than restic init -r foo --allow-empty-password, simply because the former is more to the point and the latter is just too verbose.

I fail to see any good arguments why just using a dummy password isn't a perfectly viable way to do this instead of increasing the restic code base on this topic. I've seen someone say that they might forget the password "a". While that might be true, surely it's possible to invent a simple dummy password and remember that, or at least figure it out anew when need be. But whatever, a flag works fine too, I'm just amazed at how big of a problem this seems to be :D

I'm not concerned about dummy password usage/handling - instead I'm sometimes concerned about CPU usage slowing the backup process down by the mandatory encryption when it's running on lower-end hardware.

Resolving #1018 (Unencrypted backups) would also resolve this issue - i.e. e.g. with a --unencrypted switch instead of --no-password switch.

I actually used restic on lower-end hardware where the CPU definitely didn't have AES-NI (or a similar extension) and where the backup then was CPU bound. In another case the CPU was a bit more powerful but the only available external hard drive was already LUKS encrypted and thus it was CPU bound because it wasn't powerful enough to handle two encrypting processes in parallel.

See also: #1018 (comment)

[vstavrinov]

If You forget how to use restic You can read the docs. If You forget a repository location You can find it. Or You can casual encounter orphan repository and wondering what there is backing up inside. But if You forgot password You lose your data forever. And in real life You can forget any simplest dummy password. You can forget everything You don't use often.

If You lose root password You can boot with init=/bin/bash option and get full access. While this hole could be closed it still exists in most systems. Why? Because loss from the unavailability would be more than from insecurity in those cases. Thus it is a trade-off between security and availability. For systems with higher requirement special solutions exists, like redundant keys, provided both security and availability.

resitc is not a security tool. It is a backup tool. And as such, it should provide backup functionality itself first of all, and only then security. So password protection and encryption could be provided as options only and should not be in place by default.

[vstavrinov]

BTW: defaults are the mark of software quality.

[rawtaz]

@vstavrinov Please read the introduction to restic before saying it's not a security tool. It's a backup tool of which one of the primary features is that it tries to make your backups secure. So, you're pretty far off when you say that it's not concerned about security.

But if You forgot password You lose your data forever.

Yes, and that's why you (in this case have the simple option to) use a dummy password so that you will always be able to realize the password even if you were to forget it.

And in real life You can forget any simplest dummy password.

If you do, you picked a too complex dummy password, and it's not really a simple dummy password anymore.

This whole discussion is becoming hilariously silly, frankly. I can't believe people are saying that a password like 1234, which is one of the most common and obvious ones, is something that they might forget and then not be able to figure out real quick (e.g. by just trying a few obvious dummy passwords). I'd say you have to try real hard to not be able to "guess" 1234 when you're in that situation, and even then you will most likely fail to not guess it.

[darkdragon-001]

But if You forgot password You lose your data forever.

Wikipedia might help you out: Just try the most common passwords from https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

One situation where this may happen is when the environment variable RESTIC_PASSWORD is not exported or set to the empty string accidentally.

It is possible for the code to check if a password was set to an empty string explicitly or just not set (no command line option specified, environment variable not set -> different from an empty string).

I think the choice should be given to the user which password one wants to choose.

Resolving #1018 (Unencrypted backups) would also resolve this issue - i.e. e.g. with a --unencrypted switch instead of --no-password switch.

Encryption should still be mandatory to protect against binary search on a hosting provider independently from the format, transmission over an unencrypted channel with MITM and so on. While this does give you as much protection as an empty password does for targeted attacks (zero), it still avoids collateral damage on non-targeted attacks.

[vstavrinov]

@rawtaz

It's a backup tool of which one of the primary features is that it tries to make your backups secure. So, you're pretty far off when you say that it's not concerned about security.

Not far off. Point me where I say "it's not concerned about security". I don't. You say the same: "It's a backup tool". Backup is not security, right?. So restic is not a security tool. And "... one of the primary features ...". You are right again: it is a feature. i.e. security is a feature, while a backup is a functional (target) designation.

@rawtaz

This whole discussion is becoming hilariously silly, frankly. I can't believe people are saying that a password like 1234 ...

I can do nothing, but You are right in this case too. What is silly is a discussion of a dummy password. But I think more important is to understand that password protection and encryption should be optional. As well as do not impose users extra unwanted features, leaving them a choice to use or not to use it. And this is the mark of software quality too.

[cfbao]

But I think more important is to understand that password protection and encryption should be optional.

Why? Why "should" a backup tool not have default encryption? Just because it's a "backup" tool? You're just saying this but there's no reason to any of this.

No design decision can please everyone. Restic chooses to put a heavy emphasis on security, and users like me love that strong encryption is the default.

• If you don't care about security, you cannot misuse a secure-by-default system. At worst, you see some errors and try again with an adjusted command.
• If you care about security, there are tons of ways to misuse an insecure-by-default system to catastrophic effect. One missing flag, and your sensitive data is leaked, maybe irreversibly.

It's one thing to ask for a flag that can omit the password, but arguing for no encryption by default is a dangerous "screw you" to all existing users who are relying on restic's encryption. The potential for catastrophic user errors is huge.

[vstavrinov]

@cfbao

But I think more important is to understand that password protection and encryption should be optional.

Why? Why "should" a backup tool not have default encryption? Just because it's a "backup" tool? You're just saying this but there's no reason to any of this.

"optional" is not the same as "default". Defaults as such may be arguable. But to have options is more important. While we have no choice there is nothing to do with defaults. That's the point. First provide options then it makes sense to discuss defaults.

[rawtaz]

In this case (issue) it's pretty simple - there will likely be a --no-password or similar flag to restic init (with the default still being that restic requests a password upon init), but this is just my take on @fd0's last response. And there's no ETA at this point, no need to ask about that :)

Meanwhile, use a dummy password :) I would guess that a proper implementation includes the ability to remove/unset a password/key that was previously used to init the repo, so one shouldn't have to recreate the entire repository.

Encryption is another thing however, and tracked in that other issue.

[cfbao]

I don't care too much about a no password option, but you were arguing for default no encryption:

So password protection and encryption could be provided as options only and should not be in place by default.

BTW: defaults are the mark of software quality.

which I find dangerous.

Though I generally agree with @rawtaz's points, if the discussion is strictly about a no password option (not changing default), I don't have too much of a stake in it.

[vstavrinov]

@cfbao

I don't care too much about a no password option, but you were arguing for default no encryption:

So password protection and encryption could be provided as options only and should not be in place by default.

You can see even in this cite the "options" are first and "default" is next. And that's the point again.

[tyll]

In this case (issue) it's pretty simple - there will likely be a --no-password or similar flag to restic init (with the default still being that restic requests a password upon init), but this is just my take on @fd0's last response. And there's no ETA at this point, no need to ask about that :)

Meanwhile, use a dummy password :) I would guess that a proper implementation includes the ability to remove/unset a password/key that was previously used to init the repo, so one shouldn't have to recreate the entire repository.

A probably simpler solution would be for restic to support a dummy password that it will try to open an existing repository if no password is specified by the user.

Regarding handling dummy passwords: There is no clear best dummy password that works for everyone. 1234 is an annoying dummy password since it requires four fingers to move up and type. "asdf" is a lot faster to type for example. Also some services restrict password choices, so only numbers or only four digits might not be possible. Therefore a solution inside restic would be most user-friendly. Then users would only have to type the dummy password once.

[paudley]

From a security by design perspective, providing any sort of dummy password is a bad idea.

IFF someone really wants to circumvent the encryption or does not need it, simply supply a consistent password. You don't have to type it, you can write a script to wrap restic and hard code to your heart's content in there. Really, is that more work than supplying the repository address or other config options?

Having restic try a set of fake or dummy hardcoded passwords is just asking for trouble. What if some poor soul happens to pick one of your proposed "magic" passwords? Do we warn them off choosing our special dummy, fake encryption passwords? "No Ted, you can't choose SPACECHICKEN as your repository password, it's special." ;)

I'm fine with providing a option for users to shoot themselves in the foot with ("--no-repository-password") but I don't think restic should go any further than that to appease the very small segment of users that desire REDUCED security.

[tyll]

From a security by design perspective, providing any sort of dummy password is a bad idea.

Why is it worse than allowing no password?

IFF someone really wants to circumvent the encryption or does not need it, simply supply a consistent password. You don't have to type it, you can write a script to wrap restic and hard code to your heart's content in there. Really, is that more work than supplying the repository address or other config options?

Yes, it is more work. Restic would be the backup solution and its output is the repository. So, ideally, the repository would contain everything to restore the backup. But when using a wrapper script that hardcodes the dummy password means that this script needs to be backed up by something else, otherwise the repository would be useless.

Having restic try a set of fake or dummy hardcoded passwords is just asking for trouble. What if some poor soul happens to pick one of your proposed "magic" passwords? Do we warn them off choosing our special dummy, fake encryption passwords? "No Ted, you can't choose SPACECHICKEN as your repository password, it's special." ;)

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I'm fine with providing a option for users to shoot themselves in the foot with ("--no-repository-password") but I don't think restic should go any further than that to appease the very small segment of users that desire REDUCED security.

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

[paudley]

Why is it worse than allowing no password?

I'm not sure how I would go about convincing someone that hardcoded, hidden, secretly tried against repositories passwords would be a bad idea. If you think they are, there is likely no security focused argument that would convince you.

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I chose an entertaining example, perhaps I should not have. Let's assume that your dummy password that you want restic to secretly and automatically try if decryption fails is: "12345". A naive user could very well choose that as their password. Now they have a repository that they believe is encrypted (and sort of is) but anyones restic can decrypt. This argument applies for any give set of passwords you choose in your hardcoded set. This is fundamentally bad security design.

There is a term for what you are proposing. It's called an encryption backdoor :) Hiding that backdoor in the documents assumes that all readers will fully read the manual before using restic. Would it not serve more people's needs to make them read the documents to determine how to lessen secure should they strangely desire that?

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

If you don't think that encryption at rest is a solid security policy and would opt for something else, you are certainly in the deep minority. These kind of insecure defaults serve no one and should be discouraged at every point. One needs only to look to ANY security reference for advice in this case. My point is not the contentious one - I'm arguing the industry standard practice.

Even your example of append only storage media would strongly benefit from at-rest-encryption. I'd hearily recommend reading a recent set of NIST, ISO 27002, NERC, IEC 62443 or really any globally accepted standard for guidance in best practices here. We're not in new territory.

[paudley]

I should also point out that we are effectively conflating two issues in this thread: key management and encryption.

Perhaps that's where the confusion arises.

[smlx]

Maybe this issue can be solved by documentation that says something like:

If you don't want to secure your repository with a password, just use the string: password

That way there's a well-known way to achieve backup/restore with restic without having to manage any keys.

[tyll]

Why is it worse than allowing no password?

I'm not sure how I would go about convincing someone that hardcoded, hidden, secretly tried against repositories passwords would be a bad idea. If you think they are, there is likely no security focused argument that would convince you.

I guess you are missing a "not" there...

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I chose an entertaining example, perhaps I should not have. Let's assume that your dummy password that you want restic to secretly and automatically try if decryption fails is: "12345". A naive user could very well choose that as their password. Now they have a repository that they believe is encrypted (and sort of is) but anyones restic can decrypt. This argument applies for any give set of passwords you choose in your hardcoded set. This is fundamentally bad security design.

I did not propose to try it when decryption fails but when no password is specified for decryption. If someone chooses an insecure password, it is insecure regardless of it being tried by restic directly or by someone brute-forcing passwords. "12345" is an insecure password nowadays, as well, and it would not change if it became the default password for restic.

There is a term for what you are proposing. It's called an encryption backdoor :) Hiding that backdoor in the documents assumes that all readers will fully read the manual before using restic. Would it not serve more people's needs to make them read the documents to determine how to lessen secure should they strangely desire that?

An encryption backdoor would be if restic used a default password additionally to the user-provided password when encrypting data. My proposal is about trying one password at decryption. The user would still actively choose this bad password.

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

If you don't think that encryption at rest is a solid security policy and would opt for something else, you are certainly in the deep minority. These kind of insecure defaults serve no one and should be discouraged at every point. One needs only to look to ANY security reference for advice in this case. My point is not the contentious one - I'm arguing the industry standard practice.

What's the insecure default in your opinion?

Even your example of append only storage media would strongly benefit from at-rest-encryption. I'd hearily recommend reading a recent set of NIST, ISO 27002, NERC, IEC 62443 or really any globally accepted standard for guidance in best practices here. We're not in new territory.

At-rest-encryption does not mean that restic needs to do it. The append-only storage can still be encrypted somehow else if necessary. Nevertheless, there will be some unencrypted storage, even if it is only for the password. Otherwise the backup concept would rely one someone always remembering the password.

[bjoe2k4]

unsubscribing from this thread...

[rawtaz]

Let's just leave it at this, it's clear that some people want a --no-password option to init, and that's all that this issue is about. Encryption or not is a separate issue.

[mescanne]

Just a quick comment here:
I'm a user who doesn't care about encryption. There's nothing sensitive about my data. I do care about people being able to use in 20-40 years who aren't me. Just using rclone is another poorer alternative.

Restic looks like a good tool for this, except mandating encryption and a password means that I need to take that into account. Maybe a README in the backup repository. It is more work and any solution (from my side) defeats any encryption anyway.

Mark

[fd0]

Thanks for your contributions, I think we've collected enough information.