Undefined #Security-General and #Security-Other
Closed, ResolvedPublic

Description

Security-General and Security-Other don't have any description and are undistinguishable.

Nemo_bis created this task.Aug 17 2015, 4:14 PM
Nemo_bis updated the task description. (Show Details)
Nemo_bis raised the priority of this task from to Needs Triage.
Nemo_bis added a subscriber: Nemo_bis.
Restricted Application added subscribers: scfc, Aklapper. · View Herald TranscriptAug 17 2015, 4:14 PM

We were using security-general for WMF / security in deployment issues, and
security-other for mediawiki issues that were not core or an extension.

But yes, those need to be defined and consistently used, or we can probably
get rid of one of its causing confusion.

I'm happy to batch-edit if someone decides™ what is wanted.

Sounds like they could be renamed to better reflect what they're intended for

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptJun 1 2016, 12:01 AM

I've used @csteipp's comment to attempt to clarify the project descriptions

Dzahn added a subscriber: Dzahn.Jun 1 2016, 12:07 AM

We were using security-general for WMF / security in deployment issues, and
security-other for mediawiki issues that were not core or an extension.

Almost sounds like this means "security-general" should be renamed to "security-deployment" and "security-other" is the real "security-general". But ..actually.. just merge them both into "security" per KISS.

@Dzahn, I believe that Chris meant "security in deployed software" when he said "security in deployment" issues.

Dzahn added a comment.Jun 1 2016, 12:30 AM

@dpatrick hm, ok, so "deployed with scap" is the difference? (as opposed to software that is deployed in other ways?)

In any case, please update the description of ALL #security-* projects to be distinguishable. Thanks.

@dpatrick hm, ok, so "deployed with scap" is the difference? (as opposed to software that is deployed in other ways?)

No, it just means software that is in production use on sites that we operate, as opposed to extensions which have been developed by the community but which we do not have deployed anywhere.

Dzahn added a comment.Jun 1 2016, 8:19 PM

Ah, thanks for that, that did clarify it more for me.

Ah. I'm afraid I brought up a very related question in T122624#2367743

Aklapper edited projects, added Project-Admins; removed Phabricator.Oct 7 2016, 5:01 PM
Aklapper triaged this task as Low priority.
Aklapper added a comment.EditedJun 29 2018, 1:40 PM
chasemp claimed this task.Sep 4 2018, 2:35 PM
chasemp moved this task from Backlog to In Progress on the Security-Team board.Sep 4 2018, 4:31 PM
chasemp closed this task as Resolved.Sep 4 2018, 6:40 PM

As part of revitalizing the security group here we are reviewing our workflow processes :)

  • I propose to archive the tags Security-Core, Security-General, Security-Other, Security-Extensions. These four tags are from pre-2015 Bugzilla times when a task could only have exactly one product (called "Security") and exactly one component (called "Core", "Extensions", "General".) This artifical restriction is gone as tasks in Phabricator can have 0-∞ project tags. I do not see a convincing use case in wanting to follow for example "all and any extension security issues" (via Security-Extensions). Instead, the specific tag for the affected extension must be associated to the security-related task about that very extension. Archiving these four tags will require to add the Security tag to those tasks that did not have that tag before already.

Agreed, archived as such. most of this was holdover from the BZ days.

Yes, our understanding is Security is generally for any security related task across all of the products/projects/mediums.

Yes, especially because Security is broad the team focused on particular elements within the security landscape have their own project to track work in progress.

Yes, this is a relic from the early days of phab. WMF-NDA is the only other similar case to my knowledge. I'm not sure what the right thing to do here is other than acknowledge these two are special cases.

Security-Reviews is currently in use and the rest were relics as far as I can tell and I have archived them.

In general I hope/expect for their to be more clarity to come on how the security team is organizing their work but it's been a mess in phab since time immemorial so it's a process to sort it out.

Thanks @Aklapper

Thanks @chasemp! I've edited the project descriptions a bit more to be clearer.

For the records, Security-Core had three watchers (akosiaris, bawolff, jay8g), Security-General and Security-Other and Security-Extensions have one watcher who was last active in August 2017 (jay8g).

Yes, this is a relic from the early days of phab. WMF-NDA is the only other similar case to my knowledge. I'm not sure what the right thing to do here is other than acknowledge these two are special cases.

Let's tackle that in T203511: Document phabricator user groups in a central place instead

Tgr added a subscriber: Tgr.Sep 9 2018, 11:31 AM

Agreed, archived as such. most of this was holdover from the BZ days.

This left things in a somewhat confusing state:

  • tasks within the archived projects were not migrated to Security and many of them have now no security-related tag at all
  • while the description for the other three tags were updated to explain the archival (although a pointer here would have been nice) and what to replace it with, Security-Extensions wasn't.

Yes, this is a relic from the early days of phab. WMF-NDA is the only other similar case to my knowledge. I'm not sure what the right thing to do here is other than acknowledge these two are special cases.

Updating the description of Security to be less threatening and to explain the dual nature of the project would be a start.

  • tasks within the archived projects were not migrated to Security and many of them have now no security-related tag at all

Hmm, indeed. Should that list be batch-edited to add Security tags (probably excluding some useless test tickets)? Or maybe just the open tasks?

  • while the description for the other three tags were updated to explain the archival (although a pointer here would have been nice) and what to replace it with, Security-Extensions wasn't.

Fixed.

Updating the description of Security to be less threatening and to explain the dual nature of the project would be a start.

I'm going to leave that one to the Security-Team...

Tgr added a comment.Sep 9 2018, 4:30 PM

IMO, open tasks should be added to Security and closed ones are not worth worrying about.

IMO, open tasks should be added to Security and closed ones are not worth worrying about.

Right. Done for those public ones by using https://phabricator.wikimedia.org/p/Phabricator_maintenance/ to decrease noise; for the non-public ones by using my individual work account when possible; for one task I could not edit I added a comment.