418 karma · joined November 5, 2010
Would love to know if you’ve tested the hybrid migration mode against artifactory yet. Would be very very cool to have a way to run both of these side by side while evaluating the cutover. Maybe with a way to re-sync the artifactory db changes over periodically.
Would be cool if this also could support the existing artifactory s3 backend format so you could just point this at your existing artifactory s3 bucket and migrate your db over to this.
Congrats on launching!
I’m kinda surprised someone hasn’t integrated the buildbarn nfs v4 stuff into docker/podman - the virtiofs stuff is pretty bad on osx and the buildbarn nfs 4.0 stuff is a big improvement over nfs v3.
Anyhow I digress. Can’t wait to take it for a spin.
[0] https://github.com/Barre/zerofs_nfsserve
[1] https://github.com/buildbarn/bb-remote-execution/tree/master...
Canada and Australia are jumping in [2] [3].
[0]: https://ec.europa.eu/commission/presscorner/detail/en/ip_25_...
[1]: https://www.twobirds.com/en/insights/2024/france/la-loi-sren...
[2]:https://facia.ai/news/canada-proposes-age-checks-for-online-...
[3]: https://www.abc.net.au/news/2025-07-11/age-verification-sear...
That’s the most important follow up. Without it, you’ll notice that the driving feels icy - I see it in the demo video. Most folks who fail to do the anti-roll bar and suspension wind up with cars that easily flip on turns - so they make the tires slip or they play with the surface friction, which makes the driving experience worse.
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 seemed like a cool idea for a while but it’s implementation leave much to be desired and has not stood the test of time…
Password-store[1] does a better job than git-crypt for single user git based gpg encrypted password management.
For multi-user git repo encryption I prefer Mozilla SOPS[2], especially when coupled with something like AWS KMS…
But then you might consider stepping up to something like Hashicorp Vault[3] or Infisical[4].
[0] https://github.com/AGWA/git-crypt/issues/273
[1] https://www.passwordstore.org/
[2] https://github.com/getsops/sops
Tldr: band was mourning cliff’s death and giving newsted grief.
When the engineers first rewound the master tapes for Justice they thought the tape was being shredded because the tape machine was making a very strange noise. When they stopped to take a look, they saw thousands and thousands of tiny tape edits. Apparently that was key to how Flemming Rasmussen got the drums so locked in. Hand editing and splicing every beat.
The sound the engineers heard that they thought was the tape shredding was the sound of all of those hand edits flying over the tape head.
Curious what other (easier) ways you found to accomplish the same effect?
/etc/apt/apt.conf.d/local
DPkg::options { "--force-confdef"; "--force-confold"; }
[0] https://debian-handbook.info/browse/wheezy/sect.package-meta...