fix(runtime): Improve Error Handling and-Dot Handling in-fqdn! Macro

[yazan-nidal]

Implement improvements for error handling and dot handling in fqdn! macro

This commit addresses issue (#23294 , #23552) by enhancing the error handling and dot handling logic within the fqdn! macro. Specifically, it:

• Handles parsing errors gracefully using pattern matching instead of unwrap().
• Adjusts substring parsing to correctly handle domain names ending with a dot.

This change improves the reliability and robustness of the fqdn! macro, ensuring more accurate parsing of fully qualified domain names.

Fixes: #23294 , #23552

[CLAassistant]

All committers have signed the CLA.

[mmastrac]

Thanks for the fix. Could you add some tests around the error cases this fixes?

Does this help w/ #23552 ?

[yazan-nidal]

Thanks for the fix. Could you add some tests around the error cases this fixes?

Does this help w/ #23552 ?

hi @mmastrac

Thank you for reviewing the fix! Since this is my first commit in Deno, I'm happy to add tests if necessary. Could you please guide me on how to locate existing tests in the codebase?

I tested the fix manually, but I'm keen to learn how tests are typically structured and where I can find examples within our project. This will help me understand the testing conventions used here and ensure that I contribute effectively to the test suite.

If you could point me to where I can find old tests or provide any resources on writing tests in Deno, I'd greatly appreciate it. Once I have a better understanding, I'll be more than happy to add the necessary tests for this fix.

Regarding issue #23552, I'm eager to ensure that our tests cover relevant error cases and edge scenarios.

Looking forward to your guidance!

[yazan-nidal]

@mmastrac
@bartlomieju
can u please review this pr?
I am not able to add reviewer.

[0f-0b]

This change would introduce a security hole.

$ cat a.js
const message = "AAABAAABAAAAAAAAB2V4YW1wbGUDbmV0AAAcAAE=";

// A program can trick the user into granting access to a single IPv6 address
console.log(
  await (await fetch(`https://[2606:4700:4700::1111]/dns-query?dns=${message}`))
    .arrayBuffer(),
);

// Now it can connect to the entire IPv6 network
console.log(
  await (await fetch(`https://[2606:4700:4700::1001]/dns-query?dns=${message}`))
    .arrayBuffer(),
);
$ target/debug/deno run a.js
✅ Granted net access to "[2606:4700:4700::1111]".
ArrayBuffer {
  [Uint8Contents]: <00 00 81 80 00 01 00 01 00 00 00 00 07 65 78 61 6d 70 6c 65 03 6e 65 74 00 00 1c 00 01 c0 0c 00 1c 00 01 00 00 0e 10 00 10 26 06 28 00 02 1f cb 07 68 20 80 da af 6b 8b 2c>,
  byteLength: 57
}
ArrayBuffer {
  [Uint8Contents]: <00 00 81 80 00 01 00 01 00 00 00 00 07 65 78 61 6d 70 6c 65 03 6e 65 74 00 00 1c 00 01 c0 0c 00 1c 00 01 00 00 0e 10 00 10 26 06 28 00 02 1f cb 07 68 20 80 da af 6b 8b 2c>,
  byteLength: 57
}

Note that the second fetch call proceeds without asking for permission.

[yazan-nidal]

Note that the second fetch call proceeds without asking for permission.

hi @0f-0b ,

It is for the same site, it will not request it the next time after approval the first time, and if it refuses, it will be rejected any other time, but it will ask you again if you submit a new request for another domain, and this is the original behavior, I just fixed it to make it not panic when using the wrong domain for fqdn! Macro, this did not affect the flow or behavior and was just to prevent panic

[mmastrac]

Requires some more work:

1. We can't return FQDN::default from parsing because that results in a broken permission descriptor
2. This will need some tests added to flags.rs, and spec tests added in tests/specs/run to ensure that it works as expected.
3. We'll also need to implement wildcard permission tests which we don't support -- ideally we'd return a better result from flags.rs when encountering these.

[yazan-nidal]

@mmastrac
@bartlomieju
@0f-0b

Please review the latest changes.

[bartlomieju]

@yazan-nidal there's a few linter errors - most of them are about use of eprintln! (which is now disallowed since 47f7bed) and a few because of using double reference. You can run ./tools/lint.js --rs locally to see these errors.

[dsherret]

I was just looking into #23753 and didn't realize this PR fixes the same issue.

However, I think perhaps we should be parsing the host upfront and surfacing the error instead of parsing within here and logging on failure? I'm not sure what's the best approach. I did a bit of work on this here (before I saw this PR): main...dsherret:deno:fix_panic_permissions_fqdn -- maybe that should be integrated into this pr?