Foxboron

>additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.

You are not going to see similar exploits available in a program written in Go, it would result in a crash. Not an actual code execution issue.

So you are removing attack surface by not loading shared libraries, and quite a bit of attack surface considering it's not written in C.

> this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.

Allowing better UX would also allow people to utilize better and more secure defaults. The PKCS11 stuff is general unfriendly and using it correctly as a result gets harder.

This isn't only about attack surface, but also enabling more user friendly tooling.

Apparently you can use a ssh-agent for HostKeys, and by extension ssh-keysign.

So I think this should be trivial to implement actually.

It might be cool to add some attestation feature so you can verify the boot of the machine before releasing the host keys. Might be practical in scenarios where you are SSHing into an initrd or a sensitive remote host.

> are you extending this to the usage of yubikey-agent and ssh-tpm-agent as well?

No, as they never get loaded into the ssh binary and are external programs communicating over an interface.

Consider reading over the recent qualys vulnerability report on how messy this dloading of pkcs11 actually is.

https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh...

>both variants, whether it's using a PKCS11 provider using a standardized interface, or using a completely custom SSH agent, will need to deal with secret material.

`ssh-tpm-agent` is not dealing with secret material. That is delegated to the TPM and we are only in the business of telling the TPM to sign stuff for us. Yubikey-agent does create a private key on the machine before inserting it into the yubikey.

I would not call these two things equal and there are a difference to what the potential impact is.

>although I'm no expert on the inner workings of SSH, I'd expect there to not be much difference between having the OpenSSH agent interface with ykcs11 (which is also open source and can be reviewed) and using an alternative agent with piv capabilities that was found on github.

There is a separation of concerns here though.

When you see a guide containing a 7 step manual to do something that should be simple, it's worth taking a step back and consider the question if you can make this valueable security feature more easily accessible.

Side-loading so-names into your security critical apps is probably something you should be more critical of as well.

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

EDIT: The bootdisk won't work with a recent shim nor a recent grub. The old shim it was using should be revoked if you have any remotely updated machine as well.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

>Are you sure about that? Presumably the secret parts of the SSH key are being read into memory at some point, or a RCE could dump the key the same way ssh-tpm-agent does.

This is not how ssh-tpm-agent works. It does the key signing inside the TPM so you do not have access to the key on the machine itself.

The private key never hits memory or the machine itself.

It has 6.3 Kb or something of memory. So not a lot.

What `ssh-tpm-agent` does is that it simply doesn't store the keys on the TPM at all. It creates the ephemeral SRK, then load a sealed private key back into the TPM that allows us to use it.

So you can have a couple hundred SSH key pair this way.

It's not written in the README.md, but `ssh-tpm-agent` is very much a copy-paste of `yubikey-agent` but with a bit better testing and the yubikey part swapped with TPM stuff.

How does Heads and Pureboot solve the Root of Trust issue outlined in the blog post?

Yes, they are testing this for a fraction of their packages.

It still amounts to less testing then what distros like Guix, Debian and Arch Linux is currently doing.

> reproducible builds

fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.

vimspector is a cool DSP for vim.

https://github.com/puremourning/vimspector/

The 1 Gbit/s uplink for the Tier 0 mirror has been fully saturated for almost 4-5 hours now and I expect servers to be syncing for rest of the day really.

I don't do any of the actual server infra so I don't have all the details.

The btrfs raid setup is standardized across all our infra and can be found on ansible.

https://gitlab.archlinux.org/archlinux/infrastructure/-/blob...

https://gitlab.archlinux.org/archlinux/infrastructure/-/blob...

From what I can tell it's been working fine and behaves nicely with failing disks.

Historical mostly.

Github usage predates the Gitlab instance and some projects haven't been migrated. We also keep some repositories on Github as a secondary mirror.

We've also had some performance issues on Gitlab for `svntogit` repository because of weird branch structures. However this repo is not deprecated so it doesn't matter anymore.

Well, that is a bit outdated.

I think my draft is more detailed: https://wiki.archlinux.org/title/User:Foxboron/GitMigration

Runbook for the migration can be found here: https://md.archlinux.org/utjjQ-bQTsipIKntPrpf8g?both

You could try vimspector. It's main target is vim and not neovim.

https://github.com/puremourning/vimspector/

>but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.

No, it implements the verifier API which needs to be disabled for this to be true. This should not be the case for distributions utilizing the shim+grub setup (Ubuntu/SUSE/Fedora/Debian/etc)

They don't really do any source authentication at all. There is no strategy for checking gpg/minisign/whatever signatures and fetching keys to validate these things.

> And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.

This is false.

The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.

https://github.com/Foxboron/sbctl

Slight misunderstanding in the blog post there.

> Archlinux is 78% reproducible on amd64 packages

> Debian is 95.7% reproducible on amd64 packages

This references the "fuzzing" infrastructure hosted by the Reproducible Builds project, and doesn't show "true" reproduction of binaries. It's designed to help us figure out where impurites occur in builds.

Proper package reproduction is much better in Arch because we don't have to care about all differences that can occur since our build systems are mostly static.

The true number hover around 86%-90%, which is better than the CI system.

https://reproducible.archlinux.org/

The main issues here is regressions in compilers, build tooling and leaky abstractions that needs to be found and patched. An example is how i spent a month tracking down a gcc bug that caused cgo builds to be unreproducible.

https://go-review.googlesource.com/c/go/+/413974

If someone thinks the Hy mascot, Cuddles the Cuttlefish, looks awfully familiar to a certain crustacean mascot, you would be correct!

They are both drawn by Karen Rustad Tölva!

https://www.aldeka.net/

>I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong.

When I was working on Hy, almost 10 years ago, there was a couple of Hy core devs that had managed to push some Hy code into production. I won't name names, but a known company used Hy when processing firewall rules (if i recall correctly).

I doubt that code is still being used, and I'm not aware of anyone beyond a couple of previous Hy core devs that managed to push Hy into production.

Hy isn't transpiled though, it's compiled into valid python bytecode so some of the traditional issues around transpilation doesn't apply to Hy.

I'm sorry I don't meet your expected level of professionalism on a random internet forum. Rest assured I have filed a deviation report to my manager.

> I really don’t see how arch fairs any better here, care to elaborate?

Arch has spent a considerably amount of time getting to the figure it has and is in the same position as NixOS to maintain reproducible builds. The claim that NixOS solves this, or is uniquely dispositioned to solve this, is the false. That is what I'm effectively trying to point out here.

>While it is a different problem, my litmus test for package managers is installing gnome a (the whole group) and then seeing whether I can transition to kde or vice versa without a bunch of dependencies lingering around forever. Pacman, apt, etc. all fail terribly here.

That is not what Reproducible Builds is about.

>Nix is 99.77% reproducible, so come on. It’s not marketing, nix just properly solves the problem for the first time ever.

You haven't read r13y properly.

>1733 out of 1737 (99.77%) paths in the nixos.iso_minimal.x86_64-linux installation image are reproducible!

600 packages becomes 1737 paths which are the inputs used to generate the image. Several of the compared paths are just static files which doesn't change, so the "path to package" comparison doesn't work either.

EDIT: An example set of stuff it attempts to compare can be found here:

https://paste.xinu.at/TmVM0y5FBDWX/

Taken from the build here: https://buildkite.com/grahamc/r13y-dot-com/builds/1149#01813... They have not solved the problem.

It's not. It's marketing. The focus of Nix is reproducability in the same wain as docker: Same dependencies for the same behavior. They can't guarantee bit-for-bit reproducability any more then your average distribution.

Arch Linux has a rebuilder setup and you can safely reproduce between 85% and 89% of the repository packages.

Nix has never done such a thing, and would be far away from any comparable numbers.

No worries :) I should blog more about these things so people do get better insight into obscure issues like the one above.

Lets not forget that simply using any given build system doesn't magically solve all the issues.

If a `make install` invocation gzips manpages instead of the package manager or distro hooks, then you won't have reproducible manpages unless the upstream uses the `-n` switch as well. This is just an example of many small and obscure issues that hide inn different upstream projects.