Support for reading passwords from _FILE suffixed env vars

[miralgj]

Read sensitive values from _FILE suffixed env vars. Request #1868

[acelaya]

Sorry for the long delay before coming back to you, and thanks for the contribution.

I just wanted to let you know that this is on my radar, but there's a lot on my plate at the moment when it comes to Shlink, so I'm trying to keep focused on the planned work.

That said, I read this when it was created, and I have some concerns with the approach (mainly with its complexity, as those bash lines are very hard to understand, even though they do the job).

The only reason I haven't followed up is that I didn't have the time to put some thought on this, so keep it tight.

I will try to get back to this early next year. Hopefully I have been able to publish Shlink 3.7 and shlink-web-client 4.0 by then and can save some mental space to get back to this.

[miralgj]

Hi Alejandro— Thank you for your email. You don’t have to explain the delay (we’re volunteers after all) but I appreciate the information. Whenever you get around to it you can just let me know (or leave a comment in the PR) and I can submit a new or updated PR with a function that is a bit easier to follow.

…

-G.J. Il giorno dom 5 nov 2023 alle 6:18 AM Alejandro Celaya < ***@***.***> ha scritto:

Sorry for the long delay before coming back to you, and thanks for the contribution. I just wanted to let you know that this is on my radar, but there's a lot on my plate at the moment when it comes to Shlink, so I'm trying to keep focused on the planned work. That said, I read this when it was created, and I have some concerns with the approach (mainly with its complexity, as those bash lines are very hard to understand, even though they do the job). The only reason I haven't followed up is that I didn't have the time to put some thought on this, so keep it tight. I will try to get back to this early next year. Hopefully I have been able to publish Shlink 3.7 and shlink-web-client 4.0 by then and can save some mental space to get back to this. — Reply to this email directly, view it on GitHub <#1881 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAPFJIQ4HFNFFTM3L4AD2LYC5YYBAVCNFSM6AAAAAA5AJ3LAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTG4YDONRYHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Natetronn]

I'd love to see this implemented as well!

Although, if I may, I'd like to request more than just DB_PASSWORD and RABBITMQ_PASSWORD. I think there are quite a few other ones that could be added, including more of the DB env vars (user names, ports and hosts, for example) and also some more from the other 3rd party services.

Not sure it matters, or is even helpful or not, since Splink's env vars probably won't carry over, but I thought I'd add some context from the DBs about their env vars. These are the ones that have a _FILE version. Maybe researching into how they are managing their implementations could be insightful:

postgres - Source

MySQL - Source

MariaDB - Source

Note: I didn't see any on MSSQL's DockerHub, but it's possible they exist.

[acelaya]

As I mentioned in my first comment, my main concern with this approach is that it's quite complex to follow.

I'm working on a different approach implemented in PHP, which is easier to read and test.

I appreciate the effort @miralgj. Your implementation has definitely paved the road and simplified next steps.

[acelaya]

This should do the trick #1994. I have just tested it locally and seems to work.

One benefit of that approach is that it supports the _FILE suffix on any existing and future env var.