[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Install/Update of qubes-whonix package?

@nrgaway

I’m a bit confused on the install/update objectives here…

Is the “qubes-whonix” package meant to only be installed with the build script?

Or is it also meant to be updated via the Whonix APT repository using apt-get (i thought yes)?

Also, when installed with the build script, is it meant to be called via the Qubes qubes-builder script or the Whonix build script (i thought via whonix)?

[quote=“WhonixQubes, post:1, topic:866”]@nrgaway

I’m a bit confused on the install/update objectives here…

Is the “qubes-whonix” package meant to only be installed with the build script?[/quote]

No, it will be used during the install process to install the bits and pieces that are considered update-able, everything not related to the actual setup of the template to accept Whonix. Then if there are any improvements, bug fixes, etc qubes-whonix will be updated to reflect those changes and then will be available as an apt-get update.

Or is it *also* meant to be updated via the Whonix APT repository using apt-get (i thought yes)?

Also, when installed with the build script, is it meant to be called via the Qubes qubes-builder script or the Whonix build script (i thought via whonix)?

Eventually it will be called from the whonix installer, but currently I am using the qubes-builder to build the package (as well as the whonix-setup-wizard and python-guimessages). I see this question coming … why? For a few reasons…

  1. Its not yet integrated into the Whonix repo and build functions
  2. Currently I Install the OS, then Whonix, then additional packages required for Qubes, then Qubes then finally qubes-whonix. Whonix is so much more difficult to install afterwards since it does so many checks and can fail in many spots and I have had the best success installing it first.

Any clearer?

Yes. Thanks! :smiley:

[quote=“nrgaway, post:2, topic:866”]Eventually it will be called from the whonix installer, but currently I am using the qubes-builder to build the package (as well as the whonix-setup-wizard and python-guimessages).

I see this question coming … why? For a few reasons…

  1. Its not yet integrated into the Whonix repo and build functions
  2. Currently I Install the OS, then Whonix, then additional packages required for Qubes, then Qubes then finally qubes-whonix. Whonix is so much more difficult to install afterwards since it does so many checks and can fail in many spots and I have had the best success installing it first.[/quote]

Got it. Yeah, I suspected this might still be in transition between qubes-builder and the Whonix installer. No problem, just checking in.

Got it.

Questions on this part…

What APT repository is this qubes-whonix package to be updated from? I’m guessing Whonix’s SourceForge repo?

What is to be the organizational process between people for coordinating and publishing such updated versions to the repository? Do we notify Patrick with a Git repo commit/tag version of qubes-whonix, have him verify the code additions, and then he makes a .deb package and uploads it? [Probably no established process yet?]

What APT repository is this qubes-whonix package to be updated from? I'm guessing Whonix's SourceForge repo?
Good question to nrgaway.
What is to be the organizational process between people for coordinating and publishing such updated versions to the repository?
There is indeed no established process yet.
Do we notify Patrick with a Git repo commit/tag version of qubes-whonix, have him verify the code additions, and then he makes a .deb package and uploads it?
That could work. The qubes-whonix package is relatively small and easy to audit. I'd only audit it for non-maliciousness. Wouldn't do any actual testing.

Alternatively, depending on how much a derivative qubes-whonix wants to become, feel also free to ship your own repository.

I’d suggest enabling it using something similar to Whonix Repository Tool (https://www.whonix.org/wiki/Whonix-APT-Repository) or patching Whonix Repository Tool with some extra “if Qubes then, add this extra signing key and this extra repo”. Otherwise for enabling the repository by default for everyone, I can tell from experience, that a lot would complain.

Another alternative, perhaps you already have some Qubes repository enabled by default? Perhaps that’s how nrgaway is currently doing it? Relying on the Qubes team for audit and upload?

Good question to nrgaway.[/quote]

Yeah, I think it makes sense to use the Whonix repo, since Qubes represents the more static OS infrastructure beneath Whonix and Whonix is more like the dynamic application on top of Qubes that is changing more often.

There is probably more flexibility for dynamic development by basing such things here in the Whonix community.

Qubes Git repos are seemingly often not in a consistent updated or stable state, which could also further interfere with plans to support build instructions, if we published “qubes-whonix” through ITL infrastructure.

We could certainly also ping the Qubes team and community for additional vetting when readying a new “qubes-whonix” package version.

That could work. The qubes-whonix package is relatively small and easy to audit. I’d only audit it for non-maliciousness. Wouldn’t do any actual testing.[/quote]

Sounds good. Yes, checking for non-maliciousness would be the only default expectation upon final merging/release into Whonix.

[quote=“Patrick, post:4, topic:866”]Alternatively, depending on how much a derivative qubes-whonix wants to become, feel also free to ship your own repository.

I’d suggest enabling it using something similar to Whonix Repository Tool (https://www.whonix.org/wiki/Whonix-APT-Repository) or patching Whonix Repository Tool with some extra “if Qubes then, add this extra signing key and this extra repo”. Otherwise for enabling the repository by default for everyone, I can tell from experience, that a lot would complain.[/quote]

Yeah, thanks. I think keeping releases tied into existing Whonix project repository is the way to go still at this point.

People already trust the infrastructure of the repo and team member(s) who filter what code gets into it (Patrick).

There is a Qubes update repository in the Whonix templates now for updating the Qubes integration tools.

However, this Qubes update repository is not related to the Whonix templates.

The original ITL release of the Whonix templates is solely contained within the Qubes build scripts and requires manually building a new set of templates to update right now (which hasn’t been re-done by ITL as of yet).

The “qubes-whonix” package is now a new entity since the original ITL release. I suspect the “qubes-whonix” package will be incorporated into his next upcoming version, but maybe not with APT update capability yet, until prepared and processed through the Whonix repo.

Good question to nrgaway.

There is indeed no established process yet.

That could work. The qubes-whonix package is relatively small and easy to audit. I’d only audit it for non-maliciousness. Wouldn’t do any actual testing.

Alternatively, depending on how much a derivative qubes-whonix wants to become, feel also free to ship your own repository.

I’d suggest enabling it using something similar to Whonix Repository Tool (https://www.whonix.org/wiki/Whonix-APT-Repository) or patching Whonix Repository Tool with some extra “if Qubes then, add this extra signing key and this extra repo”. Otherwise for enabling the repository by default for everyone, I can tell from experience, that a lot would complain.

Another alternative, perhaps you already have some Qubes repository enabled by default? Perhaps that’s how nrgaway is currently doing it? Relying on the Qubes team for audit and upload?[/quote]

I’m not too sure how this is going to work. The 9.6 branch is ready to go so you could look at the code and add it to the Whonix repo; so if that’s enabled so will be qubes-whonix.

The Debian package is also complete. You will see a Makefile.builder. That needs to remain untouched since currently qubes-builder builds the package and that Makefile has all the code required to tar up an .orig file; install the packages to debian/qubes-builder, etc. Your Makefiles remain for when it is built with Whonix in the future but currently they are automatically removed during the qubes build process.

The plan is to release the Whonix 9.6 version very soon. If we can’t get a repo going quick enough on your end; I’m sure qubes can host it for now.

https://github.com/nrgaway/qubes-whonix/tree/9.6-1

[quote=“nrgaway, post:6, topic:866”]I’m not too sure how this is going to work. The 9.6 branch is ready to go so you could look at the code and add it to the Whonix repo; so if that’s enabled so will be qubes-whonix.

The Debian package is also complete. You will see a Makefile.builder. That needs to remain untouched since currently qubes-builder builds the package and that Makefile has all the code required to tar up an .orig file; install the packages to debian/qubes-builder, etc. Your Makefiles remain for when it is built with Whonix in the future but currently they are automatically removed during the qubes build process.

The plan is to release the Whonix 9.6 version very soon. If we can’t get a repo going quick enough on your end; I’m sure qubes can host it for now.

https://github.com/nrgaway/qubes-whonix/tree/9.6-1[/quote]

Awesome that things are ready for 9.6! Great work!

Unless there is an emergency reason to release right away, then it is probably better for the project to establish a lasting convention and process of using the Whonix repo for the “qubes-whonix” package.

That way, there doesn’t unnecessarily have to be split versions regarding the “qubes-whonix” update infrastructure in the future, which would further complexify user support issues, etc.

There’s already an issue of uncertainty right now between users on the old Dual-HVM platform and the new ProxyVM + AppVM platform.

As far as getting the Whonix repo setup for this…

I will look through the “qubes-whonix” package today.

Hopefully Patrick can do the same soon and publish to the Whonix repo.

And then we can have ITL build and release new RPMs.

Does this sound okay?

Yes, I think a third repository would overcomplexity things.

I try adding the qubes-whonix package asp.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]