In real life outside large enterprise, implementation details are a big part of comparing possible solutions.
I don’t understand what large (or small) enterprise has to do with what I said. To my mind, implementation detail relates to execution of a plan. A plan implies a task, and a task implies a goal.
Considering the latest questions, we are currently still clarifying/agreeing on the goal.
Not to “stir the pot”, as it were, but given the way this conversation has gone, I can see this being problematic for some people. Whether or not they’d contribute if it didn’t exist, though, is another matter entirely…
You can bring a horse to water, but you can’t make it drink…
Because you can currently do it using an offline vault qube running oathtool, I don’t think adding this 2FA adds any major concerns. What GH and other services would do next if lots of people start getting hacked because they’re running keepass and oathtool in the same vulnerable place is another question, but probably not one for the near future.
FWIW, logging in using Tor Browser has always resulted in “We have sent you an email with a verification code” which is a form of 2FA.
I any case, if the web-form workaround is implemented, that should not be an issue as the backend can authenticate using oathtool, as explained.
It’s unlikely that I have anything more to add here.
I doubt that the “web form” proposal will do anything to address the
issues raised - it implements a MITM solution to posting issues, and
submitting code, and has the same data scraping issues that are seen to
be problematic. Anonymous code contributions like this would require
far greater security than signed contributions from known contributors,
even anonymous ones.
In my experience, when setting out a change proposal to the board, there
are these initial responses:
It doesn’t matter if these have been dealt with in detail in the
briefing. And it doesn’t matter what the organisation is - small not for
profits are often more troubled by change.
Are there existing alternatives to contributors using GitHub? Yes, they have been
set out in this thread.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I doubt that the “web form” proposal will do anything to address the
issues raised - it implements a MITM solution to posting issues, and
submitting code, and has the same data scraping issues that are seen to
be problematic.
As I said, it is not a solution but a workaround. The benefit will be the lack of extra tracking technology on the web forms and no registration. People can submit/read anonymously.
The MITM will be solved only after self hosting and removing CloudFlare.
Anonymous code contributions like this would require far greater
security than signed contributions from known contributors, even
anonymous ones.
Isn’t contributed code verified? Or is it being accepted just based on who signed it?
I was assuming the “handover point” in a typical journey would be opening a PR. Yes, because the PR’s anonymous it requires more careful review and can’t use the trust shortcuts available with known contributors, so it’s (a lot) slower - but the PR can be created, which is I think what’s wanted.
It’s the spam/DoS side of the web form I’d be most concerned about, but a) would expect to find something that worked well enough, and b) taking an iterative approach and reacting to increases in spam shouldn’t be risky, given sensible general controls like rate-limiting what’s sent on to GitHub. What’s actually appropriate here would depend partly on the details of GH’s ToS.
I would like to see more support for the benefits. In the absence of a known queue of anonymous contributors waiting for Qubes to do this, you’re either looking for other relevant projects that have increased contributions substantially by providing similar anonymity, or you’re asking the Qubes team either to invest in just trying it out (potentially reasonable if it’s cheap enough and there’s some evidence, and that’s where I thought this was going) or to take a principled stand on something that isn’t essential to their core values (possible but no reason to expect it that I can see).
I like what you have said Nokke. I just want to add that from a business perspective it’s about quality of news devs, not quantity. This is well known in software engineering. Job ads get thousands of engineers applying, only top 10% get hired. But it’s the top 1% who are priceless, they are the ones doing the most important work, innovations, finding vulnerabilities, etc.
If Qubes OS gives developers anonymity, even if it takes 2 years until that leads to a top 1% developer joining the team then that would have been a great investment because a top 1% developer are priceless and bring so much value.
That’s just the business perspective. Then there is what you said, the digital freedom values. Tor is really meant to stay within tor, not use exit node to enter terrible clearnet. We need to kickstart a community inside tor, i’m talking about .onion websites. The more of important core infrastructure projects like qubes os show support for .onion, then other projects will be inspired and do the same. Maybe one day we can have all of FOSS inside tor and i2p and say goodbye to clearnet which will have digital id and all kinds of tracking and censorship, it keeps getting worse constantly.
PR’s anonymous it requires more careful review
That implies a double standard in code review. If that is really the case, that’s a serious question and deserves its own thread.
It’s the spam/DoS side of the web form I’d be most concerned about
I would like to see more support for the benefits.
Privacy has no business benefits.
Reasonable, and means here we’d be looking for many projects who’ve attracted one great contributor instead of a couple of projects attracting many. It becomes harder to actually count devs once they’re anonymous, but I’m not seeing that as a big issue.
If someone has a good list like this, and an implementation idea that looks both safe and cheap, then I don’t see the Qubes team ignoring them.
Reasonable, and means here we’d be looking for many projects who’ve attracted one great contributor instead of a couple of projects attracting many. It becomes harder to actually count devs once they’re anonymous, but I’m not seeing that as a big issue.
What about bug reporters? Or those who simply need to read an issue they are referred to?
If someone has a good list like this, and an implementation idea that looks both safe and cheap, then I don’t see the Qubes team ignoring them.
Repository:
Related:
A way to view all comments of an issue with certain ID (JSON format):
https://api.github.com/repos/QubesOS/qubes-issues/issues/ID/comments
I found a Codeberg repository that encourages mirroring GitHub repositories to Codeberg instead of committal migrations, along with reasons and how-tos:
Nice summary.
@alzer89 said he had installed SourceHut and expects contributions through it but he didn’t share any further details.
FWIW, recently Stack Overflow started showing “Enable JavaScript and cookies to continue” message (a ClouldFlare challenge) to access any page on its websites. At least this is what happens in Tor Browser. I also notice their robots.txt also blocks all crawlers (which might be an implication they are under some kind of bot attack?).
I am mentioning this because there are Qubes-related questions there:
https://stackoverflow.com/questions/tagged/qubes-os
Perhaps that is worth mentioning in docs in case someone decides to use that route for asking questions.
Fortunately, a workaround for it exists:
AnonymousOverflow is currently not a workaround:
My (unlisted) AnonymousOverflow instance is also affected by the recent Cloudflare changes, but the proposed solution in the GitHub issue is experimental and temporary, so I have not changed my Docker Compose YAML file to reference unaudited/unofficial Docker images even if there is a possibilty of successfully circumventing Cloudflare with it.
The instance of member ngn13 (using FlareSolverr) works.
Sure, feel free to use the aforementioned experimental and temporary solution.
Even if you are somehow fine with Javascript but just don’t want to login with with your real name, you may be discriminated by Github:
Discussion on Hacker News: Updated rate limits for unauthenticated requests | Hacker News
