PSA: Eget That Executable from GitHub | Hacker News Reader

PSA: Eget That Executable from GitHub

taras.glek.net

47 pointstarasglek28 comments

Figuring out the “latest” release can happen via the 302 redirect that GitHub offers on releases/latest/ - no API needed. It also works directly for artifact URLs.

Glad to see that there's a `--verify-sha256=` flag.

I prefer hard-coded hashes in my code so that when the file changes, I'm made aware. I've lost so much time chasing bugs back to a dependency which changed without a version bump and whose hash was checked by a script that just got the hash it was checking at runtime.

This seems to be inspired by the smelly nerds meme

https://www.reddit.com/r/github/comments/1at9br4/i_am_new_to...

This is effectively giving Microsoft RCE on your computer.

We trust github.com and small-time publishers far too much. There’s a reason Debian packages software and runs mirrors.

True, but if you install it anyway (like the author), might as well do it with this tool.

Short of that, I really like the AUR model, especially -git packages. The scripts are so simple they can actually feasibly be reviewed (for the average arch Linux AUR user, anyway?) and are usually just "clone, make, install".

But where does Debian get the source for those packages?

I agree that github is uncomfortably large, but the problem isn't this tool, and the solution isn't something Debian can achieve on their own.

You probably already give Microsoft RCE on your computer (or Apple, or the maintainers of your linux distro, etc).

I'm curious why you think this is true of GNU/Linux distributions. I can't think of any besides Ubuntu (Snap) that this really makes sense for.

Unless you're running Gentoo or similar, you're trusting your distro maintainers to produce clean, non-malicious binaries any time you install anything from the package manager.

I don't think people read the code before running a build with portage

Choosing to download and run programs is not giving someone else RCE, unless you download and run something that allows for RCE. It's not an inevitable truth like it is with Windows or (usually) Ubuntu (not sure about MacOS).

> Choosing to download and run programs is not giving someone else RCE, unless you download and run something that allows for RCE.

In my experience, auditing compiled executables is hard. How do you do this?

So what's your approach? Are you Amish? Or did you compile every component of your setup (UEFI firmware and [C,G]PU microcode included) from source after auditing it? Or are you just convinced that a system that can't have a third party run arbitrary code simply can't exist? Please elaborate.

Simple. First, bootstrap a new universe...

Ah you see I tried that but ran into a bug: the closer you inspect one of the universe's registers, the less accurate my reading of the value is. It seems that I can either ascertain the memory location of a declared variable OR its value, but the closer I get to one, the foggier the other gets.

Has anybody else encountered this bug when manipulating the fabric of space-time in Rust? It's throwing a pretty major wrench in the gears of my newest HN-inspired project: making a Rust port of the Universe for added memory safety.

Knowing if you have an RCE backdoor and having an RCE backdoor are two different things.

Well, you hit the nail on the head with Ubuntu - I've been trying to cut that distro out of my life, and it keeps popping up every place I've worked at. I trust Debian dearly, but even then - there's just so much surface area! At least Debian is easy to strip down (and the docs are quite good). These days I like to be explicit about everything I have installed, and still - things seep through.

I like the idea, but I can't imagine using it for a few reasons.

1. There's a catch-22. In order to fetch binaries you need to first install eget.

2. You need to trust eget to not be (or become) malicious.

Perhaps #1 can be resolved by providing it as a proxy service and not an executable. For example, "wget eget.net/gopls@latest" which then usings eget on the server to grab/cache the binary and send it back.

Then again, that would mean putting even more trust in eget.

Not exactly the same, but aqua is a similar tool in this space https://github.com/aquaproj/aqua

> However, I’m firmly on the side of using GitHub for everything because projects that use alternatives to GitHub are special snowflakes that make everything harder for me as a user.

Good.

It would be way better if tooling was hub-agnostic and compatible with all git:// style url's so that github would not be a SPOF as well as a single point of monopolizing

There are privacy and data integrity issues with GitHub for both enterprise and personal use. Gitlab and other self-hosted alternatives are nearly exactly the same. I don't know if "by harder for me as a user" they mean the web-facing frontend, or something else. And even then something like Gitlab offers the exact same feature set as Github does on the web frontend.

On a sidenote this is the same "but x is so much more convenient" mentality that is driving open source projects to lock all their documentation behind something like a Discord chatroom instead of having a proper docs page or wiki.

Why do you like monopolies? GitHub is already abusing its position by refusing to let me have an account without SMS verification, and refusing to let me delete my account without SMS verification.

> Why do you like monopolies? GitHub is already abusing its position by refusing to let me have an account without SMS verification, and refusing to let me delete my account without SMS verification.

I'm against Github. I think that nuance got lost.

https://github.com/houseabsolute/ubi does a nice job of fetching binaries from GitHub. Just give it a repo and a location to place the binary.

ubi --project oalders/is --in ~/local/bin

Similarly, there's Obtainium for Android. I love it for open source apps.

https://github.com/ImranR98/Obtainium

Awesome, thank you

Reply on news.ycombinator.com