The project still lacks proper CD infra despite growth and community workarounds. Should this be addressed before its too late? @kristoff look at the issue tracker, its not going anywhere. So standing still instead of moving to another platform or improving current integration is a very bad decision.
Can you be more specific?
What are you missing from the current infrastructure approach? Please name some examples of community workarounds you see the need to be solved. How did you come to the conclusion that the issue tracker ādoes not go anywhereā?
From the discord:
Blockquote
i want to submit a pr to automate release process, could anybody provide hints and potential/workarounds/requests on linux and windows builds (unix already covered)? the GH actions infra would build the binary set (mirroring, expanding websiteās offerings), validate it, sign via Sigstore and publish all assets. All blueprinting is done, I just need to figure out how far I can take it and ifs not too early. It appears that this would really ease the bandwidth pressure on the website.
release would be triggered by a tag or a schedule for nightly builds. permissions could be tightened allowing specific accounts to trigger
Security posture should be improved ASAP (not going to expand on this one here, let me know if you want me to break it down on keybase/etc (not seeing proper channels)) and release process should be transparent and more decentralized (attestations are just in time to ease the things on the last two). Last year I spotted a project that was trying to ease the load on the zig website by re-hosting binariesāthis suggests too many things right away, so one of them got me into this topic. I love testing way more than anybody should, but choking the project with it does not feel right with me. So after seeing that community initiative to host zig binaries for CI I decided to stop feeling bad about my bandwidth and help the project.
Moving away from GH issue tracker will hurt contributions dramatically. This is not something the project can afford under current pressure.
Can you be more specific with your criticism? For example, try explaining the problem without leaning on the word āproperā, āgoing anywhereā, or āimprovingā, since all of these words mean different things to different people.
9 Likes
I used these words because there is no security policy at all (at the moment).
Again, as the third person asking you: could you please try to formulate actual specific criticism?
You are just mentioning words like security policy, CI, CD, the github issue tracker, bandwidth, without ever stating what the actual current problem is in your opinion.
I donāt think people reading/replying to this thread are currently able to discuss your ideas, because you are not giving any specific examples.
1 Like
I am not sure how else to put āthere is no active security policy for the project/orgā. Another issues are non-transparent builds (you cannot access release runs for build assertion) and lack of bandwidth because projects have to host zig binaries themselves to avoid ziglang site calls. Ill look for the forum post on the bandwidth that started the initiative and post it here, need to find it first (it was somewhere around the time i reached @kristoff about this).
Moving away from GH issue tracker will hurt contributions dramatically. This is not something the project can afford under current pressure.
Is there a movement to stop using the GH issue tracker? I have not seen anything regarding this. Perhaps a discussion on the Discord server, though Iāll admit I stopped reading much of what goes on in the Discord Server.
Last year I spotted a project that was trying to ease the load on the zig website by re-hosting binariesāthis suggests too many things right away, so one of them got me into this topic. I love testing way more than anybody should, but choking the project with it does not feel right with me. So after seeing that community initiative to host zig binaries for CI I decided to stop feeling bad about my bandwidth and help the project.
That sounds like you are refering to this delvelopment, where ziglang.org is now selfhosted, with community driven mirrors being available. Are you saying you want to help with hosting a mirror?
@kristoff stated that zig will not increase GH integration which makes no sense since, again, GH issue tracker is not going anywhere (for the reason stated above). So I am not sure why not to use it to close some holes in release engineering like lack of transparency in build runs (no access at the moment).
Precisely. I proposed to move binary hosting to GH/GL infra due the fact that other projects started to introduce their own mirrors, looks like thats the same topic.
Just to clarify, since I donāt think Iām the only one getting confused by this:
By āthe issue tracker is not going anywhereā you mean āthe issue tracker will not move to a different platformā and not āthe issue tracker is not making any progressā, right?
As the owner of a project which hosts zig binaries, I can say that, at least for me, avoiding ziglang site calls is not the main reason (it certainly is a nice side effect though). I like to sometimes switch to the latest master builds for new features, and I sometimes want to go back in time and run some old code. ziglang clears old master builds, so I have to āhostā them myself on github.
If Zig were to use github to host the releases then it might be feasible to keep all master builds available, but as far as Iāve seen, projects which do nightly builds like this still end up discarding older master build in favor for a cleaner release tab.
O yes, I meant that issue tracker is not moving to any other platform, so there seems to be no reason to ignore other GH services.
Thats actually another good reason to increase GH involvement in RE. Nightly builds in a separate repo to avoid flooding main release page? That way consumers could have access to outdated builds.
My interpretation of the ZSFās posture towards GitHub is that they are trying to avoid entrenching themselves as dependent on Github. They trying to avoid something like Pythons dependency on the benevolence of large corporations to host PyPi for free.
Here is a post by Loris on the problems python is running into: The Python Package Index Should Get Rid Of Its Training Wheels | Loris Cro's Blog
This explains the welcoming of tarball mirrors for zig releases.
Perhaps one way to address your security concerns is attempting build reproducibility? One could construct a project that just watches the zig repo and attempts to reproduce the release binary from source. Then if the binary is wrong you could get an email or something like that.
4 Likes
Technically, it seems too lateāzig has a massive dependency on GH issue tracker. So if GH dependency is a concern on any topic, whole GH must be ditched (GH is now relentlessly for-profit so any dependency on its services is kinda dangerousānothing can stop them from making service A dependable on service B).
A dedicated repo for attestations might be sufficient enough, but it sounds like a workaround.
I donāt think this is a particularly good argument.
I would say that depending on github to host letās say a few GB max for the projectās source code and itās issues is an entirely different thing compared to depending on github to create, host and distribute ~600 MB of additional build artifacts artifacts at least once a day.
1 Like
I would prefer zig to be on Codeberg, this also aligns with the ZSF Foundation more bc it is also a non profit organization. But besides that there are not much more arguments for that. Idk if it is worth it, bc it takes a lot of effort to migrate the Issues, maybe an opportunity to clean up?
2 Likes
Not the best one, just a valid one. I personally see no difference in the size of the dependency scope as long as it has anything to do with GH due the fact that they can change their service to any extent at any point, and they usually do so from for-profit perspective.
Codeberg sounds like a good alternative to self-hosted forge. Agree, the move would not be an easy task. Thats why I was thinking to postpone it till 1.0 and utilize GH to patch RE holes via attestations at least. It sounds like a good plan to start 1.0 on a properly built foundation with new issue tracker/etc, and right now there is still time to prepare for it.
As someone who deals with AppSec professionally I can assure you that āhaving securityā and āhaving security policyā are two different things. You can have one without having another. A blanket security policy does not advance your actual security unless you talk about specific security problems, threat vectors, etc.
1 Like
Sounds like a standard for-profit case where it is bad for revenue to follow security policy. Yea this is pretty much all for-profit operations if you ask me 
just my 2ct:
(1) as a regular user, Iāll have to trust that homebrew, apt, apk, pacman, scoop, zvm, mlugg/setup-zig (etc etc etcā¦) and all the other ways to install a Zig binary donāt inject malware anyway - and most of those cannot be controlled by the Zig authors either
(2) if I donāt trust those decentralized installer tools, then I can at least trust this centralized download page more: Download ā” Zig Programming Language
(3) and for the even more paranoid I would expect that they build Zig themselves (after carefully auditing the sourceā¦)
(e.g. I kind of fail to see how a publicly accessible CI/CD process would help the situation - except as a āok, nice to have that automatedā - but I doubt that the nightly builds are kicked off manually. Also most Linux package managers probably wouldnāt use those executables anyway but build Zig on their own)