and Libre Office?
is it also affected?
Apache OpenOffice (AOO) is currently vulnerable to a remote code execution vulnerability and while the app's source code has been patched, the fix has only been made available as beta software and awaits an official release. That means that most people running the open source office suite, which has been downloaded hundreds of …
I am not an expert in C++ or familiar with LibreOffice code base but looks like a no to me. The code is about the same between OO and LO, but looks like the maintainers at LO patched out this issue at the beginning of 2020.
https://github.com/LibreOffice/core/commit/aef7feb3e695ecf6d411f0777196dcc4281e201a
https://github.com/LibreOffice/core/blob/47a8a65022e3fd7624c95d0341b4809aad11fddb/connectivity/source/drivers/dbase/DTable.cxx#L850
The reason that I still use AOO is because Libre Office still doesn't work with my scanner from Canon !
With Microsoft and Libre Orifice refusing the play nicely with printers .......... there isn't a lot of choice left is there ?
Libre Orifice has other issues which have never been fixed and which I am fed up moaning about.
They all need to get a fucking life.........
ALF
When I was a kid, the size of structures changed all the time. Maybe you're writing library version 3.0 but you know somebody's going to compile against 1.0, 2.0, 4.0, etc. where the size of things has changed. Fields get added. Integers change size. You had to pay attention to size fields or your code crashed.
Of course there was no Internet back then to provide instant updates. You typed in the hex code patches from a magazine because the planet was colder, bits were much heavier, and there were a million holders for disks on a desk but zero for carrying them through the snow of the constant California Bay Area blizzards. Nobody would even write a 161 MB word processor because, obviously, nobody was strong enough to carry that many bits in a backpack.
" the .dbf file format can use one of two values in its header – fieldLength or fieldType – to determine the buffer size of a database record"
Sounds like while coding someone failed to notice that a suitable variable had already been made available and duplicated it. There was a conceptually similar c*ckup by someone at MS a few years back, where someone created a function that required as a parameter a pointer to another function. Someone called the first function, passing a pointer to the pointer to the second function.
Typically this comes down to rushing jobs without application of sufficient attention. I encounter it all the time when developers are working under pressure.
Why doesn't the Apache Foundation simply merge OpenOffice with LibreOffice? Is there some sort of contractual obligation between Apache and Oracle over the use of the trademark name which prohibits them from merging with LibreOffice?
OpenOffice is dying a slow death, but still holds the more palatable name.
> Why doesn't the Apache Foundation simply merge OpenOffice with LibreOffice?
LibreOffice is under control of the document foundation. So how should one merge single handed into the others realm? Both would need to agree on conditions pf a merge. Currently despite various tries there is no agreement. I think to both projects a merge is not the most important thing.
> Is there some sort of contractual obligation between Apache and Oracle over the use of the trademark name which prohibits them from merging with LibreOffice?
No. Oracle is out of the game for over 8 years. It is ridiculous that anyone believes that Oracle has any interest in any Office Product today. They need to earn money, and if you look at LibreOffice it is a really hard business. The competition is hard, really hard.
I believe you're wrong. IIRC has added contractual side-letters that the Apache Foundation doesn't merge with LibreOffice (or any other fork of OpenOffice).
I also believe they still hold the actual OpenOffice trademarks, but have leased them to the Apache Foundation at no cost.
I'd say it depends how OO determines filetype once the OS has invoked it with a file, and hence determines which code to parse the file with. If it's "dumb", it'll just look at the OS/FS filename extension ; if it's "smart", it'll ignore the filename and read the file contents to determine its type, then run the appropriate code.
In the former case, you're correct.
In the latter case, a dodgy.dbf could be renamed dodgy.xls and ... gotcha.
The whole concept of using the extension as anything more than a hint about how a file should be processed was broken from the beginning.
I guess it dates back to 8 or 16 bit computers, when doing sanity checking of the format of a file cost significant amounts of code when memory space issues were really a thing.
I get so annoyed when I move a file to a Windows system, and I have to actually rename a file, or jump through hoops just to get it opened in the application I want it opened in (particularly things like xml files where I want to open them using notepad or another plain text processor).