Dex

Big hearted fluffdragon...

...fictional ex-90s platformer mascot, nerd, plural, Ξ˜Ξ”.


Masto 🐘
scalie.club/@Dex
You must log in to comment.

in reply to @Dex's post:

regarding open source without revealing things, there's a couple options depending on what the issue is.

if you're hosting on github and the secrets are used when publishing or otherwise making changes, you can use github's secrets feature along with github actions, where you can add passwords or api keys or whatever to the repo privately in the settings, and then you can interpolate them into github actions config files with {{ FTP_PASSWORD }} or whatever, so secrets don't get leaked in the configs.

if you need to use secrets elsewhere in your source, you can always just move those secrets into a separate file, reference that file from your public source, and then make sure to add that secrets file to the .gitignore so it doesn't get published. if you want to be extra safe you can even use git hooks or github actions to do checks to make sure you didn't accidentally upload the secrets.

if you already have a repo with secrets in the history, you can either rebase them to remove the secrets from the history (which is complicated and a pain) or just make a new repo for the public site without anything in the history and use that one from then on.

Yeah, there's a few things that got moved to now ignored files - but the file they were originally in isn't ignored. But also things like hardcoding directories before having to think cross platform, before switching to environment variables; stuff that doesn't necessarily compromise security of the site but I'd feel bad having out there - so yeah, I suspect a fresh start would be the only option.