Separate secrets from the rest of Klipper-Backup config

[jornamon]

Is your feature request related to a problem? Please describe.

While not indispensable, it would be nice to have Klipper-Backup config backed-up with the rest of the printer configuration, excluding the secrets contained in .env file.

Describe the solution you'd like

I would like to have the secrets, say, this part:

github_token=xxx
github_username=xxx
github_repository=xxx
branch_name="main"
commit_username="xx"
commit_email="xxxxxx"

separated from the rest of the Klipper-Backup configuration, ideally in a file in ~/printer_data/config so that it can be included in the actual backups.

Describe alternatives you've considered

Still use just one config file, but allow some kind of include mechanism so the user can separate the part of the configuration he needs to be backed up.

Additional information

No response

[Tylerjet]

Just to be clear

Is your feature request related to a problem? Please describe.

While not indispensable, it would be nice to have Klipper-Backup config backed-up with the rest of the printer configuration, excluding the secrets contained in .env file.

Describe the solution you'd like

I would like to have the secrets, say, this part:

github_token=xxx
github_username=xxx
github_repository=xxx
branch_name="main"
commit_username="xx"
commit_email="xxxxxx"

separated from the rest of the Klipper-Backup configuration, ideally in a file in ~/printer_data/config so that it can be included in the actual backups.

In the first section you mention secrets being excluded but in the second half you mention wanting the token, username, etc... in a seperate file so it could be included in the backup. Did you actually mean excluded? as including the token in the backup is a major security risk and not to mention github we immediately revoke your token the second it was pushed to the repo.

Once the restore branch is finished and released you will get a restore.config file that will look like this https://github.com/Tylerjet/test/blob/55d37627f86f9aff7701c0de0f536dfa238f2620/klipper-backup-restore/restore.config with cetain data excluded from the variables.

[jornamon]

Thank you for taking the time to look into this. I’m sorry if my initial request wasn’t clear!

Let me clarify:

What I meant was to separate the secrets from the rest of the configuration so that only the non-secret parts of the configuration can be safely backed up. My goal is to ensure that secrets like the GitHub token, username, and repository remain in the local .env file (and not included in the backups).

The idea of moving the non-secret configuration to a file in ~/printer_data/config was to make the non-sensitive parts of the configuration easily backup-able, while keeping sensitive information out of the backup for security reasons.

I hope this clears up the misunderstanding. Let me know if I can explain further!

[Staubgeborener]

If I have understood correctly: Sensitive data such as the token, etc. remain in the .env file. Other data that is "not secret" (like repository name, user name, which folders should be included in the backup) is stored in an extra config file. This extra config file is then pushed so that, for example, the backup folder structure can be saved.

# secret content which remains in .env file
github_token=ghp_xxxxxxxxxxxxxxxx

# non secret content which get into new config file
github_username=USERNAME
github_repository=REPOSITORY
branch_name=main
commit_username=""
commit_email=""

backupPaths=( \
"printer_data/config/*" \
)

exclude=( \
"*.swp" \
"*.tmp" \
"printer-[0-9]*_[0-9]*.cfg" \
"*.bak" \
"*.bkp" \
"*.csv" \
"*.zip" \
)

I think it would be technically easy to solve and not an issue. However, we would then have to migrate all users to this new version automatically, as otherwise the existing users would run into an error.

I'm still thinking about it, but the effort involved in the migration is not in proportion to the benefits. In the meantime, I would advise you to save the data (except the token, of course) in a new file ~/printer_data/.env-backup and then include this file in the backup.

[Tylerjet]

Yeah in that case as mentioned at the end of my reply something like that will already be in the restore release.

Once the restore branch is finished and released you will get a restore.config file that will look like this https://github.com/Tylerjet/test/blob/55d37627f86f9aff7701c0de0f536dfa238f2620/klipper-backup-restore/restore.config with certain data excluded from the variables.

As the file paths and other data is needed to properly restore files back to the paths they were pulled from.

[jornamon]

I'm still thinking about it, but the effort involved in the migration is not in proportion to the benefits. In the meantime, I would advise you to save the data (except the token, of course) in a new file ~/printer_data/.env-backup and then include this file in the backup.

For now I'm doing what you suggested, keep a manual backup of the Klipper-Backup config.

I agree that it's not super important, and maybe it's not worth it, but it would be nice that the config of the backup tool get's also backed up without manual intervention.

This occurred to me just because I just installed a fresh OS image on my printer and the time it takes to replicate all the config of all the modules quickly adds up, even for small config files like this one.

Yeah in that case as mentioned at the end of my reply something like that will already be in the restore release.

I don't see how this helps if the secrets are still in the same file as the rest of the configuration. I'm probably missing something here.

[Tylerjet]

In that restore.config file I linked you will see that the secret variables are still there but the values are removed before being pushed to the repo that way there is no need for two separate files.

All the important data like the paths being backed up and exclusion list are backed up to the repo. Along with added data like the theme you are using (if applicable)

[jornamon]

Ohhhh! That sounds like an even better solution!

Thanks for clarifying 🙂

With that feature already in the roadmap, I believe this request is no longer necessary. Feel free to close this issue.