I'd be willing to implement additional features for people who are extra careful about security.

Could you please explain what does this consist in ?

Thanks

differently hacky idea:

since you do end up with all the packages in a repository on the filesystem, and you just want to have it do this just-in-time updating when the Packages file is accessed...

what if you list it as a normal file apt source, but you make the Packages file a FIFO?

it's a cursed idea but I'm not sure it is any less cursed than the other options we've come up with.

it may or may not help to have systemd.socket manage creating the FIFO and running the service.

What's a FIFO ?

I've also looked into VFS but found nothing I'd have the skills to implement. 😅

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

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

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.
wiki.debian.org/DontBreakDebia…

.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.

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.

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.

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.

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.

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."