#9057 Ability and permission to sign applications for download using Fedora Releng keys
Closed: Fixed 4 years ago by mohanboddu. Opened 4 years ago by dustymabe.

In the Fedora CoreOS teams we have some software components that are downloaded directly from GitHub for people to use. For example if a user wants to validate an Ignition config using the ignition-validate tool. If the user isn't on a linux box (or even if they are, but not on Fedora) then it makes sense to allow them to download a pre-compiled binary from either GitHub or directly from our documentation.

We'd like to be able to upload binaries like this and also get them signed so that users can trust the content. This is a loaded request, because we'd also want to make sure this artifact wasn't something that was built on someone's laptop, but rather in a trusted environment like the Fedora Infrastructure.

Are there existing sets of software that are downloaded directly from the fedora website that are executables to run on user's systems? Either way we'd like to work together to come up with a solution to this problem.


Metadata Update from @mohanboddu:
- Issue tagged with: meeting

4 years ago

Discussed in the releng meeting today. Some clarifications/questions to answer:

  • How do we want things signed?

    • There are detached signatures of binaries (i.e. foo and foo.asc)
    • There are signed binaries so that windows/mac don't tell you the program you're about to run is untrusted.
  • How can we build for other platforms?

How do we want things signed?

Detached signatures are fine. We'll explore the signed binaries thing in the future if it comes up.

How can we build for other platforms?

GoLang can cross compile. The CoreOS team can investigate if it works during an rpm build and put those binaries into a subpackage (on x86_64 only). Then we can pull the files out and create detached signatures for them to be uploaded to GitHub.

Clarifying some priorities/requirements:
- Highest priority is detached sigs for x86_64 linux binaries
- Other arches and OSs are less important, but shouldn't wait indefinitely. We haven't built for other arches historically, so that's lower priority than other Mac/Win binaries (again, detached sigs are fine).
- The go toolchain supports cross compiling to other OSs just fine. That's how we've been building them thus far.

As next steps I can see:
- Getting some sort of method for extracting the binary from the rpm and getting it signed with fedora keys. What do we need to do to make this happen?
- Cross-OS building the binary in an rpm. Would this make sense as a subpackage? It doesn't make sense as something people would actually install. Where should it live?

As next steps I can see:

  • Getting some sort of method for extracting the binary from the rpm and getting it signed with fedora keys. What do we need to do to make this happen?

I think we'd need to write a little piece of glue code (a script) that:

  • downloads the rpm
  • verifies the rpm signature of the downloaded rpm
  • extracts the files out of the rpm
  • chooses the files we care about
  • makes some sort of request to get them signed

The last step is the most nebulous. @jlebon recently familarized himself with our signing infra and making requests there. @jlebon do you know of an easy way to pull off that last part?

  • Cross-OS building the binary in an rpm. Would this make sense as a subpackage? It doesn't make sense as something people would actually install. Where should it live?

I would say we would just modify our ignition spec file to try to do the extra build steps to build the mac/windows binaries when we do the x86_64 build. We'd then shove those artifacts into a subpackage (all done within the spec file).

And since you said that linux x86_64 binary was the most important, then I'd say those two pieces of work mentioned in the above comment don't depend on each other. i.e. they can be executed in either order or in parallel.

The last step is the most nebulous. @jlebon recently familarized himself with our signing infra and making requests there. @jlebon do you know of an easy way to pull off that last part?

Yeah, we can probably re-use the existing org.fedoraproject.prod.coreos.build.request.artifacts-sign message to do this.

I think we'd need to write a little piece of glue code (a script) that:

Probably easiest to wrap this up in a Jenkins job where it will have access to the fedmsg credentials already.

Probably easiest to wrap this up in a Jenkins job where it will have access to the fedmsg credentials already.

Which jenkins?

And since you said that linux x86_64 binary was the most important, then I'd say those two pieces of work mentioned in the above comment don't depend on each other. i.e. they can be executed in either order or in parallel.

Yup!

OK we broke out the work into two steps:

  • Getting some sort of method for extracting the binary from the rpm and getting it signed with fedora keys. What do we need to do to make this happen?

We plan to automate this (tracked in https://github.com/coreos/fedora-coreos-tracker/issues/335) but for now we made a manual request for this first release. There are a lot of good steps in the instructions in that ticket so I'll link it here: https://pagure.io/releng/issue/9126

  • Cross-OS building the binary in an rpm. Would this make sense as a subpackage? It doesn't make sense as something people would actually install. Where should it live?

We managed to get this to work so this part is complete: https://src.fedoraproject.org/rpms/ignition/pull-request/47

Closing the ticket as the most part of it is done.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata