[Owasp-dotnet] Fwd: [getglimpse-dev] Re: Strong Naming When Source Is Open

[dinis cruz]

Interesting thread at Glimpse

Dinis Cruz

Begin forwarded message:

From: Nik Molnar <nik...@gmail.com>
Date: 6 February 2012 14:32:48 GMT
To: getglim...@googlegroups.com
Subject: Re: [getglimpse-dev] Re: Strong Naming When Source Is Open
Reply-To: getglim...@googlegroups.com

Thanks for the very good feedback guys.

This has made me re-think about signing Glimpse, and run through all the scenarios to make sure I really understand what we are trying to achieve here.

Here's what I see, please let me know if I am missing anything:

If Glimpse was NOT signed, then...
- Glimpse referencing a strongly named assembly (like our dependencies), would work
- Glimpse referencing a "weakly" named assembly (like our dependencies), would work
- Glimpse loading via reflection a strongly named assembly (like Glimpse plugins), would work
- Glimpse loading via reflection a "weakly" named assembly (like Glimpse plugins), would work
- "Weakly" named project (IE Users) referencing Glimpse, would work
- Strongly named project (IE Users) referencing Glimpse, would NOT work

If Glimpse was signed, then...
- Glimpse referencing a strongly named assembly (like our dependencies), would work
- Glimpse referencing a "weakly" named assembly (like our dependencies), would NOT work
- Glimpse loading via reflection a strongly named assembly (like Glimpse plugins), would work
- Glimpse loading via reflection a "weakly" named assembly (like Glimpse plugins), would work
- "Weakly" named project (IE Users) referencing Glimpse, would work
- Strongly named project (IE Users) referencing Glimpse, would work

When I boil it down, I see two problems (the lines with "would NOT work"):

- When Glimpse is not signed, some users would have problems.
- When Glimpse is signed, Glimpse core developers (not plugin authors) could have some problems with weakly named assemblies.

I've taken an inventory of all of our dependencies (in the latest System.Web.Abstraction branch), we have:
- AntiXSS
- Newtonsoft.Json
- NLog
- Castle.DynamicProxy2
- Moq
- xUnit
- System.* .NET Libraries

All of these libraries ship signed, which means the core dev team doesn't even need to rebuild/sign these libraries.

To me this boils down to two options then:
#1) some users may experience pain and have to sign Glimpse themselves (if we don't sign Glimpse)
#2) the dev team might experience future pain, but none as of right now nor in the foreseeable future (if we do sign Glimpse)

I really respect everyone on this thread, so I'd like to hear more of your thoughts in light of this breakdown. I'm still leaning towards to signing because I'd rather put a little pain on the developers rather than the users...

But tell me, am I missing something?

Thanks,
Nik

On Fri, Feb 3, 2012 at 6:09 AM, Adam Schröder <adamsc...@gmail.com> wrote:

Agree with Steven + Andreas

On Fri, Feb 3, 2012 at 1:16 AM, Steven Lauwers <stevenl...@hotmail.com> wrote:

I totally agree with Andreas.

Glimpse is open source, if anyone wants a signed version they can

download the source and sign it themselves.

Signing glimpse will break probably all of the plugins that currently
are available through nuget. That doesn't seem like a good move to me.

On 1 feb, 21:03, Andreas Håkansson <andr...@selfinflicted.org> wrote:
> If you flip the table a bit. The moment you sign your assembly you are also
> saying that all other assemblies that it uses will have to be signed. Now I
> will admit I am not well informed about
> the glimpse extension mechanism, but I think it uses MEF exports. So what
> if someone wrote an extension that used another assembly that was not
> signed? I would call it highly likely that
> someone will leverage 3rd party frameworks etc in custom glimpse extensions
> and I'll bet the majority of those will not be signed.
>
> When this is the case you can very easily find yourself in assembly binding
> redirect hell and even have multiple versions of the same assembly floating
> around with assembly bindings
> acting as the clue to attempt and make them all play nice
>
> Also, how many actually require a signed assembly? Since Glimpse is
> open-source they can download the source and sign it themselves. Most of
> them time when I see ppl asking for open-source
> assemblies to be signed it is not because they need to ensure the files
> originated from a trusted source, but because they have a corporate policy
> which says they need to sign their own thus all of
> the stuff they want to use also has to be signed.
>
> If you ask me, that right there makes it pretty useless and probably will
> end up making life miserable for more people than those that actually
> "benefit" from having them signed. And I say benefit
> lightly here =)
>
>
>

