Dotfiles feel too personal to share(hamatti.org)
hamatti.org
Dotfiles feel too personal to share
https://hamatti.org/posts/dotfiles-feel-too-intimate-and-personal-to-share/
152 comments
Not just the internet but communities too. High trust societies are great to live in, digitally and physically. Leave the doors unlocked, leave keys in the ignition, leave valuables on the table when you walk away.
But high trust societies only work when the price of ongoing admission is not violating that trust.
When you accept/tolerate/expect the violation of trust the doors lock.
But high trust societies only work when the price of ongoing admission is not violating that trust.
When you accept/tolerate/expect the violation of trust the doors lock.
> leave valuables on the table when you walk away
I actually do this somewhat frequently at my local game shop. Thousands of dollars' worth of Magic: The Gathering cards (because I bring multiple decks instead of just the one I'm playing) in my backpack left behind as I go to get some water or something.
> high trust societies only work when the price of ongoing admission is not violating that trust
Indeed, the reason I feel comfortable doing that is I know that nobody wants to be banned from going to that store (and they would be). In this context, the community is small enough that rumors would likely circulate at other local shops and they might also become a bit of a pariah at those other places they could play.
I actually do this somewhat frequently at my local game shop. Thousands of dollars' worth of Magic: The Gathering cards (because I bring multiple decks instead of just the one I'm playing) in my backpack left behind as I go to get some water or something.
> high trust societies only work when the price of ongoing admission is not violating that trust
Indeed, the reason I feel comfortable doing that is I know that nobody wants to be banned from going to that store (and they would be). In this context, the community is small enough that rumors would likely circulate at other local shops and they might also become a bit of a pariah at those other places they could play.
Very true. It also helps that from my experience MTG players are some of the nicest people you’ll meet
... but dude, we're talking about how you configure VI and ... bash. Like... guys. Calm down.
... to follow myself up...
I went ahead and looked in my .vimrc and lo and behold there's a "security issue" in it:
I went ahead and looked in my .vimrc and lo and behold there's a "security issue" in it:
if $USER != 'root' " Modelines let you specify format rules for a file within the file
set modeline modelines=5 " e.g. "// vim: tabstop=20 : shiftwidth=20" (or something actually reasonable)
else " They can be a security vulnerability (unlikely) so we don't enable for root
set nomodeline
endif
> unsure how best to overlap aliases and configs that are sensitive to my workplace
I have a .zshrc that sources .zshrc_mh, .zshrc_$employer, etc. That way my .zshrc is always a shareable config of sane defaults, and weird/opinionated aliases can go in my _mh, stuff particular to my employer goes in the other one, so forth.
In the past I had a more complex loading system I used (and made) that worked out of ~/.zsh.d/, but I no longer bother with all of that.
I have a .zshrc that sources .zshrc_mh, .zshrc_$employer, etc. That way my .zshrc is always a shareable config of sane defaults, and weird/opinionated aliases can go in my _mh, stuff particular to my employer goes in the other one, so forth.
In the past I had a more complex loading system I used (and made) that worked out of ~/.zsh.d/, but I no longer bother with all of that.
Installing a (read: many) custom vim plugins and color scheme and screen version and etc… stops being fun about the third time you have to log into a nameless server. That being said, there are some settings that I absolutely cannot live without; `j=gj` being a good example in vim.
IMO your dot files are only useful to share if they are usable with the default software of the place you’ve shared them to. Otherwise they become a prison that forces you to install all your special versions and plugins and scripts and etc. on the other hand, I felt like making my dotfiles easy to share forced me to use as many default settings as possible, which in the long run saves me a lot of time and energy.
“The only zen you’ll find on a mountain top is the zen you brought with you” is one of my favorite sayings, and in a weird way I find it fitting here. If you learn to love the default settings then every server feels like home.
IMO your dot files are only useful to share if they are usable with the default software of the place you’ve shared them to. Otherwise they become a prison that forces you to install all your special versions and plugins and scripts and etc. on the other hand, I felt like making my dotfiles easy to share forced me to use as many default settings as possible, which in the long run saves me a lot of time and energy.
“The only zen you’ll find on a mountain top is the zen you brought with you” is one of my favorite sayings, and in a weird way I find it fitting here. If you learn to love the default settings then every server feels like home.
I honestly just can't vibe with the "don't customize because you'll log into other servers" thing.
To me it feels like getting told to not put nice shelves in my home because other buildings don't have them.
To me it feels like getting told to not put nice shelves in my home because other buildings don't have them.
It completely depends on your work environment. My experience has been doing a lot of admin work and working with distributed databases. I probably spend a third of my day in servers that are not mine. So for me it just doesn’t make sense to make a lot of configuration changes, especially changes that will end up in my muscle memory.
Now my personal computer does have much nicer color schemes and a few plugins for code dev that I don’t carry around. But even then I try to use the defaults in my IDEs and browsers, because at this point I’m on work computer number.. 11? Configuring it is starting to get old
Now my personal computer does have much nicer color schemes and a few plugins for code dev that I don’t carry around. But even then I try to use the defaults in my IDEs and browsers, because at this point I’m on work computer number.. 11? Configuring it is starting to get old
So you spend two thirds of your day with an arm tied behind your back because one third of your day you will have to use the hand for groping in the dark...
> Configuring it is starting to get old
That's exactly the opposite of my experience. Since all my dotfiles are in Github, configuring new system is just a git clone and copying a few files around. I don't even use any config manager, since I rarely get new computers. Takes a few minutes max per machine (plus maybe package installs like zsh if it's not there already).
That's exactly the opposite of my experience. Since all my dotfiles are in Github, configuring new system is just a git clone and copying a few files around. I don't even use any config manager, since I rarely get new computers. Takes a few minutes max per machine (plus maybe package installs like zsh if it's not there already).
> Takes a few minutes max per machine (plus maybe package installs like zsh if it's not there already).
Assuming you have internet and can access GitHub. Setting up internally accessible repos for that or bake it into an image is its own excercise, which you'd have to setup again for every site and isn't there on day 0.
Even so, "a few minutes per machine" builds up quickly if that happens multiple times per day and new airgapped sites are a regular occurence. That's not including the possibly larger cost of context-switching to "customization mode" for every setup.
I do have a few dotfile customizations I carry around for sites/boxes I bother enough with but at this point they're cut down and familiar enough that it takes me a few seconds to put those in place manually from memory and dist defaults.
Minimal .profile:
VISUAL=vim EDITOR=vim
tmux and some other apps will pick up on this and switch to vi-style keybindings.
I resonate with embracing the Zen of leaning into defaults.
Assuming you have internet and can access GitHub. Setting up internally accessible repos for that or bake it into an image is its own excercise, which you'd have to setup again for every site and isn't there on day 0.
Even so, "a few minutes per machine" builds up quickly if that happens multiple times per day and new airgapped sites are a regular occurence. That's not including the possibly larger cost of context-switching to "customization mode" for every setup.
I do have a few dotfile customizations I carry around for sites/boxes I bother enough with but at this point they're cut down and familiar enough that it takes me a few seconds to put those in place manually from memory and dist defaults.
Minimal .profile:
VISUAL=vim EDITOR=vim
tmux and some other apps will pick up on this and switch to vi-style keybindings.
I resonate with embracing the Zen of leaning into defaults.
Same exp here, a simple clone and setup script sorts all this in a user directory.
The original statement was "vim plugins" SO yeah you can have your fancy alias or whatever but I'm with the GP that adding a bunch of cool plugins that I get used to and then... perpetually can't use because 40% of my time is spent on remote machines I don't have admin on... ehh.. quickly becomes not worth it.
It's like when I tried to get used to a DVORAK keyboard when I'd spend my weekdays in a school computer lab...
It's like when I tried to get used to a DVORAK keyboard when I'd spend my weekdays in a school computer lab...
You don't need admin to install emacs packages..... I'm sure vim isn't dumb enough to require that?!
For me it was that each plugin would have to go through a security approval process and that was not something they appreciated. (e.g. they have "real work" to do), whilst mapping `n` to `nzz` or setting the regexpengine to `0` well, yeah, go for it.
Seems like a great opportunity to learn a bit about automating this set up. Really not hard to upload a .vim directory on a remote server for example.
Nah. Other people need to use them too. You just don't do that kind of stuff managing a fleet of servers. Keep it standard. Automation is yet another thing to manage and maintain. I keep all of my servers completely standard.
> Automation is yet another thing to manage and maintain
But supposedly you already have an automation that you maintain your standard servers with. Adding an Ansible role that puts .vimrc into $HOME surely isn't that much of a maintenance burden?
But supposedly you already have an automation that you maintain your standard servers with. Adding an Ansible role that puts .vimrc into $HOME surely isn't that much of a maintenance burden?
The better place to spend time might be the automation of operational tasks on those servers so that logging in isn’t necessary in the first place. Then you don’t have to leave your home environment and you can run whatever custom editing configuration you want. Of course the other upsides to that automation overshadow this a bit.
I'm of the opinion that if you need to log in to a server you've already failed.
Nobody should be ABLE to log in to servers by default, that's the way they become unicorns and not cattle.
Nobody should be ABLE to log in to servers by default, that's the way they become unicorns and not cattle.
"treve uploaded WHAT on the Big Bank's server?!"
Yeaah, that don't fly unless you're in a really seat-of-your-pants environment. =)
Yeaah, that don't fly unless you're in a really seat-of-your-pants environment. =)
"dammit treve installed hyperland and riced the servers again" - sec team probably
Here you go
# Roaming bashrc profile
function sshrc() {
BASHRC=$(cat ${HOME}/.bashrc_roaming | base64 -w 0)
ssh -t $@ "echo \"${BASHRC}\" | base64 --decode > ~/.bashrc_roaming; \
bash --rcfile ~/.bashrc_roaming; \
rm ~/.bashrc_roaming";
}I was thinking of exactly that. Or maybe, for an extreme version of this, one could create a Docker image with the whole dev environment, start the container at the login, bind mount / of the host somewhere and work from there. Then Ctrl-D and it's gone.
Not exactly but almost
https://containertoolbx.org/
It's also super weird when people say this and then switch to another editor, then switch to something like vscode, which ignores the fact that using a souped-up local Vim and a minimal remote one is the same situation... you're getting a different experience local and remote.
It's bananas!
If the claim these folks make is "time spent struggling through a default config on an unfamiliar machine" > "time saved by crafting an workshop to fit your mind", then we are not the same.
(Probably, the dividing line here is time spent coding vs time spent managing infra.)
If the claim these folks make is "time spent struggling through a default config on an unfamiliar machine" > "time saved by crafting an workshop to fit your mind", then we are not the same.
(Probably, the dividing line here is time spent coding vs time spent managing infra.)
It's another form of perfectionist paralysis and rationalizing doing more non-value-add, error-prone, manual effort.
Also, if you have useful nice shelves that make your fridge aka postgres run better, why shouldn't we work on putting that on servers to make all fridges run better? Also, having a comparable and shared admin experience is a big deal in a team.
Like sure, if you need to quibble about red or yellow prompts, eh. But if there is a good log colorizer or analyzer that makes an expert better at handling the system, or some aliases that make a system easier to manage - I want this deployed for _all_ admins on _all_ relevant systems.
And sure, all code running on a server is a security topic. But then let's figure out a way to run your favorite tools through the software security pipeline and then deploy it to systems. Sure, I dislike installing the latest js-based npm fad on a database for a minor advantage, but if there is some well-aged tool from the postgres space... I'd probably rather work to have it.
Like sure, if you need to quibble about red or yellow prompts, eh. But if there is a good log colorizer or analyzer that makes an expert better at handling the system, or some aliases that make a system easier to manage - I want this deployed for _all_ admins on _all_ relevant systems.
And sure, all code running on a server is a security topic. But then let's figure out a way to run your favorite tools through the software security pipeline and then deploy it to systems. Sure, I dislike installing the latest js-based npm fad on a database for a minor advantage, but if there is some well-aged tool from the postgres space... I'd probably rather work to have it.
> I want this deployed for _all_ admins on _all_ relevant systems.
You're never going to find a config that everybody is happy with. If that were the case, then there would be no need of config at all.
I was rather referring to things like: Aliases to access important log files. Aliases to supply security credentials to important commands. Coloring logs so relevant details are highlighted.
If your biggest problem running a system is the line-next semantic, you're in a much better place than I am. No one on the team has ever raised that.
If your biggest problem running a system is the line-next semantic, you're in a much better place than I am. No one on the team has ever raised that.
it's going to depend on whether you're a software dev or a sre/ops person.
"Free and easy
That's my style
Howdy-do me?
Watch me smile
But fare-the-well me
After a while
'Cause I gotta roam
And any place I hang my hat is home"
That's my style
Howdy-do me?
Watch me smile
But fare-the-well me
After a while
'Cause I gotta roam
And any place I hang my hat is home"
Burma shave
With neovim, you have pretty good profile copy-ability. The app convention is very nice too, for isolation.
Mason is one other core bedrock components of good neovim dx. It's the main library in the neovim galaxy for bringing in lsp servers and debug adapter protocols. It mostly just works, gives great out of box debug-ability. There's like a mini `mise` running, powering the plugins you bring in.
scp -r mydesktop:.config/my_bespoke_neovim $HOME
export NVIM_APPNAME=$HOME/.config/my_bespoke_neovim
Mason is one other core bedrock components of good neovim dx. It's the main library in the neovim galaxy for bringing in lsp servers and debug adapter protocols. It mostly just works, gives great out of box debug-ability. There's like a mini `mise` running, powering the plugins you bring in.
That's why you don't use vim, but Emacs with tramp.
Emacs is a great OS, infinitely extensible. The only thing it's missing is a decent text editor.
If they don't know, they can't be sad about what they're missing. You're just sticking fingers in the wound.
Anybody who would like a decent text editor around vim key-bindings uses Emacs in evil-mode already.
Anybody who would like a decent text editor around vim key-bindings uses Emacs in evil-mode already.
Nano.
This is the main reason that, even though I know I'd enjoy zsh, I stubbornly stick with bash. It's because I know that I will be extra frustrated when I have to log into any of the number of machines that I have to do real work on that don't have it already set up.
That’s like saying: “This is the main reason that, even though I know I’d enjoy a nice car, I stubbornly stick with a run-down PT Cruiser without radio and air conditioning. It’s because I know that I will be extra frustrated when I have to take an Uber.”
I personally use zsh and do not want to miss it on my own machines. I however do log in onto machines that sometimes do not even have bash (yeah it’s rare nowadays, but it exists), and I adapt just fine. It’s not super pleasant, but not using zsh on my machines would be less pleasant.
I personally use zsh and do not want to miss it on my own machines. I however do log in onto machines that sometimes do not even have bash (yeah it’s rare nowadays, but it exists), and I adapt just fine. It’s not super pleasant, but not using zsh on my machines would be less pleasant.
[deleted]
Try fish. It has good defaults and don't require any configuration. I install it on every server I log into as my first instinct
I have some variant of this where I mostly refuse to use shell aliases, since I come from a time when you might be remoted somewhere and not have your shell available and I want the muscle memory in the middle of a fire. People look at me like I'm crazy for typing the longer commands out.
I thought the appeal of vi was it can mostly be used "as is" vs emacs being infinitely customizable? The folks I know who use vi do so because they are at their core, sysadmins, and something simple and consistent is valued.
Vim and Neovim are pretty close to being infinitely customizable, but vi is a different story. Likewise, Emacs can be used as is. If anything, the difference was in the core audience. A sysadmin is more hesitant about customizing their tools because they tend to deal with many different systems. It's also the main reason why they use vi (Vim and Neovim are simply substitutes), because it is always available. Emacs tended to attract people who customized their tools.
These days, things are a bit different. Vim and Neovim are more easily customized, and have gained a following because it is more finger friendly (even if it is harder to learn).
These days, things are a bit different. Vim and Neovim are more easily customized, and have gained a following because it is more finger friendly (even if it is harder to learn).
Interesting. Are vim on the CLI and Vim the gui program two separate things? (I actually used "MacVim" on MacOS for basic note taking in class since I could alt tab to it, but tended to do any script writing in vim on the cli.)
Anyways, my only customizations are usually to turn on line numbers and syntax highlighting... I also have sublime, but sometimes I find writing a script it can be helpful to just use a very simple editor, write out some psudocode with comments, then slowly build it out... it's easy to get distracted in a full blown IDE. (And I'd argue emacs or vim when heavily customized effectively become an IDE)
Anyways, my only customizations are usually to turn on line numbers and syntax highlighting... I also have sublime, but sometimes I find writing a script it can be helpful to just use a very simple editor, write out some psudocode with comments, then slowly build it out... it's easy to get distracted in a full blown IDE. (And I'd argue emacs or vim when heavily customized effectively become an IDE)
I hardly ever use gvim. From my understanding, there are a few relatively minor GUI specific settings for the GUI version. Contrast that to emacs. It's possible to present documents with multiple fonts and images in the graphical version. (The irony: vim and gvim are separate binaries, which emacs can have a unified CLI/GUI binary.)
I agree that heavily customized, emacs and vim can be an IDE and that it can be distracting. It is possible to pick and choose the desirable (e.g. non-distracting) elements of an IDE when configuring either editor, but that in itself turns into a distraction.
I agree that heavily customized, emacs and vim can be an IDE and that it can be distracting. It is possible to pick and choose the desirable (e.g. non-distracting) elements of an IDE when configuring either editor, but that in itself turns into a distraction.
dotfiles are pretty easy to move to a new server, no?
no. simple but complicated.
does the same .bash_profile/.bashrc work on different linux versions? what about macos? and now macos no longer uses bash. And what about saving .bash_history? and on and on.
there is a whole industry of shell scripts that try to help with this.
does the same .bash_profile/.bashrc work on different linux versions? what about macos? and now macos no longer uses bash. And what about saving .bash_history? and on and on.
there is a whole industry of shell scripts that try to help with this.
[deleted]
> does the same .bash_profile/.bashrc work on different linux versions?
If we weight versions by likelihood of interacting with them, yes, they do.
> what about macos?
I handle macOS as a special case; it is not too difficult. Mostly, macOS boils down to "Get brew, download the GNU tools with brew, alias the commands to the GNU set", mostly because macOS's builtin tools are crap. The real problem is macOS, not the dotfiles, but many employers (including my own) force one to use macOS. It just not as big a special case as you're thinking.
> and now macos no longer uses bash.
… Apple hasn't updated bash in eons. Yeah, the default is now zsh, but I really hope one isn't just bumming along with bash 3.
And it's also reasonably easier to just use zsh everywhere. zsh is basically objectively superior.
> And what about saving .bash_history? and on and on.
Eh, I learn to love the bomb there.
> there is a whole industry of shell scripts that try to help with this.
There's definitely not.
If we weight versions by likelihood of interacting with them, yes, they do.
> what about macos?
I handle macOS as a special case; it is not too difficult. Mostly, macOS boils down to "Get brew, download the GNU tools with brew, alias the commands to the GNU set", mostly because macOS's builtin tools are crap. The real problem is macOS, not the dotfiles, but many employers (including my own) force one to use macOS. It just not as big a special case as you're thinking.
> and now macos no longer uses bash.
… Apple hasn't updated bash in eons. Yeah, the default is now zsh, but I really hope one isn't just bumming along with bash 3.
And it's also reasonably easier to just use zsh everywhere. zsh is basically objectively superior.
> And what about saving .bash_history? and on and on.
Eh, I learn to love the bomb there.
> there is a whole industry of shell scripts that try to help with this.
There's definitely not.
yeah, I think i'm with you, zsh and a moderately customized profile is more than enough.
It's not a question of share everything or share nothing - with https://chezmoi.io you can choose exactly what you want to share:
* You can keep your entire dotfile repo secret by using any private git hosting, including your own git hosting or a private GitHub repo.
* You can keep individual files secret by using age or gpg encryption. If you repo is public, this only reveals the existence of the file, not its contents.
* You can keep individual parts of your dotfiles secrets, e.g. API keys, by encrypting them or storing them in your password manager. All popular password managers are supported.
Disclaimer: I'm the author of chezmoi.
* You can keep your entire dotfile repo secret by using any private git hosting, including your own git hosting or a private GitHub repo.
* You can keep individual files secret by using age or gpg encryption. If you repo is public, this only reveals the existence of the file, not its contents.
* You can keep individual parts of your dotfiles secrets, e.g. API keys, by encrypting them or storing them in your password manager. All popular password managers are supported.
Disclaimer: I'm the author of chezmoi.
Chezmoi has been a blessing to use. It is one of the only tools I've used that had been able to survive me neclecting it for months and then getting back to it. I'd love a more interactive diff when my dotfiles have driften too much. But otherwise it is perfect for my needs.
https://www.chezmoi.io/reference/commands/merge-all/ might help you here - it opens your preferred merge tool for the dotfiles that have drifted.
Meta had an internal tool called "dotsync". It persisted multiple revisions of dotfiles across multiple machines associated with a particular user's account. It supported ignoring history and secret files by patterns. This is a superset of simply storing all dotfiles in a single git repo. This unmaintained project seems suspiciously similar including the name: https://dotsync.org
I used chezmoi briefly yeeeeeears ago, and I think it didn't have the 'encrypt only parts of the files' feature yet. I might test it again :)
I feel similarly. For me it’s less about my unique customizations and more about this paranoia of there being something remotely sensitive in my ssh configs or something… the idea of hostnames, ips, domains, etc “leaking” worries me.
I use chezmoi to manage my dotfiles, if anyone has any advice on how to handle these worries I am all ears. I would love to share mine, even to just be able to point coworkers at my config.
I use chezmoi to manage my dotfiles, if anyone has any advice on how to handle these worries I am all ears. I would love to share mine, even to just be able to point coworkers at my config.
I get around that by sourcing a separate file in my config that I don't make public. Those are my company-specific settings.
chezmoi includes secret scanning from https://gitleaks.io/ by default to catch when you accidentally add a file with a secret in it. To be even more confident, you should add gitleaks as a git hook to your repo however.
How do you automatically set up the hooks, e.g. when you clone the repo on a new computer?
Also, is there a way to automatically edit a chezmoi managed file in the chezmoi directory? I accidentally type stuff like "nvim .bashrc" way too often and then forget I never added the changes to chezmoi. It would be neat if there was a vim plugin or something that just opened the chezmoi file instead if it's managed.
Also, is there a way to automatically edit a chezmoi managed file in the chezmoi directory? I accidentally type stuff like "nvim .bashrc" way too often and then forget I never added the changes to chezmoi. It would be neat if there was a vim plugin or something that just opened the chezmoi file instead if it's managed.
Please can you open an issue or discussion for these questions on https://github.com/twpayne/chezmoi - this way more people will both be able to help and more people will see the answer.
I will do that. I apologize for raising it here in the first place and thank you for creating and maintaining a great piece of software!
In chezmoi you can use gpg encryption: https://www.chezmoi.io/user-guide/encryption/
Too personal to share, but maybe too personal and important to share even with the members of the cloudy cartel, i.e. the Providers. Is exactly why I wrote myba that does full contents and paths encryption before syncing with the lapsable remotes ...
https://kernc.github.io/myba/
Some things are better public. Some are not ...
https://kernc.github.io/myba/
Some things are better public. Some are not ...
That looks nice!
The moment I started syncing dotfiles between my work and personal computers, I know it was an error because very different reasons. Difficulty of maintaining different OS details (Linux vs MacOS). What if leaked a private key or a sensible path. What if a pushed to the wrong place or somebody made public the wrong repository...
When reading your comment something and idea came to mind about using something like sops to encrypt paths, passwords and keys. But I'll check yours first, so to avoid to construct a bunch of stuff that you've already done :D
The moment I started syncing dotfiles between my work and personal computers, I know it was an error because very different reasons. Difficulty of maintaining different OS details (Linux vs MacOS). What if leaked a private key or a sensible path. What if a pushed to the wrong place or somebody made public the wrong repository...
When reading your comment something and idea came to mind about using something like sops to encrypt paths, passwords and keys. But I'll check yours first, so to avoid to construct a bunch of stuff that you've already done :D
I am trying to contextualize git-based dotfiles.
yes, complicated, probably hard to comprehend/reason about, work in progress
$ context set universe://work/customer-a/devops --update-dotfiles
$ context set unvierse://work/customer-b --update-dotfiles
$ canvas dot apply [email protected]:workspace-foo
$ canvas dot apply [email protected]:workspace-bar/shell/bashrc
yes, complicated, probably hard to comprehend/reason about, work in progress
I can no longer edit my original dot manager comment so to add some context: I developed an allergy for the term "vibe-coding" (and made a joke on the selection of OPs words), AI won't turn a lazy unskilled inexperienced person into John Carmack, lazy person + AI still equals to a lazy person. With that being said, most of you may have already experienced a divide between the above empirical truth and management decisions across your favorite corporate environments. So, the race is on, AGI-level agentic frameworks may be here soon enough to mitigate the above, then again, in the end isnt the enduser of most of our economic production directly or indirectly a human? Can a synthetic immortal system really cater for human needs? There is a reason why big deals are always negotiated in-person
this reminds me of public repos of pass [1] i've seen in the wild
same issue of intimacy, the paths aren't encrypted.
[1] https://www.passwordstore.org/
same issue of intimacy, the paths aren't encrypted.
[1] https://www.passwordstore.org/
I think the key is that dotfiles are a different genre of (code) writing than production code, with different investment, different motivations, different pain points and histories, and a sensitivity to the author that's not required when analyzing production code. You're looking into someone's daily writings, not their polished releases.
I think the fear is scrutiny, rejection, mockery for something that clearly works for you and you don't ever expect anyone else to use. But also partly that it's exposure without much reward in return. All these feelings are normal and it's fine to share or not share them. Just please honour the authors of the dotfiles you read even if you wouldn't ever think to use code in the way they do!
I think the fear is scrutiny, rejection, mockery for something that clearly works for you and you don't ever expect anyone else to use. But also partly that it's exposure without much reward in return. All these feelings are normal and it's fine to share or not share them. Just please honour the authors of the dotfiles you read even if you wouldn't ever think to use code in the way they do!
I'm sure I have stupid and weird stuff in my dotfiles. At one point I had bash set up so if I typed something like "gi tlog" it would fix it for me; this is obviously not something that everybody needs because it's due to my idiosyncratic typing-too-fast.
I've been using Unix systems since last century; my standard way to do a find-and-replace in a file is still 'perl -pi -e s/foo/bar/ filename.txt'; I've been writing that for 25 years and I'm unlike to stop any time soon unless perl stops working. I'm sure there's a better way to do this, but :shrug:?
I've been using Unix systems since last century; my standard way to do a find-and-replace in a file is still 'perl -pi -e s/foo/bar/ filename.txt'; I've been writing that for 25 years and I'm unlike to stop any time soon unless perl stops working. I'm sure there's a better way to do this, but :shrug:?
I truly appreciate people sharing their dotfiles, I learned so much about vim and zsh just by reading other people's configuration alone (and the occasional comments there).
Also, the quality of life improvements like `alias ..='cd ..'`, or mapping `l` such that it either opens a pager or lists a dir, depending on the argument. I'd never come up with those, and they're beyond useful.
Also, the quality of life improvements like `alias ..='cd ..'`, or mapping `l` such that it either opens a pager or lists a dir, depending on the argument. I'd never come up with those, and they're beyond useful.
My dots are open to anyone who cares to view my GitHub. I do tend to keep employer specific aliases/stuff in an `.employer.zsh` file that is sourced by my main `.zshrc`. But my NeoVim config is completely open for inspection. I'm not doing anything all that extraordinary though. I don't share my dots on Reddit simply because I don't feel like using my real identity on that platform.
When it comes to consuming the dots of others, I just switched to AxOS for Linux... and am auditioning Celestia (https://github.com/caelestia-dots/shell). This means that in 3 months, my desktop will likely look like everyone else's. I probably won't even commit any of this as it's not really my stuff.
When it comes to consuming the dots of others, I just switched to AxOS for Linux... and am auditioning Celestia (https://github.com/caelestia-dots/shell). This means that in 3 months, my desktop will likely look like everyone else's. I probably won't even commit any of this as it's not really my stuff.
Similarly, I have two sets of dotfiles, a public one and a private one (hosted on my own server).
Somehow, 11 people have starred my public ones on GitHub.
Somehow, 11 people have starred my public ones on GitHub.
Thanks for the reference, that looks incredible.
That actually looks pretty cool. Might have to play around a bit with Caelestia as well.
I used to use chezmoi and had a great experience with it .It made it easy to choose exactly what I wanted to share. These days, I don’t have many devices, so I stopped using it. Still, it feels great when someone asks, “How did you set that up?” and I can instantly share my entire configuration through a GitHub repo.
I found the syncing process in chezmoi to be so hard to mentally model.
I’d often change a file, forget that it was backed by the chezmoi store, later find myself trying to reconcile the differences, just so I could commit and share w/ another computer. nix + home-manager and snowfall lib, once over the multi month ramp up, have been such a breath of fresh air in multi system management
I’d often change a file, forget that it was backed by the chezmoi store, later find myself trying to reconcile the differences, just so I could commit and share w/ another computer. nix + home-manager and snowfall lib, once over the multi month ramp up, have been such a breath of fresh air in multi system management
I ended up writing some pretty hacky elisp to automatically load my chezmoi templates if I try to edit a Chezmoi-managed file. It'll also handle applying and pushing saved changes to my git remote so I don't forget that either.
https://marcusb.org/posts/2025/01/frictionless-dotfile-manag...
https://marcusb.org/posts/2025/01/frictionless-dotfile-manag...
This command solve the problem for me: https://www.chezmoi.io/reference/commands/merge-all/
You just have to put some effort into separating your dotfiles into a generic layer and a customization layer. Done something like this with my dotfiles repo, which now triples as a generic archlinux customisation tutorial with hyprland and a description of the backup strategy that is tightly coupled with the configuration layout: https://github.com/gchamon/archlinux-system-config
Professional security researcher here.
I would strongly discourage threat modeling with vibes.
Your post already reveals potentially the scariest things someone might learn if you published your dotfiles: that you use Homebrew, pip, etc as part of them. In doing so you are telling everyone you allow any internet rando to have remote code execution rights on your computer. To me that is like boldly saying you like privacy in the same breath as saying you never lock your front door or close your drapes.
Those package managers operate like Wikipedia where anyone can push whatever they want without signatures or vetting from poorly secured accounts without phishing-resistant 2FA etc.
At that point you already allow anyone capable of creating a few useful PRs to Homebrew, basic phishing, or sim swapping the ability to see and publish anything on your computer, so your dotfiles being public should be the least of your concerns.
Now you are probably thinking "There is no way tools that every smart person I know uses could be that wildly insecure"
Ask yourself if those same people have experience exposing and exploiting supply chain attacks. We all have blind spots, and almost everyone has a massive blind spot here and my team and I have exploited it many times in audits.
All said though, I personally publish my dotfiles because I am confident they are of more use to me and others public, and do not reveal anything useful to someone targeting me other than that I use some kind of Linux distro and neovim.
Any sensitive work I do is in offline stateless virtual machines deterministically built from a supply chain with high accountability and I do not use any dotfiles in those environments.
With good separation of concerns between yolo systems and hardened trusted systems, publishing information about either is perfectly fine. Almost no one has that kind of workflow separation though, usually accessing prod from their compromised dev macbooks.
I would strongly discourage threat modeling with vibes.
Your post already reveals potentially the scariest things someone might learn if you published your dotfiles: that you use Homebrew, pip, etc as part of them. In doing so you are telling everyone you allow any internet rando to have remote code execution rights on your computer. To me that is like boldly saying you like privacy in the same breath as saying you never lock your front door or close your drapes.
Those package managers operate like Wikipedia where anyone can push whatever they want without signatures or vetting from poorly secured accounts without phishing-resistant 2FA etc.
At that point you already allow anyone capable of creating a few useful PRs to Homebrew, basic phishing, or sim swapping the ability to see and publish anything on your computer, so your dotfiles being public should be the least of your concerns.
Now you are probably thinking "There is no way tools that every smart person I know uses could be that wildly insecure"
Ask yourself if those same people have experience exposing and exploiting supply chain attacks. We all have blind spots, and almost everyone has a massive blind spot here and my team and I have exploited it many times in audits.
All said though, I personally publish my dotfiles because I am confident they are of more use to me and others public, and do not reveal anything useful to someone targeting me other than that I use some kind of Linux distro and neovim.
Any sensitive work I do is in offline stateless virtual machines deterministically built from a supply chain with high accountability and I do not use any dotfiles in those environments.
With good separation of concerns between yolo systems and hardened trusted systems, publishing information about either is perfectly fine. Almost no one has that kind of workflow separation though, usually accessing prod from their compromised dev macbooks.
This is extremely alarmist. If you are on Mac, developing anything at all with Python, those are going to be your tools. If you randomly guessed at developer setups, that is going to be one of the most common setups as well.
What's next, I use a computer so someone could just upload a virus somewhere in hopes I happen upon it, which would be dangerous?
I have dotfiles which not only specify Python, but also its version and some packages. That protects against typosquatting! I will never type those package names out manually again. And this is all in Nix (btw), so all hash-pinned!
What's next, I use a computer so someone could just upload a virus somewhere in hopes I happen upon it, which would be dangerous?
I have dotfiles which not only specify Python, but also its version and some packages. That protects against typosquatting! I will never type those package names out manually again. And this is all in Nix (btw), so all hash-pinned!
It is absolutely not alarmist. Seriously, go apply to be a Homebrew developer right now under an alias, make some useful updates for a few months, then submit a PR as another alias, and approve and merge your own changes from the first alias. After you get away with skipping code review a few times, now go switch a popular package that relies on abandoned sources to point to your fork that makes a few legitimate updates.
Now in a few months make an update that compromises the random number generator on every brew users laptop making it easy to covertly intercept and manipulate the traffic of any target however you want. Maybe for less chance of getting caught, target sysadmins or release engineers by targeting a niche tool many of them use and wait until they publish new ssh keys to github (which are always public!), that you can re-generate the private keys of since you know about their compromised entropy. Check for public dotfiles of your targets to pick the right niche tool. Now go collect database dumps or crypto from a pile of major companies. Easy money if you do not have ethics.
Seen these attacks in the wild many times, some at close range. A bored teenager could do this, and in fact attacks like this happen every day. And everyone just says pointing it out is "alarmist". People used to defend lead paint and asbestos too. Survivors bias is a hell of a drug.
I have done supply chain attacks along the lines of the above myself to prove the risk is very much real to my clients. It is expensive to fix so wanting the risk to be overstated is understandable, but it is actually super easy. Sometimes you can even get away with buying the expired email domain of a inactive maintainer so you can easily just take over their identity. Done this twice and I am no state actor.
Nix, by the way, is hash pinned, but you just blindly update those hashes when there are updates, right? Their code submission process is as yolo as Homebrew. Any rando can push whatever they want without multi-party code signing. I am the one that submitted the RFC to nix to fix this which was rejected as in the end they admitted they want a hobby distro and do not want the overhead and rigor needed for professional targeted environments.
This is why I was forced to abandon nix and get all my clients to abandon it, in favor of StageX which even as the founder I have no control of. It mandates deterministic builds and cryptographic signing by at least two well known keys of maintainers.
We do not point out risks unless there are solutions to mitigate them.
Now in a few months make an update that compromises the random number generator on every brew users laptop making it easy to covertly intercept and manipulate the traffic of any target however you want. Maybe for less chance of getting caught, target sysadmins or release engineers by targeting a niche tool many of them use and wait until they publish new ssh keys to github (which are always public!), that you can re-generate the private keys of since you know about their compromised entropy. Check for public dotfiles of your targets to pick the right niche tool. Now go collect database dumps or crypto from a pile of major companies. Easy money if you do not have ethics.
Seen these attacks in the wild many times, some at close range. A bored teenager could do this, and in fact attacks like this happen every day. And everyone just says pointing it out is "alarmist". People used to defend lead paint and asbestos too. Survivors bias is a hell of a drug.
I have done supply chain attacks along the lines of the above myself to prove the risk is very much real to my clients. It is expensive to fix so wanting the risk to be overstated is understandable, but it is actually super easy. Sometimes you can even get away with buying the expired email domain of a inactive maintainer so you can easily just take over their identity. Done this twice and I am no state actor.
Nix, by the way, is hash pinned, but you just blindly update those hashes when there are updates, right? Their code submission process is as yolo as Homebrew. Any rando can push whatever they want without multi-party code signing. I am the one that submitted the RFC to nix to fix this which was rejected as in the end they admitted they want a hobby distro and do not want the overhead and rigor needed for professional targeted environments.
This is why I was forced to abandon nix and get all my clients to abandon it, in favor of StageX which even as the founder I have no control of. It mandates deterministic builds and cryptographic signing by at least two well known keys of maintainers.
We do not point out risks unless there are solutions to mitigate them.
> Seen these attacks in the wild many times, some at close range.
Not skeptical, just curious - do you have like a list of publicly reported incidents out there that we can read to ourselves during bedtime and maybe scare ourselves into changing our habits?
Not skeptical, just curious - do you have like a list of publicly reported incidents out there that we can read to ourselves during bedtime and maybe scare ourselves into changing our habits?
See my other comment here: https://news.ycombinator.com/item?id=44816971
Could you clarify what you mean by 'attacks like this happen every day' please?
Here are just a few old well known examples in popular package managers:
* Gentoo: https://archives.gentoo.org/gentoo-announce/message/dc23d48d...
* Debian: https://lists.debian.org/debian-devel-announce/2006/07/msg00...
* NPM: https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...
* PyPi: https://www.reddit.com/r/Python/comments/8hvzja/backdoor_in_...
* Ubuntu Snap: https://github.com/canonical-websites/snapcraft.io/issues/65...
* Arch Linux AUR: https://lists.archlinux.org/pipermail/aur-general/2018-July/...
* Homebrew: https://medium.com/@vesirin/how-i-gained-commit-access-to-ho...
No one has fixed the fundamental problems that allow any of these to happen after years and years.
Now put "supply chain attack" into any news search engine today.
Attacks of this nature are up by 400-1500%+ in recent years depending on whose estimates you trust. They are easy, they are common, they are everywhere... and most security engineers and sysadmins are entirely asleep on the wheel on this one.
Most of our consulting work these days is mitigating these risks in the most critical deployment and code paths of our clients.
* Gentoo: https://archives.gentoo.org/gentoo-announce/message/dc23d48d...
* Debian: https://lists.debian.org/debian-devel-announce/2006/07/msg00...
* NPM: https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...
* PyPi: https://www.reddit.com/r/Python/comments/8hvzja/backdoor_in_...
* Ubuntu Snap: https://github.com/canonical-websites/snapcraft.io/issues/65...
* Arch Linux AUR: https://lists.archlinux.org/pipermail/aur-general/2018-July/...
* Homebrew: https://medium.com/@vesirin/how-i-gained-commit-access-to-ho...
No one has fixed the fundamental problems that allow any of these to happen after years and years.
Now put "supply chain attack" into any news search engine today.
Attacks of this nature are up by 400-1500%+ in recent years depending on whose estimates you trust. They are easy, they are common, they are everywhere... and most security engineers and sysadmins are entirely asleep on the wheel on this one.
Most of our consulting work these days is mitigating these risks in the most critical deployment and code paths of our clients.
Thank you, I was not aware of all of these, and I don't doubt the seriousness of the issue.
That said: 'every day' does seem quite hyperbolic.
That said: 'every day' does seem quite hyperbolic.
There are several thousand expired email domains of maintainers right now on NPM alone, allowing you to easily take over their accounts if you wanted, arguably legally, for maybe $10. I bought the domain name of the sole maintainer of the NPM package "foreach", gaining control of their email address and likely password reset capabilities, just to prove this point and troll the press a bit, which worked better than I could have ever hoped. And yet, still not -enough- press because almost no one is doing anything about it yet.
With easily over a million published open source packages that exist, and it being -so- easy to take them over since almost no one uses hardware code signing or 2FA, and with well above 365 documented/discovered cases every year, (obviously not counting all the ones that are -not- discovered!) "every day" is a given.
If anything with LLM based pull request attacks spiking right now, I assume several malicious commits will be merged today. Most will look like accidents, hard to spot, and merged helpfully by bots that automatically merge commits to major distros. The floodgates are wide open.
"Sonatype logged over 245,032 malicious packages in open source projects available to public download in 2023, double the number seen from 2019 to 2022. In total, one in eight open source downloads poses a risk."
https://www.cpomagazine.com/cyber-security/open-source-softw...
With easily over a million published open source packages that exist, and it being -so- easy to take them over since almost no one uses hardware code signing or 2FA, and with well above 365 documented/discovered cases every year, (obviously not counting all the ones that are -not- discovered!) "every day" is a given.
If anything with LLM based pull request attacks spiking right now, I assume several malicious commits will be merged today. Most will look like accidents, hard to spot, and merged helpfully by bots that automatically merge commits to major distros. The floodgates are wide open.
"Sonatype logged over 245,032 malicious packages in open source projects available to public download in 2023, double the number seen from 2019 to 2022. In total, one in eight open source downloads poses a risk."
https://www.cpomagazine.com/cyber-security/open-source-softw...
I feel similarly. There is virtually zero chance I’m going to clone and run someone else’s dotfiles. So the act of sharing them is a generous look into a developer’s toolchain and I’ve been inspired by others’ choices. So, if you know how, please share them!
I've never straight up cloned them, but my dotfiles have grown in large part out of some copy-and-pastes from other people's.
I feel similarly. For me I know it is because of my rejection sensitive dysphoria. The fear of someone seeing and judging something personal of mine is quite uncomfortable. I don't have the same issue with code I write professionally.
> I don't have the same issue with code I write professionally.
Why not?
Why not?
It is less personal. I am writing code in the same style as the rest of the code base. Its more focused on correctness than my preferences. If someone critiques code in a PR I don't take it personally as it is usually in good faith.
Code I write professionally is polished before I send it for review. Code/dotfiles I write for myself are full of all kinds of heinous hacks.
My dotfiles are public [0], but getting there was work. I went through everyhing to make sure I don't accidentally leak something, all secrets are managed separately, you don't accidentally distribute something violating its licence, etc.
I also feel the need to write docs for some things, that I never would if they were private (I haven't actually done that, I just feel that I should).
I get everyone who wants to keep them private, but I'm also thankful for everyone who made them public so others can learn from them.
[0] github.com/Cu3PO42/gleaming-glacier/tree/next
I also feel the need to write docs for some things, that I never would if they were private (I haven't actually done that, I just feel that I should).
I get everyone who wants to keep them private, but I'm also thankful for everyone who made them public so others can learn from them.
[0] github.com/Cu3PO42/gleaming-glacier/tree/next
I've been keeping my personal .dotfiles publically for the past decade. https://github.com/cmcdragonkai/.dotfiles-nixos.
But I do agree that secrets need to be handled carefully. Look at my list of `.gitignore`! But (I'm biased of course) I would recommend using Polykey to manage your secrets instead leaving any trace of things on disk.
But I do agree that secrets need to be handled carefully. Look at my list of `.gitignore`! But (I'm biased of course) I would recommend using Polykey to manage your secrets instead leaving any trace of things on disk.
I have two sets of dotfiles - public and private. I don't mind sharing my public ones - what do I care if someone on the internet thinks my tmux setup is non-optimal? But there are some things I do keep private, though they probably don't qualify as dotfiles, exactly - RSS subscription backups, some backup scripts that reveal filepaths I'd rather not have revealed, old outdated things like my znc, irssi, etc. configs...
My dotfiles have a massive .gitignore in them for all the things I don't want to share, or can't easily divide into shareable and non-shareable. The largest section in my .gitignore is:
- backup copies of documents (which should go elsewhere)
- copies of icons from the icon theme (which should go elsewhere)
- log files (which should go elsewhere)
- piles of binary pack files, probably containing a mix of things
- configuration in XML form (potentially useful to version), but with embedded lists of recently opened files (private, should go elsewhere), including base64-encoded thumbnails.
# Some transient, some configuration files, but configuration files get written
# out every time, and not just the changed values. Some also contain
# machine-specific configuration, and private data.
- backup copies of documents (which should go elsewhere)
- copies of icons from the icon theme (which should go elsewhere)
- log files (which should go elsewhere)
- piles of binary pack files, probably containing a mix of things
- configuration in XML form (potentially useful to version), but with embedded lists of recently opened files (private, should go elsewhere), including base64-encoded thumbnails.
"...whenever 'a software' doesn't...." Ugh. "A software package" or "a piece of software" or perhaps "a program" but you don't have "one software" any more than you can have "one hardware" or "one information." Grammar, please!
I get this feeling.
I have a setup with my Emacs configuration that uses a file that is meant to live locally only, since I feel the contents of it feel too personal to share. (These are mainly Org-mode settings for specific file names and directories).
https://github.com/cyrialize/.emacs.d/blob/main/private-temp...
I have a setup with my Emacs configuration that uses a file that is meant to live locally only, since I feel the contents of it feel too personal to share. (These are mainly Org-mode settings for specific file names and directories).
https://github.com/cyrialize/.emacs.d/blob/main/private-temp...
I keep my DotFiles on my GitHub not without its embarrassments, this will help me backup and restore my tools and workflows on systems anywhere I want it to.
https://github.com/guilt/DotFiles
There's no knowledge shared here, just my own setup which can be barebones git cloned. Planning to add a curlbash installer here to help me set it up with a oneliner.
https://github.com/guilt/DotFiles
There's no knowledge shared here, just my own setup which can be barebones git cloned. Planning to add a curlbash installer here to help me set it up with a oneliner.
That's something I was a little bit conflicted about for some time. After using a few open source tools(shoutout to syncthing and linkding :)) and I realised that if you want to use something for free, sharing is the least you can do.
My dotfiles are private for now cause I need to clean some commits(I think I might have added some private info before) but I intend to publish them eventually
My dotfiles are private for now cause I need to clean some commits(I think I might have added some private info before) but I intend to publish them eventually
> My dotfiles are private for now cause I need to clean some commits
I had to do similar. I ended up deleting the git history and just recreating it before pushing. The best thing was to add a dependency on `~/.secrets` or other similar un-tracked file, which is basically just a source-able script that defines things like API keys, private URLs, etc.
I had to do similar. I ended up deleting the git history and just recreating it before pushing. The best thing was to add a dependency on `~/.secrets` or other similar un-tracked file, which is basically just a source-able script that defines things like API keys, private URLs, etc.
I thought about recreating the repo from scratch too. I was transfering from Intel to ARM Mac and keep a few tags/commits related to previous configs, so it is hard to just let it go :)
I actually resonate with this as well, but similarly can't really explain why. I have my own set of dotfiles (one set for my 'home setup' and one set for my 'work setup').
They are versioned and stored on GitHub, and are actually relatively static at this point. And even though it's pretty standard stuff, I wouldn't feel comfortable sharing them publicly. Odd.
They are versioned and stored on GitHub, and are actually relatively static at this point. And even though it's pretty standard stuff, I wouldn't feel comfortable sharing them publicly. Odd.
I have like 7500 stars on my dotfiles over the last 15 years or so; it's definitely weird. It's kind of a different open source project entirely; the goal isn't really to make good software... it's to make good software for me. Most of the time in open source those overlap completely, but with dotfiles I'll get pulls that make sense, that can be helpful, but... at the end of the day they're my dotfiles and I don't really make large changes to them anymore. It's just a lot different from my other projects I manage.
That said, mine also started before things like Oh My Zsh popped up, which are better frameworks to share and collaborate on these things. I think frameworks like that are great, and I think seeing someone's more "intimate" dotfiles is helpful, too- you get a look at how someone sets up their environment, which tends to be private unless you're doing a lot of pair programming. So yeah, just interesting all around.
That said, mine also started before things like Oh My Zsh popped up, which are better frameworks to share and collaborate on these things. I think frameworks like that are great, and I think seeing someone's more "intimate" dotfiles is helpful, too- you get a look at how someone sets up their environment, which tends to be private unless you're doing a lot of pair programming. So yeah, just interesting all around.
I would like to say an enormous thank you to Dave, who after a huge amount of pestering (and probably to try to save himself from further pestering) shared his .emacs filetree with me and told me to learn Lisp.
Be generous with your dotfiles, and especially with the young and curious engineers who ask lots of questions about your setup. Pay it forward.
Be generous with your dotfiles, and especially with the young and curious engineers who ask lots of questions about your setup. Pay it forward.
It takes a lot of discipline to keep secretes out of dotfiles. You should do that anyway, even if you have a private dotfile repo. Even if they aren't secrets per se - they can still be useful for social engineering. I don't understand why people think their configs are so special it is worth the risk.
I was close to upload my full dotfile dir to github, telling myself it would be handy when I switch computers..
Then I realized that some of those config files reflected a lot about my systems and personal preferences... and it was only going to be ever more detailed, so I said NOPE making separate repos for my nvim config maybe and that will be it!
sorry.
Then I realized that some of those config files reflected a lot about my systems and personal preferences... and it was only going to be ever more detailed, so I said NOPE making separate repos for my nvim config maybe and that will be it!
sorry.
You can always use a private repository for it. And, yeah, it's been very useful. I pushed a relatively straight forward config for Windows and WSL a few years ago, I really need to update it. I also want to get my Linux config done as well.
I mostly backup and restore from my NAS for my dot-files, and some of my ~/.config, though I need to nail that down a bit better, as ~/.config feels excessively bloated from a few apps.
I mostly backup and restore from my NAS for my dot-files, and some of my ~/.config, though I need to nail that down a bit better, as ~/.config feels excessively bloated from a few apps.
[deleted]
I share my .emacs with people who ask. Not really for privacy, but because I would feel bad: If someone tried to use any of it and was not able to ask me what I was thinking.
The usual answer is that I was not and we should change it.
I would also have to distribute a couple of novel go programs that I am not proud of if I was sharing it publicly.
The usual answer is that I was not and we should change it.
I would also have to distribute a couple of novel go programs that I am not proud of if I was sharing it publicly.
Sigh. 3 buckets:
- Secrets and environment specifics <- these needs secure storage and don't get shared obviously
- Local configuration overrides <- these need to be backed-up somehow and probably aren't useful for sharing either
- Generic configuration <- these are the type of dotfiles that can be shared
- Secrets and environment specifics <- these needs secure storage and don't get shared obviously
- Local configuration overrides <- these need to be backed-up somehow and probably aren't useful for sharing either
- Generic configuration <- these are the type of dotfiles that can be shared
I think it's even realistic to say that dotfiles are vulnerable to being used as a fingerprint mechanism by nefarious packages. One could easily create an inventory of github profiles <> dotfiles; then read local dotfiles when their package gets installed on a developer laptop.
Such a nefarious package could also read browser cookies, SSH keys, emails, photos, and a million of other things.
I'll never understand people not wanting to share their dots. Obviously you have to have a way to not share the private stuff of which there are many simple solutions, but I've learned so much from reading other peoples. To each their own, of course.
I don't even know what the author means here. I put them public on GitHub, because I can clone them from anywhere and have my config on any machine. The approximate number of people, who read them and see what I did, is 0. I just "share" them for public and free backup.
Someone thinking that bash aliases can be "intimate" is a next level of nerdyness for me. Reminds me of "gay code" scene from Silicon Valley.
Someone thinking that bash aliases can be "intimate" is a next level of nerdyness for me. Reminds me of "gay code" scene from Silicon Valley.
[deleted]
I once set out to share dotfiles as I set up a new workstation, but later removed the public repo. I realized I am often careless with that stuff, since it only lives on my machine and I am not managing them as public content, nor I want that extra overhead.
This article feels like it’s about what and how this person stores their dotfiles and then has two lines about them feeling too personal to share. I’m surprised it’s so highly voted since it’s basically “I use stow”.
Must be due to the interesting title.
Must be due to the interesting title.
I've never felt that icky. I don't really have any secrets in my dotfiles, though I have in the past. In that case, I just encrypt the private stuff using my SSH private key (stored in 1password) and age (via sops-nix).
I am more concerned about sharing something that someone can use to get access to my things that I keep locked away.
I still have it public but I try and think about what I am pushing before I push.
I still have it public but I try and think about what I am pushing before I push.
They are private. Many people store env secrets (db conn strings, etc.) in .bashrc. It's meant to be a private place in your home folder for private things.
They are really only private if you design it that way. There are numerous ways you could have access to those private parts of your bashrc, but still make the actual bashrc public.
That's coming from my kubernetes background though, and handling secrets this way is not something that people are always accustomed to.
That's coming from my kubernetes background though, and handling secrets this way is not something that people are always accustomed to.
Aren’t the default permissions 644?
RIGHT?
I could MAYBE see it if you were sharing your things on your personal blog -- but "github dotfile repos" feels wildly icky to me.
I could MAYBE see it if you were sharing your things on your personal blog -- but "github dotfile repos" feels wildly icky to me.
How? What? It's not icky.
I mean, that's subjective.
Kinda feels like uploading a picture of my bathroom/medicine cabinet. There's nothing in there particularly incriminating or whatever. Just kinda feels weird.
Kinda feels like uploading a picture of my bathroom/medicine cabinet. There's nothing in there particularly incriminating or whatever. Just kinda feels weird.
why? no one cares about your dotfiles 99% of time.
I put all kinds of weird stuff in mine. Where/who I stole the alias from. Maybe some swear words. Broken stuff. Jokey stuff. I don't want people judging me. It's like publishing the worst of your sketch book or something. People just don't need to see it.
Which really annoys me that everything is effectively public at my place of employment. I have to mildly censor myself all the time.
Which really annoys me that everything is effectively public at my place of employment. I have to mildly censor myself all the time.
One trick I use is putting secrets in 1password and just including the 1password URLs in my checked in my sample dotfile.
I feel the same about my NixOS config despite the "open repo" model kind of being a default in that ecosystem
Oh man… that “how normal is this thing of mine” feeling writing nix gives me is such a weird characteristic of the ecosystem.
I simultaneously don’t want anyone to see mine while desperately seeking affirmation that mine is not weird ^_^
Happy to hear I’m not alone!
I simultaneously don’t want anyone to see mine while desperately seeking affirmation that mine is not weird ^_^
Happy to hear I’m not alone!
It makes me feel bad because I frequently will search github with "language:nix" to find usages, which is usually done in someones (sometimes the nixpkgs commit authors) personal config :')
Sometimes there are valid security reasons for this, after all. (Looking at you, .pypirc .)
I split mine. I have public dotfiles and private. No need to share everything.
is there some sort of utility to automatically backup and retrieve dotfiles from github to keep different computers synchronized?
Well, there is cron and git. I don't see why you need anything else.
[deleted]
I keep mine public but sensitive data goes into another, private GitHub repo.
[deleted]
I'll never forget those lines because they seemed so mysterious and cool. And they informed my philosophy on how the internet should be. People should be able to see other people's stuff by default. It's nice for us to be able to learn from one another. It's harder to rely on the honor system for privacy nowadays, but I still think "share by default" is a noble ideal.
That said, I also am unsure how best to overlap aliases and configs that are sensitive to my workplace with my everywhere config. Maybe I should have a .employer file that I source if it's there, but something about including that into my everywhere config feels decidedly not righteous.