Liskni_si

That, or just pick the kernel package from unstable or testing. Apt is smart enough that mixing packages from different versions of Debian works just fine.

(I mean nothing is 100% but I've been mixing packages for like 2 decades now and literally can't remember any specific trouble resulting from it.)

2007 is when xrandr 1.2 came and made it feasible to use on a laptop - enable/disable outputs dynamically without restarting X.

Xinerama (the extension that enables one virtual screen over multiple outputs) existed before but the layout could only be defined statically - so you'd need to restart your X server with a different config if you wanted to connect a monitor or a projector or something.

> So realistically no application did this.

Old versions of GIMP (back when the toolbars etc. were separate windows) used to let you move any of its windows to a different X screen. And by "move" I don't mean drag - there was a menu where you could select the screen to move to.

What about this (actively maintained) fork of uBO that polyfills some MV2 APIs to make uBO work as an MV3 extension: https://github.com/r58playz/uBlock-mv3

Anyone tried that?

I'm somewhat aware of some of this but also... External keyboard only works if you're using the laptop as a desktop computer. It's not really practical if one uses a laptop as a laptop.

And yeah I know there are people lugging a massive mechanical keyboard to cafes but I find that about as annoying as getting used to the ridiculously bad keyboard and no trackpoint of Apple laptops.

Not just hard - impossible. To the point of making it harder to find a job, as very few jobs let you use a non-Windows ThinkPad.

