Strong names in Open Source

[Pete Davis]

I'm working on an open source application that I've got on SourceForge.

I need to use strong names for a number of the assemblies. My question is
what to do about the key file.

Since it's open source, I'd like to put the key out with the source code so
that it compiles properly. On the other hand, wouldn't that be a security
risk?

How do others deal with this?

Pete

 

[Kevin P. Fleming]

Since it's open source, I'd like to put the key out with the source code so
that it compiles properly. On the other hand, wouldn't that be a security
risk?

I think you are stuck here; you can't publish the source code _and_
produce strongly-named assemblies... well, _you_ can make the
assemblies, but if anyone else does then their assemblies won't match yours.

If you publish the private key for signing the assemblies, you might as
well not use strong naming at all, since it's not providing any protection.

 

[Jochen Kalmbach]

I need to use strong names for a number of the assemblies.

Why do you need strong names ?

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

 

[Franz]

I'm working on an open source application that I've got on SourceForge.

I need to use strong names for a number of the assemblies. My question is
what to do about the key file.

Since it's open source, I'd like to put the key out with the source code so
that it compiles properly. On the other hand, wouldn't that be a security
risk?

How do others deal with this?

You may use delay signing. Then you can postpone the actual signing.
But you will be the only one who sign the assembly. I think it may violate
the open source spirit

 

[Pete Davis]

Why do you need strong names ?

Well, there are a few reasons. The main has to do with application security
policy, which you need a strong name to allow people to configure the app's
security policy.

It also has to do with establishing policies for the DLL versioning, which I
believe also requires strong names, though I could be wrong.

Really, it's kind of this nebulous thing that I'm pretty sure I need, but
I'm not positive.

The application itself is quite large and involves a number of pieces:

- An optional socket server that some people will run as an NT service
- A web based client application
- A form based client application
- A web service.
- A number of libraries shared by all these components.

Pete

 

