Design and create salt formulas distribution method

[marmarek]

Since we've completed VM configuration stack, we need some method for distributing salt formulas. Currently the base formulas (default VMs, Whonix etc) are installed as rpm packages. But this doesn't scale well, especially for community-developed formulas (because rpm package can do a lot more than putting a simple text file in /srv/salt, so one should install packages in dom0 only from ultimately trusted places).

Standard approach for Saltstack is using git or Salt Package Manager. We may use something based on either of them, but need to add a "qrexec proxy", which will verify signatures (similar to qubes-dom0-update) (it isn't clear to me whether SPM support signatures at all...). Or we may design/use something different.

Then, we'd need some UI to import/select trusted keys. The whole point here is to support 3rd-party formulas, not only those provided by ITL. While Salt formula can do whatever it like to the system (same as rpm package), it is much easier to audit, because it is just a text file, usually very short.

A single formula may consists of multiple files. Example formula for installing Martus, based on https://github.com/QubesOS/qubes-issues/issues/1836#issuecomment-213575740: https://gist.github.com/marmarek/29f9a4a1f3a7a457cf2b449ab0b0e2f4 (place those files in /srv/salt/martus, then execute qubesctl top.enable martus && qubesctl --all state.highstate - only in Qubes 3.2)

cc @mfc @bnvk @andrewdavidwong

[andrewdavidwong]

Would it be possible to adapt Split-GPG for signature verification?

[marmarek]

I don't think it would be good idea - in the end we need dom0 to verify the signature, otherwise some VM may in practice gain control over dom0 (if you compromise formulas verification path, you can configure dom0 to do anything). Also Splig-GPG is mostly useful for using privatekeys, not just verification.

[andrewdavidwong]

So, basically, it's the same problem as the one faced in designing the backup-restore model, right? We have some input which has to be verified in dom0, but we don't want anything in dom0 to parse potentially malicious input before it gets verified. Would it make sense to approach this in the same way?

[marmarek]

In case of backup it is additionally encrypted. Here we want only signature (not simple HMAC).

[bnvk]

Then, we'd need some UI to import/select trusted keys. The whole point here is to support 3rd-party formulas, not only those provided by ITL. While Salt formula can do whatever it like to the system (same as rpm package), it is much easier to audit, because it is just a text file, usually very short.

I'd been assuming we'd a UI for the browsing / installing / removing of salt formulas from a users machine, thus this would involve more than just the key management, and by keys I assume PGP keys correct @marmarek ? In both cases, I was thinking making this engaging and welcoming with icons and names.

Since the .sls files appear to just be YML format, are they flexible enough to just add values to the existing fields like:

martus:
  recipe:
    - title: Martus
    - description: Martus is a free, open source, secure information collection and management tool that empowers rights activists to be stronger in their fight against injustice and abuse.
    - icon: path/to/logo.png
  qvm.vm:
    - present:
      - template: debian-8-martus
      - label: blue

And then to improve the usability of the key handling could we also store that data in same .sls file or some other file with the package?

maintainer:
  - name: Emma G.
  - email: emma@anarchy.org
  - website: https://anarchy.org
  - keyid: 0x3B0F8CCA
  - fingerprint: 1B5BAEEA01DBE9EC8420E5B668B2C4A23B0F8CCA 
  - avatar: path/to/avatar.jpg

My reasoning is that users tend to understand the concept of interacting with people, companies, or projects a bit better than importing a cryptographic key and of course we could still show the full fingerprint under a hidden menu (for developers we've established trust with) or shown for untrusted sources

As per my work on the New "Qubes Manager" in #1870 I envisioned calling these Recipes and clicking on the button would launch a separate window that. Now that I've got the hang of Gtk + python a bit I could pretty easily make a little interface showing these concepts with test data

[adrelanos]

In my view, users do not understand well to decide to trust various individuals or companies. They want to get task x, y, z done. For the goal towards mass adaption of Qubes, rather than inventing a key and trust scheme, I would suggest to have some well tested, well supported official recipes for common cases we want to support.

[marmarek]

In my view, users do not understand well to decide to trust various individuals or companies. They want to get task x, y, z done. For the goal towards mass adaption of Qubes, rather than inventing a key and trust scheme, I would suggest to have some well tested, well supported official recipes for common cases we want to support.

Yes, on the second thought it seems to be a better option.

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail. Anyway we definitely need some GUI with name, description, icon of a formula to install. That metadata can probably go as a separate file.

[bnvk]

@adrelanos @marmarek what i'm envisioning would look and feel like a normal "app store" experience, e.g. Apple App Store, Google Play, etc... for the trusted recipes. I think it would be nice to down the line offer installing recipes that are not official, but are still secure :)

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail.

I'll just make a small example with the metadata and how I see it being implemented toward the above goal.

[mfc]

are we actually targeting R4.1 for this? I've moved to R4.2.

once there is an agreed-upon data structure, @ninavizz it would be great to get your input on what that could look like. also i'm not clear exactly where it should live -- yes referenced from the Qubes Manager but should there also be a dedicated widget or it being linked from some other existing widget? just as all other functionality is decomposed elsewhere.

and once there is basic agreement, i would be happy to work with community to draft some example recipes.

[ninavizz]

Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is (I have a vague understanding that it has to do with package management and config scripts), and suspect that anyone who would, would be comfortable managing that in the CLI?

TL;DR, there are A LOT of things that Qubes needs GUI'd and made more usable. I'd like to get a centralized pool of such things, so that we can maybe better prioritize?

@andrewdavidwong could this get a UX tag? :D

[unman]

On Wed, Mar 31, 2021 at 05:20:27PM -0700, Nina Eleanor Alter wrote:

Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is, and suspect that anyone who would, would be comfortable managing that in the CLI?

TL;DR, there are A LOT of things that Qubes needs GUI'd and made more usable. I'd like to get a centralized pool of such things, so that we can maybe better prioritize?

@andrewdavidwong could this get a UX tag? :D

Salt is a configuration tool - you use it when you update your system, and you used it (behind the scenes) when you first set up your Qubes system.

You can use Salt to easily setup qubes, or to install particular capabilities in to templates or qubes. You can install salt states using a standard fedora package - whether you would want this to automatically implement the state is worth discussing.There's been discussion in the Forum - I prefer to allow users to review the state before running it, but then I mostly want users to understand what they are doing ,( and learn more), rather than just click and install. This doesn't make me a wonk, security or otherwise.

[ninavizz]

@unman I won't tell anyone you're a wonk, promise! ;) The SecureDrop team (whom I also work with) use Salt to configure our bespoke Qubes Workstations, so it's a term I'm familiar with... I just somewhat suck at comprehending things I can't visualize. But it's worth it to understand those things to me, if it can help me give things a visual framework for others to better understand them with.

@mfc Honestly, the best GUI would come from the designer working with a handful of formulas the community agrees are good/solid to use as a basis for building a GUI from. Data structuring, how exceptions/rules are established, etc. Do you press "Go" on them, or what actions get taken? Stuff like that.

Also, something like this I envisioned going into the proposed #6483, likely under the "Advanced" pulldown (or in place of it).

[mfc]

ok makes sense, i will try to coordinate the creation of some example salt recipes. would someone at FPF be interested in contributing some more general journalist example recipes? any interest from @unman @tlaurion @tasket ?

FYI this is an old mock-up but i think starting from scratch more systematically as you describe is the way to go.

[ninavizz]

I don't think any of FPF's journalist users have ever actually used Salt? Most are non-technical Mac users. Less curious/excited about technology that doesn't come with an 800 number to call when help is needed, and simply wanting stuff "to work" so they can focus on their investigative projects. Which I say with no doubts of Salt as a great opportunity, but more in acknowledgement of it as a current strange-unknown to our core users (and, heck, to me!).

Libre software's appeal is in its trustworthiness wrt security. The decentralized community-driven part of it of course "why" that is, yet it also imposes new behavioral and expectations shifts for end users that can feel abrupt and burdensome.

I really love the idea of creating an app-store like experience (wrt ease/access) for browsing, consuming, and sharing recipes! It feels like a terrific vehicle to present the libre ecosystem's roots in community support as an appealing thing, vs a draining thing in its otherness.

Back to Salt, tho— @conorsch is a huge Salt fan, and I mentioned this ticket to him earlier today. I definitely think he'd be a great contributor to this thread!

[fepitre]

This may be a related topic: https://groups.google.com/g/qubes-devel/c/VQOKxsMG0-Q/m/mZ2KIpJUCQAJ

[DemiMarie]

I really love the idea of creating an app-store like experience (wrt ease/access) for browsing, consuming, and sharing recipes! It feels like a terrific vehicle to present the libre ecosystem's roots in community support as an appealing thing, vs a draining thing in its otherness.

I absolutely agree, but with one caveat: we need to ensure that the recipes shared are legitimate, not malicious. That means that recipes must be cryptographically signed by their creators, and that there must be a mechanism for the reporting and removal of malicious ones. The Update Framework is ideal for the first part.

[marmarek]

I absolutely agree, but with one caveat: we need to ensure that the recipes shared are legitimate, not malicious. That means that recipes must be cryptographically signed by their creators, and that there must be a mechanism for the reporting and removal of malicious ones.

This solves the issue only partially. We'd need also a process for approving new creators or maybe even validating each recipe individually. Some stores (for example Firefox addons) have explicit markings which packages were validated and are more trustworthy - we could do a similar thing. But there is also a middle ground - some recipes may not not be strictly malicious, but may increase attack surface as a side effect (I believe this applies to most network services for example - like a recipe to setup web development environment intentionally exposed to your LAN). We could have some rating system based on what features given recipe use (idea similar to https://developers.home-assistant.io/docs/add-ons/presentation#security, although specific criteria will surely be different). Anyway, I don't think the latter should be a blocker. Rather, something necessary for this to scale.

[ninavizz]

All of this is important feedback to consider for both the UI itself, but also for the service design aspect of such a store. Off the top of my head, some kind of a verification system and probably a separate classification system and approved auditors/verifiers, will need to exist. That said, this does not sound like a small undertaking, and I question its priority over other more urgent/basic usability concerns.

[unman]

On Thu, Apr 01, 2021 at 05:28:18AM -0700, Michael Carbone wrote:

ok makes sense, i will try to coordinate the creation of some example salt recipes. would someone at FPF be interested in contributing some more general journalist example recipes? any interest from @unman @tlaurion @tasket ?

FYI this is an old mock-up but i think starting from scratch more systematically as you describe is the way to go.

No problem in generating recipes - we already have them for printer, caching proxy, multimedia player, qubes-builder, split-ssh etc etc. Would be more useful to start with what outcomes are wanted, and then contributors would know where to put their efforts. I know people like a nice GUI but why couldn't this just be assimilated in to the general (and familiar) package install process? It's easy to build packages that drop salt files, or even install the states.

[ninavizz]

Would be more useful to start with what outcomes are wanted, and then contributors would know where to put their efforts.

The above is so incredibly important for all of Qubes, before undertaking any specific effort(s). It's step 0 in most product design efforts in both the digital and analog worlds.

I've also been thinking... the only folks likely to think to themselves "I should run a Salt script!" are going to be native Linux users, IT folks, or developers. Folks also familiar with CLI interfaces—so, why should a GUI for this, be a priority now? It's just not a natural mental model for most users to want to run a script to configure things; you just go into each app's preferences to set things up, install PPD files, etc. After running "an installer" aka a package.

Much as I love the idea of the Salt store, I also question investing time on a project like this, when other areas of Qubes that new-to-Linux and new-to-VM users are more likely to encounter frustration with, have yet to receive usability love. Which isn't to suggest punting on this idea, entirely; only to not prioritize it ahead of other things, like a redesign of Qubes Manager, a redesign of the Devices Widget, major improvements to Clipboard and Split-GPG, and possibly a global File Manager or qubes-specific Task Bar.

In a couple weeks we'll begin interviewing users, as our first significant user research step following the deployment of the initial survey. From that, we'll learn a lot more about what users need/want from Qubes. I'd suggest re-considering UX priorities for the project, after findings are assembled, for +4.2 and beyond. Oh ya... and next-up on my own plate after finishing the app menu, is the Policies GUI. :)

[DemiMarie]

Much as I love the idea of the Salt store, I also question investing time on a project like this, when other areas of Qubes that new-to-Linux and new-to-VM users are more likely to encounter frustration with, have yet to receive usability love. Which isn't to suggest punting on this idea, entirely; only to not prioritize it ahead of other things, like a redesign of Qubes Manager, a redesign of the Devices Widget, major improvements to Clipboard and Split-GPG, and possibly a global File Manager or qubes-specific Task Bar.

I wholeheartedly agree with this. From what I can tell, QubesOS’s biggest limitations are (in no particular order):

• Limited hardware support.
• No hardware graphics acceleration.
• UI/UX.

The real question isn’t “Is QubesOS easy for us to use?”. It is, “Is QubesOS nearly as easy to use as Windows or macOS?”. If I cannot recommend QubesOS to my non-technical friends, that is a problem. That includes those who have a limited budget and are heavy gamers. They need an OS that can run AAA games on reasonably priced hardware, and does not require them to use a command line.

[unman]

On Mon, Apr 05, 2021 at 01:33:15AM -0700, Demi Marie Obenour wrote:

Much as I love the idea of the Salt store, I also question investing time on a project like this, when other areas of Qubes that new-to-Linux and new-to-VM users are more likely to encounter frustration with, have yet to receive usability love. Which isn't to suggest punting on this idea, entirely; only to not prioritize it ahead of other things, like a redesign of Qubes Manager, a redesign of the Devices Widget, major improvements to Clipboard and Split-GPG, and possibly a global File Manager or qubes-specific Task Bar.

I wholeheartedly agree with this. From what I can tell, QubesOS???s biggest limitations are (in no particular order):

• Limited hardware support.
• No hardware graphics acceleration.
• UI/UX.

The real question isn???t ???Is QubesOS easy for us to use????. It is, ???Is QubesOS nearly as easy to use as Windows or macOS????. If I cannot recommend QubesOS to my non-technical friends, that is a problem. That includes those who have a limited budget and are heavy gamers. They need an OS that can run AAA games on reasonably priced hardware, and does not require them to use a command line.

I think that the "heavy gamers" requirement is relatively unimportant in the great scheme of things. (Note that "relatively").

As to the salt store, it's a neat way of providing outcomes without using the command line except that for some outcomes configuration is required - e.g gpg, vpn. We could prompt during installation of course, assuming that users understood what information was required.

There is a strong tendency amongst Qubes users (and some devs) to think it is difficult to use. This has been played out in the mailing list for years. And there is an assumption that Windows and Macs are easy to use - they aren't, but familiarity has bred contempt. With good support, Qubes can be, and is, used successfully by non-technical users. If you are recommending Qubes and not providing the right level of support then you are doing your friends and Qubes a disservice.

[SvenSemmler]

They need an OS that can run AAA games on reasonably priced hardware I would consider any energy spend in this direction at this point in the development a total waste.

Agree with hardware support and UI/UX points and expect a 'salt store' if done right to be a major improvement to the UX and certainly 1000x more important than enabling gaming.

[DemiMarie]

They need an OS that can run AAA games on reasonably priced hardware I would consider any energy spend in this direction at this point in the development a total waste. Agree with hardware support and UI/UX points and expect a 'salt store' if done right to be a major improvement to the UX and certainly 1000x more important than enabling gaming.

“Enabling gaming” in this context refers to allowing qubes to use hardware-accelerated graphics, which is becoming more and more important with time. It’s really hard to drive a 4K monitor at any decent rate with software alone.

[SvenSemmler]

allowing qubes to use hardware-accelerated graphics

I'd use hardware acceleration if we had it, of course. But it's hardly a priority given target audience and current state.

It’sreally hard to drive a 4K monitor at any decent rate with software alone.

Not sure what you mean.

I have a 4+ year old ThinkPad with integrated Intel HD 630 graphics running Qubes OS R4.0 with a 4K monitor at 60 Hz. There was nothing to it other than plugging it into the correct port (for some reason 3840x2160 only works on the display port but not the HDMI port).

VLC crashes when I tell it to go full screen, but other than that I have no issues with it. I just played the first 4K trailer YouTube showed me in fullscreen, no issues (maybe a very slight stutter in action scenes).

[ninavizz]

With good support, Qubes can be, and is, used successfully by non-technical users. If you are recommending Qubes and not providing the right level of support then you are doing your friends and Qubes a disservice.

So: The above, by itself, is a significant caveat that I feel needs to be strongly considered in multiple contexts.

Not only does Qubes require "support," but it requires "community support;" which is completely new to folks also new to the libre ecosystem, and can be a major time commitment—while also not providing immediate/emergency options. It feels like a caveat that too many high-risk users will not be able to make work for them, for various reasons (from general patience, to risks that impose upon job needs, etc). Which I don't say to be a negative-nancy or to be difficult. It just feels like a simple reality that is not only a "Qubes problem," but more broadly also a linux and a libre problem.

Qubes' community support, really does seem to stand-out as the best of the best. Which I've heard in multiple places, and think is wonderful... and I realize has also been no small feat for Michael or Andrew to achieve. So, please also know, I have a very difficult time offering the above, as I don't want to diminish from the wonderfulness of what so many volunteers and paid contributors have busted their humps to make possible.

Do we "want" to impose that mandate of support-required onto all new and future users of Qubes?

[SvenSemmler]

Do we "want" to impose that mandate onto all new and future users of Qubes?

Do you think there is a way to design the UI/UX so users will just "get" how to use Qubes OS correctly?

Obviously there is work to be done to make it easier to interact with Qubes OS and also to make it prettier. There are also the obvious issues to just get started (hardware support, installation, certified/pre-installed laptops etc).

After all the is done, we are still pretty much at 0 I think.

In my imagination a new user needs something like a 5 minute video that explains why one would want to use Qubes, how it is structured, and how some basic workflow works (very high-level, just the basics) and how to find more help.

Then it would be very nice to have "wizards" (I know you will shriek but I don't know a better word) that kind of guide the user through setting up her first compartments, installs the software she needs and makes sure her theme choices (or just one standard theme) is applied in dom0 and all her qubes.

All of that stuff would obviously use salt in the background. It's also a huge task. And the more choice you want to offer the more work it will become.

So back to the original thread: having a way to review and distribute salt formulas would kind of crowd-source a lot of that work to the community to create formula for all kinds of applications and scenario upon which the above vision could be built.

Any way you slice it, if the goal is to empower new users to get going without a human guide or strong community support ... salt is the "magic" behind the scenes that will make that happen.

[unman]

On Tue, Apr 06, 2021 at 02:57:50PM -0700, Nina Eleanor Alter wrote:

With good support, Qubes can be, and is, used successfully by non-technical users. If you are recommending Qubes and not providing the right level of support then you are doing your friends and Qubes a disservice.

So: The above, by itself, is a significant caveat that I feel needs to be strongly considered in multiple contexts.

Not only does Qubes require "support," but it requires "community support;" which is completely new to folks also new to the libre ecosystem, and can be a major time commitment. It feels like a caveat that too many high-risk users simply do not have either the time nor the patience to wrangle. Which I don't say to be a negative-nancy or difficult. It just feels like a simple reality that is not only a "Qubes problem," but more broadly also a linux and a libre problem.

Do we "want" to impose that mandate onto all new and future users of Qubes?

You need only scan the myriad mailing lists, fora, and magazines, aimed at Windows and Mac users to see that these things are not new to people new to libre, unless you mean to distinguish the generally welcoming and helpful tone of Qubes community support ( my contributions excepted).

I've worked in a variety of support positions, and my view of Qubes is based on providing support to many new users. In my view, (and I've said this many times), the focus on individual qubes, in Qube manager and the default menu, is counterproductive for many new users. Providing a customised menu which is focussed on activities, setting up specific configurations (e.g. links to network drives, vpns), these are the things which I count as support.

[ninavizz]

You need only scan the myriad mailing lists, fora, and magazines, aimed at Windows and Mac users to see that these things are not new to people new to libre, unless you mean to distinguish the generally welcoming and helpful tone of Qubes community support ( my contributions excepted).

I have no idea what "things" you're referencing. Could you elaborate?

I mean, I'm a native Mac user, and could go on for hours about how about Qubes is alienating and strange, or simply "difficult;" when, it just doesn't have to be. Same, with most "Security" software. Which I don't say to be a know-it-all. I appreciate how hard it is to keep the Qubes project going, and how little funding there is to spread-across requisite resources. Yet friction = abandonment. It's' why people revert to using insecure products.

People love Macs, because they "simply work." Why not prioritize making that a goal for Qubes? Agency and empowerment to get done what each person uniquely need to get done, is what users desire; not the ability to do "anything and everything," nor a dependency upon others.

I appreciate that forums and mailing list are ongoing communications with users, but without actually studying how people use a tool and asking them questions throughout that process, it's not possible to understand why a thing is "hard" or how to shape a tool to better serve a user. With the Salt Recipes store, my gut response is "Why not just make settings and preferences easier for folks to manage?" Or, make it clearer that you install stuff on a template that is then 'activated' at the per-qube level.

Come to think—async comms sucks, and I'd really love to just do a call sometime. @unman you have my contact info, I think. If you'd be comfortable, I have an account to use an encrypted meeting tool called whereby, and I'd be happy to make time to chat at any time you could. Same to you @SvenSemmler (even tho I don't think you have my contact info). I need to re-key the research at qubes-os dot com email, otherwise I'd say just ping me there (unless you're ok pinging me there w/o GPG).

[SvenSemmler]

With the Salt Recipes store, my gut response is "Why not just make settings and preferences easier for folks to manage?" Or, make it clearer that you install stuff on a template that is then 'activated' at the per-qube level.

We share the same goal.

I am reacting to "Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is..."

It's NOT technically correct, but think of it as a scripting language. You can write scripts (formula) that automate installs and setting of preferences to be reused by others so they don't have to learn the details. These scripts need to be reviewed and then published in a trusted way to prevent abuse.

The difference between a script and a formula is that instead of a step-by-step description of what needs to be done, the formula describes the end result and let's Salt figure out how to do it. But for the purpose of this discussion that's irrelevant.

When you are done designing the settings dialog, there needs to be code that does something. When that something is about settings and preferences ... it will very likely be a salt formula, because that's the mechanism already built into Qubes OS for exactly that purpose.

Whenever you want to install something that's a bit more involved like a VPN tunnel, the ability to tether your phone to sys-net ... you would best do that using a salt formula that was reviewed by people you trust. Specifically so you don't have to research and find out yourself.

I see "design and create salt formulas distribution method" as the first step in a journey that will result in:

• having a better idea which features and functions are in high demand
• the best way to do it
• not insignificant amount of verification of that method
• the ability to pick and choose "the best" and make them built-in configuration options in Qubes... which brings us to "Why not just make settings and preferences easier for folks to manage?"

[andrewdavidwong]

You need only scan the myriad mailing lists, fora, and magazines, aimed

at Windows and Mac users to see that these things are not new to

people new to libre, unless you mean to distinguish the generally

welcoming and helpful tone of Qubes community support ( my contributions

excepted).

I have no idea what "things" you're referencing. Could you elaborate?

Community support really does seem to be the norm in the tech world, not just in open source and not just for OSes. I've had more problems with my smartphone and router than with my Qubes installations, and it's usually some fellow user on a forum who has come through with a solution (or with the bad news that there is no solution). Of course, some companies also offer direct support themselves, but I don't think it could ever match the sheer volume of community support for mass market products. You may not always realize that certain things are instances of community support because some of them are so developed, prevalent, and/or commercialized. For example, high school and university computer courses, Ask Leo, Stack Exchange, and even The Geek Squad are all examples of community support (perhaps most commonly for mainstream tech like Windows PCs), because none of them are from the hardware or software makers. (Community support can be paid or free too.) It's just that mainstream PCs are big enough to support that kind of ecosystem (where people can make a living or even build entire businesses based on functioning as community support), whereas Qubes is not.

Oh, and unman, you are by far one of the most consistently helpful people the Qubes community has ever known, so I would never want to except your contributions. :)

[unman]

On Wed, Apr 07, 2021 at 12:15:25AM -0700, Andrew David Wong wrote:

