Re: Strong Names and LGPL
From: Nicole Calinoiu (calinoiu)
Date: 01/06/05
- Next message: Doug R: "Re: Issues with .IsInRole in an Impersonated WindowsPrinciple"
- Previous message: William Stacey [MVP]: "Re: Issues with .IsInRole in an Impersonated WindowsPrinciple"
- In reply to: William Stacey [MVP]: "Re: Strong Names and LGPL"
- Next in thread: Ivan Medvedev [MS]: "Re: Strong Names and LGPL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 6 Jan 2005 13:32:43 -0500
Michael's utility simply uses sn.exe -R, so it won't work on an assembly
that wasn't signed at compile time since the PE file will have an incorrect
internal structure for application of the signature.
"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:uYTiJxB9EHA.2180@TK2MSFTNGP12.phx.gbl...
> You may also have a look at SNReplacer at http://www.atrevido.net/blog/.
> You can replace the SN on any assem, but not sure your constraints.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
> "Mike" <Mike@discussions.microsoft.com> wrote in message
> news:271280FC-F149-4767-93F4-73CB8D961115@microsoft.com...
>> The library is not strong named for that reason. It is versioned, but no
> key
>> assigned. I guess one option is to have the author put a placeholder snk
> file
>> in the project and I could then just overwrite it with my own before
>> compiling. This way it will compile as-is without complaining.
>>
>> Thanks for the info,
>>
>> Regards,
>>
>> Mike
>>
>>
>> "Nicole Calinoiu" wrote:
>>
>> > As I understand the LGPL, one need only release the change sources if
> one is
>> > actually redistributing the altered library. Also, even if you were to
> able
>> > to apply a strong name signature to the existing compiled DLL, I can't
> see
>> > that this would exempt you from the change publication requirements.
> That
>> > said, I'm no expert on the LGPL, and you might have get more educated
>> > opinions from an appropriate licensing forum. You might also want to
> look
>> > into whether application of an authenticode or similar signature is
>> > considered to require change notifications under the LGPL. If not,
>> > application of a strong name signature probably shouldn't either.
>> >
>> > You might also want to consider whether you would have felt safe using
>> > a
>> > library for which the private signing key had been published with the
>> > original sources. If so, why not just create a key pair intended
>> > solely
> for
>> > use with this assembly, then release with the appropriate altered
> sources?
>> > You would be no worse off than if you were using a private key
>> > inherited
>> > from the original author. Please note that I'm not advocating this
>> > approach. However, your original post suggested that use of an
> "inherited"
>> > key might be acceptable in your situation and, if it is, it really
> shouldn't
>> > matter who generated the key in the first place.
>> >
>> >
>> >
>> > "Mike" <Mike@discussions.microsoft.com> wrote in message
>> > news:BCD38A81-A97C-4BC6-A996-28EF2EAAC237@microsoft.com...
>> > > Nicole,
>> > >
>> > > Thanks for the quick response.
>> > >
>> > > I am not very knowledgable with the LGPL software library agreements.
> I am
>> > > under the impression that if modifications are made, they must be
> released
>> > > back to the "community" which would entail all files required to
>> > > build
> the
>> > > library. I assume this to mean the public key to delay sign with (as
>> > > specified in the AssemblyInfo.cs file) and then the private key to do
> the
>> > > actual signing - obviously the latter is not practical.
>> > >
>> > > I was just wondering if this issue has been addressed by others and
> what
>> > > solutions were employed so as to not violate the LGPL.
>> > >
>> > > Thanks,
>> > >
>> > > Mike
>> > >
>> > > "Nicole Calinoiu" wrote:
>> > >
>> > >> "Mike" <Mike@discussions.microsoft.com> wrote in message
>> > >> news:62839F8C-547A-4190-93E0-7EBD2F7E4695@microsoft.com...
>> > >> > Is it possible to strong name an assembly that was compiled
>> > >> > without
> a
>> > >> > snk?
>> > >>
>> > >> Space in the PE file must be reserved at compile time for the public
> key
>> > >> and
>> > >> signature. If an assembly was compiled without a strong name, the
>> > >> resulting
>> > >> PE file format will not support addition of a strong name using
> sn.exe.
>> > >>
>> > >>
>> > >> > I
>> > >> > am asking because we are using an LGPL licensed codebase that has
> no
>> > >> > associated keyfiles and will be used by an assembly that will
> reside in
>> > >> > the
>> > >> > GAC. What options exist for this scenario?
>> > >>
>> > >> If I understand the LGPL correctly, there should be nothing stopping
> you
>> > >> from recompiling with a strong name signature using whatever key you
>> > >> like.
>> > >> Is there some particular aspect of the license that is posing a
> problem
>> > >> for
>> > >> you?
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >
>> >
>
- Next message: Doug R: "Re: Issues with .IsInRole in an Impersonated WindowsPrinciple"
- Previous message: William Stacey [MVP]: "Re: Issues with .IsInRole in an Impersonated WindowsPrinciple"
- In reply to: William Stacey [MVP]: "Re: Strong Names and LGPL"
- Next in thread: Ivan Medvedev [MS]: "Re: Strong Names and LGPL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
