On 24 Jul, Andrea Pescetti wrote: > While the severity of the security bug we disclosed > http://www.openoffice.org/security/cves/CVE-2016-1513.html is not > particularly high (it is classified as "Medium" with no known exploits > and anti-virus software can detect malicious documents), we should > release an update incorporating the -already tested- patch we disclosed > in the announcement. > > I assume we will want to keep the effort minimal. > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used for > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > reference version. > > 2) We do not make any other changes to the AOO410 branch. This is really > meant to be a minimal update. Even the version number in the source > package will remain 4.1.2. > > 3) We tag the release as AOO4121 and build the corresponding source > package, which will have 4.1.2.1 in its name (I mean the filename, > nowhere else). > > 4) We don't prepare full end-user release binaries but we do supply > repaired libraries for power users - remember the circumstances above. > The bugfix modifies one library file, and we have binaries ready for > several platforms already. > > 5) We vote on the source and possibly binaries. We advertise the > availability of the new packages on our website, but we don't send out > update notifications and we don't put the files on SourceForge. > > Does this look OK?
Not being able to tell at a glance whether a copy of AOO has been fixed or not is bad. A while back Samsung fixed a hard drive firmware bug that could cause data loss, but didn't change the firmware version number. It was impossible to discern whether a drive had the buggy or fixed firmware with smartctl or by looking at boot messages. I ended up putting stickers on drives after I updated the firmware, but there was still no way to survey all the drives to see if they were fixed once they were installed in boxes. At a minimum, we should publish the hash values of buggy and fixed versions of the library. That might not help someone who builds and installs from source since the build not be completely repeatable. For instance the library might contain a timestamp. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
