Something in 1.9.x broke BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK #939

New Issue

Closed

opened 2024-11-18 10:25:32 +00:00 by spali · 3 comments

spali commented 2024-11-18 10:25:32 +00:00

Copy Link

What I'm trying to do and why

I used BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK a lot with 1.8.14.
And since upgrade to 1.9.1 (assuming 1.9.0 is affected to) BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK does not work anymore via borgmatic. Only the borgmatic setting unknown_unencrypted_repo_access_is_ok in the configuration is working.
As this may be a workaround to use the setting, I would prefer to not have it set by default in the configuration and only using it situative when needed.

My use-case is monitoring a repo where the HOME is always fresh and doesn't know the repo.

Steps to reproduce

1. execute any action against a existing repo that is already trusted.

2. Temporarily set HOME to something else (i.e. /tmp).

3. set BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK

export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes

1. execute any action on the same repo as before.

Actual behavior

it fails now as it's an "new untrusted" repo.

Warning: Attempting to access a previously unknown unencrypted repository!
Do you want to continue? [yN] no (from BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK)

Expected behavior

works without error and shows:
Do you want to continue? [yN] yes (from BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK)

Other notes / implementation ideas

No response

borgmatic version

1.9.1

borgmatic installation method

container (1.9.1)

Borg version

1.4.0

Python version

3.12.7

Database version (if applicable)

No response

Operating system and version

container (1.9.1) alpine linux 3.19.4

### What I'm trying to do and why I used `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK` a lot with 1.8.14. And since upgrade to 1.9.1 (assuming 1.9.0 is affected to) `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK` does not work anymore via borgmatic. Only the borgmatic setting `unknown_unencrypted_repo_access_is_ok` in the configuration is working. As this may be a workaround to use the setting, I would prefer to not have it set by default in the configuration and only using it situative when needed. My use-case is monitoring a repo where the `HOME` is always fresh and doesn't know the repo. ### Steps to reproduce 1. execute any action against a existing repo that is already trusted. 1. Temporarily set `HOME` to something else (i.e. /tmp). 1. set `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK` ``` export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes ``` 1. execute any action on the same repo as before. ### Actual behavior it fails now as it's an "new untrusted" repo. ``` Warning: Attempting to access a previously unknown unencrypted repository! Do you want to continue? [yN] no (from BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK) ``` ### Expected behavior works without error and shows: `Do you want to continue? [yN] yes (from BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK)` ### Other notes / implementation ideas _No response_ ### borgmatic version 1.9.1 ### borgmatic installation method container (1.9.1) ### Borg version 1.4.0 ### Python version 3.12.7 ### Database version (if applicable) _No response_ ### Operating system and version container (1.9.1) alpine linux 3.19.4

witten commented 2024-11-18 17:23:49 +00:00

Owner

Copy Link

Thanks for taking the time to report this. I think I know what happened here. The implementation of #914 changed borgmatic's behavior with respect to BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK. Instead of only setting that environment variable when the corresponding configuration option is set, borgmatic now sets that environment variable unconditionally, defaulting to no. That prevents Borg throwing up an interactive prompt when not run in interactive mode, which lead to an apparent hang since the user couldn't see the prompt.

So I think this has the side effect of now ignoring BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK if that environment variable is set outside of borgmatic. I think the fix is to further alter the logic to only set the environment variable if: 1. It's not already set in the environment, or 2. there's a configured borgmatic option for it.

Thanks for taking the time to report this. I think I know what happened here. The implementation of #914 changed borgmatic's behavior with respect to `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK`. Instead of only setting that environment variable when the corresponding configuration option is set, borgmatic now sets that environment variable unconditionally, defaulting to `no`. That prevents Borg throwing up an interactive prompt when not run in interactive mode, which lead to an apparent hang since the user couldn't see the prompt. So I think this has the side effect of now ignoring `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK` if that environment variable is set outside of borgmatic. I think the fix is to further alter the logic to only set the environment variable if: 1. It's not already set in the environment, or 2. there's a configured borgmatic option for it.

witten added the

bug

label 2024-11-18 17:23:55 +00:00

witten referenced this issue from a commit 2024-11-18 17:47:14 +00:00

Fix borgmatic ignoring the "BORG_RELOCATED_REPO_ACCESS_IS_OK" and "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK" environment variables (#939).

witten commented 2024-11-18 17:47:30 +00:00

Owner

Copy Link

Fixed in main. This will be part of the next release! Thanks again.

Fixed in main. This will be part of the next release! Thanks again.

witten closed this issue 2024-11-18 17:47:30 +00:00

witten commented 2024-11-19 04:45:49 +00:00

Owner

Copy Link

Released in borgmatic 1.9.2!

Released in borgmatic 1.9.2!

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

No results found.

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels

blocked

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

No Label

bug

Milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#939

No description provided.