Create an easier Qusal installation procedure for users to report errors depending on installed version

Commitment

I confirm that I have read the following resources:

Current problem (if any)

Trust is everything. Instructions in global README.md leaves the user to find its own way to pass ben-grande public key to dom0. Instructions could be better, and lead the user to different sources to verify the public key(eg https://keys.openpgp.org/search?q=00C64E14F51F9E56).

One way to do this is to have it available in a seperate git repo, also signed with the public key.

Github will then show verified commits (no more unverified yellow, scary commit traces on repo).

Proposed solution

Publish public key to seperate ben-grande repo.
Sign that commit with said public key
Link main README.md to repo containing public key as well as where the author also published the public key to other public keyservers which propagated it elsewhere.
Maybe even add that verification to qusal dom0 helper

Additionally (unrelated), maybe add in helper script the following output to help user (and ad to issue template):

Have the dom0 git fetcher script output:
- git commit of fetched to dom0 git repo
- have the helper script call setup script to reduce user error of salt recipes deployed
- have the helper script verify the last commit against imported and checked public key

The value to a user, and who that user might be

Easy way for the user to have project's public key inside of dom0.
Easy way for user to validate commit domu to dom0 qusal repo
Easy way for the user to validate that deployed qusal to dom0 is latest versin (reduce user errors)

Instructions in global README.md leaves the user to find its own way to pass ben-grande public key to dom0. Instructions could be better, and lead the user to different sources to verify the public key(eg https://keys.openpgp.org/search?q=00C64E14F51F9E56).

That is correct, I can instruct better on how to acquire my key. I think most people don't instruct it completely to leave the user to make their own judgement of what they are reading and finding the key to be trusted.

It is also available at my protfile repo and the commit was signed by the coding key.

Github will then show verified commits (no more unverified yellow, scary commit traces on repo).

I actually did not add the key to Github settings on purpose. If my account is compromised, the intruder can modify the trusted key and Verified commits will appear. Yes, still needs to bypass Multi-factor authentication to be able to hack my Github account, but I don't want to teach people to trust the Github infrastructure.

Proposed solution

Publish public key to seperate ben-grande repo.

Sign that commit with said public key

Link main README.md to repo containing public key as well as where the author also published the public key to other public keyservers which propagated it elsewhere.

Maybe even add that verification to qusal dom0 helper

I believe the profile repo fills the above role of steps 1-3, step 4 remaining to be done.

Additionally (unrelated), maybe add in helper script the following output to help user (and ad to issue template):

Have the dom0 git fetcher script output:

git commit of fetched to dom0 git repo

Can you please clarify which update method are you using?

I am still thinking of what is the best option to include in the helper.

It is difficult to automate this step due to Qubes OS restrictions to Dom0. I am thinking of how to have a better UX in this front.

have the helper script call setup script to reduce user error of salt recipes deployed

That can only happen on updates, not to bootstrap qusal, unfortunately.

have the helper script verify the last commit against imported and checked public key

Doable but I didn't do that to not enforce how the user should update. I think you saw qubes-third-party-integrations, I am still unsure of the best update method. Unman does RPM repository, but I don't have the finances to run a server on this free project at the moment. I also did not finish the RPM spec build, needs to be build only in Fedora, doesn't work on Debian unfortunately via the RPM deb package.

The value to a user, and who that user might be

Easy way for the user to have project's public key inside of dom0.

Easy way for user to validate commit domu to dom0 qusal repo

Easy way for the user to validate that deployed qusal to dom0 is latest versin (reduce user errors)

I think these are good ideas, I am worried about editing the user keyring though, I always create a separate keyring for the formulas installation when necessary. Git with GPG does not allow to specify a keyring og gpghome, only the gpg.command script, which can set these.

And I know that the following is unfortunately necessary and long as of now:

git verify-commit HEAD
git submodule foreach git verify-commit HEAD

Pulling git commits has been easier for me because I am doing so much changes that making a proper versioning and release has not been the goal yet, for users to update with signed tarball of a certain git tag. In the future this may be an option.

Hopefully last git history rewrite?

Yeah, sorry, I am trying to keep the history clean, but as I am not doing PRs to my own repo, but pushing to main, when I rewrite, I understand the people may encounter disjoint histories.

When I make the first release, I will stop with these rewrites... Or maybe I stop now...

output last commit id

I think there are multiple issues on this issue, please open a separate one for better tracking of resolved and unresolved issues.

What do you mean by output last commit id? You mean after an error occurs with the formula after calling qubesctl?

Instructions in global README.md leaves the user to find its own way to pass ben-grande public key to dom0. Instructions could be better, and lead the user to different sources to verify the public key(eg https://keys.openpgp.org/search?q=00C64E14F51F9E56).

That is correct, I can instruct better on how to acquire my key. I think most people don't instruct it completely to leave the user to make their own judgement of what they are reading and finding the key to be trusted.

Understood. Still best practices to not leave commits unverified on github. This is not against givine proper guidelines or even better, automatizing helper scripts to check things properly.

It is also available at my protfile repo and the commit was signed by the coding key.

Understood. Also missed that one personally. Maybe link your ben-grande general landing page with link to subrepo where keys can be found.

Github will then show verified commits (no more unverified yellow, scary commit traces on repo).

I actually did not add the key to Github settings on purpose. If my account is compromised, the intruder can modify the trusted key and Verified commits will appear. Yes, still needs to bypass Multi-factor authentication to be able to hack my Github account, but I don't want to teach people to trust the Github infrastructure.

Again, understood. But circular trusting with verified commits under github + helper scripts permitting to download key under helper script (--home there could land wherever harcoded) would permit helper for dom0 upgrade to have git repo in check, report commit id, verify against public key AND give users a quick ref to point you to commit when opening an issue.

Proposed solution

Publish public key to seperate ben-grande repo.

Sign that commit with said public key

Link main README.md to repo containing public key as well as where the author also published the public key to other public keyservers which propagated it elsewhere.

Maybe even add that verification to qusal dom0 helper

I believe the profile repo fills the above role of steps 1-3, step 4 remaining to be done.

Right.

Additionally (unrelated), maybe add in helper script the following output to help user (and ad to issue template):

Have the dom0 git fetcher script output:

git commit of fetched to dom0 git repo

Can you please clarify which update method are you using?

Dom0 Update with Git

Dom0 Update by literally copying the git repository

Dom0 update but coying whole git repository. Still testing qusal here, and not yet confortable with sys-git + USB Security dongle hosting private key. Will have to dig that down eventually but haven't done that yet. So not really using sys-git right now with split-gpg.

I am still thinking of what is the best option to include in the helper.

It is difficult to automate this step due to Qubes OS restrictions to Dom0. I am thinking of how to have a better UX in this front.

have the helper script call setup script to reduce user error of salt recipes deployed

That can only happen on updates, not to bootstrap qusal, unfortunately.

Also understood.

have the helper script verify the last commit against imported and checked public key

Doable but I didn't do that to not enforce how the user should update. I think you saw qubes-third-party-integrations, I am still unsure of the best update method.

To be honest, I think the git approach is more for advanced users, your helper to copy whole dir from secluded qusal qube hosting clone is actually a really nice hack to help moving things to dom0 which as of now is a trusted qube anyway and should not be used for anything else in my opinion.

Unman does RPM repository, but I don't have the finances to run a server on this free project at the moment. I also did not finish the RPM spec build, needs to be build only in Fedora, doesn't work on Debian unfortunately via the RPM deb package.

Understood. TBH, rpms for dom0 goes back to qubes integration, which I think should be an outcome of either shaker/qusal and I think QubesOS would be more open to this after qusal becomes mature and well tested. Deploying sys-cacher for example SHOULD land as a RPM deployment, built by the qubes-builder and land under QubesOS. We briefly discussed that elsewhere for contrib repo, that was discussed under last qubes mini-summit under marek conference on how to contribute to QubesOS and I still believe this should be the way to upstream. Agreed contrib are not well maintained but they are more aimed as of now as static softwares to be opt-in tested by users, but shaker/qusal seem the best candidates to be upstreamed WHILE being tested by many more.

Again, not sure what would stop low-volume/bandwidth projects like salt recipes packaged under rpms from being hosted under github (RPM repos are nothing more then deployed static webpages which could be pushed as "release" without the need to self-host?

The value to a user, and who that user might be

Easy way for the user to have project's public key inside of dom0.

Easy way for user to validate commit domu to dom0 qusal repo

Easy way for the user to validate that deployed qusal to dom0 is latest versin (reduce user errors)

I think these are good ideas, I am worried about editing the user keyring though, I always create a separate keyring for the formulas installation when necessary. Git with GPG does not allow to specify a keyring og gpghome, only the gpg.command script, which can set these.

Agreed. But yet again, it is one thing to import key into local dom0 keyring and ultimately trusting said public key. Eg i'm totally ok with git warning

[user@dom0 ~/QubesIncoming/heads-tests-deb12-nix/qusal(main)]
(129)$ git rev-parse HEAD | xargs git verify-commit
gpg: Signature made Thu 21 Mar 2024 04:53:25 PM EDT
gpg:                using EDDSA key EFDA5D7E9A01FA99BFA062E100C64E14F51F9E56
gpg: Good signature from "Ben Grande (Code signing key) <ben.grande.b@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF38 3487 5B65 7587 13D9  2E91 A475 969D E4E3 71E3
     Subkey fingerprint: EFDA 5D7E 9A01 FA99 BFA0  62E1 00C6 4E14 F51F 9E56

Maybe that is not best practice but tot me good enough?

And I know that the following is unfortunately necessary and long as of now:
git verify-commit HEAD
git submodule foreach git verify-commit HEAD
Pulling git commits has been easier for me because I am doing so much changes that making a proper versioning and release has not been the goal yet, for users to update with signed tarball of a certain git tag. In the future this may be an option.

Above were just suggestions, of course.

output last commit id

I think there are multiple issues on this issue, please open a separate one for better tracking of resolved and unresolved issues.

I will leave you tracking whatever you think pertinent for implementation/more broad discussions.

What do you mean by output last commit id? You mean after an error occurs with the formula after calling qubesctl?

Ideally, for the sake of issue tracking, I think users need a easy way to provide you through issues the version of qusal that was used and failed. This will be one thing when signed tags, but since the project seems to grasp the eyes of many interested into persona targetting salt recipes and the scope of your project is actually targetting a lot of long time issues under QubesOS, I think it would help you track down issues, bissect code and find origin of implementation changes if users were having a quick way to provide you the commit used.

This is implementation detail, but current issue of dom0 deployment (I ran into it by missing running setup after bringing coede to dom0 myself) would be to hook up, if possible and the simplest for you a quick way for the user of tracking qusal DEPLOYED (setup'ed) salt recipes.

Again, maybe the simplest would be to provide simple instructions under issue creation guidelines and skip implementing this as code but documentation when comes the time to create an issue. Problem with user issue reports is always to make sure we talk about a specifif version and as of now, since not rpms, there might be a difference between coe checkout out in trusted qube where code is downloaded/forked, what was synced to dom0 and how, and what is deployed under dom0 (setup script) to be applie on next qubesctl call.

More I think about, the more clear it comes to me that the simplest would probably to modify your setup script (which copies salt recipes to be applied on next qubesctl calls) and for that script to report on commit id, and validate signatures and report this is a clean output to the user. To minimize hustle, maybe calling setup without arguments should do nothing but give usage report of the script, and that script changed so that --deploy is actually doing something, and when called without argument, report on integrity and commit id?

More I think about, the more clear it comes to me that the simplest would probably to modify your setup script (which copies salt recipes to be applied on next qubesctl calls) and for that script to report on commit id, and validate signatures and report this is a clean output to the user. To minimize hustle, maybe calling setup without arguments should do nothing but give usage report of the script, and that script changed so that --deploy is actually doing something, and when called without argument, report on integrity and commit id?

It is in my plans to do an easier installation of qusal, considering that there is currently no good way to install 3rd party software in dom0.

I read and reread this issue and I am lost. Sorry @tlaurion, next time open one issue per topic.

Throubleshoot doc has been created.
Key was already in a separate repo
To follow RPM for easy setup and timely updates: https://github.com/ben-grande/qusal/issues/59
Verification with Dom0 helper cannot work on first install, and even on update, it is not easy to do such thing with git due to it's nature. When there are signed tags, signed archives and signed RPM repository, this will be possible, but still won't be simple on first install, only update.
To validate if commit in dom0 is up to date is just like in any other repo, nothing specific to qusal, as I do many commits constantly, I recommend always pulling new commits to update your repo. A way to report version has been added to issue template git rev-parse HEAD, that is all.

ben-grande / qusal