[Miha Markic [MVP C#]]

Why do you need strong names ?

He might need them to put assemblies into GAC.

 

[Pete Davis]

Actually, as I stated in another reply, my system does share a number of
libraries among several applications (web form, win form, socket server, and
web service).

I honestly haven't decided if I want to use the GAC or not.

But along these lines, every time an issue like this comes up people say,
"Don't use the GAC, just put your DLLs in the same directory as the app."
This isn't the first time I've had multiple apps sharing libraries.

So, it brings up the obvious question, What good is the GAC if everyone's
solution is always "don't use the GAC?" I mean, it's there for a reason,
isn't it?

Pete

 

[Jochen Kalmbach]

He might need them to put assemblies into GAC.

Why do we need GAC !?
You can simple put the assembly into the local dir where you want to use
it.
Today disk space is not the prblem...

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

 

[Franz]

Why do we need GAC !?
You can simple put the assembly into the local dir where you want to use
it.
Today disk space is not the prblem...

But if multiple applications are using the same assembly, then you may need
to put a lot of copies. Although it may not spend a large memory space, it
is a time-consuming job

 

[Jochen Kalmbach]

Well, there are a few reasons. The main has to do with application
security policy, which you need a strong name to allow people to
configure the app's security policy.

It also has to do with establishing policies for the DLL versioning,
which I believe also requires strong names, though I could be wrong.

Maybe GPL and strong names clash violently...

If the user of the source should be able to build on its on, and should
also be able to modify the version, then strong names are bad (or
good?).

If you have to control over the project then strong names might be good.
So very other is able to build and modify the project on his own and can
make an own version of the project. But this build is not able to work
with other components; which might be your intention...


So it is really a hard question.
As long as you can avoid strong names, you should do this.

I think this is only one of the problems we will face in future if TCPA
is established....
Then we have the same (or even worser) problems with Open-Source.


--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

 

[Franz]

Actually, as I stated in another reply, my system does share a number of
libraries among several applications (web form, win form, socket server, and
web service).

I honestly haven't decided if I want to use the GAC or not.

But along these lines, every time an issue like this comes up people say,
"Don't use the GAC, just put your DLLs in the same directory as the app."
This isn't the first time I've had multiple apps sharing libraries.

So, it brings up the obvious question, What good is the GAC if everyone's
solution is always "don't use the GAC?" I mean, it's there for a reason,
isn't it?

I think GAC can handle the versioning in a managed way. It can be in a case
that some applications use different versions of library. The GAC will keep
the old library until you delete it.

Pete

--
http://www.petedavis.net

Miha Markic [MVP C#] wrote:


Pete Davis wrote:

I need to use strong names for a number of the assemblies.

Why do you need strong names ?

He might need them to put assemblies into GAC.

Why do we need GAC !?
You can simple put the assembly into the local dir where you want to use
it.
Today disk space is not the prblem...

But if multiple applications are using the same assembly, then you may need
to put a lot of copies. Although it may not spend a large memory space, it
is a time-consuming job

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

 

[Pete Davis]

Rudy,

Thanks, that was very enlightening. So it seems that MS wants people to
avoid the GAC in most cases.

For my application, I suppose that I'll be leaning against using the GAC.
Yes, I have shared assemblies, but I don't know that that's really enough of
a reason.

A single machine will, most likely, only install and run one piece of the
app, be it the winform client, the web service, the socket server, etc. The
case of someone running more than one of these would be the exception, not
the rule. That being the case, I think it's best to avoid the GAC.

I'm still torn on the strong name stuff, though. I may just go ahead and
use it and publish it. I won't get the security, but I'll get the other
features that come with strong names, and that may be sufficient, unless
that somehow makes my app MORE vulnerable than an unsigned app, which I
can't think of any way that would be the case.

Unless someone can give me a reason that my app would be particularly
vulnerable by being signed by a published key, I'm just going to publish it.

Pete

 

[Rudy Velthuis]

Actually, as I stated in another reply, my system does share a number of
libraries among several applications (web form, win form, socket
server, and web service).

I honestly haven't decided if I want to use the GAC or not.

But along these lines, every time an issue like this comes up people
say, "Don't use the GAC, just put your DLLs in the same directory as
the app." This isn't the first time I've had multiple apps sharing
libraries.

So, it brings up the obvious question, What good is the GAC if
everyone's solution is always "don't use the GAC?" I mean, it's there
for a reason, isn't it?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/h
tml/cpconworkingwithassembliesglobalassemblycache.asp

"You should share assemblies by installing them into the global assembly
cache only when necessary. As a general guideline, keep assembly
dependencies private and locate assemblies in the application directory
unless sharing an assembly is explicitly required. In addition, you do
not have to install assemblies into the global assembly cache to make
them accessible to COM interop or unmanaged code."

....

"Note that there are scenarios where you explicitly do not want to
install an assembly into the global assembly cache. If you place one of
the assemblies that make up an application into the global assembly
cache, you can no longer replicate or install the application by using
XCOPY to copy the application directory. In this case, you must also move
the assembly into the global assembly cache."

 

[Pete Davis]

That's true, I suppose.

I guess for now I'm the only person doing releases anyway. I suppose what
I'll do is stick a dummy key in with the source so it's compilable but keep
the real key hidden and use it for releases.

I don't think that breaks the idea of open source. Everything is still open
source and will work without my key, but people will be able to trust
releases based on my key.

Thanks.

Pete

--
http://www.petedavis.net

Pete, we are currently getting ready to push out the .NET Terrarium source
release and we've managed to solve this issue. Basically, if a user has your
source then they are capable of fully recompiling the application and they can
attach their own strong name key if they wish. There is no need to publish
your strong name key and allow them to use it.

A strong name implies ownership which is bad in an open source release.
However, it also provides protection. As long as the strong name isn't shared
and each developer can fully recompile the application and use their own strong
naming key then things are still safe. You get all of the bells and whistles of
strong naming on a per compilation instance.

 

[Justin Rogers]

Pete, we are currently getting ready to push out the .NET Terrarium source
release and we've managed to solve this issue. Basically, if a user has your
source then they are capable of fully recompiling the application and they can
attach their own strong name key if they wish. There is no need to publish
your strong name key and allow them to use it.

A strong name implies ownership which is bad in an open source release.
However, it also provides protection. As long as the strong name isn't shared
and each developer can fully recompile the application and use their own strong
naming key then things are still safe. You get all of the bells and whistles of
strong naming on a per compilation instance.

 

[Jens Thiel]

I suppose what
I'll do is stick a dummy key in with the source so it's compilable but keep
the real key hidden and use it for releases.

Hi Pete, I wouldn't do that, as people will start to actually use the dummy
key and eventually grant full trust - doors wide open, I would say...

You should either include your public key, enable delay signing and add a
README that describes how to disable verification - OR - include no key at
all and add a keygen batch file or a makefile so that everyone has their own
keys to play with (I now favour this approach as disabling verification can
lead to the same security holes described above...).

Keep the private key to sign official releases made by you, so that people
can actually trust that key - or their very own. If you ever hand the
project to someone else or a group of maintainers establish a release policy
and use the private key accordingly.

Keeping the private key doesn't violate OS. Everybody can still release
their own versions, but nobody can use your name/key to claim that their
changes are trustworthy or have been approved by you.

Jens.

 

[Justin Rogers]

Yes, I highly recommend automatically generating a key rather than including
one in the tree. Adding an sn -k buildKey.snk is much more secure in the long
run, since every dev will get their own special key and there won't be any
full trust issues later down the road.

 

[Christoph Nahr]

For my application, I suppose that I'll be leaning against using the GAC.
Yes, I have shared assemblies, but I don't know that that's really enough of
a reason.

I'd have to look it up but... can't you just put your shared
assemblies in a common application-specific directory, and put the
path in a config file that's created by the installer?

The installer would have to ask the user where the shared assemblies
are, or perhaps store the location in the registry. Any outdated
shared assemblies would automatically be updated by the installer.

 

[Pete Davis]

Thanks to both of you. That makes a great deal of sense.

Pete

 

[Tom Wells]

Rudy,

Thanks, that was very enlightening. So it seems that MS wants people to
avoid the GAC in most cases.

For my application, I suppose that I'll be leaning against using the GAC.
Yes, I have shared assemblies, but I don't know that that's really enough of
a reason.

A single machine will, most likely, only install and run one piece of the
app, be it the winform client, the web service, the socket server, etc. The
case of someone running more than one of these would be the exception, not
the rule. That being the case, I think it's best to avoid the GAC.

I'm still torn on the strong name stuff, though. I may just go ahead and
use it and publish it. I won't get the security, but I'll get the other
features that come with strong names, and that may be sufficient, unless
that somehow makes my app MORE vulnerable than an unsigned app, which I
can't think of any way that would be the case.

Yes, this could potentially make a sysetm LESS secure, if the user has
assigned
runtime security based on YOUR key (and the key file is public) , and not at
the
assembly level, this could allow unscrupulous programmers to elevate
security
permissions of their code to be equal to what the user has assigned to your
key.