Buffer bump #1446
Buffer bump #1446
Conversation
|
Do people really care about GPG/PGP these days? |
|
To add to @tmthrgd reply: this is with older RSA keys or something? Messsages this big will also lead to fragmentation problems on the wire |
case in point.
messages this small evidently lead to problems in this lib before it even gets on the wire. your point is moot: DOT, DOH, TCP based protos resolve this. These problems are discussed in the RFC. |
|
[ Quoting ***@***.***> in "Re: [miekg/dns] Buffer bump (PR #14..." ]
Do people really care about GPG/PGP these days?
case in point.
To add to @tmthrgd reply: this is with older RSA keys or something?
Messsages this big will also lead to fragmentation problems on the wire
messages this small evidently lead to problems in this lib before it even gets
on the wire.
your point is moot: DOT, DOH, TCP based protos resolve this. These problems are
discussed in the RFC.
just upping the value also isn't a real solution. Add a space (as bind also randomly does)
should (i think) also work, as then you get multiple tokens.
all the newer based protos are mostly for the last mile, so of very much limited value
|
It's low hanging fruit - the RFC states just a single line of base64 without elaborating further. |
How does adding a space into the source text help the buffer of fixed size, which holds the text? Your test cases seem to be designed to trigger the error through sheer length, whether split by spaces or not. |
|
OK - how about this? Just reduce the overall buffer size to 512 bytes, and make it something we can grow by 512 bytes every time we run out. It also fixes my problem, and obsoletes length test cases (or at least reverses the fail logic). |
make max token size buffers str and com something we can grow. Why? Because. Reasons: When experimenting with OPENPGPKEY records, which themselves are basically a key, if my zone file already has an RSA 4096 public key record, this lib goes boom: dns: bad OPENPGPKEY PublicKey: "token length insufficient for parsing" at line: ..... The key is good. Testing against bare ed25519 keys whose base64 length is ~320 characters and there are no problems Testing against a bare RSA4096 key whose base64 length is ~3100 characters and: problems. Bare is the key word here, since for DNS, one ideally publishes as bare a key as possible, minus signatures, minus photos, minus extra metadata beyond the essential that will push a record length up. A typical public key with two RSA 4K subkeys and several signatures may rise to > ~21000 bytes.
Reverse TLSA test record fail logic TestNewRRCommentLengthCrasherString: ...
if that's easy to do, then yes |
|
Already done. Sitting ready in this PR.
|
Also version bump
See individual commit messages