I’d be interested if low review bandwidth hurt Qubes security in practice, to the extent where the risks introduced by such a proposal are balanced. I’ve not seen this case made, though.
1 Like
I am not saying the proposal is perfect as of version 3.0, but I am wondering if it can be refined to a point where it becomes useful.
Debian/Fedora maintainers and upstream committers (for example xz commit access) are in a position to introduce backdoors anyhow. They could perform a stunt such as the infamous xz backdoor, which then could compromise the distribution and even Qubes dom0 (in case of Fedora since Qubes is based on Fedora).
The xz backdoor didn’t reach Qubes due to “bad backdoor design” and being caught
by a security researcher before Qubes dom0 was upgraded to a version of Fedora which contained the backdoored xz version. (The xz backdoor did qubes-template-archlinux.) Without this kind of luck involved, the backdoor would have reached Qubes dom0. (Another lucky factor was, that the xz backdoor did as far as I know only target OpenSSH but not Qubes.)
A similar vulnerability [1], that made OpenSSL insecure, was in the past introduced by a Debian maintainer. [2]
Whether base distribution have commit access to Qubes
- Fedora maintainers to Qubes Fedora Template,
- Debian maintainers to Qubes Debian Template,
does not seem to make a difference whether they can introduce a backdoor to the respective Template or not.
I think an proposal could be refined to say that for example a Debian maintainer only maintaining some less important package which is not installed by default in Debian or Qubes Debian Templates, lets say who only maintains some old game, should not get commit access to Qubes. But those maintainers who are trusted to maintain security-critical, Qubes pre-installed packages in the base distribution, could introduce a backdoor into the base distribution anyhow. Therefore less reason to exclude them from Qubes commit access.
Some reasons coming to mind.
- Due to Qubes dom0 being based on Fedora at time of writing, only Fedora maintainers could introduce a backdoor targeting Qubes. One could argue that trusting fewer distributions is safer because then less distributions, less people have commit access.
- In theory, some distributions have a more secure vetting process than others.
- Debian maintainers could introduce a backdoor into Qubes Debian Templates anyhow. But Fedora maintainers cannot do that. Hence, only Debian maintainers would get commit access to Qubes Debian Templates but not Fedora maintainers.
[1] No hard proof that it was a deliberate backdoor exists.
[2] Lessons from the Debian/OpenSSL Fiasco [archive]
The question is, what is a (reasonably) secure process for a security-focused software project to grant commit access, in other words, to trust people?
Long term (high) quality contributions do not really discourage an advanced adversary as we have seen with the xz backdoor. Meetings in real life? Also good, also highers the bar. But is it perfect? No. Even a multi-year effort to introduce a backdoor, if caught, if by a state level actor is not a big deal for the adversary as states have sufficient funding and can even provide new identities.
So it seems the full criteria must stay undocumented and based on the decision maker’s subjective personal opinion how likely it is that it is a sophisticated backdoor attempt or genuine contributor.
2 Likes
This should be discussed in the GitHub issue, not on the forum (at least not in this thread).
1 Like
Do the Debian and Fedora maintainers want commit access to Qubes OS?
2 Likes
Not sure this is off-topic. But if it is, seems easy for a moderator to move it into a dedicated forum thread.
I think it is on-topic, because it answers the question “Why is the Qubes OS project team so small?”
One answer could be: Because there is no (at least no public documented) (reasonably) secure process on how to choose trusted people to be admitted to the core team. The related proposal failed.
I let it to moderators to decide if the process itself is on- or off-topic. Best to use the forum report button so the moderation on/off-topic meta discussion can be avoided.
I expected this question to come up. Therefore, this was addressed in the proposal upfront, and asked, and replied to in the proposal.
3 Likes
I don’t mean to insult or threaten anybody, but I have to say it.
My main conern is whether some people in the project are currently irreplaceable, because when looking at Github issues activity it sure looks like it. Let’s say one of the main devs dies in a car accident. Realistically, will Qubes OS then not suffer a major slowdown in maintenance (both keeping current features up-to-date, and introducing security fixes)? How do they expect to then fill this gap with new people if trust issues and expertise required are so high? What if someone just leaves the project overnight for whatever reason?
I don’t have these concerns with large projects like systemd or big distro maintainers like Fedora, Debian, Ubuntu, Arch. With a project like Qubes, I do. There have historically been well-known and seemingly healthy distros like Solus and Antergos that suffered a near-death experience (first one case) and deprecation (the latter case).
IMO, some redundancy in workforce is also needed for reasonable™ security, and stability of the project.
2 Likes
It’s really complicated to bring good contributors for free.
My thoughts
- Qubes OS does not have much users, but a large part of them want to remain anonymous, some of them certainly don’t want to contribute back for privacy reasons
- Qubes OS is complicated and fragmented in many repository that feel like walled garden due to the lack of documentation or simple build instructions
- I qualify Qubes OS of a meta operating system because it’s an OS to run OSes inside, it can do many things, and all users have different use cases and weird setup. There is no clear roadmap and it’s hard to figure if something we want to work on would be accepted, it’s not motivating to work on a feature and then wait 2 years to discuss it with no real way to figure if it’s ok or not, which leads to the next point
- from my point of view, the current team is hard to reach when it comes to contribution: there are no specific channel other than pinging people using their names on the forum or talk on GitHub issues, this is complicated to receive help to step up. Issues or PR often remain unanswered, which does not help motivation either.
2 Likes
I think we’d be talking about failover rather than redundancy, partly because of the small project size, partly because the trust limits are a security feature. The difference being that people might get familiar with the systems but wouldn’t be responsible until there’s some sort of succession event (planned or unplanned, gradual or sudden, disaster-related or completely normal). Such an event may trigger trust to be relaxed temporarily, so as long as there’s some pool of people who are able to take over in some sort of reasonable time frame, it wouldn’t automatically be an existential threat to the project. Yes, on any small project, succession can mean more instability for a while.
So I’d worry less about “unexpected events” and more about things like knowledge sharing, community health, and developer experience, which all make succession-handling (I don’t intend to diminish how much effort is needed), more realistic and smoother. Even if there are shortcomings on all of these, which aren’t surprising with a small team making tradeoffs (@solene is right - keeping contributors happy is hard), sometimes the right people will still just pop up out of the blue when needed, and small projects can keep momentum with just one or two such people (much worse to be on a big project when the whole dev team walks).
1 Like
That’s probably what should happen.
Contributors are one thing but I am talking about the core team. They are not charities, they are paid from sponsors and donations.
1 Like
It isnt. There are many projects which work with users making a
contribution without payment. You must know this.
My thoughts -
- Some users want to remain anonymous. That wouldnt stop them contributing. Perfectly possible to work on GitHub anonymous and over Tor.
- The roadmap includes moving features out of dom0. That’s stated over and over. But any one can start contributing by starting squashing bugs.
- Do you find the instructions in qubesbuilderv2 not simple? They seem straightforward. The number of repositories may seem difficult to start with. It isnt difficult to find where some feature or program is packaged, and then to find the repository that provides that package. But you can always ask.
- You overstate the difficulties in working with the team. The primary place to discuss features, difficulties, etc should be qubes-devel. Look at how @qubist is handling changes to firewall, and BenGrande. This is clearly stated under contributing in the docs.
- No one should expect to work on a feature in isolation, and then hope for it to be accepted. Work on a bug within existing framework, or propose a new feature etc. That seems to be how progress is best made.
I said much earlier - the number of people in the core team does not
equate to the number of contributors.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes
This is not true. There are members of the team who work for ITL and
work on Qubes. There are others who work for free. There are contributors
who are paid (from some source) for their work and others who work for
free
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
Perfectly possible to work on GitHub anonymous and over Tor.
Unfortunately, it is no longer possible to register on GitHub and use its full functionality without JavaScript. (Ironically, the same applies for this forum).
Just a side note.
2 Likes
I think it’s impossible to register at GitHub over Tor even with JavaScript right now:
2 Likes
Simple or not, they don’t work reliably, and asking is hit and miss.
Which is in a completely separate place to “Developer documentation”. Discovery is a problem with the website that’s come up for me a few times before - sometimes it’s not a reasonable expectation on the user, who would basically have to read it cover to cover to find what they’re meant to know. So the fact that it’s clear once you find it is neither here nor there.
The projects that naturally attract more contributors than they can use can maybe get away with not investing in contributor experience, but that doesn’t make it sensible. Getting keen hackers isn’t always the same thing as getting good contributors, clearly.
Perfectly possible with headaches including high connection instability, account flagging, and low confidence in Microsoft’s attitude towards privacy.
4 Likes
23 posts were split to a new topic: Contributing on GitHub requires JS and that creates challenges and some are discouraged
It was appropriate to answer about the core team size not being a definitive measure, but knowing the volume of external contribution is necessary to support that point. Looking at git logs across all Qubes-owned repos over the last year, external contributors and contributions are few and cover a tiny fraction of the codebase.
I’m not sure why you’d think anyone was talking about templates, except that it’s the bit you provide professional services on.
I wonder how I can tell you haven’t tried.
2 Likes
Well, if you want to build a Qubes iso, you have to build client
packages and templates. So there’s that.
As to “professional services”, I have no idea what you are trying to
say. I dont get paid to build the templates or packages that I release
at 3isec.
Obviously you cant tell. It’s true that I havent built a full iso for some
time; I mainly build individual packages and templates. For most
trouble shooting and fixes, that’s all that’s required.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes
Some who understand the above choose not to do it. So, Qubes may be missing the contribution of experts who have deeper understanding. That’s the only point I am making. Not looking for an argument at all.
If those experts actually existed, I’m sure they’d be able and willing to contact the qubes team to talk about this and see if they can come up with a solution. So no offense, but to me this is mostly pedantry / tokenizing “experts with deep understanding for whom true anonymity is a necessity”. Point simply is, given the size of the team, that you have to direct limited time and resources. And then it makes little sense to anticipate on this by moving away from github now that it’s been bought up by MS simply out of a wholly invented FOMO worry.
1 Like
The point is that trying to shoehorn user feedback into what you already know about, and labeling the rest as fruitless or summarily dismissing it when it’s based on knowledge and effort, isn’t just unhelpful, it’s obstructive. In this thread, you’ve tried to close down concerns from the OP, Solene, and me, with at most minimal or trivial engagement. If you do have any financial incentives behind that behavior - and you’re pushing your brand repeatedly here so I’m pretty suspicious - then that would be a lot worse.
2 Likes
Hello , june 11, 24 i think it will be very pleasent for this TEAM, to encourage …and thank for their greate work. Sorry it is my personal opinion…
1 Like