Hi @revolter,
I have mixed feelings about this change. I assume your use case is that you have several database files in subdirectories, and a single .env file applicable to all of them in the parent directory or in the project root. But what happens if we load in memory a .env file which wasn't for us and contains other secrets. I guess nothing very important, besides failing to open the database, but it put us in a risky situation.

At least, I think this behaviour should be opt-in through a setting in the preferences' dialog.

Hi @mgrojo,

I assume your use case is that you have several database files in subdirectories, and a single .env file applicable to all of them in the parent directory or in the project root.

Ish. I have some encrypted databases in an iOS app, and running it in the Simulator places the databases in a deeply nested location under ~/Library, and it also changes on every subsequent run. As such, I want to place the .env file in the root folder to be picked up regardless.

But what happens if we load in memory a .env file which wasn't for us and contains other secrets.

True, good catch!

I now realize that other tools with a similar feature have their own custom naming for these files (they're also configs, not secret holders).

At least, I think this behaviour should be opt-in through a setting in the preferences' dialog.

Makes sense!

But, with the above, what do you think of searching for .db4s.env outside the current folder, and for .env OR .db4s.env? This way, whenever you see a dotenv file with NO database next to it, you know what's it about, we don't risk clashes with other software, and we could deprecate the non-specific file name in the future.

While I understand the use case here as well, I do not think that this is the right approach. Especially with deeply nested file hierarchies, this is some unnecessary overhead, apart from the fact that at some level the permissions might not even be available anymore.

For this use case, it seems like letting the environment load the .env file into environment variables and allowing DB4S to read them (I am not sure whether this might already be supported) seems like the most straightforward approach where each user can choose the preferred way to achieve the loading.

Hi @FriedrichFroebel,

While I understand the use case here as well, I do not think that this is the right approach. Especially with deeply nested file hierarchies, this is some unnecessary overhead, apart from the fact that at some level the permissions might not even be available anymore.

Hmm, true 🤔 What about using @mgrojo's suggestion and add a new user preference for enabling this traversal, which would be turned off by default?

For this use case, it seems like letting the environment load the .env file into environment variables and allowing DB4S to read them (I am not sure whether this might already be supported) seems like the most straightforward approach where each user can choose the preferred way to achieve the loading.

This is not supported at the moment, as we're not actually reading from the environment itself, but we actually manually load the .env file and read from it.

But, even if we did, it wouldn't help with the use case of the user simply double-clicking an encrypted database file, right?

@mgrojo, @FriedrichFroebel, would you please re-review this following the recent changes I (we 😅) made? 🙏🏻

Hmm, true 🤔 What about using @mgrojo's suggestion and add a new user preference for enabling this traversal, which would be turned off by default?
[...]
But, even if we did, it wouldn't help with the use case of the user simply double-clicking an encrypted database file, right?

I guess it depends on the environment how these variables might be passed around, but I agree that double-clicking might not work then. Using a setting can work, yes.

would you please re-review this following the recent changes

I will leave this up to Manuel, as he is much more experienced with the actual code then I am.

@mgrojo, would you some some time to review the latest changes? 🙏🏻

It looks good to me. Merging.

@revolter, would you mind updating https://github.com/sqlitebrowser/sqlitebrowser/wiki/Encrypted-Databases#bypass-the-password-prompt-using-a-dotenv-file with the changes?

It looks good to me. Merging.

Thanks! ❤️

@revolter, would you mind updating Wiki: Encrypted Databases (bypass the password prompt using a dotenv file) with the changes?

Yup yup. I was already planning to, after merging - it's done ✅

Any idea when the next app release will be made?