If you're using -sk keys (i.e. setup via FIDO2 on the Yubikey like the article, not PIV) yes you can forward the keys loaded into your agent like normal, with ssh -A.
PIV keys can also be forwarded through an agent. The only thing to be aware of is that the agent process will effectively cache your PIN if you do this.
ssh-add -s
To mitigate that you can add -c to the ssh-add command. That will make the agent prompt for confirmation (on the host with the PIV key) every time something asks to use it. Doesn't quite get you the same security as just not caching the PIN to start with but it's OK.
Hey I'm in the middle of doing a very similar thing, though I didn't go quite as far as OP. I'm slowly deprecating my old RSA SSH keys and replacing them with a combination of Yubikey, Password Manager, and alternative SSH auth:
1. -sk keys on Yubikeys (with touch enabled) are my primary keys, used for signing and always installed on every host I touch/etc. I initially planned on using the PIV slots on my Yubi's to store the SSH keys instead of the built-in FIDO2 setup, but I hated having to manage multiple moving parts (like getting pscd running on all my clients). The only main benefit of using the PIV slots was being able to set the "cache" touch policy: the YK would cache a touch for up to 15 seconds so doing something like "signing multiple commits during a rebase" would only take one touch instead of num_commits. The side benefit would have been getting to re-use the same SSH key across primary and backup Yubis. The simplicity of the FIDO setup won out and I decided to treat getting annoyed at pressing my Yubikey a bunch of times as a sign I should be doing some sort of alternative setup like a dedicated key. Most prominently, I've now properly setup my Ansible configs with dedicated deploy keys kept as secrets instead of reusing my personal key.
2. I use 1Pass and Bitwarden (work/personal) to store a secondary SSH key that's only used for basic Git auth or other low-risk tasks. This SSH key is loaded from the Password manager directly into ssh-agent via stdin so it never touches my disk; I use fnox to make this backend agnostic.
3. Work uses Teleport, personal uses Tailscale so I rely on those SSH auth most of the time. Nothing much to say here except that Tailscale ssh is really convenient :) .
I've also setup PAM login and sudo on my machines, which brings me back to the old Sun Ray/Smartcard days. None of this is really to prevent security breaches/dedicated attackers or anything, though it certainly makes me harder to compromise. I just wanted to make absolutely sure I couldn't accidentally upload an SSH private key somewhere.
Running very similar setups. PAM handles FIDO / security key based auth on my local systems for root users and sudo commands, as well as LUKS decryption.
I have a handful of security keys, so I have a helper script to drop them into new hosts and another helper script on my systems to import keys straight to ssh-agent once detected.
Has worked very well and I don't think I'll ever go back to a "password manager as SSH agent" again, but it's probably the best alternative backup. I still have Bitwarden holding some backup keypairs for this reason, but haven't needed to use them in months.
I logged in to my macs for a few years using Yubikey. I did eventually abandon it though out of fear of Apple screwing it up with an upgrade which Im sure was founded. Dont use macs anymore. I think my main beef with yubikey is really is it doesnt have enough space for enough keys. But I use it for many things.
Neat! I've got a similar setup for the hours, though I use normal 24-hours and just adjust the start/end times by relation to current dawn/dusk. I'd love to get it on a clock but alas for now it lives as a Home Assistant automation, playing chimes whenever the hour changes. You wouldn't happen to have a repo for your version would you?
I learned about the hours through the game Pentiment; you may enjoy the clock face used in it to tell in game time: https://pentiment-clock.vercel.app/ .
I'll package it up and share my git repo either this evening or tomorrow morning. Love that Pentiment clock! What a great way to visualize it. My implementation is a C engine that keeps the time calculations separate from the display. I have an app for Windows and one for Android. Both use SDL 2 for the presentation. Mine looks like a 64-element LED screen for a fun crossover feel between Roman time, but 60s-tech presentation. You can fill in your own GPS coordinates and it doesn't talk to the internet at all. It's self-contained. I also have a terminal version that uses no graphics library. I'll post a link separately later so you get a notification.
> and in Kitty's case the whole annoying lot of Kitty-derived and Kitty-standardized features every terminal emulator is now supposed to support, which also break existing compatibility -- with the usual "you are holding it wrong" arguments when someone points it out.
What an odd complaint; it's not like he's going about to other projects forcing them to add them. I suspect the reason some of Kitty's standardized features are being independently adopted by other terminal emulators is because they are genuinely useful.
> I suspect the reason some of Kitty's standardized features are being independently adopted by other terminal emulators is because they are genuinely useful.
Correct, kitty-keyboard-protocol or kitty-image-protocol are actually useful and thats why Ghostty for example supports them. The alternatives are often worse or only have niche benefits (looking at you sixels)
Yeah nothing made me more confident in my choice of terminal (after trying quite a few) than seeing that "Kitty" graphics protocols are all over the place for SotA TUIs. Love to see it!
But really Kitty is the GOAT because of the customization ethos. Just top-notch.
Gotcha, that's what I figured but I was still curious. I've got a side-project that was originally designed for traditional GitOps but got OCI support as a feature submission from a user. I've been seeing more usage of the OCI backend these days and originally figured it was a side-effect of the project domain (Podman Quadlets) but maybe it is an over all field shift.
In the last couple of weeks, I've been moving a deployment stack off ArgoCD pointing at Git, and ended up settling on Flux fetching OCI artifacts from ECR. The artifacts are built and pushed by GitHub Actions. It seems like a nice way to "have GitOps" without needing GitHub to be up all the time.
Really looking forward to seeing Tangled develop! I've got a side project that's main repo and CI is on my self-hosted Gitea but code and releases are mirrored to Github; I'm hoping to move it off Gitea and onto Tangled for code/releases/potentially CI and just keep Github for discoverability/backups/namespace "squatting".
Just need git-bug to add a Tangled bridge so I can keep issues synced and (ideally) for there to be instructions for running the client self-hosted. It doesn't have to be a full featured client but I also don't want to be SOL for web visibility if the main Tangled appview is down.
One musing: I did run into my first "issue" with federated Git hosting the other day while setting up Neovim on a new machine. One of the plugins I use is hosted on Tangled and I guess its backing Knot was down. This was awkward for two reasons:
1. It as unclear to me from the Tangled website the backing knot was the issue (for a while I thought it was something on my end)
2. I really had no backup plans for something like a Neovim plugin's source forge being down and, clearly, neither did the Neovim package manager as it just kept showing an error on every session I started with no way to fix it :).
I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time. ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
> I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time.
Pretty much. We want to make running your own git remotes as easy as possible. Lets you scale on your own too.
> ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.
It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
> It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
Someone (or some group) could also in theory go fully content-addressing with their data store, and make content available based on their hash, effectively layering that missing benefit on top of the existing architecture. Someone could probably vibecode this together in some hour(s) :)
> I really had no backup plans for something like a Neovim plugin's source forge being down
this problem could exist with any package manager, the go package manager is one example, where it allows specifying packages from any git url. we host a mirror of all git repositories on our infra, and serve that when the backing knot is down. you could choose to trust that and pull from there (verifying that the tarball has a known correct hash), the way the go package manager pulls from proxy.golang.org.
Ah, I didn't realize the tarballs on the Tangled site were cached. If it happens again I'll try that :)
But yeah I recognize it's an issue for any package manager. I suppose I just forgot that even something like my local editor is reliant on remote forges now unless I go out of my way to mirror it all.
I started mirroring as much of the core git repos I depend on to my NAS with systemd timers to update from remote, and post-receive hooks to mirror externally if I control the repo. This reminds me that I should expand those efforts
The graph generator looks interesting, but the rest of the blog post is filled with so much marketing it's a slog to get through to the good bits. I struggle to imagine a scenario where I willingly choose the "Trails" view even if, and god help us if it is, that's the direction PR review is going.
Hey, Haimantika here from the Entire team. Thank you for the feedback on blog, we will work on it for our future announcements.
For Trails: There’s agent sessions, gates, agents(evals basically) and checks - so it gives you all the information you need to review better (compared to the diffs for example).
Throwing out some thoughts after reading the docs page(s):
1. The "What are trails" section does not actually tell me what trails are; it tells me it brings agents and devs together, and that branches are involved somehow through "changes", but it doesn't actually tell me what they are
2. I am never going to willingly watch a Youtube video embeded in docs. I'm barely going to watch a video in a docs page at all. I'm here to learn how to use something, not see a sponsored ad for NordVPN.
3. The marketing blurb, the top half of the docs, and the bottom half ("Enable Trails" onwards) all feel like their describing different things. The marketing blurb describes a total reinvention/view of the PR layout where instead of seeing diffs you see different bars that you can balance by telling the bots to keep reviewing/changing. The top half of the docs sounds like some sort of spec description system and absolutely reeks of LLM speak.
4. The rest of the docs make more sense: Under the web UI tab for "Create a Trail" I finally see what a Trail looks like (a simplified Jira ticket or GH issue) and I start actually understanding that this is an elaborate "built for AI" version of stacked PRs, CI checks, and project management.
5. The Agents and Gates subdocs are where content starts getting interesting and the documentation quality is a lot better. I am actually getting interested in this product.
I still don't fully understand what and why I would want Trails, but I suspect I'm not the target audience. There's bits of it that certainly look interesting but having to swap all my infra over to Entire is a hard sell.
Yes, I will say it's a high-AI-trust approach. I can see this being adopted by people like Anthropic who already don't read the code. Personally I'm still trying to get my company to add AI review to MRs :(
I am happy to YOLO stuff into my -dev branch unread but even for private tooling nobody else will ever use I then let things mature a little bit before extracting an explainably and clearly-scoped change to add to main. It's going to be really interesting to see how different team cultures deal with this stuff.
Yeah I'd love to see/hear some examples here; I mostly listen to small-to-mid-level black/doom/trad/power bands and haven't noticed this type of standardization of sound.
It's possible I don't have the ear for it though, so now I wish the article had posted how it made this type of analysis so I could run some of my albums through it myself.
> I wish the article had posted how it made this type of analysis so I could run some of my albums through it myself.
I very simple way is to throw a track into a DAW and see if the drum hits line up perfectly with the "grid". Most DAW's have a grid background so you can see. If it's perfect for the whole song, then it's definitely quantized to death (pun unintended, though does sound quite kvlt).
Fnox (by jdx of mise) supports fetching secrets and caching the results either in local age encrypted files or in a background daemon (in memory only) to minimize repeated gets. The daemon is per terminal instance too I believe so you fetching a secret once doesn't store it for the whole session.
It's not a perfect fix but it keeps secrets out of env with (so far for me) minimal inconvenience.
reply