You need only scan the myriad mailing lists, fora, and magazines, aimed

at Windows and Mac users to see that these things are not new to

people new to libre, unless you mean to distinguish the generally

welcoming and helpful tone of Qubes community support ( my contributions

excepted).

I have no idea what "things" you're referencing. Could you elaborate?

The "things" were those mentioned, cited as examples of "community support", which it had been said would be new to users. I would also include, naturally, friends and family members.

Community support really does seem to be the norm in the tech world, not just in open source and not just for OSes. I've had more problems with my smartphone and router than with my Qubes installations, and it's usually some fellow user on a forum who has come through with a solution (or with the bad news that there is no solution). Of course, some companies also offer paid support, but I don't think it could ever match the sheer volume of community support. You may not always realize that certain things are instances of community support because some of them are so developed, prevalent, and/or commercialized. For example, high school and university computer courses, Ask Leo, Stack Exchange, and even The Geek Squad are all examples of community support (perhaps most commonly for mainstream tech like Windows PCs), because none of them are from the hardware or software makers. It's just that mainstream PCs are big enough to support that kind of ecosystem, whereas Qubes is not.

Yes.

Oh, and unman, you are by far one of the most consistently helpful people the Qubes community has ever known, so I would never want to except your contributions. :)

Thank you - I am overly short in my comments and, I fear, tone. Others are far more generous in time and help.

