A supporting note - my first thought was "well the author wants to work in CTF/pentesting situations where root access might not be available" but it tuns out that https://nixos.wiki/wiki/Nix_Installation_Guide#Installing_wi... is pretty well covered these days. At that point the only thing is that nix is complex enough that it might be easier to invent your own package manager than to master nix[0]. (I don't know enough about your other suggestions to comment.)
[0] Don't take this criticism too harshly; I'm writing this comment on a nixos laptop;)
And if you're not able to install Nix (running something on a target machine?), you can use `nix bundle` on your own machine. More relevant for the author may be that a lot of pentesting tools aren't in Nixpkgs yet: https://github.com/NixOS/nixpkgs/issues/81418
As my comment above stated, hysp relies on single binaries.
The default source for PKGs that's shipped with hysp, contains only statically compiled binaries.
This allows you to run a single binary anywhere on any system. And since you can host your own binaries for whatever architecture, hysp is agnostic.
Further, since only binaries are installed, there's no need for toolchains/cache or any kind of other dependencies.
There is also nix-portable (https://github.com/DavHau/nix-portable), which is basically a drop-in replacement for normal nix that does everything required for no-root operation by itself when needed. Just put the single binary in your PATH and it's ready.
To address your concerns:
1. Hysp is not a developer tool and isn't meant to be used as such.
2. Nix, Conda etc. all can & do work without requiring elevated privileges or root. However, what differentiates hysp, is that it is simply a downloader for a binary hosted somewhere else (defined in config file), that it fetches, verifies sha256sum/blake3 sum & puts in the directory (also defined in config file) which can be then directly called & used.
3. Hysp, doesn't care about dependencies, and neither does it attempt to install anything that's not specifically defined in the config.
4. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
People might just not like nix for a number of legitimate reasons and they might to take an attempt at a new package manager with better UX. It's fine to make a new piece of software, even if 100 tools exist already. Package management is definitely far for a solved problem, and I personally don't think than nix is "it".
One advantage I can think of is that it makes it easier to remove everything at once without needing to rely on any behavior of the package manager itself. I imagine that this could be useful if you want to test changes "live" rather than in a sandboxed environment.
1. Hysp is completely agnostic: Does not depend on or care about what OS, Architecture & dependencies are installed. Just parses config.toml, based on that, installs what's defined & how is it defined.
2. No Toolchains or any other kinds of dependencies are required. Each & every single binary is statically compiled. This is the core at philosophy of Hysp. A single binary that runs anywhere. No dependencies whatsoever. This saves enormous space, storage & time.
3. Self-Hostable : As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
I use Linuxbrew extensively across multiple WSL distros every day. As the “weird Windows person” on a team full of Mac users the experience is pretty uniform—the same brew commands for standing up a macOS dev environment mostly “just work” on WSL/Linux.
I use linuxbrew at work which uses relatively old SLES 12 machines with some odd configs. I find the nix portable solutions don't work because the kernel is too old to support the needed sandbox features. I do have a coworker who got NIX working in his account, but it was non-trivial, and still had issues.
Still, several homebrew packages need some tweaking, but that is straightforward.
I've been using Linuxbrew for few months last year, it was always hit-or-miss whether some tool will work or if it will be macOS only recipe.
Then I started using aarch64 CPUs, and Linuxbrew still doesn't work on those. Bummer.
So while I'd love to see a package manager that spans all Linux distros, Homebrew is not it, at least for now. Nix may be it, but it has its own interesting issues at times.
I recently used distrobox to run Arch Linux container on Fedora host and it was a good experience. I did not try exposing the CLIs from there to the host OS but it sounds possible https://github.com/89luca89/distrobox/blob/main/docs/usage/d... . I don't want to daily-drive Arch again, but it's a great project to install fresh versions of various CLI tools from.
I think people make projects like these because by the time they have need of the tools, they've already formed strong opinions about how those tools should work. Otherwise even Homebrew wouldn't exist, because pkgsrc already did.
Sorry if I came across negative; it was more my intent to paint motivations as a positive thing. All these projects definitely learn from each other, and different priorities bring new approaches. I think it's how the industry moves forward, but I can see how my phrasing might be read as dismissive. Not my intent at all!
Wouldn't it be easier to make a `snap install x x x x `
Or `flatpak install x x x x` script ?
Isn't this type of issue what those two project's aim to solve ?
1. Hysp is a single binary (Statically compiled), download & run anywhere kind of package manager.
2. Hysp, doesn't care about dependencies, and neither does it attempt to install anything that's not specifically defined in the config.
3. Due to 1 & 2, you do not need go or rust or anything else installed to install something. No dependencies whatsoever. This saves enormous space, storage & time.
4. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
The aquilles heel of package managers isn´t consistency, but lack of packages.
I appreciate the benefit of distro-agnostic package management, but unless you rely on a portable toolchain, or distribute statically linked binaries exclusively, we fall short from the panacea of portability (many other options available, yes, but packages are needed!)
I have personally leveraged pkgin[1] for consistency. I can simply drop pkgsrc[2] in my home directory and use the same tools in *bsds, smartos, linux, macos and cheese.
To address your concerns:
1. Yes, no portable toolchains or any other kinds of dependencies are required.
2. Each & every single binary is statically compiled. This is the core at philosophy of Hysp. A single binary that runs anywhere.
3. Currently, there's about 200 pkgs for x86_64 & arm64 each. The upstream source (https://github.com/Azathothas/Toolpacks) has over 400 for x86_64 & 300+ for arm64, which will slowly be added to Hysp-Pkgs.
4. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
Hey, thanks for replying! I had missed the static binary detail, and it is by far the most sensible solution.
Regarding the packages, those are very respectable numbers... But who is maintaining them? It takes a lot of effort to maintain a repo up to date, with patches both functional and security related. This is in most distros a full time job for a group of people. For comparison pkgsrc has 19444 packages, and it takes a substantial effort to keep up to date.
Regarding 4... I am not sure about your angle there... "Running random binaries" is risky. Technically hysp is a random binary itself, from a random source. I don´t know who you are, and even in that case any certification of authority is best efforts. You can´t certify that the code you built has not been compromised... This is a tough problem, good ideas are still needed!
OTOH, maybe you could leverage the work of the pkgsrc team to increase the number of available packages, traceability, and portability!
Join forces!
Synergy!!!!
Regarding pkgsrc, we came across that and the reason we eventually ended up creating hysp was that we didn't want to use any dependencies what's so ever.
So if you wanted to, you could use pure bash and nothing else to parse the TOML files that hysp uses and do everything that it does.
Hysp is simply an abstraction over that philosophy.
As to the question of maintaining them, currently only I am.
Hysp is a small project for now, and we have no plans to add anything that's dynamic. This will ensure low numbers of packages, but guarantee that those packages will work anywhere.
So maintaining the PKGs is quite simple, I write custom build script for each of them and then GitHub Actions automates the rest.
This currently requires very little manual maintenance.
The following repos are where the current packages are sourced from:
I had to mention 4, because people kept asking us about security concerns.
Self-Hosting everything on your own server and using hysp just as the frontend, is an option for those people.
1. Yes, the readme could be better and have better documentation explaining the why. We will update this and clearly list the reasons. Thanks for pointing it out.
As to the actual why:
1. Be completely agnostic: Do not depend on or care about what OS, Architecture & dependencies are installed. Just parse config.toml, based on that, install what's needed.
2. The default pkg source that ships with hysp, contains only statically compiled/linked binaries that will work on anything.
3. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
I actually love that you included a "Why" section in your readme, very few projects do that and I think it's extremely useful. So props for that.
I think some specific questions that would be nice to address:
1. I would recommend writing out Capture The Flag, CTF may not be as widely known as you imagine (I had to google it). Having unfamiliar jargon at the top of the readme might turn off prospective users who could benefit from your features.
2. How does this compare to some of the alternatives that others have mentioned, and why / how does this solve the problems differently?
Of course it's totally great to make software just for fun, but I get the sense this project serves a specific purpose. Good luck to you!
I hope we never find a time where a person (whether it be a researcher, tinkerer, dreamer, visionary, misfit, whatever) hears "X is already solved" and says "that's good enough for me".
I've found that security skill in one area doesn't translate to others. Someone good at breaking things isn't necessarily good at building secure things.
1. Hysp allows making request to http-only sites, because hysp doesn't care where you host your binaries. As long as you have sha256sum/blake3sum of the binaries, and they match, hysp will work.
2. The default pkg source that ships with hysp, is hosted on github itself, where's there's no need to use http. HTTP is simply a fallback, and meant for maximum compatibility.
3. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
$BIN.TOML must contain either blake3sum or sha256sum of the binary specified as source.
And once hysp downloads them, it checks if they match exactly as specified in the $BIN.TOML
We prevent MITM or any other shenanigans by trusting whoever is hosting the pkg, isn't tampering both the binary and the checksums.
So yes, not completely foolproof (an attacker could, in theory, tamper both the binary and the checksum), but that's why we have the self-hosting option for people who want to trust only themselves and their servers.
The config allows you to specify different URL/Host for the TOML files and the actual binaries.
So unless, both the TOML files and source binaries are being hosted on an HTTP site, MITM is not possible.
And as already specified, the default source that ships with hysp, doesn't use HTTP anywhere.
Sometimes a package manager doesn't have my package doesnt get solved by adding one more package manager.