Signing a fork of DotNetOpenAuth with my own key

[Werner Strydom]

Hello,

I created a fork of DotNetOpenAuth and would like to sign it with my own key.  I extracted the public key from my own key and modified the InternalsVisibleTo attributes to have it and changed each project such that the assembly is signed with my key.  I'm still getting errors that the assemblies signed with my key cannot be loaded.  

The reason I'd like to do that is to make some contributions to the DotNetOpenAuth  codebase.  However, the best way for me to verify my changes is to use it in a actual product I'm developing.

I'd appreciate any help I can get.

Thanks,
Werner

[Andrew Arnott]

I imagine the reason for the errors is that DNOA builds using delay signing.  So until you build one of the targets that signs the build, you'll still see errors on the machine you build with unless you register your public key token for skip verification (which is the approach I recommend you take):

sn -Vr *,yourpublickeytoken

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/hJzbOuHbzQcJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Werner Strydom]

Andrew,

It turns out that (rather unexpectedly) the signing settings was setting for each project was ignored. This morning I got a clean copy, updated DotNetOpenAuth.props file to use my key (and not to delay sign it), and then updated the InternalVisibleTo of all the DotNetOpenAuth projects to use my public key, not that of DotNetOpenAuth.  No other changes were required.  Everything seems to be running just fine at this stage.

You may want to document this somewhere since I'm sure there are others that would like to build the source. 

Werner

[Andrew Arnott]

Building from source is not something we encourage or support.  We publish samples' source code of course, and include compiled symbols and the source is available so folks can step through the code in the debugger, but making source changes and building customized versions of a security library is not usually a good idea since anyone not intimately familiar with the whole project could accidentally defeat security measures in the library by a simple source change.

The only recommendation for this that we make is that folks register for skip verification of the official public key token on their local box so they can build and test prototype changes.  But then to submit those changes to be included in an official build before using them in production so they can be code reviewed, tested, etc.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/3LeHr1n38D4J.

[Werner Strydom]

That policy does make it more difficult to contribute and test changes.  

Much of the changes I'd like to contribute are related to things I raised using the library within a project.  The samples are mostly inadequate for this purpose due to the technologies and frameworks they use.  There are numerous features in the framework for which there are no samples.  Creating a sample from scratch isn't a trivial matter.  This may change if we simplify the framework. 

That said, it would be detrimental if there are several flavors of DotNetOpenAuth in the public and one cannot guarantee its security. So I fully understand the policy.

Werner  

[Andrew Arnott]

Inline...

On Sun, May 13, 2012 at 5:07 PM, Werner Strydom <blou...@gmail.com> wrote:

That policy does make it more difficult to contribute and test changes.  

How so?  It seems one command is simpler than some .props files changes along with a bunch of InternalsVisibleTo changes.

 

Much of the changes I'd like to contribute are related to things I raised using the library within a project.  The samples are mostly inadequate for this purpose due to the technologies and frameworks they use.  There are numerous features in the framework for which there are no samples.  Creating a sample from scratch isn't a trivial matter.  This may change if we simplify the framework. 

Thank you very much for keeping a "contribute back" mindset in place while you're adopting/evaluating the library.

 

That said, it would be detrimental if there are several flavors of DotNetOpenAuth in the public and one cannot guarantee its security. So I fully understand the policy.

Thanks.  As an aside, anyone considering publishing their own fork of DNOA would necessarily have to change the name to comply with the license agreement.  But I agree -- I'd hate to see the audience, support, and features splinter.  Much more preferable to find ways to make contributing easy enough for everyone to get or contribute what they want.

[Werner Strydom]

How so?  It seems one command is simpler than some .props files changes along with a bunch of InternalsVisibleTo changes.

If it worked, I would certainly have used it. I have spent days trying to get my applications to work partially signed builds of DotNetOpenAuth without any success.  I gave up and focussed on my project. 

I realized yesterday that by forking the library and signing it with my own key, I can deploy and test my flavor in environments and situations that I can't otherwise test on my development machine. When there are problems, I can address it, test it and then contribute those changes back without having to wait for the official copy to have those changes.  

[Andrew Arnott]

Good points.  

If we go with supporting your workflow, we'd probably want to adjust the assemblyinfo.cs files so that they don't have to actually include all the public key tokens, but rather have a build step that auto-generates these files based on the public key token of the key that is actually being used in the build.

This is something I've wanted to do for a while, but it hasn't been a priority so far.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/m9avhrZ3S0QJ.