dotfiles VS git-crypt

Oh man that's nowhere near fair! ripgrep is one tiny little command that is mostly compatible with GNU grep. Lots of the flags are the same. And its default usage is really easy: `rg whatever`.

But I gave it ten minutes and ported part of https://github.com/BurntSushi/dotfiles/blob/bedf3598f2501ad5... to https://github.com/BurntSushi/dotfiles/blob/bedf3598f2501ad5...

Not much, but it took me some time to get the basics down.

One thing that stood out to me was that startup times are kinda brutal. I'm not sure if that's intended or if it's something about my environment:

    $ cat /tmp/murex-test

So ired is a toy. One wonders how many search results you've missed over the years because of ired's feature "it's so minimal that it's wrong!" I mean sometimes tools have bugs. ripgrep has had bugs too. But this one has been in ired since 2009.

What is it that you said? YIKES. Yeah. Seems appropriate.

[1]: https://github.com/BurntSushi/dotfiles/blob/eace294fd80bfde1...

[2]: https://github.com/radare/ired/blob/a1fa7904e6ad239dde950de5...

I've been using X11 on my Framework laptop for years. No desktop environment at all. Just my regulard old school window manager[1]. No KDE or GNOME. But also no XFCE.

The only thing I had to do to get scaling working for me was set two environment variables[2].

I was indeed worried about this when I bought the laptop. Prior to this, I avoided anything with resolutions higher than 1920x1200. But it turned out that everything mostly worked with a couple tweaks.

I think the only real issue I've run into is `git gui`. As I understand it, the GUI toolkit it uses doesn't support scaling? Not sure. I ended up working around it by just increasing font sizes. I suppose this exposes the weakness that is probably impacting you: the scaling on my laptop is being done by the GUI toolkits, not the display server or compositor. (I don't always run a compositor, but when I do, I use `picom`. Mostly just to avoid tearing.)

[1]: https://github.com/BurntSushi/wingo

[2]: https://github.com/BurntSushi/dotfiles/blob/ea3a88e6160f4244...

Here's a really simple example: https://github.com/BurntSushi/dotfiles/blob/214aab9fdc45e7a507d41b564a1136eea9b298c9/bin/pre-rg

The full details of my setup (and more) are here: https://github.com/BurntSushi/dotfiles

If it turns out to be the library (I'd wager not, 4 minutes feels excessive), then you could give roxmltree a try. This program deals with about 7GB of XML (my SMS history for the past few years) in about 15 seconds.

Did you try roxmltree? It worked really well for me and was quite fast: https://github.com/BurntSushi/dotfiles/blob/90f2acf2f45548ca0ff2da827f3108be0a965b74/bin/rust/searchsms/main.rs

find-invalid-utf8: walks a directory tree and prints invalid UTF-8 in files using nice hex escapes with coloring. This is useful for honing on in where invalid UTF-8 occur. You have a good bet of finding some by checking out any moderately sized repository of code. The Linux kernel used to have some. The Mozilla repo does. The CPython repo does too. This is why it's important for CLI tools to deal with invalid UTF-8 gracefully in some way.

Yeah it's great! I used it to implement a little utility to convert a subset of SMS/MMS messages from an XML backup to a more readable plain text version: https://github.com/BurntSushi/dotfiles/blob/0b075d79a6ff8812a1f48a37b9858938b3eadc58/bin/rust/searchsms/main.rs

Git-crypt is a dead product with numerous unresolved issues and drawbacks.

Newer versions of git cause git to crash when invoking git-crypt[0].

It doesn’t scale with users: Off-boarding a key is a commit in git. Since it is trivially easy to rewind a git repo before the revocation commit and then decrypt with the revoked key, this means you need to rotate every key under management when any revoke is performed.

It provides the illusion of asymmetric key encryption, but your asymmetric key wraps a shared symmetric key used to encrypt the entire repository. This also means a user could roll the repository back before a key was revoked and steal the symmetric key used to protect the repository and then use that key to decrypt the repository any time in the future.

It doesn’t scale with the number of files under management. As a result of how it’s implemented, every invocation is a separate process launch. This means every file triggers an asymmetric unwrap of the symmetric key. If you’re protecting your GPG key with hardware keyfob, decrypting the repository will take a long time.

This product was cool for a while but is flawed… do yourself a favor: Mozilla’s SOPS is better when coupled with something like AWS KMS.

[0] https://github.com/AGWA/git-crypt/issues/273

Years ago, before going full on Vault, I was using git-crypt, a git plugin that uses gpg to encrypt files before committing them to the repo.

Not sure if it’s still fine, I see their last release is 2 years old nowadays.

https://github.com/AGWA/git-crypt

Apart from a few exceptions (like ansible for example, which supports native encryption), we moved away from encrypted secrets in git repos and use external things, depending on the platform (like parameter store / secrets manager for AWS or keyvault for Azure - both of these do track changes, btw), so I haven't looked for quite a while. Back in ye olden days we used https://github.com/AGWA/git-crypt which worked quite nicely, but the key management is cumbersome and it's based on GPG, which in itself is a bit of a light redish flag these days.

How about encryption?

https://github.com/AGWA/git-crypt has been solid for me

You might want to check out git-crypt. It allows you to encrypt and decrypt files in a git repo without needing an external account, and supports .env files. That said, trying your hand at making one as a personal project could be a fun and rewarding experience!

I hesitate to append this but one option I have seen thrown around and also debated is git-crypt [1] There are many caveats to doing this as any integrations that would need to read the file contents would also need to be able to decrypt the files so this may not be entirely useful and may add many levels of complexity and fragility.

[1] - https://github.com/AGWA/git-crypt

The most interesting approach I've seen for this is https://github.com/AGWA/git-crypt

Here is the Makefile.