this post was submitted on 06 Sep 2024
126 points (100.0% liked)

Linux

1258 readers
70 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
126
I made a local APT repository that automatically fetches DEBs and AppImages from anywhere (jlai.lu)
submitted 2 months ago by KaKi87@jlai.lu to c/linux@lemmy.ml
41 comments fedilink hide all child comments
 

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 :)

top 41 comments
sorted by: hot top controversial new old
[–] Asetru@feddit.org 6 points 2 months ago (2 children)

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.

[–] KaKi87@jlai.lu 9 points 2 months ago (2 children)

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.

[–] cqst@lemmy.blahaj.zone 2 points 2 months ago* (last edited 2 months ago) (1 children)

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.

[–] KaKi87@jlai.lu 3 points 2 months ago (1 children)

I'm and end user working for end users.

[–] cqst@lemmy.blahaj.zone 2 points 2 months ago* (last edited 2 months ago) (1 children)

I’m and end user

Yeah, we all are. What's your point?

End users are also developers. All computer users are developers. You are developing.

user working for end users

By making a script that lets me get backdoors and shitty packages with ease? The linux package distribution system is a nightmare, Debian is the least bad approach. There is basically always a better option to using a .deb file. If you come across something that isn't packaged, I recommend Flatpak, building from source (and installing unprivileged), or using the developers vendored tarball (installing unprivileged).

https://wiki.debian.org/SecureApt

By using local .debs you lose the benefit of:

Reproducible builds

GPG checksums

Stable release model

debian security team

[–] KaKi87@jlai.lu 3 points 2 months ago

My point is that I'm working a solution for end users.

The solutions you're offering are not user-friendly.

[–] ulkesh 1 points 2 months ago (1 children)

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.

[–] KaKi87@jlai.lu 2 points 2 months ago (1 children)

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.

[–] ulkesh 1 points 2 months ago (1 children)

I didn’t say it was more secure, I said it’s about the same.

The difference is a person being forced to go to a website to download software means more steps and more time to consider the safety of what they’re doing. It’s part psychological.

Not all such packages are retrieved from GitHub, I remember downloading numerous .deb files direct over the past 25 years (even as recent as downloading Discord manually some years back).

The main point I’m making is that you should legally protect yourself, it’s a low and reasonable effort.

[–] KaKi87@jlai.lu 1 points 2 months ago (1 children)

I didn’t say it was more secure, I said it’s about the same.

You said automation breeds laziness (by design, to an extent) and lazy end users tend to shoot themselves in the foot.

So, my question is : what part of automating download of DEBs from a specific source can be shooting oneself in the foot compared to doing the same thing manually every time ?

you should legally protect yourself

The MIT license will take care of that.

Also, to force the user to accept and acknowledge that the software they are installing using this tool is not verified to be safe is inducing fear and/or guilt, therefore is bad UX, I'm not doing that.

[–] ulkesh 1 points 2 months ago

I already answered that first question.

And then all those app store fronts that say whether a flatpak is verified or not is inducing fear and/or guilt and is therefore bad UX. It's not, but you are free to have your opinion.

Have fun then, I'm done wasting my time here.

[–] lambda@programming.dev 2 points 2 months ago (1 children)

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.

[–] KaKi87@jlai.lu 1 points 2 months ago

You understand perfectly.

[–] bizdelnick@lemmy.ml 6 points 2 months ago* (last edited 2 months ago) (1 children)

If I'd decide to implement something like this, I'd consider two options: local repo with file:// scheme or custom apt-transport. HTTP server is needless here. (But I'll never do this because I prefer to rebuild packages myself if there's no repo for my distro.)

[–] KaKi87@jlai.lu 4 points 2 months ago (1 children)

local repo with file:// scheme

With that, I couldn't trigger a download when apt update is ran, I could only do a cron, i.e. a delay, that I do not want.

custom apt-transport

I thought about that, but found no documentation on how to do it. If you have any, I'm interested.

Even just finding documentation on how to generate DEBs and APT repository metadata files was very hard.

[–] bizdelnick@lemmy.ml 4 points 2 months ago (2 children)

It is documented in libapt-pkg-doc (/usr/share/doc/libapt-pkg-doc/method.html/index.html).

[–] KaKi87@jlai.lu 3 points 2 months ago

Yeah, I don't have the skill for this. I'd be very happy if someone else would make this, but if not then I'm sticking to HTTP.

[–] KaKi87@jlai.lu 3 points 2 months ago

In an APT package OMG 😂

