Waiting for AOO
The project did manage to get the 4.1.3 bug-fix release — its first in nearly one year — out in October, but has not made any releases since. At the time, the plan was to move quickly to release 4.1.4, followed by a 4.2.0 feature release shortly thereafter. The 4.1.4 branch was created on October 11, shortly before the 4.1.3 release. Since then, it has accumulated 24 changesets (which map to about 30 changes in the original SVN repository). There have only been four commits to this branch since early February, at least one of which includes security fixes.
In September, Ariel Constenla-Haile volunteered
to be the manager for the 4.1.4 release, but then vanished without a trace
in February. In May, Jim Jagielski asserted that he was now the release manager,
and said that "we should shoot for a release next week at the
latest
". Jagielski was last seen on the development mailing list on
June 19, though he made a commit to the 4.1.4 branch on
August 1. All told, it would appear that the project is having
significant trouble putting together a 30-patch minor release.
What about 4.2.0? There are currently 1,174 changesets by about 25 developers that have been merged to the AOO trunk since the 4.1.0 release. Of those, 294 (from a total of ten developers) have been merged since the beginning of September 2016. Three of those developers (Damjan Jovanovic, Matthias Seidel, and Pedro Giffuni) account for 85% of the changes made in that time. Giffuni expressed his disappointment at the lack of progress in March, and has committed no changes since.
In other words, the project does have a bit of feature work stored on its trunk representing development done since the 4.1 release in April 2014, but that work does not appear to have much prospect of finding its way into an official release anytime soon. For all practical purposes, only two developers are doing any sort of regular work on the code.
Last year, the Apache board was evidently concerned about AOO's ability to sustain itself and keep up with responsibilities like security releases. So it is interesting to see how AOO is representing itself to the board. The April report is the latest available as of this writing; with regard to development, the report says:
Next Steps: Improving the mentoring of newcomers and expanding the capacity to address major issues as part of new releases.
Signs of progress on the "next steps" have been fairly scarce in the intervening months. With regard to security issues:
Again, if that analysis is happening, it's not evident on the public mailing list.
The LibreOffice project reported
in May on its use of Google's OSS-Fuzz to identify (and fix) possible security
issues. The LibreOffice code base has moved on significantly since the
fork, and the LibreOffice developers have doubtless been quite productive
in the introduction of their own security bugs. But it stands to
reason that some of those bugs may have also existed in AOO. If so, they
are still there. It is also interesting to note that the January board
report stated that "there will be at least one security fix in the
under-development release 4.1.4
". One has to look at the
Wayback Machine to see it, though; that text has been removed from the
official version on the Apache site.
All of this might be irrelevant except for one other little bit from the
report to the Apache board: "As of 2017-Apr-12 we have more than
214,000,000 million [sic] downloads and it is still at a consistent rate with
~100,000 downloads in average per day
". That is 100,000 people
every day who are downloading the output of a project that clearly lacks
the development
capacity to get important bug fixes out to users, much less understand and
improve the entirety of such a massive body of code.
In the wake of the 2016 discussion, the project deserved another chance to
show that it could reinvigorate itself. Nearly one year later, it seems
clear that AOO lacks the developer interest needed for it to be a
sustainable project. Sooner or
later, the Apache board is going to have to face up to that fact.
Posted Aug 2, 2017 16:03 UTC (Wed)
by vbabka (subscriber, #91706)
[Link] (3 responses)
Posted Aug 2, 2017 22:35 UTC (Wed)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Aug 6, 2017 20:31 UTC (Sun)
by cornelio (guest, #117499)
[Link] (1 responses)
LO and AOO are for all purposes different projects and the Apache Software Foundation can't make any claims on the quality or suitability of external projects. What could happen, if they don't release new code, is that the project would be moved to the "Attic" in which case the software would still be made available with a note that it is being EOL'ed.
Posted Aug 6, 2017 23:39 UTC (Sun)
by donbarry (guest, #10485)
[Link]
Posted Aug 2, 2017 16:03 UTC (Wed)
by kiko (subscriber, #69905)
[Link] (3 responses)
Posted Aug 2, 2017 16:34 UTC (Wed)
by micka (subscriber, #38720)
[Link] (1 responses)
Posted Aug 2, 2017 17:34 UTC (Wed)
by dark_knight (subscriber, #47846)
[Link]
Being pedantic, "214,000,000 million" is incorrect either way.
Posted Aug 4, 2017 15:24 UTC (Fri)
by mauricio (guest, #6370)
[Link]
Posted Aug 2, 2017 17:07 UTC (Wed)
by smoogen (subscriber, #97)
[Link]
The usual way to really test that is by having programs which activate when the software is run and 'check updates' or some similar tool. The order of automatic update checks are usually 2-3 orders of magnitude smaller than the download counts show. I don't think either AOO or LOO have this though and a lot of people see that as spyware which I can understand.
Posted Aug 2, 2017 17:13 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (8 responses)
This itself is also not good. If you post "official" records but then quietly edit them over time, I have no choice but to assume bad faith in all the records I'm shown by you. Why should I believe anything Apache board members claim was "minuted" but which in fact it turns out they might have just edited into their records days, weeks or years later? One of the things I particularly watch for in modern news media (where no physical artefact captures whatever "mistakes" are published as once happened with newspapers) is whether when they inevitably correct a mistake they _acknowledge_ that or they instead just silently change things.
Example: https://www.vox.com/identities/2017/7/31/16068972/tradema... is a story about trademarking slurs and other marks or identifiers we'd maybe rather see less of. But originally someone (the author? a sub-editor? it's not usual to tell the audience in the news media) decided on a headline about copyright. Except copyright is entirely separate law - even if I have met supposed "IP lawyers" who didn't know that - and it would be ludicrous to try to claim "copyright" for the simple geometric figure of a swastika. Sure enough the headline was corrected. But far more importantly to me, the updated article _acknowledges_ that it was previously wrong.
Own your mistakes. This is (closer to LWN topicality) an important lesson for new programmers, especially people who are self taught or have never worked in a team before. If the reality is you pushed out a release that doesn't even compile, and then you spotted the typo six minutes later, that's fine, that's what the git repo should show. Don't come to me asking if there's a way to change history so that it seems as if it didn't happen that way. How does that help anybody? Own the mistake. Say to yourself "I am human and I screw up sometimes" and remember that when you see somebody else screw up too.
And on the topic of this particular article you need to own bigger mistakes too. It doesn't matter if the Apache board genuinely believed in 2014 that this was a good idea, it should now be obvious to everyone that it wasn't. Board members allowing it to continue can't fall back to "Well we didn't know...", because they do now. Every day that they have the evidence in front of them that the project is failing and do nothing they're _culpable_ for that as members of the board. Daren't tell Jim he's wrong? Then you're in the wrong job, resign. Don't really have the time to spend on this stuff? Resign. If Apache is, as it has sometimes claimed, a vibrant community with plenty of people ready and willing to step forward then losing bad board members only strengthens Apache. If in fact the whole thing is rotten it's better to find out through a formal process (the whole board resigns and the organization ceases to exist) than a gradual drip-drip of rumours and insinuations.
Posted Aug 3, 2017 9:21 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (7 responses)
These are the changes:
I agree that this is telling. The minutes of meetings are supposed to be immutable!
Posted Aug 4, 2017 20:55 UTC (Fri)
by amk (subscriber, #19)
[Link] (1 responses)
Posted Aug 5, 2017 7:48 UTC (Sat)
by smurf (subscriber, #17840)
[Link]
Perhaps somebody got cold feet because of liability issues – if you knowingly distribute defective software, your unreadably-large legal disclaimer may not be able to bail you out …
Did anybody ask the meeting's chair for comment?
Posted Aug 5, 2017 2:12 UTC (Sat)
by gdt (subscriber, #6284)
[Link] (1 responses)
If these minutes came to me for approval I too would have squashed "at least one security fix in the under-development-release". It's not the role of board minutes to notify clients of security issues; they are not a forum clients can be expected to monitor for this information. Due to an unfortunate operation of the law, board members often have only an "accept or reject item" option for altering board minutes, so I would have sadly asked for "reject" and perhaps asked the chair for more acuity from their staff when noting this topic in the future. I wouldn't read much into the deletion, beyond a board operating normally.
Posted Aug 7, 2017 13:03 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link]
But Apache policy is to only put up the report (from groups like AOO) when the minutes are approved. _Then_ after they'd been published (so that the Wayback Machine has a copy even, so we're not talking about 30 seconds) the minutes were altered. So either the originally published minutes aren't the ones agreed by the board, or these aren't, and I don't much care which because either way I can't trust their records.
It also doesn't achieve any supposed security goal, bad guys don't have to accept that you've rescinded your previous announcement and are now claiming not to have security problems, they can read the original version. It's the same mistake as when people figure that they'll "undo" the damage from publishing their private keys to github by asking github to purge the data. It's a Pandora's box, you can't unopen it, that's just not how information works. The only thing achieved was to mislead researchers foolish enough to believe the ASF about their own projects.
Posted Aug 10, 2017 10:00 UTC (Thu)
by moltonel (guest, #45207)
[Link] (2 responses)
I'm surprised we don't hear of more actively exploited AOO bugs, given that it has remained mostly static for years and must be a tempting target.
Posted Aug 10, 2017 10:12 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (1 responses)
Not really, as most people use LO these days – thus developing an exploit that doesn't affect the vast majority of users (I hope) isn't interesting.
Posted Aug 10, 2017 11:59 UTC (Thu)
by moltonel (guest, #45207)
[Link]
The Apache foundation at least belives that there is still a significant share of AOO users. We could argue about actual numbers, but it still looks sizable. And most importantly, I expect current AOO users to generally have poor security awareness and therefore be prime targets for malware-type attacks. Fewer but more attackable targets still qualifies as "tempting".
Posted Aug 2, 2017 17:26 UTC (Wed)
by luya (subscriber, #50741)
[Link]
Posted Aug 2, 2017 20:53 UTC (Wed)
by roc (subscriber, #30627)
[Link] (8 responses)
Then either AOO releases an update with fixes, improving things for their users, or they don't, putting even more pressure on the Apache board to do the right thing.
Posted Aug 2, 2017 22:43 UTC (Wed)
by rahvin (guest, #16953)
[Link] (2 responses)
This is literally the kind of thing that destroys brands as they are in effect deliberately providing software with known exploits with no acknowledgement of that. Posted Aug 3, 2017 11:26 UTC (Thu)
by mfrancis (subscriber, #14996)
[Link] (4 responses)
LO wins over users by behaving like a professional and competent project, and developers by being a genuinely friendly and accessible community to get involved in. The sort of publicity that would result from sticking an oar into this situation publicly just wouldn't be that useful or interesting on either front.
Posted Aug 3, 2017 11:47 UTC (Thu)
by bangert (subscriber, #28342)
[Link] (2 responses)
Posted Aug 3, 2017 16:37 UTC (Thu)
by dsommers (subscriber, #55274)
[Link]
Sad, but too often true :/
Posted Aug 7, 2017 19:32 UTC (Mon)
by chfisher (subscriber, #106449)
[Link]
Seems applicable here.
Posted Aug 3, 2017 11:52 UTC (Thu)
by roc (subscriber, #30627)
[Link]
Posted Aug 3, 2017 21:22 UTC (Thu)
by xtifr (guest, #143)
[Link] (7 responses)
I don't know if this means that they've simply decided LWN is simply a den of irredeemable evil, not worthy of their offers of salvation, or if they simply lack the manpower to even try to promote their project, or if they've just thrown in the towel, and are trying to find a face-saving way to admit it. In any case, it's an interesting development.
Posted Aug 3, 2017 22:46 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (6 responses)
Last year I had posted a SubscriberLink to a LWN article about AOO to HN; I'm doing it again right now, so if they read HN and my post reaches the front page there, we might be able to see them here again.
Posted Aug 3, 2017 23:53 UTC (Thu)
by k8to (guest, #15413)
[Link] (5 responses)
Posted Aug 4, 2017 0:17 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (1 responses)
It would have been better to post the link directly to their mailing list, but unfortunately doing so as a first-time poster would be treated as a provocation. HN is a neutral place.
Posted Aug 4, 2017 0:30 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Aug 4, 2017 0:34 UTC (Fri)
by corbet (editor, #1)
[Link] (2 responses)
Posted Aug 11, 2017 0:33 UTC (Fri)
by jtc (guest, #6246)
[Link]
Posted Aug 14, 2017 20:34 UTC (Mon)
by jepler (subscriber, #105975)
[Link] (1 responses)
Posted Aug 15, 2017 2:43 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
… which applies to every other AOO version.
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Own mistakes
Own mistakes
6. Committee Reports
Summary of Reports
The following reports required further discussion:
[…]
F. Apache Apex Project [Thomas Weise / Shane]
See Attachment F
- Marvin: possible public disclosure of security issue was not
- in the report
-
- Mark: the "worst" of the issues were resolved but minor
- security issues appear to be unresolved; the PMC has been
- unresponsive for three months
-
- @Shane: "encourage" the PMC to be responsive to security
- issues
-
[…]
RELEASES
========
The current release is Apache OpenOffice 4.1.3 and was published on
2016-Oct-12.
Apache OpenOffice 4.1.4 is planned for release in 2017 Q1 for further
-maintenance and available security fixes.
+maintenance.
Apache OpenOffice 4.2.0 is planned for this year - but without to name a
specific time frame - to include new features and bigger enhancements
-but of course more bugfixes and security fixes if needed.
+but of course more bug fixes.
[…]
A number of previously-active committers have returned to activity
as part of the response to the previous-quarter public discussion
of what AOO retirement would look like.
Next Steps: Improving the mentoring of newcomers and expanding the
capacity to address major issues as part of new releases.
-Handling of Security
---------------------
-There will be at least one security fix in the under-development
-release 4.1.4.
-
-
Branding
--------
[…]
Own mistakes
Own mistakes
Own mistakes
Own mistakes
Own mistakes
Own mistakes
Own mistakes
For those reasons, the Vancouver Public Library quietly switched from Apache OpenOffice to LibreOffice.
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
That is sensible. Here is the patch:Waiting for AOO
Seems like it would be a good thing for someone
at LibreOffice to run a set of theirLibreOffice's exploitable-bug testcases against AOO, report the failures to AOO, and notify the Apache board and the public that they have done so (not necessarily identifying specific bugs), noting that this would also be very easy for an attacker to do.
Then either AOO releases an update with fixes, improving things for their users, or they don't, putting even more pressure on the Apache board to do the right thing.
Talk, including mine, remains cheap.
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
Waiting for AOO
HN can drive a lot of traffic; a link that sits on the front page for a while can bring tens of thousands of non-subscribing readers to LWN. Experience suggests that some of them will subsequently choose to subscribe. I wouldn't want to see all of our subscriber content there, but an occasional link does us nothing but good as far as I can tell.
Subscriber links
Waiting for Godot
Waiting for AOO
Waiting for AOO