Hi Ben, On Sun, Dec 20, 2020 at 02:34:17PM +0100, Benjamin Marwell wrote: > Hello Roberto, > > looking at https://tracker.debian.org/pkg/shiro, it seems extremely unwise > to have a java library as a package. Being both a debian/ubuntu user *and* > java developer myself, I know this can cause a lot of incompatibilities. > For example, application "a" might require shiro-1.3.2, application "b" > might require shiro-1.7.x and application "c" might require the > incompatible shiro-2.x.x. > In my (personal) opinion, java applications should always be packaged with > their own lib directory. >
I understand. As a Java developer I rarely depend on any Java library as shipped by a Linux distribution, preferring the approach you describe. That said, the shiro package is in Debian and it is better to have the vulnerability addressed rather than to leave it open. > Anyway, back to your original question. I will talk to the rest of the team > if such a disclosure is possible. > > The list of published CVEs can be found here: > https://shiro.apache.org/security-reports.html > > > However, at the moment I am concerned with CVE-2020-13933 > > This would be most unpleasant for users, as they would still suffer from > the other CVEs. Are you referring to CVE-2020-17510? I have not yet investigated that CVE. Or are you referring to other CVEs? > I wonder: does your policy actually allow this? > It depends. CVEs are evaluated and a variety of factors are considered in deciding whether a CVE will be fixed or not. > Best regards, > Ben > Regards, -Roberto > > Am So., 20. Dez. 2020 um 06:45 Uhr schrieb Roberto C. Sánchez < > [email protected]>: > > > Hi Ben, > > > > Thanks for responding. > > > > It seems that my initial message was not especially clear. > > > > Please see my comments below. > > > > On Sat, Dec 19, 2020 at 09:03:41PM +0100, Benjamin Marwell wrote: > > > Hi Roberto, > > > > > > I found your email in my spam folder. Maybe this is the reason why noone > > > answered. > > > > > > There will probably no backport for the CVE you mentioned. > > > > I am more than willing to backport the fix, but the specific commit > > associated with fixing the CVE in question is not identified anywhere. > > If someone who is knowledgeable about the shiro history could specify > > the commit(s) which fix the CVE, that would be a good start. > > > > If it turns out that backporting the commit(s) to fix the CVE will not > > work, then I could work out an alternate fix based on the 1.3.2 code. > > Note that this would require information about the exploit and how to > > reproduce it, so that I could validate the alternate fix. > > > > > On the contrary, there were multiple other CVEs in the meantime. > > > > > I understand. However, at the moment I am concerned with CVE-2020-13933 > > and shiro 1.3.2. > > > > > I can highly recommend you to update to SHIRO 1.6.0 and stay updated as > > > much as possible. > > > > > > Is there a specific reason why you want to stay on 1.3.2? > > > As far as I know, there was no version of shiro which introduced > > > incompatibilities. > > > > > That is not possible. The policy for package updates in Debian > > precludes such a change. Backports of security fixes are possible, > > however. > > > > Regards, > > > > -Roberto > > > > > Best regards, > > > Ben > > > > > > Am Fr., 18. Dez. 2020 um 02:08 Uhr schrieb Roberto C. Sánchez < > > > [email protected]>: > > > > > > > bump > > > > > > > > On Thu, Sep 24, 2020 at 02:48:17PM -0400, Roberto C. Sánchez wrote: > > > > > Shiro Devs, > > > > > > > > > > I am working on a security update for the shiro package in Debian. > > The > > > > > announcement for 1.6.0 indicates that CVE-2020-13933 is fixed in that > > > > > release. However, the specific commit is not identified. > > Additionally, > > > > > since neither the announcement nor any available information on the > > CVE > > > > > describes the means of exploitation it is not clear how I should > > proceed > > > > > to go about backporting the fix. > > > > > > > > > > The 1.6.0 announcement describes the new "Global Filters" feature as > > > > > helping to mitigate the type of issue described by CVE-2020-13933. > > It > > > > > seems that commit dc194fc977ab6cfbf3c1ecb085e2bac5db14af6d is what is > > > > > being referred to. However, the change is rather substantial and > > > > > appears like it would require significant reworking to apply to > > 1.3.2. > > > > > > > > > > If someone could help with the following questions it would be very > > much > > > > > appreciated: > > > > > > > > > > - Is a backport of commit dc194fc977ab6cfbf3c1ecb085e2bac5db14af6d to > > > > > 1.3.2 possible/feasible? > > > > > - Would it be possible to obtain information about the exploit to > > assist > > > > > with either backporting dc194fc977ab6cfbf3c1ecb085e2bac5db14af6d or > > > > > with developing a new fix for 1.3.2? > > > > > - Is there another approach that I should be considering instead? > > > > > > > > > > Regards, > > > > > > > > > > -Roberto > > > > > > > > > > -- > > > > > Roberto C. Sánchez > > > > > > > > -- > > > > Roberto C. Sánchez > > > > > > > > -- > > Roberto C. Sánchez > > http://people.connexer.com/~roberto > > http://www.connexer.com > > -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
