1558812 - Upgrade kinto-offline-client to 12.4.3

Status: RESOLVED FIXED

(Firefox :: Remote Settings Client, defect)

Comment 1

[Mathieu Leplatre [:leplatrem]]

Attachment: Bug 1558812 - Upgrade kinto-offline-client to 12.4.3

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/571616e08622
Upgrade kinto-offline-client to 12.4.3 r=glasserc

Comment 3

[Ethan Glasser-Camp (:glasserc)]

Comment on attachment 9071609 [details]
Bug 1558812 - Upgrade kinto-offline-client to 12.4.3

Beta/Release Uplift Approval Request

• User impact if declined: Users will not be able to retrieve updated security-state/intermediates data. :jcj and :dkeeler can probably provide more information about the security impact of this.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Old code clearly did not work (obvious from simple inspection); the fix will at least make things slightly better.
• String changes made/needed:

Comment 4

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/571616e08622

Comment 5

[Julien Cristau [:jcristau]]

Do you have more details about the affected collections? At least intermediates preloading is disabled in 68.

Comment 6

[J.C. Jones [:jcj] (he/him)]

Basically, any Kinto collection that relies on updating existing entries rather than just adding or deleting new ones can suffer from this bug.

Intermediates is a big one, since we don't want to make clients re-download two thousand 3kB files. OneCRL and such we don't tend to edit, though we have assumed always that we could if we made an improper entry. Now we know, at least until this patch is disseminated, we have to delete and re-add.

Crypto Engineering, thus, doesn't critically need this in 68, though it would be nice to have for the lifetime of 68 ESR. As-is though, we need to make a process remediation that if we have an error in OneCRL (or CRLite, or intermediate preloading) that we delete/re-add.

Comment 7

[Mathieu Leplatre [:leplatrem]]

Basically, any Kinto collection that relies on updating existing entries rather than just adding or deleting new ones can suffer from this bug.

More precisely, any collection that relies on the local fields feature.
AFAIK Intermediates is the only one.

[...] since we don't want to make clients re-download two thousand 3kB files.

In the attachment downloader that we provide, we store the attachments files in the profile folder. Inserting into the Cert storage would decorelated from downloading (see also Bug 1559132)

though it would be nice to have for the lifetime of 68 ESR

Do you plan on enabling CRLite / new cert storage at some point?
If yes, then we should uplift this patch.

Comment 8

[Ethan Glasser-Camp (:glasserc)]

If the feature is going to remain disabled for 68, then I guess the urgency to uplift the patch is diminished. However, I did some queries in https://dbc-caf9527b-e073.cloud.databricks.com/#notebook/131943/command/131947. We can see that many beta clients are trying and failing to sync this collection. Maybe at an earlier point, when the feature was still tentatively enabled for beta, the clients did the downloads and corrupted their local data because of this bug. IMO that local data can remain corrupted -- it won't affect remote settings in other collections -- but we have to remember that it's still there when those clients roll over to the next beta version.

Comment 9

[J.C. Jones [:jcj] (he/him)]

OK, if it's only those with local_fields affected, we do not need this for ESR 68. CRLite and intermediate preloading can ride the trains normally.

Comment 10

[Julien Cristau [:jcristau]]

Comment on attachment 9071609 [details]
Bug 1558812 - Upgrade kinto-offline-client to 12.4.3

Thanks all!

Comment 11

[Ethan Glasser-Camp (:glasserc)]

This decision means that CLRite/intermediate preloading can never be preffed on in 68/68esr. I think that's OK because since https://bugzilla.mozilla.org/show_bug.cgi?id=1547877, those features aren't even compiled in release. However, could you please confirm that it's OK? ni? sec-eng, relman

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I think that's ok. Enabling CRLite/intermediate preloading on 68/68esr would require a number of uplifts (of patches we haven't even written yet), so I'm confident it will never be in 68.

Comment 13

[J.C. Jones [:jcj] (he/him)]

The only reason I see for this to be uplifted is that impressive graph of kinto errors coming from this... but since it's prefed off in ESR, those errors should tail off as the train passes us by.

But then again, CryptoEng isn't the one getting the flood of errors, so I don't want to be heartless here.

Comment 14

[Anca Soncutean, Desktop QA]

I will mark this qe-verify - as per comment 3.