Issues on publishing an official radare2 snap package

Hi All,

I am collecting here issues relating to the process of eventually getting an official radare2 snap package. It’s a reverse-engineering (security) tool.

Here is the background discussion (Github issue) on getting an official radare2 snap.

The current issue is on how to setup the automated build of the snap on build.snapcraft.io.
As it is now, build.snapcraft.io asks for too many Github permissions and the developers of radare2 are reluctant to set this up. The repository exists in the account of a user (not an organization), which I think it means that currently, only the core developer of radare2 can setup successfully build.snapcraft.io to do the builds.

Is there a way to deal with this issue?

1 Like

CC @evan

@simos

What specific permission is deemed needless or blocking on the upstream side?

I believe the permissions asked for allow hooks to be established, so that the store gets notified when it’s time to rebuild. Last I heard about it, it was also possible to grant no permissions at all, as long as you are willing to copy & paste the hooks in place.

@noise Is that still the case? Any issues remaining?

@niemeyer @noise From a conversation I had with people who worked directly on build.snapcraft.io (BSI, for short), you can’t “grant no permissions at all”. This is deliberate because doing so without the permissions created a really poor user experience.

you can’t say ‘no’ - when you authorize BSI for the first time you give permission to access organisations and to set up webhook, and user has to accept them to use BSI.

BSI asks “only read permissions to orgs, and write permissions to set up webhook (only on users action, only on repo where the given user can set up webhooks)”. “we need these permissions to be able to set up webhook so that BSI knows when to rebuild”.

One additional point of confidence is that the build.snapcraft.io codebase is public, anyone can check it doesn’t do anything evil with the permissions: https://github.com/canonical-websites/build.snapcraft.io

  • Daniel

This disagrees with the agreement we had on this particular area, and the rationale for the agreement was exactly the case at hand here: every now and then people are concerned about opening up access into their sensitive projects for external tooling. These people are also often the ones that wouldn’t mind following a simple tutorial that explains what to paste and where.

Having such a tutorial and the option to just copy & paste still feels reasonable to me, and doesn’t sound like much work on our end either. Is that not the case?

Reading the tutorial is also a very nice way to tell the user “this is all we’d do for you”, which may encourage just accepting the permission access too.

radare2 is a security program and the developers are similarly security-minded.
Allowing API access to their accounts would increase the attack surface, and there is this potential risk that someone else might get access to their source code, etc.
It is not a direct complaint towards BSI, it is just the uneasiness of those in the security field to grant access tokens. And I can understand that.

In such situations, a suitable approach would be to also offer an alternative manual option.
In BSI there is already a button Build manually now, so building manually without a webhook is feasible.

In addition, the UI when you add a new repository on BSI looks like this:

  1. Click on green button Add repos….
    Shows a list of repositories in user’s Github account. Could be empty if no repositories are avaialble.
  2. There is a link that says Any missing?
    This opens up ability to cater for several corner cases.

Here there could be an extra option like
Adding manually a Github repo? Type the URL: _____________________

If there is a need to verify the user has official access to the Github repo, you can ask them to create a file .build.snapcraft.io at the repo with contents the username of the BSI user that is allowed to add it (on BSI).

As more developers get to know the benefits of BSI, and the users get to demand the availability of fresh snaps, you would get more developers happy to set up their Github accounts on BSI.