(I mean yeah, of course AuDHD makes it harder to find a job, no surprise there. But it's a shame that laptop manufacturers make it even harder.)

Anyone else still using the 7x13 "misc fixed" font that comes with X11? I just can't switch. Perfectly readable on both 14" 1920×1200 and 35" 3440×1440. Yes it's small but that's kinda the point.

The only issue is that Nerd Font symbols are really hard to read at that size, even if one manages to get them to render (which isn't that hard in alacritty but needs some extra hacks in rxvt-unicode).

What if "the IT department" is just this one guy who asks me to Cc him an invoice when I buy a laptop and that's the end of it?

(yes that's a real story from my career, and the company was 100+ employees at the time)

> But they won't get your private key.

Indeed, that was my point exactly a couple posts up the thread. :-)

> you may realise that something wrong happened

I think I can iterate on the exact mechanics to make this less likely. I mean it's getting off-topic but the one thing that comes to mind is to enable ControlMaster for all ssh connections which allows any second ssh invocation to skip the auth and just re-use the existing connection. ssh-copy-id is near instant then and doesn't ask anything.

At that point you might—rightly so—argue that they're no longer tricking the user into authorising a different operation. Just a reminder that if someone can run code as your local user, they can easily and sneakily gain access elsewhere. Even if you need a yubikey touch to connect there.

The original attack idea of timing the yubikey touch for when you normally expect to touch it might still be relevant for a scenario like ssh-agent forwarding to a malicious box. They can't run code as your local user, but can still perhaps trigger the agent to interact with the yubikey. Maybe.

Okay let me elaborate how I envision that attack to work:

1. attacker wants to use your yubikey-backed ssh key, let's say for running ssh-copy-id once with their own key so they can gain access to your server

2. thus they need to trick you into touching the key when they run that command

3. the best way to trick you is to wait until you do something where you'd normally need to touch that key yourself

4. so they alias ssh to a script that detects when you're trying to connect to this server yourself, and invoke ssh-copy-id instead, which prompts you to touch the yubikey and you do

5. spit out a reasonable looking error (something that makes you think "bloody DNS, it's always DNS, innit" or something silly like that); then they undo the alias so you succeed on the next try and suspect nothing

Perhaps one extra bit to add: you've mentioned consuming slots on the device - that's what happens if you generate a resident key. Those keys live on the device and can be used from any computer you plug them into, without having to retain/copy any files. A non-resident key, on the other hand, is derived from the master key on the device, and a "handle" that's stored as a file on your computer. You can have as many as you want, but if you lose either the file or the hardware device, they're gone.

(Others in the thread have confirmed that both resident and non-resident keys never leave the hardware. If you generate one that requires touch, they're fairly secure - you need physical presence and confirmation for every operation.)

Well I wasn't talking about ssh keys at all - that's where the misunderstanding comes from. I was simply trying to counter your claim that TPMs are never ever useful for individuals. They can be useful to individuals worried about having their boot tampered with.

I absolutely agree that they do zilch to protect your SSH keys. Hardware security keys that need physical confirmation of presence are much better for that use-case.

I don't see how entering a passphrase into a compromised boot loader/kernel/initramfs is as safe as a measured boot with TPM providing the decryption key only if nothing seems to have been tampered with. Can you elaborate please?

I really don't think this is true for FIDO2 like Yubikey. My understanding is that your ssh client gets a challenge from the server, reads the key "handle" from the private key file, and sends both to Yubikey. The device then combines its master key with the handle to get the actual private key, signs the challenge, and gives the result back to your ssh client. At no point does the private key leave the Yubikey.

What am I missing?

Yeah but they already mentioned that they expect the attacker to hijack your ssh command so you'll touch it yourself, thinking you're authorizing something else than you actually are.

It does mean that they can't use the key a thousand times. But once? Yeah sure.

Fair point. Ubuntu 18.04 won't support this. :-)

TPMs can be useful to you as an individual if you're trying to protect against an evil maid attack. Although I think Linux isn't quite there yet with its support for it. The systemd folks are making progress though.

They can use the key as long as they can access your computer, but they shouldn't be able to get the secret key out of the TPM or Yubikey and use it elsewhere while your computer is off. That's the main point of HSMs.

It's also a bit outdated. OpenSSH supports FIDO2 natively, so all this gnupg stuff is unnecessary for ssh. One can even use yubikey-backed ssh keys for commit signing.

And the best thing is that you can create several different ssh keys this way, each with a different password, if that's something you prefer. Then you need to type the password _and_ touch the yubikey.

Many of those are "Merge branch 'master' into armanc/subtitle-sync-refactor". Rebasing the PR on top of master would bring that down to like 15 or something.

It's awesome that they're adding a UI for stacked branches¹! The UX of the CLI tool seems weird, though. Why do I need to explicitly create and add branches to the stack if all I really want is to open PRs from my commits? Here's the workflow that I built for myself instead:

∙ `git checkout -b feature-branch-xyz`

∙ make a few commits, perhaps some fixups, rebase, whatever

∙ start tig, look at the history, decide at which points I want to break the branch into stacked PRs, and mark those points using shift-s (which calls my own `git gh-stack branch create $commit` and creates a specially named branch there)

∙ `git gh-stack sync` — collects all the specially named branches, builds a graph of how they're stacked on one another, pushes them, opens stacked PRs

GitHub has had some "support" for stacked PRs for a while, so merging the first one to main will automatically change the target branch of the second to main.

If I need to change anything, I can just `git rebase --interactive --update-refs`, amend commits, split commits, rearrange commits, and then running `git gh-stack sync` will update the PRs for me. If I split a commit in the middle and shift-s to mark it, it will open an extra PR and restack everything to update the order.

Furthermore, the "PR stack" doesn't actually need to be a stack (linear chain), it can be a tree. If I know that some commits are independent of the rest, I don't need to create a separate stack, I just create another local branch, mark PR-ready commits with shift-s, and `git gh-stack sync` will do the right thing. If I need to rebase the whole tree on top of current main, then `git rebase -i --rebase-merges --update-refs` does the job.

I guess what I'm saying is that as someone who's been using git since its inception, it feels much more natural to just do everything in git, and then have a single command that pushes my work to GitHub. And I think this might work even better with jujutsu — just point `git gh-stack sync` at the branches jj makes and it'll make a stack/tree of PRs out of them. :-)

https://github.com/liskin/dotfiles/blob/home/bin/git-gh-stac... if anyone's curious. It's just a few hundred lines of code. Building the graph is done by `git log --simplify-by-decoration`. Opening PRs is shelled out to `gh pr create`.

¹) I mean, I'd much rather they added a UI for reviewing PRs commit-by-commit, with the option to approve/request-changes on each, and the possibility to merge the first few approved ones while continuing work on the rest… But in a world of almost every $dayjob insisting on squash-merging, a UI for stacked PRs is a total game changer, positively.

They haven't fixed the fork issue, the FAQ clarifies this. I suspect the target audience is squash merging corpos. Everyone else can just do normal PRs with atomic commits reviewed individually...

Not a single one, but it can be done with 2.

Assuming you're currently on the most recent branch (furthest from the trunk), `git rebase -i --update-refs trunk` will rebase all the intermediate branches. If you need to make a change to the first branch nearest the trunk, either use `edit` in the interactive rebase, or make a fixup commit and enable autosquash for the rebase. The `--update-refs` flag makes sure that all the intermediate branches get updated during the rebase.

Then, to push them all, something like `git push origin 'refs/heads/yourname/*'` will push all branches prefixed with `yourname/`. It's a bit stupid that one can't just do `git push 'yourname/*'` though.

That's not that unusual though. Many countries' age of consent is ~15 so you can legally do it sooner than you can film it.

I tried to do something similar well over a decade ago during an internal hackathon (the motivation back then being speeding up destructive integration tests). My idea was to have the memory be a file on tmpfs, and simply `cp --reflink` to get a copy-on-write clone. Then you wouldn't need to bother with userfaultfd or slow storage as the kernel would just magically do the right thing.

Unfortunately, the Linux kernel didn't support reflink on tmpfs (and still doesn't), and I'm not genius enough to have been able to implement that within 24 hours. :-)

I still believe it'd be nice to implement reflink for tmpfs, though. It's the perfect interface for copy-on-write forking of VM memory.

You can comment on the individual commits' changes, but you can't comment on the commit (e.g. its message) itself. I believe you can do this in Gerrit.

Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit.

If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...

You do if you find yourself in a team where PRs are squash-merged. :-(

I've seen porn in Google's own Chrome too.

In general, yes, it is easier to exfiltrate the token because if you can control some of the code that runs with the token available as an env var, you can do whatever.

In the specific case of the attack described in the blog post, though, the attackers added an extra GitHub Actions workflow that sent the token to an external server. That means they had enough privileges to change GHA workflows, and could just as easily change a workflow that used Trusted Publishing.

(It may be possible to configure branch protections or rules limiting who/when can trigger the Trusted Publishing workflow, but it's about as difficult as limiting the secret tokens to only be available to some maintainers.)