Change Details

Via HackerOne (<https://hackerone.com/reports/220909>). When we close commits in response to "Fixes Txxx", we currently act as the omnipotent user. This allows users to close tasks they can't see by pushing commits with "Fixes Txxx" in the message. However, we can't actually tell who authored or committed a change: we're just using the "Author" and "Committer" values from Git in most cases, and anyone can forge those. So we can't really get this right, in a security sense. (We can tell who //pushed// a change if we host it, but that's often not the right user. If GPG signing was more prevalent, we could use that. In the future, we could use side channels like having `arc land` tell Phabrcator who was pushing changes.) Since I think the impact of this is fairly minor and this isn't //really// a security issue (more of a confusion/abuse/product issue) I think the behavior is okay more-or-less as-is, but we can do better when we do identify an author: drop down and use their privileges to load commits. This effectively implements this rule: > If we identify the author of a commit as user X, that commit can only affect tasks which user X can see and edit. Note that: - Commits which we can't identify the author for can still affect any task. - Any user can forge any other user's identity (or an invalid identity) and affect any task. So this is just a guard rail to prevent mistakes by good-faith users who type the wrong task IDs, not a real security measure. Also note that to perform this "attack" you must already have commit access to a repository (or permission to create a repository).

Via HackerOne (<https://hackerone.com/reports/220909>). When we close commits in response to "Fixes Txxx", we currently act as the omnipotent user. This allows users to close tasks they can't see by pushing commits with "Fixes Txxx" in the message. However, we can't actually tell who authored or committed a change: we're just using the "Author" and "Committer" values from Git in most cases, and anyone can forge those. So we can't really get this right, in a security sense. (We can tell who //pushed// a change if we host it, but that's often not the right user. If GPG signing was more prevalent, we could use that. In the future, we could use side channels like having `arc land` tell Phabrcator who was pushing changes.) Since I think the impact of this is fairly minor and this isn't //really// a security issue (more of a confusion/abuse/product issue) I think the behavior is okay more-or-less as-is, but we can do better when we do identify an author: drop permissions, and use their privileges to load the tasks which the commit "fixes". This effectively implements this rule: > If we identify the author of a commit as user X, that commit can only affect tasks which user X can see and edit. Note that: - Commits which we can't identify the author for can still affect any task. - Any user can forge any other user's identity (or an invalid identity) and affect any task. So this is just a guard rail to prevent mistakes by good-faith users who type the wrong task IDs, not a real security measure. Also note that to perform this "attack" you must already have commit access to a repository (or permission to create a repository).

Via HackerOne (<https://hackerone.com/reports/220909>). When we close commits in response to "Fixes Txxx", we currently act as the omnipotent user. This allows users to close tasks they can't see by pushing commits with "Fixes Txxx" in the message. However, we can't actually tell who authored or committed a change: we're just using the "Author" and "Committer" values from Git in most cases, and anyone can forge those. So we can't really get this right, in a security sense. (We can tell who //pushed// a change if we host it, but that's often not the right user. If GPG signing was more prevalent, we could use that. In the future, we could use side channels like having `arc land` tell Phabrcator who was pushing changes.) Since I think the impact of this is fairly minor and this isn't //really// a security issue (more of a confusion/abuse/product issue) I think the behavior is okay more-or-less as-is, but we can do better when we do identify an author: drop downpermissions, and use their privileges to load the tasks which the commits "fixes". This effectively implements this rule: > If we identify the author of a commit as user X, that commit can only affect tasks which user X can see and edit. Note that: - Commits which we can't identify the author for can still affect any task. - Any user can forge any other user's identity (or an invalid identity) and affect any task. So this is just a guard rail to prevent mistakes by good-faith users who type the wrong task IDs, not a real security measure. Also note that to perform this "attack" you must already have commit access to a repository (or permission to create a repository).