On Debian-based distros, when an app is available as a DEB or an AppImage (that doesn’t self-update), but no APT repository, PPA or Flatpak, the only option is to manually download each update, and usually manually check even whether there are updates.
But, what if those would be upgraded at the same time as everything else using the tools you’re familiar with ?
dynapt is a local web server that fetches those DEBs (and AppImages to be wrapped into DEBs) wherever those are, then serves these to APT like any package repository does.
I started building it a few months ago, and after using it to upgrade apps on my computers and servers for some time, I pre-released it for the first time last week.
The stable version will come with a CLI wizard to avoid this manual configuration.
Feedback is welcome :)
Sorry to be that guy, but this sounds like a cybersecurity nightmare. While everybody was busy to come up with schemes that make absolutely sure that only trusted sources can update a system to avoid having malicious players push their code to users, this one just takes any rando’s pile of whatever and injects it straight into the system’s core? Like, that doesn’t sound like a good idea.
Well, I’m just automating what people currently have to do manually : visit GitHub and download DEB and install DEB.
If the automated process would be dangerous then the manual process also would be, and that would be on the maintainer for not providing an APT repository or a Flatpak, not on the user for just downloading from GitHub.
It’s a cool concept, but automation breeds laziness (by design, to an extent) and lazy end users tend to shoot themselves in the foot. So it isn’t great for security, but it also isn’t that much worse for security :)
Since some people with money tend to be litigious, and, of course, I am not a lawyer, I would advise a warning message (or part of the license if you don’t want to muck up your CLI), if you don’t have one, to force the user to accept and acknowledge that the software they are installing using this tool is not verified to be safe.
How is the manual step more secure though ?
What does the user do before downloading a DEB that makes that gap between manual and automated ?
I’d be willing to try and reproduce that, but I don’t see anything.
Well, I’m just automating what people currently have to do manually : visit GitHub and download DEB and install DEB.
Yeah. You should never do that. Like ever. Build from source; or use a vendored tarball. https://wiki.debian.org/DontBreakDebian
.deb is a terribly insecure nightmare thats held up by the excellent debian packagers, gpg , and checksums, and stable release model. don’t use .deb files.
I see it more as a local repo. Like, setup the repo to do what you would have done manually so that you don’t have to do it on multiple computers. I could be misunderstanding it though.
No matter where you install from, you have to trust the source. Indeed, you have to trust every step in the supply chain.
If you are getting your code straight from the author, you are eliminating an exploit that’s introduced by a compromised account of a packager.
Carry on.
If you are getting your code straight from the author,
Which is not what you are doing at all with a .deb file. A .deb file is a binary with a bunch of scripts to “properly” install your package. Building from source is what you SHOULD be doing. Debian has an entire policy handbook on how packages are supposed to be packaged. Progrmatically you can review the quality of a package with ‘lintian’. .debs made by developers following a wiki tutorial can’t even come close. remember, apt installs happen as root and can execute arbitrary code.
Also, debian packagers can be project maintainers, so they can be “the author.”
