rosuavio / system-configs Goto Github PK

The auto merge tool in github relies on the github merge methods, I don't like them because they dont use the same head commit from the branch.

I need some other method to automerge that does use put the same HEAD commit from the PR to main (probably something that uses git commands under the hood).

I need this for when I want to auto-merge my hand written changes and auto generates ones from github actions.

On pulsar (at least) I zpool status tells me my zpool can be upgraded. I should get around to this.

https://github.com/Rosuavio/system-configs/actions/runs/5451374423/

The github action to update nixpkgs pin will create a PR that will get its HEAD commit tested, and if the PR gets merged. It uses github's rebase-merge which re-writes commits causing another CI run on the essentially the same changes.

On my systems I encrypt the entire drives by default, but all types of encryption have an negative impact on performance. I have my drives encrypted to protect any sensitive data from being read from my drives when they are offline and to make it prohibitively difficult to tamper with any data or programs on the system without it being detected.

Given my requirements, full drive encryption is being used on data that need not be encrypted and causing unnecessary performance desegregation.

Most of the system configuration has no plain text secrets, but I do need to be able to verify that is has not been tampered with before it is used (on boot). This means it does not need to be encrypted.

Much of the user directories can contain data that needs to be protected, so keeping those encrypted makes sense.

Some of programs and config for the users is not sensitive and some of it is sensitive.

Much of the software that users build is sensitive and might rarely not be.

What this means for a system using nix

While the volatile and mutable data can easily just live encrypted home directories. Programs and config build with nix all end up in the nix store, but at the different levels (system/user/project) the need for encryption varies drastically. Unfortunately the files in the nix-store cannot easily be from a mix of encrypted and non-encrypted partitions. There might be somethings that can be done with linux overlayfs and maybe the in RFC feature "local-overlay" could help too.

Essentially we would need a nix store for the non-sensitive parts of the system. another for the sensitive parts of the system. Another nix store for the non-sensitive parts of the user config and another for the sensitive parts and another store of the possibly sensitive ad-hock shells. All of the sensitive stores can be on an (or many) encrypted partition(s).

This seems like it would be impossible or very inconvenient currently.

While it is possible to get tested commits on main, by opening a PR and when CI passes on the head of the PR pushing that commit to main, it is still possible to use a github merge method instead on the github web interface.

I dont like githubs merge methods. It would be really cool to make it impossible (or really difficult) use those merge methods.

It could help if I check CI status threw the gh cli tool instead of opening the web interface. (The less i look at github.com the less remember that the PR can be merged on the web.)

Having to manually type in a password to decrypt volumes on boot is significantly inconvenient. When remoting into a system if I reboot the system then I wont be able to reconnect until I provide the encryption password for the drive at the physical machine.

I encrypt the drive to protect the offline data from being read and from being tampered with.

Possible solutions

Use TPM module to decrypt the drive with using a password/passphrase as a fallback method for decryption.

Make the docs easier to navigate. This might involve directory structures, numbered pages, and themes.

Like how we wrap nixos-rebuild, maybe we want to provide wrapped `nixos-option

          Needs a unit test to catch API breakage.

Originally posted by @Rosuavio in #22 (comment)

I want to have all example code for using this repo to always be tested and always pass tests.

This includes standalone code examples as well examples in documentation.

apognu/tuigreet#68 (comment)

Even when I rebased main on a tested commit and push it to main, CI re-runs tests on the same commit.