Cookbook · 3 of 3

Get into a feed

A release gives users a download. A feed gives them apk upgrade — the only path that keeps working after they have installed once. This is what owfeed-packages asks for; another feed will differ in detail, not in shape.

Two things it requires

Your packages must be signed with your own key, and its public half is pinned in the feed. A feed that cannot attribute a package will not publish it — the check is in the pipeline, not in the prose: owfeed doctor fails an unsigned package and the tree publishes without it.

This is step 2, so if you followed it you are done. Send author.pub.pem with the request.

Your description says what the package is, not what it is for. It is shown by apk info and travels into the index — factual, technical, under 512 bytes.

Publish a signed manifest, and updates land unattended

Three shapes, and which one you are in decides how much a person has to do for every future release:

What you publish	What the signature covers	Automatic updates
`owfeed release` manifest	the whole inventory — every file, its size and hash, plus the repository and tag	yes
signed `.apk` assets	each asset, but not the list of them	yes, while the set of files is unchanged
bare binaries and checksums	nothing — a checksum says the download was not corrupted, never who produced it	never

That is the honest reason to publish a manifest: it is one command, and an update then lands within the hour instead of waiting for somebody to read a notification.

The request

Publish a release with a signed manifest — step 2. The feed verifies it before touching anything.
Open an issue from the Request package publication template: repository, a tag, your public keys and their ids.
A bot checks it within a minute — the release exists, the manifest verifies against the key you claim, the format is one the feed reads. It says what is wrong, if anything.
A person reviews the key. The only manual step, and not skippable: pinning a key is the entire trust decision, and their name is on the merge.
After that it is automatic. Every tag you push is picked up within the hour.

What automation will not do on its own

Even with everything in place, a person still looks at these — because a signature answers did the author publish this and not should this go out unread. An upstream whose release key is stolen signs perfectly:

A major version change, where upstream changes what the package is.
A diff touching anything but the pins, which would be the verification quietly relaxing itself.
A third update to one package in a day. A stolen key can publish a chain of releases faster than anyone reads the notifications.
Anything under keys/, ever.

What you are agreeing to

A feed distributes; it does not review. Asking it to carry your package means you assert, and remain responsible for:

the right to have it distributed — the licence permits it, its conditions are met, no trademark stands in the way;
what is inside it — contents, behaviour, security, lawfulness;
the truth of its metadata — the declared licence, description and upstream URL are your assertions, carried through unchanged;
answering reports about it — bug reports, security reports and complaints go to you.

A package can be suspended at any time, without notice. There is no entitlement to remain in somebody else's feed. The full terms are in the feed's CONTRIBUTING.

Check that the channel works, not just the package

owlab test --release 25.12.5 \
  --feed 'https://repo.owfeed.org/releases/25.12/x86_64/packages.adb' \
  --feed-key ./owfeed-packages.pem \
  --install my-app \
  --assert 'http 200 /cgi-bin/luci/admin/services/mine'

Installing a file proves the package works. Installing it by name out of a signed index proves the channel does — that the index parses, the URL does not redirect, and the key on the router matches the one that signed it. A file install cannot fail in any of those ways, so it cannot detect them.

Show it in your README

Once a feed carries your package it publishes two badges for it, generated from the index it just built — so they cannot claim a version nobody can install:

[![owfeed](https://img.shields.io/endpoint?url=https://repo.owfeed.org/badge/my-app.json)](https://owfeed.org/install/)
[![owfeed](https://img.shields.io/endpoint?url=https://repo.owfeed.org/badge/my-app-releases.json)](https://owfeed.org/install/)

The first shows the version the feed serves; the second, the release lines it serves it on.

What your users then do

One command, and it is the same for every feed that runs owfeed: wget -qO- <feed>/subscribe.sh | sh. Point them at the install page rather than writing your own, which is how a documented URL drifts from a working one.