Foxboron

Nix is not content addressable though, the hashes is based off on the derivation files which are equal to the lock files you would find in other package managers.

> The thing it provides is the toolchain of dependencies that are reproducible. [...] If the inputs change then so does the output. If the output itself is not reproducible (like, say an artifact with a build-time embedded in it) then you have something that is inherently not reproducible and two people trying to build the same exact nix package will have different results.

There are no guarantees they are reproducible. The only guarantees Nix gives you is that the build environment is the same which allows you to make some claims about the system behaving the same way. But they are certainly no guarantees about artifacts being bit-by-bit identical.

> We don't need to be looking for such contrived examples actually, nixpkgs track the packages that fail to reproduce for much more trivial reasons. There aren't many of them, but they exist

Less than a couple of thousand packages are reproduced. Nobody has even attempted to rebuild the entirety of the nixpkgs repository and I'd make a decent wager on it being close to impossible.

> Nixpkgs focuses on reproducible builds, that means that for the same inputs, you always are going to get the same binary output.

This is a common misconception, nixpkgs only really supports "repeatable builds" and "reproducible build environments".

The Reproducible Builds aspect of nixpkgs is still very much a work in progress as it is with all the other linux distributions and hardly a focus.

Parts of this seems dated. I'm pretty sure the entropy changes suggested doesn't really add anything after the recent (~2 years ago) rework of `/dev/random` in the kernel.

It doesn't mention `systemd-homed` which might be useful in some cases and the kernel module signing portion is just... wrong or misguided.

This doesn't help at all as you need to coordinate so-name rebuilds across multiple architectures. This implies you need to some way to orchestrate a staging repository and have building do rebuilds towards this repo interactively until all issues are solved.

Retrofitting this ontop of gitlab sounds painfull. I don't even know if we would like to be that tied to a singular forge.

It's all part of the same problem domain; How do we rearchitecture the release process of Arch so we can support multiple architectures.

The amount of people that understand this problem domain, have the time+energy to work on it and is actually able to see it too completion is.. well. Not many.

I tried to hack on buildbot, as I wrote in that email, but I have been questioning the maintainability of trying to fit what we need on top of buildbot. In constrast to writing something from scratch.

There has been patches floating around to support this for quite a while. One example here: https://github.com/sandsmark/vlc-chromecast-subtitles

CCC is a political organization.

That is not great. Currently this makes the barrier of entry for new people to contribute to projects using gitlab quite a lot higher.

There is also a huge volunteer cost here where we have to manually make accounts.

A lot of effort is spent on packaging the stuff we need for our own infrastructure so we can run it in prod. Gitlab is one of these exceptions but generally it's been working well for us.

Here is a post of the git migration to Gitlab on their tech blog written by Levente Polyak (Arch project leader).

https://about.gitlab.com/blog/2023/09/11/migrating-arch-linu...

Mentioning it as it never did well on HN, but probably interesting in light of this post.

We do. The infrastructure is obviously open-source as well.

Ansible role for gitlab: https://gitlab.archlinux.org/archlinux/infrastructure/-/tree...

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

There is no limit to the password. Usinging a 4 digit numeric PIN is just easier to remember, and because of the bruteforce resistance it doesn't decrease the security.

AUR is unsupported, and the fact that nixpkgs decides to support everything is for them to decide.

Reaching for reproducible builds support in Arch is a more attainable goal than for nixpkgs. Properly maintaing 80k packages without regressions is going to be a lot more work in the long term.

It's unclear at the moment because of the limited testing (minimal ISO and a Gnome ISO) vs Arch/Debian/Guix rebuilding entire package repositories.

I'm very sure you are actually just rebuilding the container images themselves, not the package tree you are depending on. Building reproducible ISOs, or container images, with a package repository as a base isn't particularly hard these days.

> Your comment can be misinterpreted as saying "Nix does not do binary reproducibility very well, just input reproducibility", which is false.

It's only "false" as nobody has actually tried to rebuild the entire package repository of nixpkgs, which to my knowledge is an open problem nobody has really worked on.

The current result is "only" ~800 packages and the set has regular regressions.

There are multiple legit use cases for TPMs, ssh-tpm-agent is neither the first nor the last.

Simple key storage and signing is the base useage for these things, people just focus on the "wrong" aspects of this.

> 1) is there a simple key destroy function?

Just rm the key file. TPM sealed secrets are never actually stored inside the TPM, they are just files with strong encrypted that only the TPM can decrypt. So deleting the key file removes your ability to recreate the key.

> 2) if somebody gains remote login access to the host with root, noting they can't exfiltrate the keys, can they subvert process chains to claim linkage to the ssh-agent process?

Possibly, yes.

--first-parent is a nice option I wasn't aware of. But it would still depend on upstream not merging PRs failing the test suite.

No, it does a binary search over the 100 commits. You would probably hit the issue before you hit 7 or 10 commits depending on how lucky you are.

Bisecting to find the root cause is always going to be a better strategy if you know there is a good version.

I really recommend adopting this strategy.

Right.

Imagine you are a terraform provider developer that is working on making sure their code is working with `opentf`.

Lets imagine opentf does an initial `v1.0.0` release of their code and your provider doesn't work. But you know it worked with the last FOSS release of `terraform`.

What do you do?

You find the common ancestor between these two projects, lets say 8a085b427b74ce3829500a59508b77465f1bbef0 (as that is the last commit `opentf` has from `terraform`).

You will now run `git bisect` on the history between `8a085b427b74ce3829500a59508b77465f1bbef0` and `v1.0.0`.

You will do a binary search on the 100-200 commits here, and everytime the source fails to build, or the test suite doesn't pass for whatever reason, you are making it much harder for the downstream provider to figure out why their code doesn't work.

You can easily just try do this today and see what happens. Does the current untidy git history cause you any problems?

Most people don't spend this much time on PR before releasing their fork though.

If they had worked on this publicly from the start I'm sure a lot of the current PRs would have generally been of better quality as they could get community input earlier.

> Branch protection doesn't allow merging without a passing test-suite.

https://github.com/opentffoundation/opentf/pull/243

EDIT: and just to point out. If you have 1 PR with 19 commits that break the test suite. The last commit fixing it doesn't matter as you will be hitting one of those 19 commits at some point during a bisect.

>Could you expand? You choose a sensible commit message on squash, while the PR's commits become fairly irrelevant at that point.

It's optional. Nothing prevents you from just adopting whatever the PR said initially. Turning it on doesn't automatically make it better.

How does the merge setting solve the complete lack of any useful information in the pull request?

The squash merge is not going to solve the lack of proper commit messages and the fact that things are breaking the test suite left, and right.

Figuring out bugs with `git bisect` is not going to be a fun endeavour for people trying to understand incompatible changes.

It would be trivial to at least continue the standards set by the terraform project. Now there are commits messing with `internal/backend` that breaks tests with the commit message "more".

Someone is going to hit this with `git bisect` and it wont be their lucky day.

As technical lead for the OpenTF project, how does things like this get merged?

https://github.com/opentffoundation/opentf/pull/36/commits

I've been hacking on `ssh-tpm-agent` which allows you to create or import TPM sealed keys. This is practical as it prevents key extraction and it has dictionary attack protection which allows you to have 4 digit pins instead of passphrases to protect your private keys.

https://github.com/Foxboron/ssh-tpm-agent

Currently hacking up better support for `HostKeyAgent` and `HostKey` for `sshd`.