B2G teams are sadly missing older status-b2g flags which currently required for bug and vulnerability management: status-b2g-1.3 status-b2g-1.3T status-b2g-1.4 status-b2g-v2.0 status-b2g-v2.0M status-b2g-v2.1 Even though branches may have been declared EOL we still need those and the tracking information they contain quite a bit longer, for spotting and coordinating patch uplifting and partner efforts for shipping updates. In case of 2.x those flags were pulled right under our noses between opening bugs. Please reactivate them, and please involve :pauljt and me in future removal discussions.
Please involve B2G Release Management in this request.
Josh, what's been the though behind removing those B2G status flags? We absolutely need 2.x in vulnerability management for the bugs we're working on right now. We can probably do without 1.3 and 1.4 until there's partner demand for updates. AFAIU, the data isn't lost and can be re-activated on demand.
(In reply to Christiane Ruetten [:cr] from comment #2) > AFAIU, the data isn't lost and can be re-activated on demand. that's correct -- data is rarely deleted from bugzilla.
(In reply to Christiane Ruetten [:cr] from comment #2) > Josh, what's been the though behind removing those B2G status flags? We > absolutely need 2.x in vulnerability management for the bugs we're working > on right now. > > We can probably do without 1.3 and 1.4 until there's partner demand for > updates. AFAIU, the data isn't lost and can be re-activated on demand. The flag can be easily restore without question. However, we need to figure out a way of retiring old release otherwise we only backporting patches but no partners picking nor Mozilla internal using them (2.0/2.1). Questions includes: 1. How long do we need to support a release? 2. How do we communicate with partners about these security patches? Maybe also a good reference from platform team. What do we do for critical security patches found in Firefox browser 28 if user refuse to upgrade to latest version of Firefox? NI TAM manager Vance Chen for his comment.
Flags: needinfo?(jocheng) → needinfo?(vchen)
Agree with Josh, it is easy to restore the flag for older FFOS release, but the point is if it is really necessary(or I should say helpful) to do so : From partner's side, now I don't think any partner is still maintaining 1.3/1.3T/1.4 device. So they won't submit any bug of these branches to us, even if they do, I don't think Mozilla will spend time to fix the bugs. So from partner's point of view, I don't think they need the status flag At our end, 1.3/1.3T/1.4 are of Gecko v28 and V30, are we still maintaining v28 and v30? if our core team still backport important patches to v28/v30, then I agree we should probably still need the status flag for v1.3/1.3T/1.4 As to v2.0/v2.1, I think since some partners just launched the devices, maybe it is still helpful to restore the flag Thanks Vance
Also NI FxOS RM Mahe for any comment/opinion.
Offline discussed with RyamVM. Hi Christiane, We think we can restore flags (2.0/2.0M/2.1) in order for us to mark affected branches. We would prefer mark it as "wontfix" since it makes it more clear that we aren't committing to any backporting to that specific release but at least indicates that we're aware that it's affected and are choosing to not fix. Please note that infra for 2.0/2.1 are turned off for those releases (or in the case of 2.0m, never existed) thus we cannot backport these patches on those branches but we can certainly notify partners if the sec-team/TAM feels that to be a useful exercise. The patches can either provided as attachment or other manner. Any comment?
(In reply to Josh Cheng [:josh] from comment #7) > The patches can either provided as attachment or other manner. I'd be careful in what we commit to doing here. Backporting patches isn't always trivial and I doubt engineers are going to want to spend time rebasing and testing their patches against older versions that may or may not ever actually be used. One of the reasons we decided to explicitly EOL these older branches was to cut down on that wasted effort.
We currently have backports in 1188716, and that's a very serious vulnerability that deserves them. Unless they can land in our public repos, we obviously can't set them fixed. I'm not very partial towards either wontfix or affected, but wontfix sounds a bit harsh when we have patches around, but in the end, wontfix is fine for me. I'd absolutely encourage communicating the availability of these patches to all partners with 2.x devices. Let's use bug 1188916 as a guide to document procedures and contacts for extreme cases like this. It probably won't be the last time. Please include me in e-mail regarding this, Josh. Are you pinging TAM? I'll provide documentation infrastructure and make sure it'll find its place.
Flags: needinfo?(cr) → needinfo?(jocheng)
NI TAM manager Vance. Hi Vance, Could you help to check comment 9 from Christiane? Thanks!
Hi Christiane - Partners now are still maintaining the 2.x series devices, so if you have security patch ready for 2.x series, you can just ni me and I will have the correspond TAM to pass the information to partners and encourage them to take the patch and release the FOTA package
Flags: needinfo?(vchen) → needinfo?(cr)
Hi Byron, Per our discussion with sec-team. Could you help to restore following: status-b2g-v2.0 status-b2g-v2.0M status-b2g-v2.1 Thanks!
Hi Vance, there are backported patches for the lockscreen bypass in bug 1188716. Will ni you there.
(In reply to Josh Cheng [:josh] from comment #13) > restore: > status-b2g-v2.0 > status-b2g-v2.0M > status-b2g-v2.1 done.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(In reply to Byron Jones ‹:glob› from comment #15) > (In reply to Josh Cheng [:josh] from comment #13) > > restore: > > status-b2g-v2.0 > > status-b2g-v2.0M > > status-b2g-v2.1 > > done. Thank you Byron
You need to log in before you can comment on or make changes to this bug.