Using kinto-wizard for example: 1) Dump into YAML $ kinto-wizard dump --full --server=https://settings.prod.mozaws.net/v1 --bucket blocklists --collection certificates > blocklists-certificates.yaml 2) Modify the YAML to rename blocklists to security-state and certificates to onecrl 3) Load the YAML using the cloudservices_kinto_prod user $ kinto-wizard load --server=https://settings.prod.mozaws.net/v1 --auth cloudservices_kinto_prod:XXX blocklists-certificates.yaml

We initialized the records of security-state-staging/onecrl with the current content of blocklists/certificates. Someone in the security team has to request a review, and someone approve it. After that, both collections will contain the same data. It will enable us to ship Bug 1512451 Until we declare security-state/onecrl as the new source, the security team would have to publish their changes in both places.

I've requested the update, and we should be mostly able to take it from here. That said, some of our comparison tooling [1] isn't working because anonymously accessing security-state-staging/collections/onecrl/ [2] fails, whereas the comparable previous bucket staging/collections/certificates [3] is open for reading to the public. Is that expected? Since our tooling can't use LDAP logins anymore, we went anonymous. [1] https://github.com/jcjones/kinto-blacklist-entry-checker [2] https://settings.prod.mozaws.net/v1/buckets/security-state-staging/collections/onecrl/records [3] https://settings.prod.mozaws.net/v1/buckets/staging/collections/certificates/records

> I've requested the update, and we should be mostly able to take it from here. Great, thanks! > Is that expected? Since our tooling can't use LDAP logins anymore, we went anonymous. Well, yes. The staging bucket isn't really supposed to be publicly readable. If you look at other collections like [1], you'll see that it's not the case. I'd suggest to avoid ad-hoc configs like this, and rely on the same strategy everywhere. The official way is to create a dedicated Kinto account (eg. "onecrl_check"). See this example Bug 1512466. A password can be generated and emailed to you, and you'll use basic auth as LDAP used to be. Then let us know if you want it to have read-only access or editor as well in order to publish changes (I guess you'll want to keep review manual). We'll add it to the appropriate permissions [2] [1] https://settings.prod.mozaws.net/v1/buckets/staging/collections/addons/records [2] https://github.com/mozilla-services/remote-settings-permissions/blob/d837a955765c7751a315822d7dd78108470807b1/kinto.prod.yaml#L1080-L1098

(In reply to Mathieu Leplatre [:leplatrem] from comment #3) > > I've requested the update, and we should be mostly able to take it from here. > > Great, thanks! > > > Is that expected? Since our tooling can't use LDAP logins anymore, we went anonymous. > > Well, yes. The staging bucket isn't really supposed to be publicly readable. > If you look at other collections like [1], you'll see that it's not the > case. I'd suggest to avoid ad-hoc configs like this, and rely on the same > strategy everywhere. I didn't know. Since the only bucket I ever use is this one, it seemed pretty reasonable. > > The official way is to create a dedicated Kinto account (eg. > "onecrl_check"). See this example Bug 1512466. A password can be generated > and emailed to you, and you'll use basic auth as LDAP used to be. > Then let us know if you want it to have read-only access or editor as well > in order to publish changes (I guess you'll want to keep review manual). > We'll add it to the appropriate permissions [2] OK. Will do for this and for CRLite. Thanks!