> On Wed, Feb 1, 2012 at 8:52 PM, Nik Molnar <nikm...@gmail.com> wrote:
> > Andreas,
>
> > Thanks for bringing this up - I should have explained this to begin with.
>
> > Basically, Jimmy Bogard sums it up nicely in this post :

> >http://lostechies.com/jimmybogard/2011/08/15/to-sign-or-not-to-sign-a...

>
> > In my own words, we view Glimpse as a framework for enabling simplified
> > application diagnostics. If a given user's application assemblies are
> > required to be strongly named (for whatever reason), they would not be able
> > to include a custom Glimpse tab or customization if Glimpse were unsigned.
>
> > If we sign Glimpse, any assmbly, regardless of how strong or weak it is,
> > could reference/leverage Glimpse.
>
> > With that in mind - we've pretty much decided to strong name Glimpse. We'd
> > be willing to hear reason's why this would be bad though. I've also looked
> > at Sebastien Lambla's arguments to not sign (

> >http://codebetter.com/sebastienlambla/2011/01/05/strong-naming-assemb...)

> > but didn't feel like the given use case applied to Glimpse.
>
> > Thoughts?
> > Nik
>
> > On Wed, Feb 1, 2012 at 2:11 PM, Andreas Håkansson <

> > andr...@selfinflicted.org> wrote:
>
> >> I'm going to play the devils advocate here and ask why you would
> >> strong-name an open-source project at all?
>

> >> On Wed, Feb 1, 2012 at 7:51 PM, nikmd23 <nikm...@gmail.com> wrote:
>
> >>> All,
>
> >>> Looking for a few opinions here...
>
> >>> Beginning with Version 1.0 of Glimpse (the next version we plan to
> >>> release), we will strong name the Glimpse assemblies.
>
> >>> Strong naming requires a Public/Private key pair, which is typically
> >>> kept in source control. Since Glimpse's source is open, this could
> >>> present a security problem since anyone would be able to download the
> >>> source, including the key pair, and create what seems to be an
> >>> "official" version of Glimpse - a possible security and support issue.
>
> >>> As I see it, we have two possible options:
>
> >>> 1) *Include the Public/Private key pair in source* - This would
> >>> simplify the community's ability to build Glimpse fresh from GitHub
> >>> (pro), but would then allow for "counterfeit", signed, versions of
> >>> Glimpse to be created (con).
>
> >>> 2) *Include only the Public key in source* - We would then delay sign
> >>> the assembly, and distribute the private key internally only to
> >>> trusted, core, team members. Delay signing would allow the community
> >>> to build a "partially strongly named" version of the assembly, but it
> >>> would fail assembly verification and require additional configuration
> >>> to circumvent (con). However, any developer could then trust a signed
> >>> copy of Glimpse since only our team could fully strongly name the
> >>> assembly (pro). (Read More Here -
> >>>http://msdn.microsoft.com/en-us/library/t07a3dye.aspx)
>
> >>> Right now I'm leaning towards option #2 - but would like to hear
> >>> everyone's thoughts.
>
> >>> As an aside, if we did go with option #2, would it be alright to
> >>> automatically turn off the .NET assembly verifier for just Glimpse
> >>> assemblies as part of the post build process? Seems like some people
> >>> might find that invasive, but it would make building a lot easier...
>
> >>> Thanks,

> >>> Nik- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -