If you're going to reopen tp32, then I'll retarget https://github.com/apache/tinkerpop/pull/969
Robert Dale On Fri, Oct 26, 2018 at 7:56 AM Robert Dale <robd...@gmail.com> wrote: > So to answer your earlier question on security fixes, the driver should be > our security policy ;-) > > For example, if tp32 is not officially closed and accepts bug fixes, and > given "security problems are just bugs" [1], then tp32 should get > security-related bug fixes. > > We can use CVSS [2] to score vulnerabilities. They even have a handy-dandy > calculator [3]. > > The release trigger should also be in the security policy. It could be > based on the CVSS score: > <5, next scheduled release > <7, within 30 days > <8, within 2 weeks > <9, within 1 week > 9+, asap > > Or we just keep it simple, release next cycle unless someone can provide a > proof of concept or just feels strongly otherwise. > > For example, I don't think TINKERPOP-2068 [4] is critical because our > serializers handle only explicitly listed types. Nothing is blindly > delegated to Jackson. No need for an emergency release. Someone can confirm. > > 1. https://lkml.org/lkml/2017/11/17/767 > 2. https://www.first.org/cvss/ > 3. https://www.first.org/cvss/calculator/3.0 > 4. https://issues.apache.org/jira/browse/TINKERPOP-2068 > > Robert Dale > > > On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette <spmalle...@gmail.com> > wrote: > >> tp32............... >> >> i started thinking that we could keep a JIRA ticket open that had a list >> of >> bugs we might backport to tp32 should we have some triggering event, >> but....i dunno. maybe we go with a first step at this and re-open the >> branch but just ship security+bug fixes at it and not try to wait for a >> triggering event for release. i would expect the CHANGELOG for 3.2.11 to >> be >> really small if we do this right. please let me know if there are any >> concerns, otherwise we'll start heading down this route and i'll re-open >> the branch on Monday. >> >> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette <spmalle...@gmail.com> >> wrote: >> >> > there's always going to be those kinds of things though right? can we >> get >> > away with doing stuff to tp32 only when there is some specific demand >> for a >> > 3.2.11. like, that fix on its own doesn't feel like something we'd >> trigger >> > a release over....or would we? >> > >> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale <robd...@gmail.com> wrote: >> > >> >> You don't want to put >> >> https://issues.apache.org/jira/browse/TINKERPOP-2068 >> >> on tp32? >> >> >> >> Robert Dale >> >> >> >> >> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette <spmalle...@gmail.com >> > >> >> wrote: >> >> >> >> > > I created a ticket to track this and I can probably take care of >> it >> >> next >> >> > week >> >> > >> >> > that makes sense, thank you. >> >> > >> >> > separately, code freeze is now lifted on tp33 - i've bumped to >> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to >> go. >> >> > I've left tp32 on 3.2.10 until we decide to actually do something on >> >> that >> >> > branch. For now, we'll just say we're done there as we discussed >> >> > elsethread. >> >> > >> >> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder >> >> if it >> >> > will be more convenient to delete branches as we go now that we have >> the >> >> > github UI available to us. might be good to just hit the "delete >> branch" >> >> > button right when we hit the merge one. >> >> > >> >> > i will announce the releases on monday morning EST time. >> >> > >> >> > >> >> > >> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann < >> >> f...@florian-hockmann.de> >> >> > wrote: >> >> > >> >> > > We currently use this to push the package: >> >> > > >> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg >> >> > > >> >> > > which pushes all NuGet packages starting with Gremlin.Net. You >> >> probably >> >> > > also had the package for version 3.4.0-rc2 in that directory. So, >> >> > > nuget.exe tried to push that version again which isn't allowed by >> >> NuGet >> >> > > as packages are immutable for a given version. >> >> > > >> >> > > I guess we should specify the exact version here instead to avoid >> >> these >> >> > > problems in the future. Otherwise we could push development >> versions >> >> to >> >> > > nuget.org by accident. I probably implemented it like this at >> first >> >> > > because I assumed that mvn clean would always remove older packages >> >> > > which seems to be not the case here. >> >> > > >> >> > > Anyway, I created a ticket to track this and I can probably take >> care >> >> of >> >> > > it next week: >> >> > > >> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074 >> >> > > >> >> > > >> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette: >> >> > > > Florian, any idea what's going on with this error when i deployed >> >> > 3.3.4: >> >> > > > >> >> > > > main: >> >> > > > [echo] nuget.exe already downloaded. >> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to ' >> >> > > > https://www.nuget.org/api/v2/package'... >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> > > > [exec] Created https://www.nuget.org/api/v2/package/ >> 1362ms >> >> > > > [exec] Your package was pushed. >> >> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to ' >> >> > > > https://www.nuget.org/api/v2/package'... >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> > > > [exec] Created https://www.nuget.org/api/v2/package/ >> 11405ms >> >> > > > [exec] Your package was pushed. >> >> > > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to ' >> >> > > > https://www.nuget.org/api/v2/package'... >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> > > > [exec] Conflict https://www.nuget.org/api/v2/package/ >> 365ms >> >> > > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and >> >> version >> >> > > > '3.4.0-rc2' already exists and cannot be modified.) >> >> > > > >> >> > > > >> >> > > > why is it trying to push the 3.4.0 line? looks like the error >> >> didn't >> >> > > > matter as the other two published fine, but let's fix the error >> if >> >> we >> >> > > > can........... >> >> > > > >> >> > > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette < >> >> spmalle...@gmail.com >> >> > > >> >> > > > wrote: >> >> > > > >> >> > > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT >> >> artifacts >> >> > > and >> >> > > >> docs too: >> >> > > >> >> >> > > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/ >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette < >> >> > spmalle...@gmail.com> >> >> > > >> wrote: >> >> > > >> >> >> > > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs: >> >> > > >>> >> >> > > >>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/ >> >> > > >>> >> >> > > >>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale <robd...@gmail.com> >> >> > wrote: >> >> > > >>> >> >> > > >>>> I'll take 3.2.10. >> >> > > >>>> >> >> > > >>>> Robert Dale >> >> > > >>>> >> >> > > >>>> >> >> > > >>>> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette < >> >> > spmalle...@gmail.com >> >> > > > >> >> > > >>>> wrote: >> >> > > >>>> >> >> > > >>>>> So - code freeze for the tp32 and tp33 branches is in effect >> at >> >> > this >> >> > > >>>> point. >> >> > > >>>>> We'll use this thread to discuss issues related to 3.2.10 and >> >> 3.3.4 >> >> > > >>>> leading >> >> > > >>>>> up to the build of release artifacts for 10/15. We currently >> >> have a >> >> > > >>>> few PRs >> >> > > >>>>> that need merging to those branches, >> >> > > >>>>> >> >> > > >>>>> https://github.com/apache/tinkerpop/pull/952 (submit scripts >> >> with >> >> > > >>>>> gremlin-javascript) >> >> > > >>>>> https://github.com/apache/tinkerpop/pull/953 (minor fix for >> >> > testing >> >> > > >>>> around >> >> > > >>>>> inject in .net) >> >> > > >>>>> >> >> > > >>>>> but they are related to GLVs so we shouldn't be affecting the >> >> > ability >> >> > > >>>> of >> >> > > >>>>> graph providers to test against the core code. If those merge >> >> > during >> >> > > >>>> code >> >> > > >>>>> freeze, I don't think that's too big a problem. >> >> > > >>>>> >> >> > > >>>>> Note that the master branch will remain open for development >> >> during >> >> > > >>>> this >> >> > > >>>>> time period. >> >> > > >>>>> >> >> > > >>>>> Anyone care to volunteer for release manager duties for >> either >> >> of >> >> > > these >> >> > > >>>>> releases? >> >> > > >>>>> >> >> > > >> >> > > >> >> > >> >> >> > >> >
