Created attachment 184463 [details]
Are these patches from upstream? If so, please add comments to the header of those patches referencing links to the upstream commits/bugs if that information is available
Note: The existing VuXML entry (for package: oniguruma5) will need to be updated to reflect which package version is/is-not vulnerable (ie: 5.9.6_p1, as provided in this patch)
(In reply to Kubilay Kocak from comment #1)
I modified the patch published by my hand and applied it to 5.9.6_p1.
I think there is also vulnerability in 5.9.6_p1 before patch preparation, but it is not yet investigated.
I do not have the environment to test a series of vulnerabilities.
Been watching since the oniguruma5 vulnerability was posted. There is no sign of upgrade maintenance of oniguruma5.
Would it make more sense to change dependencies to oniguruma6, which already has been patched?
(In reply to dnewman from comment #3)
I am not sure if the change is appropriate for dependency on oniguruma6.
However, in my surroundings there is no problem with oniguruma6.
Therefore, I think that there is no effect on the change itself.
The patch I submitted this time was made for hackers where dependency on oniguruma5 remains.
(In reply to takefu from comment #4)
OK, thanks. I'm OK with patching oniguruma5 as well, since other ports/packages may depend on it.
In comment 1 on this thread, Kubilay Kocak asked for some revisions to the patch before proceeding. Are those changes you are able to make? Many thanks!
(In reply to dnewman from comment #5)
Those modifications are just referencing the github diffs linked by takefu in the patch files.
So, the top lines of patch-regexec.c should read:
Patches taken from
While the top lines from patch-regparse.c should read:
Patches taken from
With the port patched, there's only the matter of the VuXML entry left.
The problem that does not seem to be addressed is that oniguruma5 and 6 conflict with each other, as half the ports tree needs one and the other half the other, it is a real pain. What you should be working on is removing oniguruma5, not fixing it. (Or make it not conflict with oniguruma6)
(In reply to Mathieu Arnold from comment #7)
Actually, that's exactly what Yuri says, who's working on oniguruma 6:
> It's best to delete all oniguruma ports except the last, rename
> oniguruma6 to just oniguruma, and switch all dependencies to it.
> Multiple onigurumaN ports have no meaning whatsoever.
How do we move on from here to build consensus on this?
I have no idea. My point is that the current situation is bad.
There should either be only one oniguruma port, or if there are more than one, they should be able to live in harmony and not conflict.
It may be easier to have only one, yes.
(In reply to Mathieu Arnold from comment #9)
I concur -- this would be simpler with one current version of oniguruma. That is not the situation we have now.
See also these other efforts to move to oniguruma6:
While I very much appreciate takefu's effort to fix oniguruma5, I believe it would be cleaner to consolidate all this work and just support the (security-patched) release of oniguruma (currently version 6).
For a patch o5 -> o6 to mail/sylpheed see
There's one more port that depends on o5:
That port is marked BROKEN right now, so testing looks difficult.
The last port that required o5 was obsolete and deleted.
(In reply to Kurt Jaeger from comment #13)
From the linked ticket #220438 and the information on freshports.org, it seems that lang/mosh still depends on o5.
If and when that is fixed, I suggest to close this ticket and open one to delete the oniguruma5 ports entirely.
(In reply to Michael Bueker from comment #14)
Kurt has fixed the last remaining dependency. This report can now be closed, as the results of the discussion have been distilled into:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222867 to delete oniguruma4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222868 to delete oniguruma5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222869 to rename oniguruma6 to oniguruma
(In reply to Michael Bueker from comment #15)
MARKED AS SPAM