[ctz]

This splits off some parts of #103 -- I've processed the prior comments made there.

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 1 benchmark is dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 3 untouched benchmarks

---

_{Comparing jbp-generalise-fetch (d88181b) with main (13255b5)}

[djc]

Can you explain some more of your thinking behind this? I feel like the fetching stuff here is a little unclear about whether it wants to be a framework or a library.

Do the intermediates and CRLite upstreams actually share a manifest type definition, or are you chosing to reuse their definition for your intermediates setup?

Would it make sense to attach MANAGED_EXTENSIONS to the PostProcessor trait (perhaps renaming it to something more generic)?

[ctz]

Can you explain some more of your thinking behind this? I feel like the fetching stuff here is a little unclear about whether it wants to be a framework or a library.

Mainly I want the networking details to be as reusable as possible. If intermediate preloading and crlite filters are doing something drastically different to fetch their data, that would feel very odd.

Do the intermediates and CRLite upstreams actually share a manifest type definition, or are you chosing to reuse their definition for your intermediates setup?

Depends what you mean by upstreams. The source data are different (crlite has a manifest-like JSON structure as part of the firefox settings service, but obviously is not a stable format and is re-cast into the manifest by the mirroring step; intermediates construct a manifest based on the contents of CCADB after sharding the intermediate certificates to limit the number of files needing to be downloaded.)

If you mean the upstreams as in mirror contents, yes, these already both use the same manifest format:

https://upki.rustls.dev/intermediates/manifest.json
https://upki.rustls.dev/revocation/manifest.json

Would it make sense to attach MANAGED_EXTENSIONS to the PostProcessor trait (perhaps renaming it to something more generic)?

It's a separate concern. Intermediates probably would have pem for extensions and no post-process step.

[djc]

Can you explain some more of your thinking behind this? I feel like the fetching stuff here is a little unclear about whether it wants to be a framework or a library.

Mainly I want the networking details to be as reusable as possible. If intermediate preloading and crlite filters are doing something drastically different to fetch their data, that would feel very odd.

Okay, I think that makes sense.

Do the intermediates and CRLite upstreams actually share a manifest type definition, or are you chosing to reuse their definition for your intermediates setup?

Depends what you mean by upstreams. The source data are different (crlite has a manifest-like JSON structure as part of the firefox settings service, but obviously is not a stable format and is re-cast into the manifest by the mirroring step; intermediates construct a manifest based on the contents of CCADB after sharding the intermediate certificates to limit the number of files needing to be downloaded.)

If you mean the upstreams as in mirror contents, yes, these already both use the same manifest format:

https://upki.rustls.dev/intermediates/manifest.json https://upki.rustls.dev/revocation/manifest.json

Right. Maybe we can add some comments to the Manifest type to explain who "owns" the format and where/how it is used?

Would it make sense to attach MANAGED_EXTENSIONS to the PostProcessor trait (perhaps renaming it to something more generic)?

It's a separate concern. Intermediates probably would have pem for extensions and no post-process step.

Fair enough.