@Erik Sipsma @vito Hey 🚀

[tired ice]

Yeah part of the changes are that now if you want files/dirs from outside your module's source directory they need to be explicit arguments to the module (probably to it's constructor).

What the use case here specifically? Like what files do you want want that exist outside of ci/? Can give more specific suggestions based on that

[calm bough]

For my typescript dev modules, I created it inside a sub directory named ci but it requires source from parent

[calm bough]

Oh that's not cool 😦

[peak musk]

can't you put dagger.json at the top-level, and then have source: "ci"?

[calm bough]

This PR: https://github.com/dagger/dagger/pull/6522

[calm bough]

Would this work?

[queen coral]

Yes that's the recommended pattern. dagger.json at the root of your repo, and if you don't want to pollute your repo with module source, use source: "./other/dir".

[tired ice]

No not yet, source was actually removed in the previous changes (see this thread #1202321084016513044 message) so there's currently only a concept of a "root" and a source dir that contains all the module implementation code, but you can't separately configure a third variable of "subdir where the module implementation is"

But being able to configure that "source subdir" is coming in this PR https://github.com/dagger/dagger/pull/6575

[peak musk]

phew ❤️ i had a moment where i worried that we'd decided to get rid of this entirely 😄

[calm bough]

So python dev module is also broken?

Is there any workaround? Because I cannot access the source code from my module then :/

My need is

repo source code # <- how do I access this in the current state of dagger
ci/
   # Module implementation

[queen coral]

You pass the source code as argument to your build function

[calm bough]

Ughh I don't like this pattern

[queen coral]

Sorry

You would like even less what will happen to the ecosystem if we let that backdoor open

[calm bough]

Wdym?

[queen coral]

Inconsistent API for passing inputs. Maybe you pass the source code as an argument. Maybe it's implicitly available to the module because of where it's hosted. Maybe it's both, with co-located directory used as a default to the argument. There's no way to know! Just look at the README.

[calm bough]

I see

[queen coral]

It's the same problem as ambient access to environment variables

[calm bough]

Well, an argument in the top level object it will be then

[strong wedge]

Yeah, I still need to fix it, but it's fine. Fixed dagger.json locally, but not dag.host use.

[tired ice]

Can also be to the constructor, which may simplify further if the dir is needed in multiple functions across the module

[queen coral]

@calm bough but don't worry there is hope 🙂 #daggernauts message

[dry talon]

yeah I've landed on putting it in the constructor, feels nice so far

[calm bough]

My line become: dagger --source=$PWD/../ call project terminal --cmd=/bin/sh

Sounds okay

@errant yoke Here's the solution for your issue 😉

[dry talon]

../ should work instead of $PWD/../, looks less scary 😛

[strong wedge]

Or: dagger call -m dev --source=. project terminal

[calm bough]

It says it requires an absolute path

[calm bough]

^

[calm bough]

I like this one!

[calm bough]

host: directory: host directory ../: path ".." escapes workdir; use an absolute path instead ┃ input: resolve: host: directory: host directory ../: path ".." escapes workdir; use an absolute path instead

[queen coral]

Seems like something we can fix in the CLI

[tired ice]

We can also have the CLI automatically make it an abs path, which I think would be safe and extremely quick (or lift the limitation in the underlying host api)

[calm bough]

Yep!

For now I'll use Helder's method, it works well

I kinda like the new way, it feels more generic

[tired ice]

https://tenor.com/view/the-god-father-marlon-brando-vito-corleone-talk-to-me-gif-20107028

[peak musk]

hm, i was thinking actually. we should probably change this entire logic.
atm, it's a bit of an issue that a dagger server can effectively request any file from the client, since the checks are on the server

e.g. a modified server could grab a bunch of extra stuff

[tired ice]

My assumption is that we trust the server (since it's our code and lives in the dagger engine binary that you need to trust anyways, can't be changed by clients) and thus it can read files from the client as it wants but just needs to have guardrails around what clients can do (i.e. can't read each others files, etc.), which are in place. What changes were you thinking of?

Like a modified server would have to be a fork of dagger, at which point users are on their own 🙂

[peak musk]

i think the weird scenario i'm imagining is like in the context of a remote dagger engine (like one in kubernetes), or the future with compute drivers.
essentially, if i can trick you into connecting to my dagger engine, i can grab any file from your machine

super unlikely today, but i would potentially classify it as a bit of a security issue. but very minor, since it's only possible for weirder configurations of dagger (and not the default we ship)

[tired ice]

There is actually an option for the engine client to disable the filesync attachables already: https://github.com/sipsma/dagger/blob/49392773866282928a35f1590e210c01a5ed9827/engine/client/client.go#L65-L65 (think playground uses it), which could be exposed in the CLI for the paranoid if we wanted. But generally speaking if you connect to an evil engine, it can do all sorts of awful things outside of just reading files so I think we just need to approach the problem as ensuring clients connect to an engine they trust

[peak musk]

hm, maybe we should do both.
i know buildkit considers client<->server like this as a security boundary: https://github.com/moby/buildkit/blob/master/PROJECT.md#client

[tired ice]

Yeah also totally possible for the client to specifically allow only some paths. Would also need the same thing for our h2c/c2h attachables, etc.