ikskuh
commented
1 year ago I really like the idea of running the build in a sandboxed environment, but right now i have some use cases that would not be possible.
The first one is that i have a custom build step that compiles resources into a desired target format:
pub const CompileDrawingStep = struct {
const Self = @This();
sdk: *const Sdk,
step: Step,
input_file: FileSource,
output_file: GeneratedFile,
pub fn getOutputFile(self: *Self) FileSource {
return FileSource{ .generated = &self.output_file };
}
fn make(step: *Step) anyerror!void {
const self = @fieldParentPtr(Self, "step", step);
const src_path = self.input_file.getPath(self.sdk.builder);
// Just run the input file through the TVG parser once
{
const file = std.fs.cwd().openFile(src_path, .{}) catch |err| {
std.debug.panic("Failed to open {s}: {s}", .{
src_path,
@errorName(err),
});
};
defer file.close();
validate(self.sdk.builder.allocator, file.reader()) catch |err| {
std.debug.panic("{s} is not a valid TinyVG file: {s}", .{
src_path,
@errorName(err),
});
};
}
// No need to cache it, we just verbatim pass the file through
self.output_file.path = src_path;
}
fn validate(allocator: std.mem.Allocator, reader: std.fs.File.Reader) !void {
var parser = try tvg.parse(allocator, reader);
defer parser.deinit();
while (try parser.next()) |cmd| {
_ = cmd;
}
}
}; I have several of similar build steps (one invokes a format compiler, one converts images via zigimg, ...) that will finally be bundled into a zig package:
https://github.com/Dunstwolke/core/blob/047d36ce01be3fd7ac160c2360f0139b9c0a5856/Sdk.zig#L393-L601
This stuff will be way harder with a purely declarative/sandboxed build runner.
Another example is the Zig Text Template: https://github.com/MasterQ32/ZTT/blob/master/src/TemplateStep.zig#L43-L278
Imho the ability to do such things without having to put all of that logic into separate executables (in case of Dunstwolke compiler that isn't really possible anyways) is quite a significant feature of the Zig build system.
If we can get such things working (preopen the project directory to read/write file system access might already be enough), it would be awesome to have these things sandboxed
kuon
deflock
mattnite
rdunnington
silversquirl
eLeCtrOssSnake
thezealousfool
ScottFreeCode
daurnimator
presentfactory
BratishkaErik
KilianHanich
Extracted from #14265.
build.zig is handy for adding build logic, but it's not handy to trust a lot of different people's code running natively on the host. A deep dependency tree has the problem that many different build.zig scripts are all running, and the chance of insufficient auditing grows quickly the more dependencies there are.
This issue is to make the zig build system compile build.zig to wasm32-wasi instead of natively, and merely output its build graph, based on the user-provided build options, to stdout. At this point a separate build_runner can execute the requested build steps (or not, depending on the permissions granted).
Perhaps a middle ground, here, would be to run the make() steps directly in the WASI code. But eventually the idea would be that make() steps happen by a separate build runner, not by the wasm guest.
I can foresee a potential escape hatch for opting into running build.zig directly on the host. As an example, the Android SDK package wants to access the Windows registry in some cases. However, I would like to avoid even having this escape hatch if possible.
This issue will require Zig to gain a WASI interpreter, written in Zig. Whereever will we find one?