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.
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. I wonder: does your policy actually allow this? Best regards, Ben 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 >
