> From: "Matt Caswell"
> 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
