bormatic 1.9.9 breaks my pass command #987
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I'm just trying to do basic repo listing which fails with
bormatic
version1.9.9
and works with1.9.8
. This looks related to the changes in #961.Steps to reproduce
Actual behavior
Expected behavior
Other notes / implementation ideas
This is my config (without comments):
borgmatic version
1.9.9
borgmatic installation method
Arch Linux packge
Borg version
borg 1.4.0
Python version
Python 3.13.1
Database version (if applicable)
No response
Operating system and version
Arch Linux (rolling)
Thanks for filing this! Are you intending your passphrase to come from
encryption_passphrase
or the command run byencryption_passcommand
? And is that the actual value the passphrase is set to (""
).. or did you redact it? Because borgmatic 1.9.9's behavior, ifencryption_passphrase
is set, is to ignoreencryption_passcommand
and issue a warning about that to the log. This is intended to mimic Borg's native behavior.So if you intend
encryption_passcommand
to be used, then remove or comment outencryption_passphrase
. But if you intendencryption_passphrase
to be used here, then I guess.. do you intend for it to be blank? Because that might be causing borgmatic to interpret it as "not set," which one might consider a bug.Fair point! However even with that part commented out it does not work, this is the new config (with exclude patters stripped) that still fails:
Interesting! Could I see your (redacted) logs for the full run with
--verbosity 2
?I think it's self redacted? If there's still anything sensitive in there please point it out and I'll rotate my creds 😆
Anyways, here are the logs:
borgmatic does redact environment variable values from the logs, but some users are sensitive about hostnames or other info that borgmatic doesn't touch.
Anyway, the good news is I have a local repro of this error!
It's really odd, because when I use a passcommand that calls out to an external password manager (and prompts for a password manager's own passphrase the first time), theBut when I replace it with aborgmatic list
command succeeds.cat
command like you have here, it fails. So that makes me think there's got to be a timing component that's impacting this. If that's the case—and the problem has to do with how I'm passing the passphrase to Borg via a pipe—then I may have to revisit that approach.I'll dig into this when I get a chance and report back. Thanks for your patience!
Ugh, I'm pretty sure I found the problem. What's apparently going on is that the pipe used to send the passphrase to Borg is created once and then consumed by the initial
borg list
call as it should be. But then the pipe is never recreated for the second call—which means Borg can't actually read the passphrase from it. I'll need to think about how to solve this.(FYI I don't think this ever worked for
list
, not even for the password manager case. I was incorrect about that.)Okay, this is fixed in main and will be part of the next release. The solution was indeed to avoiding reusing anonymous pipes that transmit the collected passphrase to Borg.
I also tweaked the passphrase vs. passcommand logic to prefer a passphrase over a passcommand even when the passphrase is an empty value. I think this behavior is probably less surprising given that an empty passphrase is a valid thing with Borg.
Thanks again!
Thanks for coming up with a fix so quickly, that is really appreciated! 🎉
Released in borgmatic 1.9.10!