[unman]

A minimal effort solution will be to pull together any useful formulae and serve them from a repo. I already run Qubes repos for Ubuntu packages, and I'll extend this to include saltings. The only effort will be in reviewing any packages I find, writing up descriptions, and links to the origin. I think it would be good to provide two versions of each package - one which will drop the files in place for review and manual installation, and one which will automatically process. I'll do this and see how it looks - maybe test run on the list or in the forum. This isn't intended to pre-empt any discussions or UX development - just testing poc for salt delivery.

[ninavizz]

Community support really does seem to be the norm in the tech world, not just in open source and not just for OSes. I've had more problems with my smartphone and router than with my Qubes installations, and it's usually some fellow user on a forum who has come through with a solution (or with the bad news that there is no solution). Of course, some companies also offer direct support themselves, but I don't think it could ever match the sheer volume of community support for mass market products.

So... for men, this is true. Unfortunately, "community" has been a significant barrier to women entering tech. In some cases (Reddit) it's because a specific platform breeds toxic communities. More broadly though, I suspect it has more to do with how we're raised and experience the world around us, differently from dudes. For centuries women were expected to be dominated by their fathers or husbands, and in the 20th century that flipped. The remaining cultural fallout (in my own anecdotal observation) has men consciously or not, often trying to rescue women; and women, consciously or not, fighting to do everything on our own. For so many reasons. Everyone over-compensating for so much, all at the same time.

