Installing and browsing freenet, the majority of requests fail with "Error detected parsing the header". After getting help on the freenet irc channel, I've narrowed it down to the dev-java/commons-compress library. Downgrading to 1.5, freenet works. Upgrading again to 1.6, it fails again. Freenet currently is only officially tested with commons-compress 1.1, though I don't think that version is necessary, or desirable because a) it works with 1.5, and 1.4.1 was a security release.
Having the same problem and cannot downgrade, because dev-java/commons-compress-1.10 is the one and only version in portage. I guess this should be reported upstream at Freenet because they use a really old version of commons-compress.
>Having the same problem and cannot downgrade, because dev-java/commons-compress-1.10 is the one and only version in portage. I believe it was as simple as "cp commons-compress-1.10.ebuild commons-compress-1.5.ebuild && repoman manifest" for me to work around this issue. > I guess this should be reported upstream at Freenet because they use a really old version of commons-compress. I don't know if it's considered "reported upstream" or not, but before I reported this b.g.o issue, I asked upstream about the issue here: https://freenetproject.tenderapp.com/discussions/problems/57-all-page-loads-fail-with-error-detected-parsing-the-header
(In reply to Claes from comment #2) > >Having the same problem and cannot downgrade, because dev-java/commons-compress-1.10 is the one and only version in portage. > > I believe it was as simple as "cp commons-compress-1.10.ebuild > commons-compress-1.5.ebuild && repoman manifest" for me to work around this > issue. That did not work because commons-compress-1.5-src.tar.gz cannot be downloaded then, but I found it here: https://archive.apache.org/dist/commons/compress/source/commons-compress-1.5-src.tar.gz Afterwards, the error disappears. > > I guess this should be reported upstream at Freenet because they use a really old version of commons-compress. > > I don't know if it's considered "reported upstream" or not, but before I > reported this b.g.o issue, I asked upstream about the issue here: > https://freenetproject.tenderapp.com/discussions/problems/57-all-page-loads- > fail-with-error-detected-parsing-the-header I really think upstream (freenet project) should act, because it use commons-compress 1.0 (if I am not mistaking) and this has known security issues, as you pointed out. Sticking with an very outdated version of a library cannot be a solution. Especially if you have other software that depends on newer releases.
I created an upstream report: https://bugs.freenetproject.org/view.php?id=6921
I have this bug too.
Confirmed still an issue.
*** Bug 606384 has been marked as a duplicate of this bug. ***
I am still not able to reproduce the issue and i also have commons-compress-1.10 installed. It seems like there are more conditions to meet (maybe something like: happens only for older/newer freesites, happens only with a certain jvm or something else). So unless i can reproduce this myself locally, not much i can do here.
It's still an issue for me. Even with commons-compress-1.10, 1.12, 1.13. (After version 1.14, there seem to be new dependencies that are required... compilation is failing for me with errors mentioning the Brotli and Zstandard libraries. 1.13 and newer also need to be compiled with -source 1.7 ... I got it to work with "export JAVA_PKG_WANT_TARGET=1.7") In the meantime, can we get 1.5 back into portage, in case that fixes the issue for some of us? It's very weird how it's only affecting some of us. Thomas, are you able to see Toad's freesite? That is an example of one that's failing for me. The "freesite howto" freesite is one of the few that seem to work for me. I updated upstream about this -- hopefully they'll have more insight.
I came up with two potential fixes to this, and mentioned them in the upstream bug report. One involves a quick patch to freenet's ArchiveManager.java file, the other involves a quick patch to all the commons-compress TarArchiveInputStream.java versions > 1.5. I still haven't figured out exactly why it's only affecting some of us. I've narrowed down the issue to something to do with IOUtils.skip (which was introduced in 1.6), and/or how that interacts with Freenet's buckets/inputstreams.
I think this was an even lower-level bug in my openjdk's vm. Although I had this bug with openjdk version "1.8.0_151", I no longer have it with version "1.8.0_161". Can anyone verify this?
Nm, this bug still exists even with the newer jdk. ( https://issues.apache.org/jira/browse/COMPRESS-449 )
Any update on this one?
It's working/fixed in the current versions of freenet (1484) and dev-java/commons-compress (1.10) in portage. Even though the official fix was only introduced upstream into commons-compress 1.17, freenet 1484 already has the new wrapper class in src/freenet/support/io/SkipShieldingInputStream.java, so no need for the newer dependency.
Thanks for the reply. Closing this bug as fixed.
