Closed f1-outsourcing closed 7 years ago
Hi @f1-outsourcing
If your installed version of OpenSSL is equal to or greater than the version specified by CalendarServer, we should not build OpenSSL. I see that you have version 1.0.1e installed (1.0.1e is ~4 years old), while CalendarServer specifies 1.0.2h. We probably should be even more strict about this, given the importance of having a TLS implementation that is free from known vulnerabilities, although doing that would be even more inconvenient for users. As I write this, the minimum OpenSSL version we require is around 9 months old, and there have been 3 releases in the 1.0.2 line after 'h'.
See https://github.com/apple/ccs-calendarserver/blob/master/bin/_build.sh#L511 for the implementation of the version check (which of course you are free to modify at your own risk ;)
Maybe you should change your avatar to a dumb frog?
AS I WROTE BEFORE
Furthermore i trust the people of RedHat more configuring and building openssl than you
And if you do reply do some research first! https://access.redhat.com/security/updates/backporting http://mirror.centos.org/centos/7/os/x86_64/Packages/
You know better than RedHat a 2billion US$ revenue, 10.000 employee company??? https://en.wikipedia.org/wiki/Red_Hat
Focus on what you are good at! It is for sure not system administration or anything related with the linux o.s.
Hi,
Thanks for clarifying your position. I am temporarily changing my avatar to a dumb frog at your request. Indeed I was not aware that RHEL backports fixes to older versions of OpenSSL while still maintaining the original version number (which kind of destroys the value of that version number). For RHEL users, that is probably a good tradeoff in exchange for the reduced churn associated with backported fixes, compared to always taking newer versions just to get security fixes.
Personally I would stop short of getting mad at somebody (who doesn't live on RHEL) for not having read the final section of RHEL's backporting doc to learn that the upstream version number cannot be relied upon to convey useful information in RHEL's packages. If that link had been included in your first message, this would have been a shorter thread. In our case, I don't believe we rely on any new OpenSSL features, but keep in mind that a version number check is commonly used to detect not only security patch level but also feature support - maybe not in the RHEL world, but certainly elsewhere.
In any case, your point is valid and we should probably stop building OpenSSL. I anticipate that we will take your suggestion of simply failing the build if OpenSSL is not detected, and maybe printing a warning if the upstream version is older than we hope for. I'll leave this thread open for now and expect to have this change tested and committed soon.
Finally, I surely don't claim to know more than RedHat about what's best for RHEL users, but just for the record, I do have several successful enterprise-scale deployments under my belt for a company quite a bit larger than RedHat.
@f1-outsourcing The bin/develop
, bin/run
, etc. scripts exist for the benefit of developers working on the software. They are not meant for deployment or creating distributions for others to use.
Perhaps you should do your own research first: https://github.com/apple/ccs-calendarserver/blob/master/bin/run#L20
If you don't want to have OpenSSL built for you, then build and/or install the dependencies yourself as needed and use setup.py
directly, like any python project.
Regardless, your comments indicate a remarkable lack of decorum. Please refrain from filing tickets here until you can figure out how to behave appropriately.
When i do a new install
git clone -b CalendarServer-9.0 https://github.com/apple/ccs-calendarserver.git calendarserver
It looks like it is downloading openssl and compiling it, while these are installed:
Linux calcard1 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux openssl-libs-1.0.1e-60.el7.x86_64 openssl-devel-1.0.1e-60.el7.x86_64 openssl-1.0.1e-60.el7.x86_64
I would recommend not building this from source at any time. It is the system administrators responsibility to update these accordingly. When you are doing this, this means the source needs to be build especially for the calendarserver while normally a rpm update would be sufficient. Furthermore i trust the people of RedHat more configuring and building openssl than you. Stick to core business, developing the calendarserver. Just fail the run/build, people should be able to install rpms.