BUGFIX: Make OPENPGPKEY records functional.#4139
Conversation
Previously, DNSControl#3718 introduced support for `OPENPGPKEY` records. However, that PR assumed that the `OPENPGPKEY` key data was hex-encoded. [RFC 7929 §2.3] states that when in "Presentation Format", `OPENPGPKEY` record data must be base64-encoded instead. Since most hex-encoded data can be parsed as base64, DNS providers would not reject a hex-encoded key, but they would instead parse it as base64, leading to a corrupt result. Additionally, the previous PR also unconditionally lower-cased the key data, making it impossible to use base64-encoded keys. Once again, lowercased base64-encoded data can usually be parsed as base64, but the result will be corrupted. This current PR fixes both of these issues by instead treating the key as base64-encoded data, and by no longer lower-casing the key data. To maintain backwards compatibility with existing hex-encoded keys, the code attempts to detect keys that appear to be hex-encoded, and decodes them as hex before re-encoding them as base64. [RFC 7929 §2.3]: https://datatracker.ietf.org/doc/html/rfc7929#section-2.3
Currently, using the `--debug` command-line argument just prints the DNSControl version and exits. This is because the long option `--debug` is mapped to the short option `-v`, but `-v` is used for `--version`, so the parser gets confused. This commit remaps the long option `--version` to the short option `-V`, which prevents the parser from getting confused and makes `--debug` work again.
b068798 to
5179a4c
Compare
tlimoncelli
left a comment
There was a problem hiding this comment.
Hello friend!
Thanks for spotting this and making a PR to fix it.
The new encoding makes a test fail. Can you please take a look at this?
$ cd ~/git/dnscontrol/pkg/js
$ go test ./...
# Test 056 fails. The actual results are in parse_tests/056-openpgpkey.json.ACTUAL
# If they are correct...
$ cp parse_tests/056-openpgpkey.json.ACTUAL parse_tests/056-openpgpkey.json
$ cd ../..
$ bin/generate-all.sh
|
@gucci-on-fleek I was trying to make a PR based on your PR. I did the usual "git push" which gives me a URL to click to make the PR, but it actually accepted the push. oops! i guess the permissions were wide open. Sorry. Anyway... I was able to make the change to |
|
(Sorry for the delay, I was travelling last week)
Fine by me, thanks for pushing the fixes! That worked because I had the “Allow edits and access to secrets by maintainers” box checked (which I think is the default): 
Yes, that looks like the correct output to me. Thanks again! |
I'm unable to get DNSControl to create an
OPENPGPKEYrecord thatgpgoropenpgpkeywill accept. From what I can tell, it looks like DNSControl always corrupts or misinterprets the input, meaning that there is no possible input that will produce a valid result. But if I build DNSControl with this PR applied, bothgpgandopenpgpkeyaccept theOPENPGPKEYrecord without any complaints.I'm probably just misunderstanding something though, since I wouldn't expect for the current code to not work at all.
I've also expanded the
OPENPGPKEYdocumentation, and fixed a small bug with the--debugargument. Full commit messages:BUGFIX: Make
OPENPGPKEYrecords functional.Previously, #3718 introduced support for
OPENPGPKEYrecords. However, that PR assumed that theOPENPGPKEYkey data was hex-encoded. RFC 7929 §2.3 states that when in "Presentation Format",OPENPGPKEYrecord data must be base64-encoded instead. Since most hex-encoded data can be parsed as base64, DNS providers would not reject a hex-encoded key, but they would instead parse it as base64, leading to a corrupt result.Additionally, the previous PR also unconditionally lower-cased the key data, making it impossible to use base64-encoded keys. Once again, lowercased base64-encoded data can usually be parsed as base64, but the result will be corrupted.
This current PR fixes both of these issues by instead treating the key as base64-encoded data, and by no longer lower-casing the key data. To maintain backwards compatibility with existing hex-encoded keys, the code attempts to detect keys that appear to be hex-encoded, and decodes them as hex before re-encoding them as base64.
BUGFIX: Make
--debugnot print the version.Currently, using the
--debugcommand-line argument just prints the DNSControl version and exits. This is because the long option--debugis mapped to the short option-v, but-vis used for--version, so the parser gets confused. This commit remaps the long option--versionto the short option-V, which prevents the parser from getting confused and makes--debugwork again.