Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refactors the integration of the Zig toolchain within Xmake by separating its functionality into dedicated toolchains for Zig language compilation and C/C++ cross-compilation. This enhances modularity, clarifies usage, and centralizes the logic for detecting target architectures, making the build system more robust and easier to manage for projects leveraging Zig's diverse capabilities. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the Zig toolchain by splitting it into zig for compiling Zig code and zigcc for using Zig as a C/C++ compiler, which is a great improvement for clarity and modularity. However, a critical security vulnerability was identified in the zigcc toolchain's wrapper script setup: the use of a shared temporary directory for wrapper scripts can lead to local code execution on multi-user systems. This should be addressed by using a more secure, user-specific location for these scripts. Additionally, a few areas were found where the code can be further improved for maintainability and to follow best practices.
| local wrapper_path = path.join(os.tmpdir(), "zigcc", tool) .. script_suffix | ||
| if not os.isfile(wrapper_path) then | ||
| if is_host("windows") then | ||
| io.writefile(wrapper_path, ("@echo off\n\"%s\" %s %%*"):format(zig, tool)) | ||
| else | ||
| io.writefile(wrapper_path, ("#!/bin/bash\nexec \"%s\" %s \"$@\""):format(zig, tool)) | ||
| os.runv("chmod", {"+x", wrapper_path}) | ||
| end | ||
| end |
There was a problem hiding this comment.
The _setup_zigcc_wrapper function creates wrapper scripts in a predictable, shared temporary directory (os.tmpdir()/zigcc). On multi-user systems (like Linux), an attacker can pre-create these files with malicious content. Since the code checks for the existence of the file before writing (if not os.isfile(wrapper_path)), it will not overwrite an existing malicious script. This allows an attacker to execute arbitrary code with the privileges of any user who runs xmake with the zigcc toolchain.
To remediate this, use a more secure location for the wrapper scripts, such as a directory within the user's home directory or a project-specific directory. If a temporary directory must be used, ensure it is unique to the user and has restricted permissions (e.g., 0700).
| -- define toolchain | ||
| toolchain("zig") | ||
| set_kind("standalone") | ||
| set_homepage("https://ziglang.org/") |
There was a problem hiding this comment.
The set_kind("standalone") declaration has been removed. Since the zig toolchain can still be used as a standalone toolchain for Zig language projects (as seen in the test cases), it seems this declaration should be kept for clarity and correctness, similar to other language toolchains like dlang, rust, etc. Please consider adding it back.
set_kind("standalone")
set_homepage("https://ziglang.org/")
| local paths = {} | ||
| for _, package in ipairs(toolchain:packages()) do | ||
| local envs = package:envs() | ||
| if envs then | ||
| table.join2(paths, envs.PATH) | ||
| end | ||
| end | ||
| local sdkdir = toolchain:sdkdir() | ||
| if sdkdir then | ||
| table.insert(paths, sdkdir) | ||
| end | ||
|
|
||
| local zig = get_config("zc") | ||
| local zig_version | ||
| if not zig then | ||
| zig = find_tool("zig", {force = true, version = true, paths = paths}) | ||
| if zig and zig.program then | ||
| zig_version = zig.version | ||
| zig = zig.program | ||
| end | ||
| end | ||
| if zig then | ||
| _setup_zigcc_wrapper(zig) | ||
| toolchain:config_set("zig", zig) | ||
| toolchain:config_set("zig_version", zig_version) | ||
| return true | ||
| end |
There was a problem hiding this comment.
The logic for finding the zig executable is duplicated in xmake/toolchains/zig/xmake.lua and xmake/toolchains/zigcc/xmake.lua. To improve maintainability and avoid code duplication, this logic could be extracted into a new utility function in xmake/modules/private/utils/toolchain.lua.
1 participant
#7372