Thrift
  1. Thrift
  2. THRIFT-509

C# Library Does Not Provide Strong Name

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: C# - Library
    • Labels:
      None
    • Environment:

      Fedora 10 i386 - Mono version 2.0.1 - Thrift r770888

      Description

      I'm in the process of having a Thrift package reviewed for Fedora. Unfortunately the C# library is failing to register because it thinks Thrift.dll doesn't provide a "strong name".

      If this is something that could be added to the library it would be very much appreciated.

      Error:

      DEBUG: + gacutil -i lib/csharp/Thrift.dll -f -package Thrift -root /builddir/build/BUILDROOT/thrift-0.0-0.fc10.20090501svn770888.i386/usr/lib
      DEBUG: Failure adding assembly lib/csharp/Thrift.dll to the cache: Attempt to install an assembly without a strong name

      Package Review: https://bugzilla.redhat.com/show_bug.cgi?id=498873

      P.S. If I'm being stupid and this is something which I need to address in the build process please let me know.

        Activity

        Hide
        Nelson Marques added a comment -

        Hi,

        I've recently packaged Thrift for EPEL (as my employer prefers we maintain the packaging on a 'upstream' project than maintain them internally). When I submitted the package to Fedora EPEL, I was asked to maintain it for Fedora as well.

        Now, for my needs I only need the cpp and php modules (which are the only ones I provide on the EPEL version), unfortunatly for Fedora I was asked to build all the modules that Fedora offers dependencies to. Most of it is done, except for this tiny issue around the strong name.

        Is there a way we can have a fix by upstream regarding this? I don't care how much foolish it might be (including the swinging around with private keys), but I really need to get this stuff done. Anyway we can have fix for 0.8.1 or even a cherry picked patch from git is most likely welcome. I don't mind maintaining the patch on Fedora if I have to and if you guys decide not include it, but either way, I really could use a 'upstream approved' patch.

        NM

        Show
        Nelson Marques added a comment - Hi, I've recently packaged Thrift for EPEL (as my employer prefers we maintain the packaging on a 'upstream' project than maintain them internally). When I submitted the package to Fedora EPEL, I was asked to maintain it for Fedora as well. Now, for my needs I only need the cpp and php modules (which are the only ones I provide on the EPEL version), unfortunatly for Fedora I was asked to build all the modules that Fedora offers dependencies to. Most of it is done, except for this tiny issue around the strong name. Is there a way we can have a fix by upstream regarding this? I don't care how much foolish it might be (including the swinging around with private keys), but I really need to get this stuff done. Anyway we can have fix for 0.8.1 or even a cherry picked patch from git is most likely welcome. I don't mind maintaining the patch on Fedora if I have to and if you guys decide not include it, but either way, I really could use a 'upstream approved' patch. NM
        Hide
        James E. King, III added a comment -

        The C# runtime engine overhaul I did for THRIFT-66 includes strongly named assemblies.

        Show
        James E. King, III added a comment - The C# runtime engine overhaul I did for THRIFT-66 includes strongly named assemblies.
        Hide
        Jeff Brown added a comment -

        I was thinking of submitting a patch for this myself and including a default .snk out of the box. Creating a strong-signed assembly is very useful for corporate clients and others downstream who wish to sign their own modules. Given that Thrift is OSS, clients can always choose to recompile the library with their own custom key if the provided well-known key isn't up to their standards.

        Show
        Jeff Brown added a comment - I was thinking of submitting a patch for this myself and including a default .snk out of the box. Creating a strong-signed assembly is very useful for corporate clients and others downstream who wish to sign their own modules. Given that Thrift is OSS, clients can always choose to recompile the library with their own custom key if the provided well-known key isn't up to their standards.
        Hide
        Silas Sewell added a comment -

        Any decision on this?

        Show
        Silas Sewell added a comment - Any decision on this?
        Hide
        David Reiss added a comment -

        I guess I could go either way. It just seems silly to have a "private" key that is plastered all over the web.

        Show
        David Reiss added a comment - I guess I could go either way. It just seems silly to have a "private" key that is plastered all over the web.
        Hide
        Michael Greene added a comment -

        The .snk file only comes in binary form, sorry.

        I can't say I really know whether it is customary to include private keys in the .snk in the source tree. Out of various notable open source .NET projects, Apache log4net and NHibernate, for instance, do not do it and require people to supply their own snk to build the release. The Rhino and Castle projects and Apache iBatis do include the snk. In a corporate environment the recommendation from Microsoft is to allow delayed-signing with individual developers leaving a build unsigned but still marked for signing, and a trusted authority signing the build. I'm not sure what makes sense for an open source project--who would be the keyholder? Is there a private, shared storage space at Apache for something like this?

        This patch replaces the previous one should address the other issues you mention, following the style of the rest of the autoconf script.

        Show
        Michael Greene added a comment - The .snk file only comes in binary form, sorry. I can't say I really know whether it is customary to include private keys in the .snk in the source tree. Out of various notable open source .NET projects, Apache log4net and NHibernate, for instance, do not do it and require people to supply their own snk to build the release. The Rhino and Castle projects and Apache iBatis do include the snk. In a corporate environment the recommendation from Microsoft is to allow delayed-signing with individual developers leaving a build unsigned but still marked for signing, and a trusted authority signing the build. I'm not sure what makes sense for an open source project--who would be the keyholder? Is there a private, shared storage space at Apache for something like this? This patch replaces the previous one should address the other issues you mention, following the style of the rest of the autoconf script.
        Hide
        David Reiss added a comment -

        I think AC_PATH_PROG sets the variable to an empty string if the program is missing. We should disable csharp rather than aborting the build if gacutil is not installed. I don't suppose there is a text format for that .snk file. Is it customary to include private keys in the source tree?

        Show
        David Reiss added a comment - I think AC_PATH_PROG sets the variable to an empty string if the program is missing. We should disable csharp rather than aborting the build if gacutil is not installed. I don't suppose there is a text format for that .snk file. Is it customary to include private keys in the source tree?
        Hide
        Silas Sewell added a comment -

        That should work well for me.

        Show
        Silas Sewell added a comment - That should work well for me.
        Hide
        Michael Greene added a comment -

        There are a couple of ways to do this, and one could be addressed in your build process, but since other packagers are running into the same issue, I think it's best that we solve it here upstream.

        This patch adds a strong name keyfile with public and private keys, adds an AssemblyInfo file for more explicit naming, and causes make and make install to sign the file and invoke gacutil, respectively.

        Would this work for you?

        Show
        Michael Greene added a comment - There are a couple of ways to do this, and one could be addressed in your build process, but since other packagers are running into the same issue, I think it's best that we solve it here upstream. This patch adds a strong name keyfile with public and private keys, adds an AssemblyInfo file for more explicit naming, and causes make and make install to sign the file and invoke gacutil, respectively. Would this work for you?

          People

          • Assignee:
            Unassigned
            Reporter:
            Silas Sewell
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development