Java's implementation of ZIP format includes some vulnerabilities which must be corrected in all tools implementing creation or decompression of ZIP files. Since our implementation of MED format is one of them, it is concerned and must be corrected.
The correction was sent by a student to the core team of OmegaT, which decided to use it as a pretext to completely remove MED format, considering that even its creator does not support it anymore. However, I want in the future to use MED as a sample for a more generic support of ZIP archives, which I call package plugins, reason why I would have preferred not to remove it. That is the reason why I decided to apply the correction in DGT-OmegaT. This correction will also be used in future implementation of package plugins.
During a long time OmegaT was using own segmentation format. DGT-OmegaT migrated to standard SRX since version 2, but the core team applied my patches only recently, with the consequence that lot of users still have files in the old format, either globally or in their projects, making difficult to completely remove the support.
However support of this old format was based on an old serialization library which had a vulnerability. We had a long discussion with Hiroshi and found various solutions. My solution in DGT-OmegaT is a little bit different from what is in core OmegaT 6.x (not to criticize but because I wanted to test something else), but in both cases the vulnerability is now corrected.
Actually, when multiple versions of a plugin are present in the classpath, the first which appears wins, even if this is not the most recent one.
Core OmegaT implemented a correction for this based on informations present in the manifest. However, these extensions in the manifest were implemented in OmegaT 5, long time after the version 3.6 used to build DGT-OmegaT.
Maybe in the future I will also add these extensions, but for the moment, I implement a solution based on recognition of the file name: if two plugins are named XXX-2.0.jar and XXX-2.1.jar, we will consider that these are two versions of plugin XXX and 2.1 is the most recent version.
That can be improved in the future but at least it seems correct. However this remains potential source of bugs, because of that it is not in the STABLE version.
Add new comment