tl;dr let’s say I have two private github repositories,
timbertson/app. Base is… some shared stuff, and app builds upon it.
When I import
timbertson/app/package.dhall, I will need to pass auth headers including my $GITHUB_AUTH environment variable.
That all works fine when I’m importing locally, but comes unstuck when I want to import
app/package.dhall from github directly - I can’t evaluate the header expression since it can’t access any environment variables.
One fallback which works in both local and remote contexts is:
-- base-impl.dhall (https://raw.githubusercontent.com/timbertson/base/COMMIT_ID/package.dhall using ./github-headers.dhall) ? ../../../base/COMMIT_ID/package.dhall
and then importing that (to freeze it):
-- base.dhall ./base-impl.dhall sha256:(...)
But it’s got quite a few usability issues:
- I can’t test the (local) path is right without actually pushing it and importing the result
- I need to repeat the COMMIT_ID in both parts, and keep the paths in sync
- it confuses tooling (e.g. I have a script to bump a commit for github imports, and it’ll only understand the first import)
- I need two different files for a single import
- the error messages for fallbacks tend to be more confusing, since one of the two errors is “expected” but users aren’t always aware of which one or why. And even when they are it’s still a screenful of error message to wade through.
So I’m wondering if there’s a modification to the the “same origin” policy which could support a single import working in both contexts.
One idea would be that for a remote file (imported from the web), any transitive imports with the same origin implicitly use the same headers (even if it’s not a relative import). I think it would also need to ignore explicit headers in the case where a remote import happens to contain a fully-qualified import for the same origin, which is definitely a little surprising.
I imagine headers are only really used for auth in practice though, so this slightly surprising behaviour is likely to be the most useful? I don’t believe it weakens dhall’s security posture, since it only affects behaviour which is already within the same origin (and can already use relative imports).