Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package signing #9

Open
Informatic opened this issue Apr 19, 2021 · 3 comments
Open

Package signing #9

Informatic opened this issue Apr 19, 2021 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@Informatic
Copy link
Member

Some system of signing .ipk's is an interesting addition.

@Informatic Informatic added enhancement New feature or request help wanted Extra attention is needed labels Apr 19, 2021
@mariotaku
Copy link
Member

I have checked through this link: https://stackoverflow.com/questions/34449531/is-there-any-method-to-do-package-signature-for-openwrt-ipk
We can use openssl to sign the IPK file as a whole, and save it as pkgfile.ipk.sig. opkg Will be able to recognize it, if not we can do manually.

@mariotaku
Copy link
Member

I'll think about signature thing later. I prefer to make user trust signature from each fresh install of a package, and store this information. As we can't endorse security of any package provided by other developers, so we don't distribute trusted signatures.

@DavidBuchanan314
Copy link
Member

To repeat a vague idea I proposed on discord:

  • repo manifest contains a copy of the "repo master key"

  • repo manifest also contains a list of developer keys, which are themselves signed by the master key

  • individual packages are signed with their respective developer key

  • when a new repo is added, there's a "do you want to trust this repo..." prompt, which, if accepted, stores a copy of the master key in some local directory of trusted keys

  • we can pre-initialise this directory of trusted master keys, by shipping it with the homebrew channel IPK

So, there's trust-on-first-use, but on a per-repo basis.
Anyone only using the default repo will never have to accept anything, and people adding custom repos will only have to accept once per repo that they add.

As a user, adding a repo means you trust that repo's maintainer(s), who in turn trust the developer(s) of the apps hosted in the repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants