Skip Hide 2FA status from other members in organization members list #421
Labels
No Label
backport/v1.19
backport/v1.20
backport/v1.21
bug
dependency
Chi
dependency
Chroma
dependency
citation.js
dependency
devcontainers
dependency
dropzone
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Gitea
dependency
Go-org
dependency
Golang
dependency
goldmark
dependency
Goth
dependency
Helm
dependency
MariaDB
dependency
Mermaid
dependency
minio-go
dependency
Monaco
dependency
PDFobject
dependency
Runner
dependency
ssh
dependency
urfave
dependency
Woodpecker CI
dependency
XORM
Discussion
duplicate
enhancement/feature
forgejo/accessibility
forgejo/actions
forgejo/branding
forgejo/ci
forgejo/documentation
forgejo/federation
forgejo/furnace cleanup
forgejo/internationalization
forgejo/moderation
forgejo/privacy
forgejo/release
forgejo/scaling
forgejo/security
forgejo/ui
issue
closed
issue
do-not-exist-yet
issue
open
OS
FreeBSD
OS
Linux
OS
MacOS
OS
Windows
No Milestone
No Assignees
9 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: forgejo/forgejo#421
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Concerns were expressed about the change of UI introduced by Hide 2FA status from other members in organization members list.
I definitely think this needs a bit more thought, not sure if we should revert it.
Revert Hide 2FA status from other members in organization members list (#22999) (#23023)to Skip Hide 2FA status from other members in organization members list (#22999) (#23023)I did not mean to revert it in the development branch. But to skip it for Forgejo v1.18.5-0 until the discussion concludes and maybe include it later. I used "Revert" because technically speaking it is cherry-picking it and reverting it, for the purpose of keeping track of this decision in the git history.
Does that make sense?
The commit is not included in Forgejo 1.18.5-0.
As the author of that PR, I'm curious what the concerns are. This seems to fit with the privacy focus of Forgejo.
If anything this does not go far enough, though there is practical use to organization owners being able to check if members with code write access have well protected accounts.
I think the change makes sense and I approve of it.
My primary concern would be that a user visible changes (and generally the user experience) should not be something left for developers to decide on their own. At the very least there should be some kind of user feedback and consultation before it happens.
That being said... most if not all UI decisions in the current codebase are driven by developer decisions with no user research and no user experience design. It is therefore not out of the ordinary and reforming this process will be a very large undertaking.
For some reason this particular change triggered a surprise reaction from members of the Forgejo community. Maybe because it was discussed, implemented, backported and released in a record time (24h or so)? In any case, the current behavior has been around for a very long time and I think it won't make much of a difference if Forgejo waits a little before it is released.
I couldn't fnd Aminda on Codeberg. @crystal was also involved in the discussion about 2FA.
The gist from what I can see is that „any given repo in an org is only as secure as the least secure member of that org”.
We checked how GitHub handles 2FA communication to non-members. It's only exposed to org owners (not even regular members can see it).
Given different opinions on the display of 2FA allowing choice via a config was proposed.
@Ryuno-Ki No. This should not be configurable. Every member of
orgshould be able to see status of 2FA of fellow members.At the same time, people outside of said
orgshould not be able to see status of 2FA onorg member list; it should be hidden for them regardless status.Just my 2p's
I summarised the concerns I am aware of.
Independent of my own opinion on them.
To be clear, the Gitea behavior after my change matches this GitHub behavior.
Owners are the ones creating teams, adding and removing members. There seems to be no point showing it to anyone but owners, others have no control over team membership.
Really I think what you want is the ability to set certain teams as requiring 2FA, and somehow make that clear when joining the team. Rather than a user config options that would affect all organizations you are a member of, or showing this 2FA status in the members list at all.
https://github.com/go-gitea/gitea/issues/880#issuecomment-1441555518
I think there's different types of members. For example at Blender we have a team of trusted users that help with triaging issues and so they get write access to issues. But we don't give them write access to code, and I don't think they need to know the 2FA status of developers. Or fellow users that do triaging for that matter.
@brechtvl oh Blender; nice piece of software. Using it for my hobby projects, loving it 👍 Its far better than paid alternatives.
But to topic: Every org has its own setup, thats normal: thing is that noone is forced to use every feature software offers. Some will find feature X useful, others will find feature Y as usefull. Normal thing.
But, its good to have rich feature-set.
Fair enough, but that's a generic argument for every configuration option. Generally I think there should be some specific use cases for when it's useful to justify it. Why it's useful to see the 2FA status of fellow members, which I didn't understand so far.
I can't think of a use case where viewing the 2FA status of fellow members is needed.
@dachary just quick example/tip for you:
orgadmin.......My previous comments on this matter basically amount to this:
I have reconsidered my objections since initially raising them, and ultimately I think this change is okay, especially since GitHub behaves the same way. That being said, I would like the points above to be considered. Especially the mandatory 2FA thing. GitHub has that and Forgejo is severely lacking there imo.
@crystal 💯
points 1 && 2 I agree 100% with.
However, I stronghly disagree with 2FA being configurable. This is security setting and as such should be enabled without ability to disable.
Nobody is saying it should be possible to disable 2FA, I'm saying it should be possible to configure the visibility of 2FA status for other members of the same team/org
@crystal please read your own comment (the one I was responding to)
You said:
I responded:
How do I not understand?
I think in terms of security the argument would be something like this. You have a user that you make part of a team with limited access (say read-only for issues). And then that users has ill intentions or their account gets compromised, after which someone could target particular developer or owner accounts with the least security.
If it would say "weak password" for some accounts I think we could agree that's definitely bad. This is not as bad but somewhat similar.
Completely agree that an option for mandatory 2FA for teams or organizations is where things should go though.
@brechtvl exactly
Alright after a full day of doing other stuff. The PR makes sense, it matches the Github behavior (which is the ideal one). It's ideal, because I cannot find a answer to 'What's the justification for members to see fellow member's 2FA status', not from a developer or from a user perspective.
This proposal to revert this patch, I'm not in favor.
I think this got derailed a bit, so let me say this: stay on-topic and otherwise open a new issue.
I understand this argument, it's not like I didn't think of it. It just feels like security by obscurity. I would recommend keeping 2FA enabled for everyone. Like I said before, I ultimately believe we should accept this change, possibly make it configurable, and definitely add the mandatory 2FA feature.
You seem to be under the impression that I wish for the 2FA feature in general to be disabled. I assure you that is not the case and it's genuinely starting to get on my nerves that you think you can tell me what I meant by something I just wrote. I only wish for this particular change, i.e. the visibility of 2FA status for fellow organization members, to be configurable.
@crystal Im under impression which you want me to be under/you paint in wording messages.
Believe me, Im far, far from telling you (or anyone in fact) what you/they meant. Im only saying whatever I read from what you have written.
You seems to lack ability of clearly conveying what you have in mind: you think one thing, you write the other.
@crystal @wojtekxtx Please move this discussion to the matrix room. Don't continue here, it's derailing the topic.
I just want to make the following 100% clear:
When I said "This" in my original comment, I was referring to the topic of this issue. I did not feel that required additional clarification at the time, but I was obviously wrong. Perhaps more annoying, even after explicitly clarifying what I did mean by that twice, my statements are still being intentionally misinterpreted. @wojtekxtx is literally gaslighting me in real time.
I am formally requesting that @wojtekxtx DO NOT INTERACT with any of my future comments on this issue tracker. I feel their comments are often entirely unproductive, especially when they are in response to one of my comments. Moreover, their behaviour in both the issue tracker and the Matrix channel has made me feel excessively uncomfortable and I wish for my interactions with this person to be limited as much as possible, including by project moderators if necessary.
There has been a lot of unrelated noise on this issue tracker and other Forgejo spaces that led to actions from the moderation & well being teams. I think @wojtekxtx behavior has been toxic and ask them to refrain from further interactions in all Forgejo spaces.
Skip Hide 2FA status from other members in organization members list (#22999) (#23023)to Skip Hide 2FA status from other members in organization members listThere seems to be a consensus that the behavior implemented by https://github.com/go-gitea/gitea/pull/22999 is good in the context of Forgejo and the associated commit will be included in future releases.
Sorry for the delay, I have a post-mortem comment:
The use case is a scenario with a compromised account. It is difficult to take that scenario as a starting point to build a security measure for the rest of the team. What about the other side of this supposed circle of trust: if I am a non-owner member, why should I trust the organisation's decision to allow unsecured member accounts without transparency about their inclusion? From this other point of view, obscurity acts as blind trust.
Or another eventual case: what if a member note an unexpected behavior of another one and checking his profile notes that 2FA is now disabled? it couldn't be a good sign of warning of a security compromise?
At last: what is the limitation to the inclusion of people in a fake org made by a malicious user? There is no consent at all, so the eventual weakness of knowing which people have 2FA and which don't is much more attainable than the use case detailed here and justifying implementation. If this is considered a threat, then the path to follow is clear.
I cannot either. there was mention of teams in another comment. Those are an artificial construct - we have an organization, within that projects, then granular 'groups', not teams. We build that artificial construct independent of the software in a published and non-software integrated level.
further:
I don't know what you mean by 'user research', perhaps a fancy, invented terminology, but thank you for pointing that out, and it's not to be taken in a derogatory way for those who are prolific "coders"...
Programmers code. that's what they do, and it's often not a matter of how larger issues may come into play - challenge presented, "hmmmm i can do that!", so they do - success! It's often about the challenge and without deference to whatever that accomplishment might entail with respect to other arenas of consequence.
But getting back to the crux of this issue, and thank you for addressing that dynamic...
I elected to refrain from participation here until the matter was resolved and closed. Call it a social experiment if you like, but I have confidence in wisdom prevailing.
Yah, I'm an eternal optimist and hopeless romantic 😜
That having been said, this is still a privacy issue - it's completely possible to not allow ANYONE to invade their privacy if an individual user's account configurations are week or strong while still preserving the security concerns of an organization and project, by simply allowing the org it to enforce an authentication option for members without ever having to reveal to those people what that particular user's account settings are.
You can simply say "only those with MFA activated can blah blah..." - Same effect, no invasion or trespass upon the user's privacy and yet, project and org level security is enacted and enforced - NOW THERE'S A CODING CHALLENGE - Any takers? lolz 😜
Okay, so I get why you might have elected to bring this forward, and truly appreciate that you have deference to some that it may have been an issue to, but I'mma take an unpopular and what some would call an opinionated position here...
From a factually derived PoV, it is idiotic to expose the level or method that any user account has implemented for themself to anyone but the software itself.
Of course it is easy to glean or ascertain that info based on published standards by membership in an org or project that effects to enforce s specific MFA policy, but it's an entirely different social engineering construct to simply expose that information otherwise - obviously, for anyone with a brain.
At every turn, it behooves us to make it as difficult as possible for evil miscreants to glean information about the size of the attack surface that any user account has.
conversely, it is almost as valuable to bad actors to know this information because noe they know which user accounts ARE NOT among the low lying fruit that they can target.
Okay then! All's well that ends well, right? Not necessarily folks. I challenge someone here to address the cofing challenge that I introduced earlier in this comment - For a project or Org to merely require certain security considerations and enforce them, without actually being able to view (expose, rather) whether those user accounts have enabled those options, is both a sound operational capability, and a privacy respecting integration + one of the things that Forĝejo is all about.
I hope that helps, and ask the best!
⛵
.
[Modified by Wellbeing team] The related conflict is a Wellbeing case under our care.
Hi @wojtekxtx
Commenting in name of the Wellbeing team. We understand it is hard to refrain from responding to remarks addressed to you. Your comment and the one you responded to are part of the Wellbeing case we currently handle, and we will edit both comments to reflect that. I am happy you are in contact with @fr33domlover as we further handle the case. We appeal to you to let this rest and refrain from project interaction for now.
FYI As a best-practice for the project, I created forgejo/meta#172 for consideration in our Wellbeing process.