You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Write a pcapkit/vendor/tls crawler for ContentType and HandshakeType #2495
pcapkit.const.tls.content_type.ContentType and pcapkit.const.tls.handshake_type.HandshakeType (#2441) both cite a live IANA TLS-parameters registry and claim full coverage, but no pcapkit/vendor/tls/ crawler exists to back them -- flagged in #2441's own review and merged on the stated reasoning that the crawler would follow.
Why it matters
Every other const module is generated and re-crawled; these two are hand-maintained, so a future IANA addition silently goes stale.
Next step
Write pcapkit/vendor/tls/content_type.py and handshake_type.py following the existing crawler template (pcapkit/vendor/default.py), add both to pcapkit/vendor/__init__.py's __all__, and regenerate the two const modules from them.
If it's a hand tailored/maintained registry, use the DATA attribute for the crawler. There're existing presidents for this and the current convention doc on main is incorrect. There's no exception from this ruling.
Ruling reconciled: no exception. ARPHRD still needs a crawler -- the DATA-attribute pattern already used elsewhere for hand-tailored registries, not a live-URL scrape. Reworking const-vendor-pairing.rst to drop the exception section and documenting that pattern, plus writing the ARPHRD crawler, against the real precedent rather than guessing at it.
ARPHRD side done as PR #2497: new DATA-attribute crawler, const module regenerated as a no-op, doc rewritten per the no-exception ruling. TLS crawler (the other half of this issue) is separate work, not started.
Reopening: PR #2497 closed this automatically via the "Closes #2495 in part" keyword, but the TLS crawler (the other half) is not done. Relabelling pending since no worker is on it.
Activity
JarryShaw commentedon Oct 31, 2026
ALL const MUST have its own vendor crawler.
If it's a hand tailored/maintained registry, use the DATA attribute for the crawler. There're existing presidents for this and the current convention doc on main is incorrect. There's no exception from this ruling.
JarryShaw commentedon Oct 31, 2026
Ruling reconciled: no exception. ARPHRD still needs a crawler -- the DATA-attribute pattern already used elsewhere for hand-tailored registries, not a live-URL scrape. Reworking
const-vendor-pairing.rstto drop the exception section and documenting that pattern, plus writing the ARPHRD crawler, against the real precedent rather than guessing at it.JarryShaw commentedon Oct 31, 2026
ARPHRD side done as PR #2497: new DATA-attribute crawler, const module regenerated as a no-op, doc rewritten per the no-exception ruling. TLS crawler (the other half of this issue) is separate work, not started.
feat(vendor): add the ARPHRD crawler, DATA-attribute shape (#2495)
feat(vendor): add the ARPHRD crawler, DATA-attribute shape (#2495) (#…
JarryShaw commentedon Oct 31, 2026
Reopening: PR #2497 closed this automatically via the "Closes #2495 in part" keyword, but the TLS crawler (the other half) is not done. Relabelling
pendingsince no worker is on it.fix(vendor): add the SSLv2 crawler, DATA-attribute shape
fix(vendor): add the SSLv2 crawler, DATA-attribute shape
feat(vendor): add the TLS content-type/handshake-type crawlers, close…
feat(vendor): add the TLS content-type/handshake-type crawlers, close…
feat(application): add an SSLv2 dissector (#2466)