Dhall-lang: Importing from a configurable HTTP URL?

[michalrus]

Hello! :wave:

Could something along the lines of :arrow_down: be done?

{
  connectivity =
    let c = (./connectivity.dhall).local-dev in
    c // http://localhost:${Integer/show c.backendPort}/connectivity-overrides.dhall
}

[ocharles]

I think parameterised imports aren't supported as they can be a security
risk.

On Thu, 12 Jul 2018, 2:05 pm Michal Rus, [e-mail] wrote:

Hello! 👋

Could something along the lines of ⬇️ be done?

{
connectivity =
let c = (./connectivity.dhall).local-dev in
c // http://localhost:${Integer/show c.backendPort}/connectivity-overrides.dhall
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dhall-lang/dhall-lang/issues/187, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABRjiwRVWcP9H9faFs9WkRsYKSQQDZWks5uF0mDgaJpZM4VMz7k
.

[Gabriel439]

There are two issues to supporting the general case of computed imports:

• One is the security risk since this can be used to exfiltrate sensitive program state
• The second reason is that import resolution precedes normalization which prevents this sort of computed import (with caveats; see below)

However, Dhall does support computed headers, which avoid the above two issues because:

• The semantics enforce that the expression for computing the headers is closed (i.e. you can't reference other variables in scope because it is imported from another file), which prevents it from being used as an exfiltration vector
• The semantics actually have a special case which allows for importing, type-checking, and normalizing the expression for computed headers entirely within the import phase. This is the exception in the language semantics to the rule that import resolution strictly precedes type-checking and normalization (Note: this is not yet standardized, but this will be how it works when standardized)

So if you could parametrize the request via headers instead of the URL then you could do what you want. For example, suppose that you could send the information via some fictional Port header, then you could do this:

-- ./headers.dhall

[ { header = "Port", value = Integer/show ((./connectivity.dhall).backendPort) } ]

-- main.dhall

{
  connectivity =
    let c = (./connectivity.dhall).local-dev in
    c // http://localhost/connectivity-overrides.dhall using ./headers.dhall
}

... and that would work.

In principle, we could also add something similar to using for computing the path. i.e. something like http://example.com path ./path.dhall analogous to using. However, I don't think we want to be able to compute the port (since that is transmitted in the clear even for an HTTPS request) nor do we want to be able to compute the domain (since that can leak via DNS even if you make an HTTPS request).

However, before doing that I'd still like to see if using computed headers can solve your problem first.

[michalrus]

Oh, this all makes perfect sense. Thank you for the detailed explanation! I wouldn’t have thought of these vectors initially.

My case is that I’m running a few versions of an environment locally, each in a separate set of QEMU VMs. Their ports are configured in connectivity.dhall, which is also read by Nix, when defining those VMs.

However, there are some values that Nix computes, which I’d like to able to also see from locally running Haskell code (on my laptop, bare metal, not in VMs), one that’s currently being developed. I could copy those values, but I’d rather have them defined in a single place.

It’s not a problem when all of the code is running in a VM, I can just override in-VM Dhall files, no problem. And to deliver them to bare-metal Dhall, I thought of sharing them over HTTP from within a VM. But its port changes, depending on which env exactly I’m working with.

So I could hardcode those import URLs alongside backendPorts, I guess, but I hoped to be able to reuse backendPort, as this is the only thing that changes.

Thank you once more!

[Gabriel439]

You're welcome! 🙂

[ocharles]

It sounds like this was answered, so I'm going to close this. Please feel free to reopen if I read that wrong!