the Fiddler's picture

[OpenTK] Create RPM packages for Fedora/openSUSE and derivatives (help wanted)

Project:The Open Toolkit library

Similar to issue #1406: [OpenTK] Create DEB packages for Debian/Ubuntu and derivatives (help wanted), we should distribute RPM packages for OpenTK. This would allow easy installation and dependency resolution both for OpenTK and for projects relying on OpenTK. Additionally, it would be the first step necessary for including OpenTK in official repositories.

In the short term, we need someone familiar with - or willing to learn - the tools that create RPM packages to help create those packages. In the long term, we should find a way to automate package creation through the build system.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture


Component:Documentation» Miscellaneous
nodoid's picture


Version:0.9.x-dev» 1.0.0-rc1
Assigned to:Anonymous» nodoid


I already have a spec file ready for inclusion into the Fedora repos (with fixes for the beta-3 scripts, they pointed to somewhere that didn't exist!) The current problem though is that the dll produced is not strongly signed so can't be included in the gac. WIll this be addressed prior to the 1.0 release or is it something that I can use the fedora key to sign and include into the gac?


the Fiddler's picture


Thanks for looking into this!

There are two parts to the signature issue:

  1. Ability to sign the assemblies. This is already implemented in OpenTK: $ mono Build.exe lib will automatically sign everything if a keyfile ("OpenTK.snk") exists in the build directory. All 1.0 binaries distributed through sourceforge are signed.
  2. What keyfile should you use? .Net policy dictates that all binaries of a "product" are signed with the same key. Unfortunately, this is at odds with open-source development: you cannot add the private key to source control (because that would allow a malicious person to distribute a tampered binary without any way to detect the tampering) and you shouldn't use different keys for the same product (because that's against .Net policy and would break applications that verify the signature at runtime).

Two solutions I can think of:

  • Either distribute the private key to all packagers of an application. (I have no idea what is the policy of fedora regarding this but I don't think that would work.)
  • Or sign the assemblies with the fedora key and rely on the fact that mono doesn't provide a way to verify signatures at runtime (AFAIK).

What do you think? Is there an official policy on this sort of thing?

Edit: on further research, it seems that signature verification ("authenticode") is actually a different issue entirely. In light of this, it might be better to simply add the keyfile in source control. I wonder how the Tao Framework handled this issue.

nodoid's picture


Private key isn't really allowed. If the source for Build.exe is included, then the package can self sign (fedora say that binaries distributed with the source cannot be trusted, but need to be built again using the code signed by the default mono key)

With the exception of a missing file (see one of my bug reports) and the Examples csproj being broken (see another report), 1.0.0-rc1 build fine under Mono 2.6.3 (fedora)