Hi Roberto, after talking to the PMC chair, I can give you three commit links.
https://github.com/apache/shiro/commit/042c59356cc6442345a9f935aed3e7603cb4dfad https://github.com/apache/shiro/commit/5b1add9a4c4ed046b52cf2132ed0f264a22caf1d https://github.com/apache/shiro/commit/1b9d8d99cd6d50d7114916508a13677a0fe6f345 I guess it is quite obvious what is inside these commits. Best regards, Ben Am So., 20. Dez. 2020 um 18:35 Uhr schrieb Roberto C. Sánchez < [email protected]>: > 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 >
