activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <>
Subject Re: [DISCUSS] Make fixes to CVEs more transparent
Date Thu, 11 May 2017 02:04:26 GMT
I think more transparency is fine as long as the CVE has already been
announced.  It makes sense to officially link the Jira and any commits that
fix the issue so people have that information.

In fact, linking the commit to the CVE is the actual recommended policy if
using subversion. The security steps documented here in step 16 say to amend the
commit that fixes the issue with the CVE number.  We of course can't do
this since we use Git and it would screw up the history but we could at
least make it easier for people to find the commit and Jira that matches
the CVE by listing it somewhere.

On Wed, May 10, 2017 at 4:29 AM, Christian Schneider <> wrote:

> We currently list CVEs at
> urity-advisories.html which is already a good thing.
> I think we are missing an important link though. We should also link the
> jira issue that fixes the CVE. This allows users to see exactly what was
> fixed and in which versions it was fixed. It also allows users to create
> their own patched versions if they can not switch to a new ActiveMQ version.
> For example in this CVE :
> -7559-announcement.txt?version=1&modificationDate=1493024710000&api=v2
> We see that the issue is fixed in ActiveMQ 5.14.5 but probably it was also
> backported to other versions. The jira and commit would make that more
> transparent.
> I stumbled over this issue when I was asked to backport a fix to an
> ActiveMQ 5.11.3 version and the issue came up if we could also apply the
> CVEs for the custom version.
> Of course one issue with more transparency is that hackers have an easier
> time to attack unpatched versions as they get more informations.. but
> honestly I think hackers will find this information anyway if they really
> want.
> What do you think?
> Christian
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message