<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2016 at 13:37, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Wed, Apr 13, 2016 at 1:41 AM Stian Thorgersen <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>All existing adapters follow:</div><div>* Release at the same time as server (by the same Jenkins job)</div><div>* Same version as the server</div><div><br></div><div>Then the improvements we discussed at F2F are:</div><div>* Add note to release notes to show what adapters are required to update<br></div><div><div>* Add a separate adapters guide, with a chapter for each adapter.</div></div><div><br></div><div>That is the simplest and cleanest solution IMO. Further, just to point out that I want all official Keycloak adapters to follow the same process.</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 April 2016 at 21:54, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span><div class="gmail_quote"><div dir="ltr">On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi all<div><br></div><div>I've been emailing with Stian about versioning in the "Node.js adapter releases" thread, but as he pointed out, some of my concerns are broader than just Node.js and so I am broadening the conversation a bit.</div><div><br></div><div>Background: I am working as part of a Node.js RHT "middleware" team to, among other things, contribute towards the development of Node.js modules for our existing JBoss technologies. As part of this, we're doing what we can for the Keycloak Node.js pieces.</div><div><br></div><div>As it stands now, I understand that versioning of adapters must remain in lockstep with Keycloak core. I understand the motivation for this, but want to push back on this just a little bit, and open it up for discussion.</div><div><br></div><div>I see a couple of scenarios where this is potentially problematic. I am using Node.js and NPM here, but I think the concerns should apply to any adapter that is part of an ecosystem outside of Java.</div><div><br></div><div>1) There is a security flaw in some 3rd party dependency of the adapter, discovered the day of a Keycloak core release. This renders the "latest" version of an adapter useless until a new Keycloak server is released. I understand that the release cadence is anticipated to be approximately every 6 weeks (which is laudable), but still that's > 1 month that users have to wait for a security fix.</div></div></blockquote><div><br></div><div><br></div></div></span><div dir="ltr"><div class="gmail_quote"><div>In my opinion it depends how critical and exploitable is the vulnerability. For critical updates, I'd say that the adapter should be release ASAP and the patch number increased and released. For example: vulnerability found at 0.0.16 we just bump it up to 0.0.17 and release. </div></div></div><div dir="ltr"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2) There is no change in the adapter between releases of Keycloak server. In this case, it's not necessarily a problem to release a new adapter version, but it seems noisy and pointless if the bits are exactly the same.</div><div><br></div><div>When we look at version numbers, they are typically MAJOR.MINOR.PATCH with possibly a pre-release suffix like -Alpha1. I would like to discuss the possibility for adapters to issue patch level releases independent of a server release. This would allow for MAJOR.MINOR versions to remain consistent so to communicate compatibility with a given Keycloak server version. But would provide flexibility for adapters to deal with both issues noted above.</div></div></blockquote><div><br></div></span><div>I'm +1 on keeping independent version numbers from the server and state something like connect-keycloak v0.0.17 is compatible with Keycloak server 1.9.2.Final for example. But I'm -1 on independent release dates — unless we have a critical security fix.</div><div><br></div><div>If we release whenever we want the adapters, would be hard to test, because we don't have bandwith for it. I see as something which could become out of control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC 1.9.2, but v0.0.18 only works with KC 2.0.x. </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>And just for the sake of argument, let's look at a hypothetical situation where Keycloak is baptized a Product, and the release cadence slows down significantly to every 12-18 months. What if a major security flaw is discovered in an adapter? Should this trigger a new release of Keycloak server itself? Would it not be better to allow the adapter to issue a patch level release instead?</div></div></blockquote><div><br></div></span><div>+1 for just the adapter issue a patch level release.<br></div><div><br></div><div>tl;dr my personal opinion is (anything that I'm going to say here can be innacurate, because I don't have the whole context about the conversations during the F2F):</div><div><br></div><div>- Adapters should be released on exactly the same dates as the server (with one single exception, critical security fixes)</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>They are actually going to be released by the same process.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>- The version number should be independent, in this way we state something like Node.js adapters version 0.0.17 are fully compatible with KC 1.9.x.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>No, version is the same as the server. Having to install server 1.9.5, jee adapter 1.8.7, javascript adapter 1.0.5 and nodejs adapter 0.5.0 is just crazy.</div></div></div></div></blockquote><div><br></div></div></div><div>I'm sorry but I have to disagree, we already do it for years with 3rd party dependencies into our projects. For security fixes where you have the adapter and the server with version as 1.9.2.Final, we cannot bump up the version of the server because the adapter has a critical security issue and have to be released.</div><div><br></div><div>But if this is a decision already taken, I'm not taking this road discussing why I think it's bad. </div></div></div></blockquote><div><br></div><div>The decision has been made, but nothing is set in stone. I suggest we try the approach we decided at the f2f and adjust later if it becomes a problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div dir="ltr"><div><br></div><div>If you've read this far - thanks! Looking forward to your thoughts.</div><div><br></div><div>Lance</div><div><br></div></div></span>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></blockquote></div></div></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div></div></div></blockquote></span></div></div>
</blockquote></div><br></div></div>