> From: "Matt Caswell" <matt@xxxxxxxxxxx> > Subject: Re: openssl 1.1.1 minor patches to build on SCO OpenServer 5.0.7 > > Hi Kevin, > > The patch in s_socket.c is likely to be acceptable. It looks reasonable > to me, it may well be useful on other systems and can probably be > described as a bug fix. > > The other changes require the new OPENSSL_SYS_SCO5 define and are > essentially adding support for a new platform into the codebase. > > We have a couple of policies which describe acceptable changes in this area. > > Our platform policy says: > > "Support for a new platform should only be added if it is being adopted > as a primary, secondary or community platform." > > https://www.openssl.org/policies/platformpolicy.html > > Essentially this means that someone has to volunteer to be a community > maintainer of the platform moving forwards, i.e. they are the contact > point for any bug fixes/problems that may arise on that platform. You > don't need to be a committer on the project to be a platform maintainer. Interestingly, openssl 1.1.1o already has support for this platform, but it is not up-to-date since I need these patches: For example: Configurations/10-main.conf # SCO 5 - Ben Laurie says the -O breaks the SCO cc. "sco5-cc" => { inherit_from => [ "BASE_unix", asm("x86_elf_asm") ], cc => "cc", cflags => "-belf", ex_libs => add("-lsocket -lnsl"), thread_scheme => "(unknown)", perlasm_scheme => "elf-1", dso_scheme => "dlfcn", shared_target => "svr3-shared", shared_cflag => "-Kpic", shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", }, "sco5-gcc" => { inherit_from => [ "BASE_unix", asm("x86_elf_asm") ], cc => "gcc", cflags => "-O3 -fomit-frame-pointer", ex_libs => add("-lsocket -lnsl"), bn_ops => "BN_LLONG", thread_scheme => "(unknown)", perlasm_scheme => "elf-1", dso_scheme => "dlfcn", shared_target => "svr3-shared", shared_cflag => "-fPIC", shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", }, I'm not trying to be argumentative here. It just seems it might be nice to give these trivial changes to the general public without having to make them find a fork of the entire openssl codebase, but if that doesn't work for the project, c'est la vie, as some might say. > You are proposing updates to an existing stable branch (1.1.1) - as > opposed to the latest dev branch (master). 1.1.1 also happens to be a > Long Term Support (LTS) release. In that case our Stable Release Updates > Policy applies which says this about new platforms: > > "The addition of new platforms to LTS branches is acceptable so long as > the required changes consist solely of additions to configuration." > > https://www.openssl.org/policies/technical/stable-release-updates.html > > In this case the changes are more than just configuration changes - they > actually require code changes. Therefore they will not be acceptable on > the 1.1.1 branch. This is interesting, and I suppose subject to interpretation differences. My patches entirely involve configuration changes. I.e. They ONLY affect pre-processor directives. In my opinion, pre-processor directives are not code. I suppose this response means the project interprets code as source code files? If so, then a clarification of terms in the documents linked might be in order. > If the changes were only on the master branch (and therefore the stable > release updates policy does not apply) then the changes are likely to be > acceptable assuming that there is a volunteer to be the community > maintainer. That's all subject to the standard PR review process of course. > > > Matt As it turns out, I had incorrectly assumed that building 3.0.3 might be out-of-reach, but it is not. The patches for 1.1.1o generally apply to 3.0.3 unmodified, and one other patch is a simple typedef change to match system headers. I have since resolved the entropy issue by realizing that the Configure switch --with-rand-seed=egd is sufficient to fix it. As far as a community maintainership goes, in my current employment situation, it is in my interest to build openssl releases as they come out. As long as maintainership is primarily related to build issues, I don't really have a problem with doing this. The main concern I would have is that I do not have an in-depth knowledge of the openssl code-base, so if maintainership involves code issues that pretty much any platform might encounter because the code is the same for them, I cannot claim to commensurate experience along those lines. Interestingly, Xinuos' OpenServer 5 Definitive still supplies openssl-1.0.2, and they have modified their system headers to obviate the need for some ( maybe all) of these patches. I say some, because their release notes do not mention all. Frankly, I don't see a lot of folk building either 1.1.1o or 3.0.3 since Xinuos has not provided perl 5.10.1 and the required Test::Simple >= 0.96 perl module used for tests. I suppose that means that demand for these patches is low, so that could either be interpreted as indicating I could support requests for help, or that the changes are pointless (excepting the fact that the codebase already contains support for the platform). -- Kevin R. Bulgrien
