Show HN: Nami – A decentralized binary package manager | Hacker News Reader

Show HN: Nami – A decentralized binary package manager

github.com

39 pointstxthinking30 comments

Why do people assume package managers do some form of gatekeeping?

It’s not the package managers who gatekeep, it’s their associated repository. People are free to create and host their own repositories (or, in Homebrew-speak, taps). Users are free to add those with no PRs involved whatsoever.

1. It's for pre-built binary, different OS/Arch need different binary file. So nami needs to know download which file for user's OS.

2. Yes, people are free to create brew taps. But you know humans are divided into 'I will do this' and 'I wont do this'

3. There are there roles: [software developer], [package maintainer], [user].

3. Most cases, [the software developer] is not the [package maintainer]. The software developer only push code, test code , build code. Like we know, build binary is a step of the software developer, but they don't like to create much more packages with apt-get/brew/pacman/etc, so many packages in the centralized PM are outdate. Examples are endless.

4. [User] is people who using software, they like less concepts thing. They just a user, not developer, not maintainer.

> 2. Yes, people are free to create brew taps. But you know humans are divided into 'I will do this' and 'I wont do this'

The point I was trying to make was: as a 3rd-party package maintainer, why would I look into nami (rather than upload my package to a 3rd-party repository so users are free to use the package manager they already know?)

> different OS/Arch need different binary file. So nami needs to know download which file for user's OS.

So like https://packagecloud.io/ ?

It hosts standard package repos which can internally do selection for distro/version/architecture.

My "bounce rate" for having to install a package from a third party repository is close to 100%.

It's just too much administrative overhead in the long run. I don't run just one machine. This is not laziness, it's a mode of operation.

Also, it's a red flag. If you can't get into official repos, what else is wrong with you? Perhaps nothing, perhaps those gatekeepers are gatekeeping too hard. Still, I'm not going to invest my resources to figure it out.

Homebrew maintainer here.

There are many good reasons for a piece of software not to be included in a default repository.

First of all, it’s about prioritizing maintainer workload. It makes sense to draw the line somewhere in order to prevent the backlog from growing. A huge backlog is bad for everyone: it tends to burn out maintainers, causes important (security) updates to slip, and can be frustrating for users.

As a package maintenance team, what options do you have to draw a line? You may decide to narrow the scope somewhat arbitrarily (e. g. FOSS only, stable versions only, latest only), add some notability requirement (e. g. 50 or more GitHub stars), or streamline your process (e. g. exclude packages that would require downstream to write and maintain patches).

Anything of the above can cause a perfectly trustworthy package not to be included into a default/core repository, leaving 3rd-party repositories as a good enough option.

I think it’s super important to be extra vigilant when tapping into a 3rd-party repository. But it would be a little unfair to consider those packages (or their upstream projects) damaged goods.

Not saying you did imply the latter; I just felt like chiming in with my point of view.

Thank your serious discussion. I don't deny the official repos , like apt-get, brew. This is an option for developer who can't stand outdate and want to control by self.

So sort of the same idea as docker where the address of a package (docker image) is built into its name. Interesting but also problematic. If a package in rhel repo is broken I can mask it with one I've built of the same name in my company repo. Since the package address isn't tied to its name, this works.

If a package broken, you can built of the same name in your company repo too, the address is yours, but the package is same package.

most cases, we install package which is open sourced and trusted. So anyone can fork it.

Looks really awesome for internal usage, but public binary distribution without some form of gatekeeping is spooky.

Yes, actually you don't do install package you don't trust. And actually even the package is code not binary, the users don't see code always. The result is user install package because they trust the author of package.

This is not good enough security position for a package manager.

Yes, it is like Android APK vs iOS app store :)

Besides features, how does this compare in daily workflow to https://asdf-vm.com/? Does it provide version management or just upgrade to latest?

Am I missing something? How does this handle different package types for the same OS/Arch? Like, if I wanted to host a .deb, .rpm, *.appimage, etc?

# Nami

A decentralized binary package manager

### Why

There are already many package managers, like apt-get, brew, but this is all centralized. Every time the author updates the software, they need to write complex configuration files and PRs and wait for merge.

Nami is a decentralized binary package manager, she allows software authors to publish their software anywhere, without having to request a merge from a software center for each update.

### Install

    $ curl -L git.io/getnami | bash && exec -l $SHELL

### Usage

    NAME:
       nami - A decentralized binary package manager

    USAGE:
       nami [global options] command [command options] [arguments...]

    COMMANDS:
       install  Install package. $ nami install github.com/txthinking/nami
       upgrade  Upgrade package. $ nami upgrade github.com/txthinking/nami
       remove   Remove package. $ nami remove github.com/txthinking/nami
       info     Print package information. $ nami info github.com/txthinking/nami
       list     Print installed packages. $ nami list
       help, h  Shows a list of commands or help for one command

    GLOBAL OPTIONS:
       --help, -h  show help (default: false)

### Example

    $ nami install github.com/txthinking/nami

### What Does Nami Do?

All files are stored in `~/.nami`

## Nami for Software Publisher

- Package name such as `yourdomain.com/package` - Nami will send GET request to `https://yourdomain.com/package/nami.json`, `nami.json`

### Built-in supported domains

* `github.com`: Package name such as `github.com/txthinking/nami`, put binary files in the [github releases](https://github.com/txthinking/nami/releases)

## License

Licensed under The GPLv3 License

  $ curl -L git.io/getnami | bash && exec -l $SHELL

When will this crap end? I can't understand how can people still do that. Everyone knows it's dangerous to pipe random scripts to bash, especially from unsecured websites, and people still suggest it as recommended way to install software...

You're right. It's far safer to just download and run a binary you can't inspect than to execute a bash script you can inspect. Doubly so if there's a hash to guarantee the script/binary you downloaded is the one they intended. That means there aren't any nefarious things in it. ️

Alternately you could homebrew/apt-get some_package_ive_never_looked_at_the_source_of that'd be wicked safe.

</sarcasm>

Very droll indeed. I don't use homebrew so I don't know how is it managed, but I have generally believe Debian maintainers to be more credible than random github user. When I see install instructions like these I always at least skim the instal script before running it. And of course Debian packages are signed unlike downloading script from unsecured website like in this case where you risk MitM attack.

From the documentation:

> Nami is a decentralized binary package manager, she allows software authors to publish their software anywhere, without having to request a merge from a software center for each update.

If you're trying to install a decentralized binary package manager which doesn't require maintainers to merge anything, you're presumably planning on taking far greater risks than curling this installer.

Can you please not lead with a punch when posting like this? The other user shouldn't have overreacted, but your comment was nasty to begin with, especially since this is a well-known point of disagreement—not to mention well-trodden, therefore generic, therefore predictable, therefore tedious, and therefore mostly off-topic.

https://news.ycombinator.com/newsguidelines.html

See this in particular: https://news.ycombinator.com/showhn.html. It includes:

Be respectful. Anyone sharing work is making a contribution, however modest.

Ask questions out of curiosity. Don't cross-examine.

Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.

When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.

I have a question, what does this for?

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...

>I have a question, what does this for?

>/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in....

Sorry, your first sentence still doesn't make much sense. If you are asking how is that better command than piping download into bash, it's pretty much same thing, but at least this one uses https.

http status code 301

Is transmitted unencrypted and thus exactly vulnerable to MITM

Reply on news.ycombinator.com