lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Removing signing of assemblies (starting in v4)
Date Tue, 29 Apr 2014 13:15:44 GMT
I went ahead and discussed this in length here:
http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net

I'm assuming most place which _require_ SN, and their process can't really
change easily, will also likely not being using nuget anyway (big
corporate, government agencies, etc). While this is not always the case,
I'm happy with assuming this and redirecting them to the download page.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Tue, Apr 29, 2014 at 3:40 PM, michael herndon <
mherndon@michaelherndon.com> wrote:

> 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