Open witten opened 2 months ago
I agree. I've had significant issues with Borgmatic starting to declare my password incorrect, after having worked for the past 6 months at least. I'm convinced this is part of the problem. After painstaking review, I figured out that the issue was the BORG_PASSPHRASE environment variable in my docker compose file. In the past I had it set to BORG_PASSPHRASE="mypassword", but not it only works when I take out the quotes, i.e. BORG_PASSPHRASE=mypassword.
I'm guessing this is related. The README and documentation still has quotes, and I think this needs to be changed.
My backups started failing when called from CRON with 1.8.13 too, 'passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect.'
. Passcode fails regardless whether its included in quotes or not.
If I log into the container, echo $BORG_PASSPHRASE
shows the correct string that includes the following special characters &^*$#@
. If i call borg from the command line it works fine, i.e docker exec borgmatic sh -c "borgmatic -c /etc/borgmatic.d/example.yaml --verbosity 1 --files"
EDIT: 9/5/24 failing in 1.8.14 too.
I observe similar issues with passphrases that contain something like $0
.
However, the root cause depends on the special character.
With characters like "
and backticks, the following line fails immediately:
https://github.com/borgmatic-collective/docker-borgmatic/blob/8adec5d7c8d906fda2200c170d4db2a961d02428/root/etc/s6-overlay/s6-rc.d/secrets/run#L22
Whereas with stuff like $0
, the issue is in the following lines (when using BORG_*
environment variables, but a similar issue seems to exist for *_FILE
variables):
https://github.com/borgmatic-collective/docker-borgmatic/blob/8adec5d7c8d906fda2200c170d4db2a961d02428/root/etc/s6-overlay/s6-rc.d/secrets/run#L58-L59
While the contents of the resulting /etc/s6-overlay/env/cron-env
look correct in the second case (e.g., export BORG_PASSPHRASE="my$0passphrase"
) the double quotes around the value lead to another round of shell expansion for the cron environment - in the example above, this results in a BORG_PASSPHRASE
value of my/runpassphrase
.
I am unsure whether this expansion behavior is on purpose, maybe @Psycho0verload can comment on that - depending on the intended behavior, either code or documentation should be adjusted. My personal take is: the borgmatic image should make no assumptions at all about the passphrase (which requires some very careful handling of the passphrase in shell scripts).
@SECtim It's been a few days now. I suspect that I also had problems with the special characters and that's why I put it in quotation marks.
I've seen that Linuxserver.io also works mainly with S6-overlay, and there are Secrets implemented by default. It's very cleanly written there and I'll test if that's not the better option for borgmatic as well.
I am by no means a shell guru, but I suppose single quotes instead of double ones in the cron-env
file would already solve most of the issues - except of course when the value itself contains single quotes, then these have to be escaped (I am not aware of a ready-to-use POSIX function to do so, but once again, I am not that familiar with shell programming).
No problem, I am currently testing a different type of Secrets integration. The way it is used by linuxserver.io. that could help :)
Just for your information. I am still on vacation. I will start working on this ticket again next week ;-)
I encountered this problem. I spent a lot of time trying to find where I went wrong. Until I found this issue. I rolled back to 1.8.12. Is there any news?
I am current working on this
As of docker-borgmatic 1.8.13, some Borg passphrases that worked fine with 1.8.12 no longer work. For instance:
Which, if cron is actually configured and runs, leads to a Borg error about:
passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect
.Whereas with 1.8.12:
And then if cron is actually configured, the passphrase comes through correctly and there's no error from Borg.
I believe the problem was likely introduced in #331 and specifically in https://github.com/borgmatic-collective/docker-borgmatic/pull/331/files#diff-df5fc4ba71d9f961534c2d65215e50da1befb1f2a16c4a03c58eba442f8c5dc3
It's possible that a backtick is not the only special character broken in this way by 1.8.13.