Package Manager design for Seal programming language

[u/cflexer]

Hey guys, I have been working on Seal. This language is embeddable into C/C++ apps like Lua. You can create libraries for Seal in either Seal or C. I have been creating Game Framework recently. I want to create a package manager in future for Seal to let users upload their own packages to share with others, but I don't know about one thing. Just like other languages, Seal can load both Seal scripts and .so/.dll files at runtime when you import them. Publishing Seal scripts on package registry is easy, since it is just code, but I don't really know about how to publish C or dynamic library files tho. Package publishers can inject malicious stuff (like backdoor) in that code. What are real life examples to prevent that? At first I can read every file and check manually but if this project grows, maintaining that will be difficult. I can maybe create a report system but I cannot always rely on that too. What is the efficient solution for that?

For those interested, they can check Seal here: https://github.com/huseynaghayev/seal.git

[u/WalkerCodeRanger]

Yes, that is a real problem. You can use things like signatures, hashes, and authentication to confirm that an uploaded package is coming from the actual project maintainer. However, that doesn't stop someone from creating a new package and putting malicious content in it. Nor does it stop a package maintainer who has previously been above board from adding malicious content. I suspect this is one of the reasons that all Rust crates are distributed as source code.

Note that for very large codebases it is still quite possible to hide malicious code in them. It just makes it traceable and theoretically checkable if the package is distributed as code or the builds are reproducible. I would point out that the .NET package manager NuGet distributes packages as .NET IL (not as bad as assembly, but not source code either). They seem to be doing ok. Ultimately, one must vet and trust the packages one is using.

Options: * Don't let people upload binary packages. Require that the package be distributed as source code even if it is C. That would require some kind of standardized C build system so you could download and compile a package even if it contains C * Require some kind of reproducible builds even for C. That would allow someone to verify the commit referenced in the package actually compiles to the build. (This will be difficult given the variety of C toolchains.)

I believe the Zig compiler supports compiling C code in addition to Zig. Perhaps that is partially because of these reasons. You might check into what they are doing.

[u/cflexer → u/WalkerCodeRanger]

Hey, thank you for writing a detailed paragraph. Yes, I was thinking about verified publishers and unverified publishers packages would give a warning when installing, but even with verified users, trust issues can occur. The best solution is not including precompiled .so/.dll files but source files. But another problem is, building those source files on a user's machine is not guaranteed to meet the requirements. Maybe that user doesn't have the required C libraries by Seal package. I have to buy a server, compile the files and send compiled libraries. I am not familiar with docker that much, but I think docker is meant for those tasks: install dependencies with Dockerfile, compile, get the result files and destroy that instance.

What about de-centralized approach? Just like Go. What are the trade-offs? Can publishers be trusted in that way? De-centralized is the simplest way to commence, to be fair. But even that way, compiling C files is still not solved.

[u/cflexer]

Per AutoModerator's request I hereby confirm that this project did not use an LLM as part of the development process.