Dotfiles feel too personal to share
hamatti.org
hamatti.org
# A righteous umask
umask 22
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.
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.
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 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
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.
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.
To me it feels like getting told to not put nice shelves in my home because other buildings don't have them.
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
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).
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.
It's like when I tried to get used to a DVORAK keyboard when I'd spend my weekdays in a school computer lab...
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?
Nobody should be ABLE to log in to servers by default, that's the way they become unicorns and not cattle.
Yeaah, that don't fly unless you're in a really seat-of-your-pants environment. =)
# 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";
}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.)
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.
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.
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"
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.
Anybody who would like a decent text editor around vim key-bindings uses Emacs in evil-mode already.
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.
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).
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 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.
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.
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.
* 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.
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.
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.
Some things are better public. Some are not ...
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
$ context set universe://work/customer-a/devops --update-dotfiles
$ context set unvierse://work/customer-b --update-dotfiles
$ canvas dot apply user.name@remote.id:workspace-foo
$ canvas dot apply user.name@remote.id:workspace-bar/shell/bashrc
yes, complicated, probably hard to comprehend/reason about, work in progress
same issue of intimacy, the paths aren't encrypted.
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'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:?
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.
l() { if [ -d "$1" ] ; then ls -alFh -- "$1" ; else "${PAGER:-pager}" -- "$1" ; fi }
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.
Somehow, 11 people have starred my public ones on GitHub.
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
https://marcusb.org/posts/2025/01/frictionless-dotfile-manag...
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.
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!
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.
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?
* 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.
That said: 'every day' does seem quite hyperbolic.
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...
Why not?
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
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.
# 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.
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...
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.
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
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.
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.
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.
Be generous with your dotfiles, and especially with the young and curious engineers who ask lots of questions about your setup. Pay it forward.
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.
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.
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.
- 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
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.
Must be due to the interesting title.
I still have it public but I try and think about what I am pushing before I push.
That's coming from my kubernetes background though, and handling secrets this way is not something that people are always accustomed to.
I could MAYBE see it if you were sharing your things on your personal blog -- but "github dotfile repos" feels wildly icky to me.
Kinda feels like uploading a picture of my bathroom/medicine cabinet. There's nothing in there particularly incriminating or whatever. Just kinda feels weird.
Which really annoys me that everything is effectively public at my place of employment. I have to mildly censor myself all the time.
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!