Those of us courageous enough to ask for support, I'd like to believe have often had great experiences—but they're different, from men's experiences. Guys I raced with (when I raced motorcycles), loved the diversity women added to our community, and would drop everything to help us—but that often resulted in many eager hands, but not any with the right qualifications. An entire clutch assembly was once installed backwards on my 125, because my buddies were just so eager to help me—a grown girlchild, who'd not been raised working on cars, as the boychildren had been (at least that's the standard in the US). So lots of women just live as adults, hyper-independent, or only ever reaching out to friends we trust. My own adaptation to that, was to become my own mechanic. It was a happy accident I also love mechanical engineering and am a natural gearhead, but its also a common anecdote girls hear: "You can't rely on anyone but yourself, so become an expert at everything and only ever accept help when you pay for it." Then of course, there's toxic dynamics in mostly-male communities when women enter. We all know those stories, so I'll not digress.

TL;DR, we cannot change broader social dynamics in our world. To be inclusive of women users and folks simply lacking the emotional/mental bandwidth to engage in community support, I'm extremely motivated to shape experiences to not require support. Not because "support is awful," because it's not. Especially here, with you all. Does that make sense?

Its to support marginalized users, more. To be inclusive, is to facilitate self-guided and self-empowering experiences, so that any individual no matter where they are on the autism or gender or social-comfort or cultural or other spectra, can succeed. I see SO much eagerness for social support in the security community, but not enough eagerness to shape self-guided experience opportunities for non-technical users. </nina-soapbox>

I see "design and create salt formulas distribution method" as the first step in a journey that will result in:

• having a better idea which features and functions are in high demand
• the best way to do it
• not insignificant amount of verification of that method
• the ability to pick and choose "the best" and make them built-in configuration options in Qubes... which brings us to "Why not just make settings and preferences easier for folks to manage?"

Right. My #1 kvetch with my own experiences of libre software to date, is the trend towards "empowering" users to do "everything" they may desire—which effectively disempowers them from doing anything, with ease.

So, yeah. The SALT Store (for lack of a less Capitalistic way of framing it) sounds like it should be kicked-off as a "project" perhaps, with a workshop. A workshop with a goal of learning what would make for effective moderation/oversight; where dependencies are, and how to define roles in that workflow. I'd be happy to facilitate if folks like @andrew, @unman, @mfc, and other nominees wd be keen to participate.

The actual GUI part of such an experience for end-users, sounds like the least of the "needs;" and TBH, could be done on a website that's bookmarked by default in a qube.

[SvenSemmler]

@ninavizz thank you for making this so clear. Totally get it and agree. If that workshop happens I'd love to help.

[gonzalo-bulnes]

Hi everyone :wave:, my 2 cents:

Much as I love the idea of the Salt store, I also question investing time on a project like this, when other areas of Qubes that new-to-Linux and new-to-VM users are more likely to encounter frustration with, have yet to receive usability love.

As a relatively new Qubes OS user, and an engineer in a product team otherwise, I couldn't agree more on the prioritization thoughts expressed by @ninavizz: understanding how to distribute Salt formulas can be extremely interesting, but there are currently (several,many?) usability topics that could have a much broader impact in terms of accessibility and adoption of Qubes OS.

The question of priorities probably boils down to what is currently the biggest opportunity for Qubes OS. Because of the potential impact for a broad range of people, I personally lean towards accessibility and adoption as a goal.

With that in mind, in most cases I when it comes to most Salt formulas, I would likely express the desired outcome as: "I want to be able to perform some activity (in a reasonably secure way)", say for the sake of example: "I want to be able to use SSH in a reasonable secure way" (which is admittedly not close to being an universal wish, but it's one I have). That outcome could be achieved, for example, by ensuring that a few qubes/VMs are configured to provide split-SSH via a Salt formula, but how it is achieved won't matter but for a smaller number of Qubes OS users.

Would be more useful to start with what outcomes are wanted, and then contributors would know where to put their efforts.

Now, all that being said, and to @unman's point: as someone who is interested in helping to achieve that outcome (a contributor) and someone who is interested in using Salt to explore how good a solution it could be to achieve other outcomes, I would like to "be able to distribute/install some Salt formulas on a daily basis in a reasonably secure way".

A minimal effort solution will be to pull together any useful formulae and serve them from a repo.

My take on it, is that it is fair to assume that the people interested in that narrower outcome are somewhat already invested in learning how Qubes OS works, and can probably make do if the development team provides targeted guidance in key areas. An I think @unman is on point thinking about "minimal effort" solutions.

Finally, to the topic of distributing Salt formulas: I found myself faced with this same issue myself, and thought about what I'd like to have found a few months ago, and ended up concluding that some documentation would have been be a good start for me (my limited experience, but I think I am part of the audience of people who would thinker with Salt formulas). I am writing some, that is limited to explaining how to make your own formulas easier to maintain (so keeping a whole lot of trust questions out of scope). I would find useful to be able to check how aligned that is to broader goals.

Back to @unman's point above: getting direction on what outcome would be desirable would certainly help me know where to focus the time I have to make my contributions more effective. Another way to say the same could be: making visible a list of desired outcomes at the contributor-level, would allow contributors to better coordinate their efforts towards supporting the user-facing outcomes that the Qubes OS team is prioritizing.

[andrewdavidwong]

Community support really does seem to be the norm in the tech world, not just in open source and not just for OSes. I've had more problems with my smartphone and router than with my Qubes installations, and it's usually some fellow user on a forum who has come through with a solution (or with the bad news that there is no solution). Of course, some companies also offer direct support themselves, but I don't think it could ever match the sheer volume of community support for mass market products.

So... for men, this is true. Unfortunately, "community" has been a significant barrier to women entering tech. In some cases (Reddit) it's because a specific platform breeds toxic communities. More broadly though, I suspect it has more to do with how we're raised and experience the world around us, differently from dudes. For centuries women were expected to be dominated by their fathers or husbands, and in the 20th century that flipped. The remaining cultural fallout (in my own anecdotal observation) has men consciously or not, often trying to rescue women; and women, consciously or not, fighting to do everything on our own. For so many reasons. Everyone over-compensating for so much, all at the same time.

Those of us courageous enough to ask for support, I'd like to believe have often had great experiences—but they're different, from men's experiences. Guys I raced with (when I raced motorcycles), loved the diversity women added to our community, and would drop everything to help us—but that often resulted in many eager hands, but not any with the right qualifications. An entire clutch assembly was once installed backwards on my 125, because my buddies were just so eager to help me—a grown girlchild, who'd not been raised working on cars, as the boychildren had been (at least that's the standard in the US). So lots of women just live as adults, hyper-independent, or only ever reaching out to friends we trust. My own adaptation to that, was to become my own mechanic. It was a happy accident I also love mechanical engineering and am a natural gearhead, but its also a common anecdote girls hear: "You can't rely on anyone but yourself, so become an expert at everything and only ever accept help when you pay for it." Then of course, there's toxic dynamics in mostly-male communities when women enter. We all know those stories, so I'll not digress.

I think we're talking past each other. I'm just trying to make a very simple point, that "community support" is commonplace in the tech world. By "community support," I just mean support for some piece of tech provided by an entity other than the official maker/provider of that tech. You could instead call it "unofficial support," if you prefer.

When someone takes a vehicle to an independent mechanic for repairs, that's also an example of community support, because vehicles are also pieces of tech, and independent mechanics are independent of the official makers/providers of those pieces of tech.

When I have problems with computer-related software or hardware, I usually start by using a search engine to search for the problem, and I often find some website where other people have had the same problem and some people have written some useful information that helps me try to solve it (e.g., a forum or a how-to article). In the vast majority of cases, I do not ask anyone for help. I just use the existing resources that have already been written (sometimes based on other people having already asked for help). I would think that this is what other independent people also prefer to do to try to solve their tech problems. Is this not a familiar experience? It seems almost too commonplace to be worth mentioning. It probably happens thousands of times a minute around the world.

(Also, remember that paid community support is still community support, as in the independent mechanic example.)

TL;DR, we cannot change broader social dynamics in our world. To be inclusive of women users and folks simply lacking the emotional/mental bandwidth to engage in community support, I'm extremely motivated to shape experiences to not require support. Not because "support is awful," because it's not. Especially here, with you all. Does that make sense?

I'm simply describing the way the world is, not the way it should be. Of course it would be better if support were not required. Most people aren't trying to design tech that will be problematic or hard to use. But that's a bit like saying it would be better if the field of medicine were not required. We can try to prevent the need for it as much as we can, but we can't escape it. The need is inevitable.

Its to support marginalized users, more. To be inclusive, is to facilitate self-guided and self-empowering experiences, so that any individual no matter where they are on the autism or gender or social-comfort or cultural or other spectra, can succeed. I see SO much eagerness for social support in the security community, but not enough eagerness to shape self-guided experience opportunities for non-technical users. </nina-soapbox>

I wouldn't count myself among the eager. I see community support as a necessary evil (specifically, the least bad option among the alternatives). I would much prefer a world where we could all be self-reliant and not depend on each other for help.

I see "design and create salt formulas distribution method" as the first step in a journey that will result in:

• having a better idea which features and functions are in high demand
• the best way to do it
• not insignificant amount of verification of that method
• the ability to pick and choose "the best" and make them built-in configuration options in Qubes... which brings us to "Why not just make settings and preferences easier for folks to manage?"

Right. My #1 kvetch with my own experiences of libre software to date, is the trend towards "empowering" users to do "everything" they may desire—which effectively disempowers them from doing anything, with ease.

So, yeah. The SALT Store (for lack of a less Capitalistic way of framing it) sounds like it should be kicked-off as a "project" perhaps, with a workshop. A workshop with a goal of learning what would make for effective moderation/oversight; where dependencies are, and how to define roles in that workflow. I'd be happy to facilitate if folks like @andrew, @unman, @mfc, and other nominees wd be keen to participate.

I'm not sure exactly what the "project"/"workshop" thing would be. TBH, this sounds like spending a lot of time on meetings upfront, and I question the usefulness of that. I don't know if we need to make this all so complicated (including this giant discussion thread). I suggest starting with our usual approach to implementing new features (which tends to be a very "lean" approach in terms of not requiring synchronous meetings and such). If it turns out that a project/workshop is required, that's fine, but at least the need will be clear based on progress already made.

The actual GUI part of such an experience for end-users, sounds like the least of the "needs;" and TBH, could be done on a website that's bookmarked by default in a qube.

That probably will not be what we want for a variety of reasons, but it's too early to say.

[ninavizz]

@andrewdavidwong My points about community support vs products being more intuitive from the start, were to speak to team prioritization. Qubes is made possible by a very, very small team, and we have to prioritize our efforts. Per that, it's my own point of view to not prioritize things people aren't already asking for in large numbers.

Intuitive software, clearer documentation for what software already exists, and more stable releases, are the clear/dominant ask from our survey w/ over 6k responses to date.

I'm not sure exactly what the "project"/"workshop" thing would be. TBH, this sounds like spending a lot of time on meetings upfront, and I question the usefulness of that. I don't know if we need to make this all so complicated (including this giant discussion thread).

"Workshops" are carefully moderated, well-planned things UX and product folks often plan and then moderate. They're not open-discussion around agenda points; there's specific activities planned for collaborative synchronous work, to yield much, much quicker results than long asynchronous discussions. No slide-decks, no "Let's talk about 'blah' and try to all agree" rabbitholes.

For many reasons, doing products exclusively through asynchronous communication, just does not work for producing intuitive experiences that meet both the user and organization's needs. That matters. Open Source is not famous for doing either of the aforementioned, well... and there's just too much time between feature releases for Qubes, to embrace "lean" practices. A caveat with Lean, is frequent (monthly or more often) iterative releases—which we couldn't even do if we were funded to the tune of millions.

Coming back to priorities I spoke to earlier: if Qubes is to sustain in the long run, releases can't be pushing features and products out, that seem "half baked" or are not usable... which is what users experience, with some parts of the Lean approach, but spread-out over 18mo release cycles.

[andrewdavidwong]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

And I didn't mean "lean" as in specifically following some Agile methodology; just in the sense of minimal overhead.

[SvenSemmler]

I don't know if we need to make this all so complicated (including this giant discussion thread).

I agree, it seems we are talking past each other.

Nina saw this thread from the perspective of designing a store UI (which at some point later would surely be awesome). You seem to think about it from the perspective of developing something.

But the way I understand this ticket is "design and create [...] distribution method". This is asking primarily for a process.

How can less skilled users download, trust and apply salt formula?

If it comes from unman and there is a description how to apply it, many might choose to trust since he is a core Qubes OS team member.

But what if maybe I want to contribute a formula? How can users that doesn't understand salt formula trust?

So what we need is a process. Something like:

• a central repository
• very limited number people with commit rights
• some form of review process

Kind of like how it is with the HCL reports right now. Everyone can send you a pull request but only you and maybe a small number of others can commit and thereby publish on the website.

[SvenSemmler]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

Ok, maybe I misunderstood you too. Seems we are on the same page.

Process and tools first. UI later.

When I read workshop I thought "come up with process/tools" not "come up with UI".

Sorry for the confusion.

[ninavizz]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

Workshops are for needs-finding, and to co-create processes. Please don't assume a thing I might be proposing might be to exclusively hone-in on presumed limitations of "UX."

Broadly, UX cannot succeed without a lot of other things falling into place. Historically, because of that, UX designers have often stepped-up and into product development roles to resolve the myriad of open questions that need to be solved for, in order for tools we develop to succeed.

So while I see very little UI design being actually needed for this product to succeed, I do see user research factoring into it—as well as a lot of "product development" around roles, processes, etc. for the human system behind the store. If that makes sense. Please see this article on Service Design. This is much more of a service design project, than a "UI" design project; and Service Design is more than half the work, that most UX designers do.

[ninavizz]

Sidenote: I see a LOT of time spent by folks, rabbit-holing on Issues here in GitHub, that do not seem to align with actual priorities for the QubesOS project to succeed beyond the walls of its existing community.

The goal of a Workshop, is to get requisite tasks done, done thoroughly and well, and to get them done fast—then closed (or put into the hands of an individual contributor to get to work 'building stuff').

Otherwise, actual priories never receive the attention they need, and everything suffers. This project just does not feel like a priority, but it is clearly desired—so then how to gather requisite information for a community member to build something on their own with all the information they need, is the goal of the workshop.

[SvenSemmler]

rabbit-holing on Issues here

Proposal to change that:

https://qubes-os.discourse.group/t/design-and-create-salt-formulas-distribution-method-1939/3592

[ninavizz]

Thank you @SvenSemmler! I've also pinged UX colleagues who regularly do workshops, to get some ideas going for async workshop formats so that everyone could potentially contribute, over the period of a week or something. Whatever we do, this is @andrewdavidwong's realm and I want to be mindful to not step on his toes. Workshopping is a common tool used by UX folks to gather requirements and find alignment on products that I'd love to be able to put to work w/ this community if possible.

[ninavizz]

31 March, I asked:

"Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is (I have a vague understanding that it has to do with package management and config scripts), and suspect that anyone who would, would be comfortable managing that in the CLI?"

I never really got the answer I'd hoped for at that time. Which is ok! UX designers often don't get those answers, for quite a while. :)

I finally got my answer: Enable easy installation (and updating capabilities) of apps to qubes. Boom! More granular as well, is a desire to facilitate easy installation of apps configured to security needs unique to a user's circumstances.

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

Big thanks to @tlaurion for helping me understand this, in an hour+ meeting we had a couple of weeks ago. From the the appmenu survey:

Most importantly, the issue to be tackled here as said in previous meeting is how the user is supposed to install applications. I spoke about Wire as a typical example. Let's follow the rabbit a little.

user goes to : https://wire.com/en/download/ Then if knowledgeable enough, understands that Ubuntu=debian, and chooses to click on the repository link. He then lands here: https://github.com/wireapp/wire-desktop/wiki/How-to-install-Wire-for-Desktop-on-Linux

Follows instructions, transferring inner knowledge of QubesOS, launches debian-10 terminal and then: sudo apt-get install apt-transport-https wget -q https://wire-app.wire.com/linux/releases.key -O- | sudo apt-key add -

Which fails. Because TemplateVMs are not able to exit outside of the whonix proxy for apt/dnf. So the user here has two options, give debian-10 network access and forget about it, or if knowledgeable enough, will block all internet connection and put exclusion for the next 5 minutes. Still, he is playing with the TemplateVM configuration, which he should not be doing.

wget -q https://wire-app.wire.com/linux/releases.key -O- | sudo apt-key add - should be replaced by curl --proxy http://127.0.0.1:8082/ --tlsv1.2 --proto =https --max-time 180 https://wire-app.wire.com/linux/releases.key | sudo apt-key add -

And then user can continue to follow other application installation that has a repository available. We are not talking here about installing snap, nor qubes-os-snap-helper. The user needs to know a lot of the background workings to be able to install an app, where, prior of being able to use it.

One UX focus should be to permit installation of applications by salt provided and validated repository, downloaded and made available through QubeSOS updates. The installer should propose to deploy such personas, attached to the applications per se. And/or, the repositories should be made available, but deactivated, so the user can launch Template relative GUI for software installation, and activate/deactivate possible channels to be able to be independent in installation of the softwares. he needs to use on a daily basis. Otherwise, we are loosing users or need to assist them a lot, while documentation are not making those ""translations"" (wget to curl to have internet access through proxy)."

[andrewdavidwong]

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

This is a hard problem because, even if the UX-finger-wagging is correct, most of the target of that wagging is probably stuff we merely inherit from upstream projects, including entire gigantic Linux distros. The reason this is a hard problem is because we (the comparatively tiny Qubes OS Project) don't stand a chance of trying to fix the UX problems of gigantic upstream Linux distros, and it'd be foolish of us even to try. At best, we can get our own UX house in order, but that will still leave a lot of stuff in the "you need to learn some Linux" realm.

[DemiMarie]

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

This is a hard problem because, even if the UX-finger-wagging is correct, most of the target of that wagging is probably stuff we merely inherit from upstream projects, including entire gigantic Linux distros. The reason this is a hard problem is because we (the comparatively tiny Qubes OS Project) don't stand a chance of trying to fix the UX problems of gigantic upstream Linux distros, and it'd be foolish of us even to try. At best, we can get our own UX house in order, but that will still leave a lot of stuff in the "you need to learn some Linux" realm.

When it comes to software installation, Flatpak tries to solve the problem and does an okay job at it. We can also make installing some particularly common applications easier by shipping Salt formulas to securely install them.

[ninavizz]

@andrewdavidwong Nope, "the problem" was that I tried installing Signal in the VM, and not the Template; and then once I installed it on the Template, I did not know that I had to manually refresh the Apps list in the app vm. None of that is a single-environment mental-model, which comes back to the core usability issue with Qubes. A very hypervisor-specific problem we absolutely can/should speak to in a Simple User Guide, and should the funding becomes available, speak to in an Installation Manager.

Repeating CLI prompts on a software package's installation page, is cake. When an org like Signal makes it so easy, and the user is working with a common distro like Debian or Fedora, we should be able to pick up from that to keep it smooth.

[tlaurion]

@DemiMarie I replied to your comment https://github.com/QubesOS/qubes-issues/issues/1939#issuecomment-846733739 under https://github.com/QubesOS/qubes-issues/issues/2766#issuecomment-851020388. I would love to have your insights about the current state of flatpak/snap since I am not yet comfortable recommending it.