Strong named Castle binaries

[Jonathon Rossi]

Do many people put Castle binaries in the GAC. I assume most people would ship them in their bin directory, but I just wanted to get a feeling for how many people use the GAC.

--
Jono

[James Curran]

This complicates things, but is nevertheless probably a good idea.

We would need one key-pair set which must be kept completely private,
and used for the official binary-only release. An assembly with that
key can be assured to be "pure", and therefore that key set cannot be
released with the source code. (If it were, a cracker could create a
malilicous version of Castle, and it would be indistinguishible from
the real code --- ths defeating the purpose of string naming in the
first place).

Which means we have the choice a) we provide a secondary "faux"
key-pair with the downloadable source code , or b) the source code
won't compile until the user creates thier own key-pair.

Truth,
James

[Jonathon Rossi]

On Tue, Feb 9, 2010 at 2:28 PM, James Curran <james....@gmail.com> wrote:

This complicates things, but is nevertheless probably a good idea.

We already sign everything, I only wanted to get an idea of how many people make use of it.

We would need one key-pair set which must be kept completely private,
and used for the official binary-only release.   An assembly with that
key can be assured to be "pure", and therefore that key set cannot be
released with the source code.  (If it were, a cracker could create a
malilicous version of Castle, and it would be indistinguishible from
the real code --- ths defeating the purpose of string naming in the
first place).

The purpose of strong naming is exactly that, not partially named and not security. Digital signatures on PE files is the way to go if you need security to prevent a cracker recreating your binaries. I do not think we have any reason for digital signatures at this point in time. I also don't see any reason we shouldn't release our private strong name key, there really is no harm in doing so.

Which means we have the choice a) we provide a secondary "faux"
key-pair with the downloadable source code , or b)  the source code
won't compile until the user creates thier own key-pair.

Truth,
   James

On Mon, Feb 8, 2010 at 10:52 PM, Jonathon Rossi <jo...@jonorossi.com> wrote:
> Do many people put Castle binaries in the GAC. I assume most people would
> ship them in their bin directory, but I just wanted to get a feeling for how
> many people use the GAC.
>
> --
> Jono

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[John Simons]

nope

[Roelof Blom]

never

nope

[Fabian Schmied]

> Do many people put Castle binaries in the GAC. I assume most people would
> ship them in their bin directory, but I just wanted to get a feeling for how
> many people use the GAC.

Some of our projects do because of Visual Studio designer quirks.
(Yes, there are some projects link to a Castle assembly and still use
the ASP.NET designers.)

In addition, I want to state that strong names are not only needed if
Castle binaries are put into the GAC, but also if another strong-named
library links to Castle assemblies.

Fabian

[SimoneB]

no gac here, never

[Henry Conceição]

no gac here either.

Cheers,
Henry Conceição

[G. Richard Bellamy]

GAC: Only when I've got a gun to my head, and someone willing to pull the
trigger (oh, and it's loaded)... even then I might still say 'no'.

GAC is evil. 'Nuff said.

-rb

[Cesar Sanz]

GAC? why?

[Krzysztof Koźmic]

It brings nothing but pain.

Why would you ever want to do such a thing to yourself?

[Jonathon Rossi]

Thanks everyone. I don't want to do it myself; you don't need to tell me the GAC is evil ;)

I think the GAC should be reserved for Microsoft to put the framework assemblies and that is all.

I wanted to know if anyone does, because something I am working on will not support strongly named assemblies and I just wanted to know if it would affect anyone if they decided to use it.

2010/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

--
Jono

[John Simons]

Sorry Jono for hijacking your post but I was just about to start a
thread on the same topic.

Why are we strong naming the Castle assemblies?
As far as I know it doesn't really gives us any benefits, if we didn't
strong name assemblies we wouldn't have problems like this:
http://groups.google.com/group/castle-project-devel/browse_thread/thread/4a2cdffa18ab6583

Thoughts?

[Jonathon Rossi]

No problem at all. I was actually going to ask the same question after I got responses for the initial question, because I don't want them strong named.

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[James Curran]

A strong-named assembly cannot use a non-string-named assembly.
Since many of Castle's parts (like Windsor, DP and ActiveRecord), are
used as building blocks of third-party tools -- which themselves might
be strong-named, our assemblied must be.

Truth,
James

[Jonathon Rossi]

On Thu, Feb 11, 2010 at 6:40 PM, James Curran <james....@gmail.com> wrote:

A strong-named assembly cannot use a non-string-named assembly.

Yes, absolutely.
 

Since many of Castle's parts (like Windsor, DP and ActiveRecord), are
used as building blocks of third-party tools -- which themselves might
be strong-named, our assemblied must be.

I guess might is the keyword here, whereas everyone above said the GAC is evil so they don't need strong named assemblies in their applications.

Currently, I am considering just flicking the switch in the CLR header to state the assembly is not strong named for my own purposes:
http://www.codeproject.com/KB/security/StrongNameRemove20.aspx
http://www.nirsoft.net/dot_net_tools/strong_name_remove.html

Truth,
   James

On Thu, Feb 11, 2010 at 3:23 AM, John Simons <johnsi...@yahoo.com.au> wrote:

> Why are we strong naming the Castle assemblies?
> As far as I know it doesn't really gives us any benefits, if we didn't
> strong name assemblies we wouldn't have problems like this:
> http://groups.google.com/group/castle-project-devel/browse_thread/thread/4a2cdffa18ab6583

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[John Simons]

http://www.codeplex.com/Signer

On Feb 11, 7:40 pm, James Curran <james.cur...@gmail.com> wrote:
> A strong-named assembly cannot use a non-string-named assembly.
> Since many of Castle's parts (like Windsor, DP and ActiveRecord), are
> used as building blocks of third-party tools -- which themselves might
> be strong-named, our assemblied must be.
>
> Truth,
>     James
>

> On Thu, Feb 11, 2010 at 3:23 AM, John Simons <johnsimons...@yahoo.com.au> wrote:
> > Why are we strong naming the Castle assemblies?
> > As far as I know it doesn't really gives us any benefits, if we didn't
> > strong name assemblies we wouldn't have problems like this:

> >http://groups.google.com/group/castle-project-devel/browse_thread/thr...

[James Curran]

On Thu, Feb 11, 2010 at 3:48 AM, Jonathon Rossi <jo...@jonorossi.com> wrote:
> I guess might is the keyword here, whereas everyone above said the GAC is
> evil so they don't need strong named assemblies in their applications.

But strong-naming isn't just about using the GAC -- It's mostly about
having a verifiable origin. In a world where corporate IT departments
lock out all kinds of software coming from the Internet, being able to
show that an assembly is the original version and not one create by a
hacker who download and modified the source code is important.

Truth,
James

[Jonathon Rossi]

Thanks John, that looks like a useful utility too.

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[Jonathon Rossi]

James, in the case of most open source projects this goal is fruitless because the private strong name key is available in source control.

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[Fabian Schmied]

> http://www.codeplex.com/Signer

Are you implying that any project that uses Castle and needs its
assemblies to be strong-named should just use Signer and sign them by
itself?

If so, I think this would be a very bad default. Libraries should be
strong-named so that they can be reused in strong-named applications
and other libraries. Everything else would be an unpleasant surprise.
If someone really needs a version of the Castle stack without strong
naming (for whatever reason), he or she should be required remove the
strong names, not the other way around.

What are the actual arguments in favor of removing strong names?

The posting cited by John (
http://groups.google.com/group/castle-project-devel/browse_thread/thread/4a2cdffa18ab6583
) seems to me an argument for releasing (or re-releasing the same
version with updated references) more often rather than just removing
strong names. .NET provides facilities to use newer versions of
referenced libraries (assembly dependency rebinding), and that
mechanism is very explicit for a good reason: it can easily break
something if the newer version isn't fully backwards compatible.

The argument that the snk is publicly available anyway is a good one.
But I'd rather solve it by having a private key for official builds
that is not in source control and available to only a limited number
of people. E.g. Castle Stronghold, or the PMC.

Fabian

[Krzysztof Koźmic (2)]

I'm +1 for sticking to strongly named assemblies.
It may be some more headache for us, but is less headache for users.

Krzysztof

On 11 Lut, 11:11, Fabian Schmied <fabian.schm...@gmail.com> wrote:
> >http://www.codeplex.com/Signer
>
> Are you implying that any project that uses Castle and needs its
> assemblies to be strong-named should just use Signer and sign them by
> itself?
>
> If so, I think this would be a very bad default. Libraries should be
> strong-named so that they can be reused in strong-named applications
> and other libraries. Everything else would be an unpleasant surprise.
> If someone really needs a version of the Castle stack without strong
> naming (for whatever reason), he or she should be required remove the
> strong names, not the other way around.
>
> What are the actual arguments in favor of removing strong names?
>

> The posting cited by John (http://groups.google.com/group/castle-project-devel/browse_thread/thr...

[Jonathon Rossi]

I understand that some users use strong names and that is why I posted links to the tools to remove the strong naming. At this point in time I also think strong naming is the right default.

So maybe the alternative is to not increment the assembly version but the file version for hotfix/patch releases (i.e. 2.0.1, 2.0.2). Which means that you could just drop in a patch release without worrying about updating dependant libraries, this then ensures the user is using compatible versions and allows us to fix bugs that don't break public interfaces.

2010/2/11 Krzysztof Koźmic (2) <krzy...@kozmic.pl>

For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[Henry Conceição]

Makes sense for me.

Cheers,
Henry Conceição

2010/2/11 Jonathon Rossi <jo...@jonorossi.com>:

[Richard Fleming]

In case anyone is interested I've attached the modifications I made to the StrongNameRemove21 application a while back to make it easier to strip batches of assemblies, the only thing I would probably do to make this a little better would be to check if the referenced assembly exists in the same folder as the assembly being patched (to keep from stripping the signing of .NET framework assemblies), however currently the attached modification to the source doesn't do that (haven't had any issues though, I use it to strip from all the components that I use.)

To use it just do the following in the folder which holds your assemblies:  StrongNameRemove -clean *.dll


Thanks,
Rick Fleming

2010/2/11 Henry Conceição <henry.c...@gmail.com>