Join GitHub today
QubesOS Template #153
Thanks for creating this issue!
I think the steps include:
Is it possible to (easily) convert standard Debian testing installation into SGOS? In that case, building the template can be just an addon to building standard Debian template (the same way as Whonix template is built). Links:
As for testing GUI agent - all the relevant packages are available in http://deb.qubes-os.org/r3.1/ (signing key) installing
One problem is HVM usage - in Qubes 3.x PV and HVM diifers much (for example you can't switch between those modes for a VM without recreating it). It will be much better in Qubes 4.0 (HVM/PV is just a VM changeable property there), but we're still at least few months away from having stable enough version for testing SGOS there.
Most likely I've forgotten about something here, will post an update in such a case.
random important thoughts on the subject:
note: ive been running qubes as my primary machine since the original alpha. someone asked me why i never filed a bug report and i figured its probably because i am annoyed that the qubes people dont use qubes as their primary computing platform and they are very slow to fix bugs and sensitive to criticism. that said, qubes-os is one of the most important projects in human history. it is the first operating system manifestation of attack surface mitigation through isolation and separation moving up and down through all the modern layers of virtual abstraction - in the computational sense - to create an ecosystem/interface that both promotes and enforces secure human operating procedures or workflows... and the architecture is truly elegant. the developers are in a world of their own. i dare say that projects such as subgraph and qubes belong somewhere in the same chapter as openbsd (its a bit early to say they are on the same page... i'll save that compliment for the next decade if everyone keeps their shit together).
the devs have a theory that either redhat or oracle is going to buy them (dafuq?) and the obsession with pv is unnecessary (fast sec is best sec lel?!). i believe that this implementation should lean towards HVM first and have a sane upstream technology supplychain. qubes is a wonderful security technology in the form of a framework, but the qubes-os distribution is an ugly and ill-organized mess. the choices they made like kde, fedora, obsession with pv, no domu security whatsoever, etc etc are testament to both how successful attack surface mitigation through isolation can be and how understaffed and underfunded qubes is (not to mention unappreciated and maybe even a little unimaginative).
i think we shouldnt start with debian template and make subgraph. we should start with whonix-ws template. if we can produce a disposable whonix-gw based subgraph implementation we will have solved all possible problems above the hypervisor on qubes (with respect to the problem in question). the next step is to get a subgraph based dom0 (obviously most of subgraph will not be necessary in dom0 for qubes but that doesnt mean we should have something retarded there like fedora+kde. orthogonality is one of the pillars of computer science and qubes fails here miserably). if they put their egos aide and apply the same standard of excellence to the distribution that they have applied to the framework they will adopt all of this upstream... if not we'll have "whosubqubesnixgraph-os" and more users will be running qubes on subgraph than qubes on qubes-os (because it will be obviously better). that should teach them to defy the majesty of my most excellent demands (ok just trying to be funny here for all you autistic geniuses out there)... im sure the whonix people will adopt it immediately so maybe the qubes people will take a hint early. if not i will just laugh for a longer period of time.
one thing that has not yet been mentioned anywhere is having metaproxy with whonix-gw and various challenges providing a consistent and sustainable secure-workflow experience. eventually subgraph needs to have tight integration with whonix-gw. this is a discussion for after many milestones though.
Subgraph OS is not Open Source yet. Reference:
Do you have a ticket for that yet?
Unfortunately, it has not been answered yet if Subgraph OS is more than its Debian packages. And the source code for the packaging has not been published. If there was a list of packages (or ideally a meta package) that defines the diff between Debian testing and SGOS, then that might be doable.
@matthaab yes it is, all of the relevant code is up on github (and already was there). Some patches to live-build are not, but they are not particularly relevant either (ie they don't affect the outcome, just working around some bugs from upstream). If you see something specific we may have missed let us know.
This ticket is becoming a source of and a reference to too much misinformation about our project.
Subgraph OS has always been Open Source. All source code for all custom components are on Github and have always been there. It took us some time to develop correct Debian packaging due to the our initial inexperience with Debian and the special complexity of packaging Go language applications. We have mentioned this before and nobody offered to help.
Nobody has ever tried to build an ISO that we're aware of or asked us for help to do so. It's always been technically possible to build your own ISO, but until recently the process wasn't very well documented and at times the build required some manual intervention for reasons beyond our control.
It was rather inconvenient for us when the only Debian live-builder maintainer quit suddenly over internal Debian politics:
I'm going to close this ticket and I invite anybody working on creating a template for Qubes to open new tickets for any specific obstacles that we can address.
However, I failed to build Subgraph OS since it is too difficult. David McKinney had agreed about a missing snapshot apt repository.
Quote David McKinney
My other questions Is subgraph os more than its Debian packages? and What is the status of the subgraph deb apt repo? / What is the status of debootstrapping subgraph? were also supposed to deepen my understanding of Subgraph OS internals. Because if the answer would be "yes", then it may be not too difficult to create a Qubes template with Subgraph OS.