I found an online version though, which I would never have found through my search engine (and on a site that doesn't even support HTTPS) 😅

Looks like difficult reading too 😭

Thanks anyway.

[–] barkingspiders@infosec.pub 4 points 2 months ago (1 children)

Neat! Thanks for sharing!

[–] KaKi87@jlai.lu 3 points 2 months ago

Thank you for your appreciation !

[–] flashgnash@lemm.ee 3 points 2 months ago (1 children)

Is that autotiling on cinnamon? Didn't know it could do that

[–] KaKi87@jlai.lu 3 points 2 months ago

It doesn't, that's provided by Cortile.

[–] Churbleyimyam@lemm.ee 3 points 2 months ago (1 children)

Great idea!

[–] KaKi87@jlai.lu 2 points 2 months ago

Thanks !

[–] JustARegularNerd@aussie.zone 3 points 2 months ago* (last edited 2 months ago) (3 children)

This might be for the better, but Discord was so infuriating about updates and forcing you to download them what felt like 50% of the time I opened it, I gave up and just use it in Ungoogled Chromium now. I'm pretty sure within a few months I ended up having 15+ debs of Discord in my Downloads folder.

For anyone else trying to use the native Discord app on Debian, I think they'll find this a major treat.

[–] KaKi87@jlai.lu 3 points 2 months ago (1 children)

Discord not automating downloads of DEBs is one of the reasons motivating me to do this.

Personally I need the desktop client because I mod it with plugins that are so useful that I can't do without these anymore.

Alternatively, there are third-party repositories here and here.

There still is delay between Discord releases and repository updates so I still believe dynapt to be the better solution.

[–] cqst@lemmy.blahaj.zone 1 points 2 months ago (1 children)

Personally I need the desktop client because I mod it with plugins that are so useful that I can’t do without these anymore.

Discord client modifications are against the Terms of Service. https://www.gnu.org/philosophy/free-sw.en.html

[–] KaKi87@jlai.lu 2 points 2 months ago

I don't care.

[–] teuto@lemmy.teuto.icu 1 points 2 months ago

This is 100% of the reason that I use the discord flatpak.

[–] lambda@programming.dev 1 points 2 months ago (1 children)

Just use the flatpak?

[–] KaKi87@jlai.lu 2 points 2 months ago (1 children)

I didn't know there was one, that's interesting, thanks.

Updates must still be delayed because of being third-party though.

[–] lambda@programming.dev 1 points 2 months ago

I've never had an issue with the flatpak version being out of date. 😊

[–] Telorand@reddthat.com 3 points 2 months ago (1 children)

I like it. Wonder if this could be retooled to work on rpm-ostree systems, because any layered packages installed from RPM files have the same limitation of needing to be manually upgraded.

[–] KaKi87@jlai.lu 2 points 2 months ago

I don't know anything about RPMs, but if you or anyone is familiar with it then perhaps !

[–] Shdwdrgn@mander.xyz 2 points 2 months ago (1 children)

Sorry to ask, but isn't this basically the same thing as apt-cacher-ng?

[–] KaKi87@jlai.lu 5 points 2 months ago (1 children)

Sorry to ask

Don't be. I would love to know that an existing and more experienced program does what mine does.

I've been looking for it myself for a long time before deciding to build it.

isn’t this basically the same thing as apt-cacher-ng?

Here's what I'm reading :

Apt-Cache-ng is A caching proxy. Specialized for package files from Linux distributors, primarily for Debian (and Debian based) distributions but not limited to those.

A caching proxy have the following benefits:

  • Lower latency
  • Reduce WAN traffic
  • Higher speed for cached contents
+------------+         +------------+        +------------+
| Apt Client |  <------+ Apt Cache  | <------+ Apt Mirror |
+------------+         +------------+        +------------+

So, not the same thing.

It locally mirrors existing repositories containing existing packages, it doesn't locally create a new repository for new packages from standalone DEBs.

[–] Shdwdrgn@mander.xyz 3 points 2 months ago

OK yeah, I wasn't sure if it had a way to collect debs from other sources. I've been using it for years to locally cache the standard Debian repos so I don't need to re-download packages every time I update my various servers and VMs, but I haven't really tried using it for anything beyond that.

[–] skimm@lemmy.sdf.org 1 points 2 months ago (1 children)

Neat project!

While this might not solve all of your use cases, did you consider a tool like mise?

Theres a number of other options out there such as asdf-vm and others who's names I can't recall. I recently moved from asdf to miss but its a great way to install things on different machines and track it with your dotfiles, or any other repo you want to use. Mise has tons of configuration options for allowing overrides and local machine specific versions.

It won't tie into apt for your upgrades but you could just alias your apt update to include && mise up.

[–] KaKi87@jlai.lu 1 points 2 months ago

My main use case is end user desktops.

[–] Daeraxa@lemmy.ml 1 points 2 months ago (1 children)

Willing to give this a go. My go-to for getting non-repo debs automatically has been deb-get which works well but seems susceptible to issues when changes in the software it lists causes it to break and whilst the fix itself is usually made pretty quickly, it seems to go long periods of time between PR merges and releases (which includes adding new software). If this is a viable replacement for it then i'd love to start using it.

[–] KaKi87@jlai.lu 1 points 2 months ago

Willing to give this a go.

Alright, don't hesitate to ask questions if you have any and request help if you need any

My go-to for getting non-repo debs automatically has been deb-get

Yes, I mentioned it in the Differences with deb-get & AM section of my tutorial.

it seems to go long periods of time between PR merges and releases (which includes adding new software)

Yeah, I could reiterate in that section that my app allows the user to add apps themselves.