lucenenet-dev 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 Tue, 29 Apr 2014 12:40:28 GMT
Signed assemblies do hurt projects that use unsigned assemblies.  Binding
redirects are painful.

There seems to be a lot of discussion around this issue for other projects:
* https://github.com/octokit/octokit.net/issues/405
* https://twitter.com/search?q=%23nomorestrongnaming&src=hash
* http://shouldiusestrongnaming.azurewebsites.net/
* the aforementioned post from Jeremy Miller.

There are pain points on both sides of the issue which is why there is a
big discussion happening in the .NET community.

The real solution might need the community to step up and change the
package manager nuget in order to accommodate a single feed that allows for
signed and unsigned assemblies and a way to filter on them.

-M


On Tue, Apr 29, 2014 at 5:30 AM, Alexey Shcherbachev <
alexey@renaissance-it.ru> wrote:

> Hi,
>
> I would strongly opt to keep assemblies signed by default too. Due to
> platform constrains our solution is forced to install assemblies into the
> GAC, which means that everything has to be signed.
>
> I would note, that number of projects that depends on Lucene.Net being
> signed is considerably higher than number of assemblies referenced by
> Lucene itself. So it is easier to keep them signed rather than force
> everybody who needs a signed version to do that themselves or use
> alternative distribution. And since keeping Lucene.Net signed won't hurt
> projects that use unsigned assemblies, but it will hurt everybody who uses
> signed version, it sounds more reasonable to keep everything as is.
>
> Regards,
> Alexey Shcherbachev
> US: 408.600.2737
> Russia (mobile): +7 (905) 47-97-677
> Russia (office): +7 (863) 266-50-67
> Skype: Leha-2304
> LinkedIn: http://linkedin.com/in/shcherbachev
>
>
> On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle <
> magnus.strale@episerver.com
> > wrote:
>
> > Hi,
> >
> > I've been following this mailing list for a long time with the intent of
> > eventually become more actively involved. Professionally I use Lucene.NET
> > and we are relying on the NuGet distribution both internally and for our
> > customers / partners that are building on our platform.
> >
> > Removing strong naming / signing of the assemblies shipped in the NuGet
> > feed will be a *big* pain for us.
> >
> > 1. We have signed assemblies that have dependencies on lucene.net.
> > 2. We have a large number of installations that are set up with NuGet
> > dependencies to Lucene
> > 3. We push updates on a fairly regular basis (weekly).
> > 4. Some of our partners implement various solutions based on Lucene.Net
> >
> > The combination of 1 & 4 used to be a big problem, but now (mostly) just
> > works thanks to NuGet.
> >
> > As I see our only practical option would be to create our own Lucene.net
> > NuGet package and get all our customers/partners to take  dependency on
> > that version.
> >
> > Please, please - keep the main distribution signed. If you really have to
> > go to an unsigned distribution, at least wait until the 4.x release and
> > continue to provide signed 3.x releases.
> >
> > ...and yes - this is the time for me to step up. What would be the best
> > area for me to start help out with Lucene.Net? Automation of the NuGet
> > release process with signed assemblies?
> >
> > Magnus Stråle
> > EPiServer AB
> >
> > -----Original Message-----
> > From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com]
> On
> > Behalf Of Itamar Syn-Hershko
> > Sent: den 28 april 2014 19:07
> > To: dev@lucenenet.apache.org
> > Cc: user@lucenenet.apache.org
> > Subject: Re: Removing signing of assemblies (starting in v4)
> >
> > Yes, and this is why we are going to provide signed versions as downloads
> > + scripts to sign the sources, just not in the main distribution stream
> > which is nuget.
> >
> > We will take a canary testing kind of approach where we will do a
> > pre-release of v4 and a bugfix release of v3 both usigned and see how
> much
> > people will complain.
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant Author of RavenDB in Action <
> > http://manning.com/synhershko/>
> >
> >
> > On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rvesse@dotnetrdf.org> wrote:
> >
> > > +1 to Oren's point here
> > >
> > > Remember the signing dependency issue works both ways, there are lots
> > > of other projects that depend on Lucene.Net which do sign their
> > > dependencies and so changing whether the project is signed breaks
> > > upstream consumers of the library
> > >
> > > An unsigned assembly can happily depend on a signed assembly whereas
> > > the opposite is not true
> > >
> > > Regardless of how effective/valuable SN signing is we are
> > > unfortunately stuck with it in the .Net world and you will only get
> > grief.
> > >
> > > My own project got rid of signing for a while and had to bring it back
> > > because we got too many user complaints about this.  For comparison my
> > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > would strongly suspect you will get far more user complaints far more
> > > quickly if you drop signing in future releases.
> > >
> > > Rob
> > >
> > >
> > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ayende@ayende.com>
> > > wrote:
> > >
> > > >I'm many corporate environment that is a big requirement In a library
> > > >like Lucene, where other people depend on it, a sign build is
> > > >important On Apr 23, 2014 2:27 PM, "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-
> > > eve
> > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > >> > >
> > > >> > much<
> > > >> >
> > > >>
> > > >>
> > > http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> > > nin
> > > >>g-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