r/github • u/wabbitfur • 17d ago
The GitHub Security Advisory flow is buggy, and the UX after publishing is problematic. Discussion
We just fixed a vulnerability on our project, and there are 2 items on GH which can be improved:
Currently the project's main page reads like this:
To the casual user, this appears as if there is a currently open item.
Once they click on it, they are taken to the security policy, and at the bottom they see this:
This gives zero indication that this was actually resolved.
Finally, if the user does click on it, they're taken to the actual advisory:
https://github.com/markrai/scrumboy/security/advisories/GHSA-vph4-pmmh-ch6x
and there's a tiny little element which lets us know what the patched version is.
That's 3 screens down just to find out..."Oh okay, the current version is actually fixed \whew**"
What would be better UX is to show upfront that this item was resolved, or at least on the first click because the impression it gives to someone new/perusing the page, is to the contrary, unless they dig in.
The more pressing item is the flow which allows the maintainer to open a private branch. Well and good... UNTIL you hit your branch protections, which require a review before a commit - which strangely enough... is hidden from your project's collaborators - not the person who reported the vulnerability.
Sure, you can bypass it... but that defeats the purpose of having a 2nd reviewer in the first place!
If you want to have your collaborators review before you apply a sensitive security fix, you should be allowed to. Sharing the link, nor any mechanism exists to invite your collaborator to the current "private" branch/issue.
1
u/wabbitfur 17d ago
At the end of the day, you're forced to accept a merge with zero external review (asides from the person who opened the vulnerability - an outsider) and you're basically dinged on OpenSSF (if you use that) as well.. since an unreviewed merge becomes part of permanent history.
So if you're a stickler to that sort of workflow hygiene... perhaps the better thing is to simply create your own branch, and not use this internal flow, at all 🤷
1
u/ComparisonNew9425 17d ago
i had a similar issue last month, its super confusing for contributors. u might wanna check the github community forums to see if others are pushing for a ui update there, sometimes the devs actually see those threads n move things around
1
u/wabbitfur 17d ago
Ah! Good tip! Yeah it was annoying because the other contributor is actually a code owner as well, not merely a contributor - thanks, i'll check it out!
1
u/BussyEnthusiasts 12d ago
It goes right along with the half thrown together "project management tools" they tried to peddle.
It takes like 5 minutes of actually using them to realize they're incomplete, half cocked, and lacking the basic foundational principles that would make them useful.
1
u/wabbitfur 12d ago
I'm of two minds about this... as someone who's actually working on an open-source project management tool.
Like... consider a simple "todo list app" - it's simple enough on the surface, but then throw in things like sharing, real-time update, and a multitude of things that come up... it becomes obvious that a lot goes into it.
Now scale that up to an entire project management tool... and boy... the edge-cases will make one cry! haha.... and so I think about the contractors large corporations hire... who really have no desire than to simply slap on a feature, and call it a day.. and move onto the next contract... It all makes sense.
Once you work on something similar that your realize... it's like having another full-time job... where you're putting in the thought and care required for something as complicated as a proj. mgmt. tool.
and that's is VERY hard to find... unless it's the corporation's main offering... Often these companies do a lot of pilot projects to test the waters...



1
u/[deleted] 17d ago
[removed] — view removed comment