lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From michael herndon <mhern...@michaelherndon.com>
Subject Re: Removing signing of assemblies (starting in v4)
Date Thu, 24 Apr 2014 01:31:38 GMT
Corporations and Governments tend to use signed assemblies in their
internal applications.

They'll typically download the binaries, put it into their own dependency
store. Some will take the time to confirm the hash and run security checks
on the binary.

Creating signed assemblies and making them available to download would be
less friction to consumers.

It might be as simple doing the following:

 <PropertyGroup Condition=" '$(Configuration)' == 'ReleaseSigned'">


<AssemblyOriginatorKeyFile>Lucene.Net.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>
</PropertyGroup>


Another option would be to create an alternate feed on a site like myget.org
.

-M





On Wed, Apr 23, 2014 at 8:08 PM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> I thought about the option of having 2 nugets, but I really don't think
> that's a good solution. As Petar mentioned, the better solution would be to
> provide an easy way to sign the assemblies and have it properly documented
> and highlighted in the source and our website.
>
> What that means is places that _do_ need a signed Lucene.NET will have to
> get it manually (and not through nuget), run the signing script, and then
> reference it manually. I'd actually expect that in corporate environments
> where this is indeed required and rules can't be changed nuget won't be in
> wide use anyway. At least that's what I usually see.
>
> Seems like the next release of NTS will be signed again:
> https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not sure
> how it happened that they stopped signing it and then decided to bring it
> back. Oh well. What that means is this lost some of the severity (besides
> delaying the v3 bugfix release), but I still think this is an important
> discussion.
>
> I'm still contemplating on this. I'm thinking of removing signing on the v4
> branch, and start releasing it as -Pre to nuget and let it boil over there.
> Worst case we can only bring signing again, but so far nobody has shown big
> objection.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <scoundrel@gmail.com> wrote:
>
> > We too have moved away from signing assemblies. What about building two
> > Nugets a signed and an unsigned version differentiated by name. This
> would
> > lighten the load on adoption of Lucene.Net for organizations which
> require
> > signing.
> >
> > - KevM
> >
> > On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> > wrote:
> >
> > There is a long discussion about SN here:
> > https://nuget.codeplex.com/discussions/247827
> >
> > I'd suggest that even if decision is not to sign, there should be an easy
> > way to get signed assemblies.
> >
> > Like:
> > 1. clone repo (signing keys are publicly accessible in repository)
> > 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > 3. c/p files from /build folder
> >
> > I stopped signing my assemblies long ago, but probably there still are
> many
> > that still do
> > and less obstacles in adopting Lucene.NET the better.
> >
> > Regards,
> > Petar Repac
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > All Lucene.NET assemblies are signed, aka strongly named.
> > >
> > > We are starting to run into problems with dependencies which not being
> > > signed. What's becoming more common in the .NET world (OSS mainly) is
> to
> > > stop signing assemblies because its
> > > pretty<
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > > >
> > > much<
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > > >
> > > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> the
> > > last link: What Strong Names Can't Do).
> > >
> > > Regardless of the argument about SN it seems to bring more fraction and
> > > trouble than anything good, especially considering we are an
> open-source
> > > library.
> > >
> > > Case in question, I'm moving to updating the spatial module and want to
> > > fetch dependencies from nuget. While spatial4n is signed (so it can be
> > used
> > > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > > time soon. Since signed assemblies cannot reference non-strongly-named
> > > assemblies, I can't currently do that - not through nuget at least.
> This
> > > introduces a lot of frustration and tons of fraction which I'd like to
> > have
> > > removed.
> > >
> > > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > > assemblies (v4 and forward), and having a wiki page that describes why
> > > signing is pointless and how to manually sign it if you insist.
> > >
> > > I can see 2 disadvantages for not signing, both of which I doubt really
> > > matter nowadays and given our usage scenarios:
> > >
> > > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > assemblies can be SN or ILMerged as part of the install process)
> > >
> > > 2. Signed assemblies / project won't be able to get Lucene.NET from
> nuget
> > > directly because they'll have to sign it before referencing it. Or lose
> > SN
> > > themselves.
> > >
> > > Thoughts?
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant
> > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message