From: Junio C Hamano <hidden> Date: 2016-06-15 23:03:09
Torsten Bögershausen [off-list ref] writes:
On 12/01/2014 04:02 AM, Michael Blume wrote:
quoted
I have no idea whether this should concern anyone, but my mac build of git shows
CC imap-send.o
imap-send.c:183:36: warning: 'ERR_error_string' is deprecated: first
deprecated in OS X 10.7 [-Wdeprecated-declarations]
fprintf(stderr, "%s: %s\n", func,
ERR_error_string(ERR_get_error(), NULL));
^
[]
Isn't the warning a warning ;-)
I don't see this warnings because my openssl comes from
/opt/local/include (Mac ports)
Does anybody know which new functions exist in Mac OS X versions >= 10.7 ?
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? Specifically, the
log message for 4dcd7732 begins like so:
Makefile: add support for Apple CommonCrypto facility
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
From: Eric Sunshine <hidden> Date: 2016-06-15 23:03:10
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
Torsten Bögershausen [off-list ref] writes:
quoted
On 12/01/2014 04:02 AM, Michael Blume wrote:
quoted
I have no idea whether this should concern anyone, but my mac build of git shows
CC imap-send.o
imap-send.c:183:36: warning: 'ERR_error_string' is deprecated: first
deprecated in OS X 10.7 [-Wdeprecated-declarations]
fprintf(stderr, "%s: %s\n", func,
ERR_error_string(ERR_get_error(), NULL));
^
Isn't the warning a warning ;-)
I don't see this warnings because my openssl comes from
/opt/local/include (Mac ports)
Does anybody know which new functions exist in Mac OS X versions >= 10.7 ?
I have not been able to find suitable Mac OS X replacements (nor could
I when resubmitting David's series [1] to use CommonCrypto).
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? Specifically, the
log message for 4dcd7732 begins like so:
Makefile: add support for Apple CommonCrypto facility
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
From: Michael Blume <hidden> Date: 2016-06-15 23:03:10
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine [off-list ref] wrote:
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
Torsten Bögershausen [off-list ref] writes:
quoted
On 12/01/2014 04:02 AM, Michael Blume wrote:
quoted
I have no idea whether this should concern anyone, but my mac build of git shows
CC imap-send.o
imap-send.c:183:36: warning: 'ERR_error_string' is deprecated: first
deprecated in OS X 10.7 [-Wdeprecated-declarations]
fprintf(stderr, "%s: %s\n", func,
ERR_error_string(ERR_get_error(), NULL));
^
Isn't the warning a warning ;-)
I don't see this warnings because my openssl comes from
/opt/local/include (Mac ports)
Does anybody know which new functions exist in Mac OS X versions >= 10.7 ?
I have not been able to find suitable Mac OS X replacements (nor could
I when resubmitting David's series [1] to use CommonCrypto).
quoted
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? Specifically, the
log message for 4dcd7732 begins like so:
Makefile: add support for Apple CommonCrypto facility
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
Apologies, accidentally sent this from inbox the first time.
If there's actually no way to address this, is there a simple way to
silence deprecation warnings only in this file? I only ask because
overall the git build seems to be extremely quiet, and it seems
valuable to preserve that, so that warnings we want to act on stick
out.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:03:10
On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume [off-list ref] wrote:
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine [off-list ref] wrote:
quoted
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? [...]
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
If there's actually no way to address this, is there a simple way to
silence deprecation warnings only in this file? I only ask because
overall the git build seems to be extremely quiet, and it seems
valuable to preserve that, so that warnings we want to act on stick
out.
An individual developer can add '-Wno-deprecated-declarations' to
CFLAGS to suppress these warnings, however, that's pretty much a
sledge hammer which would impact deprecations from all included
headers, not just Apple's. For this reason, we probably wouldn't want
to make this the default.
The potentially lesser evil would be this small patch (minus Gmail
whitespace damage) which disables the deprecation warnings only for
Apple's headers:
----- >8 -----
It's still mildly heavy-handed, in that it could silence legitimate
Apple deprecations, but it does give us a clean build with little
fuss. An alternative would be to relegate these #defines to the Darwin
section of the Makefile if placing them in git-compat-util.h seems too
invasive.
Considering that Mac OS X is now at 10.10 and these deprecations
commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
still has not provided drop-in CommonCrypto equivalents, it seems
unlikely that they will do so any time soon. Consequently, suppressing
these otherwise unavoidable warnings may be the best we can do.
I'm willing to formalize and submit this as a proper patch if it's not
considered too disgusting by the powers-that-be.
From: David Aguilar <hidden> Date: 2016-06-15 23:03:10
On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote:
quoted hunk
On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume [off-list ref] wrote:
quoted
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine [off-list ref] wrote:
quoted
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? [...]
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
If there's actually no way to address this, is there a simple way to
silence deprecation warnings only in this file? I only ask because
overall the git build seems to be extremely quiet, and it seems
valuable to preserve that, so that warnings we want to act on stick
out.
An individual developer can add '-Wno-deprecated-declarations' to
CFLAGS to suppress these warnings, however, that's pretty much a
sledge hammer which would impact deprecations from all included
headers, not just Apple's. For this reason, we probably wouldn't want
to make this the default.
The potentially lesser evil would be this small patch (minus Gmail
whitespace damage) which disables the deprecation warnings only for
Apple's headers:
----- >8 -----
It's still mildly heavy-handed, in that it could silence legitimate
Apple deprecations, but it does give us a clean build with little
fuss. An alternative would be to relegate these #defines to the Darwin
section of the Makefile if placing them in git-compat-util.h seems too
invasive.
Considering that Mac OS X is now at 10.10 and these deprecations
commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
still has not provided drop-in CommonCrypto equivalents, it seems
unlikely that they will do so any time soon. Consequently, suppressing
these otherwise unavoidable warnings may be the best we can do.
I'm willing to formalize and submit this as a proper patch if it's not
considered too disgusting by the powers-that-be.
Tweaking those internal #defines can only come back to bite us
in the future when the functions are finally ripped out.
CommonCrypto seemed like a viable option at the time, but the
remaining deprecated functions don't have any replacements and
I wouldn't hold my breath waiting for CC to provide them.
It seems like a better approach might be something like [1].
I'd even suggest ripping out all of the commoncrypto stuff if it
makes the final curl-ified code easier to read.
libcurl 7.30.0 ships with OS X 10.9 (maybe even father back?)
so making imap-send default to using openssl for <= 10.8 and
curl for newer OS X seems like a good long-term solution.
[1] http://thread.gmane.org/gmane.comp.version-control.git/255171
--
David
On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote:
quoted
On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume [off-list ref] wrote:
quoted
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine [off-list ref] wrote:
quoted
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? [...]
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
If there's actually no way to address this, is there a simple way to
silence deprecation warnings only in this file? I only ask because
overall the git build seems to be extremely quiet, and it seems
valuable to preserve that, so that warnings we want to act on stick
out.
An individual developer can add '-Wno-deprecated-declarations' to
CFLAGS to suppress these warnings, however, that's pretty much a
sledge hammer which would impact deprecations from all included
headers, not just Apple's. For this reason, we probably wouldn't want
to make this the default.
The potentially lesser evil would be this small patch (minus Gmail
whitespace damage) which disables the deprecation warnings only for
Apple's headers:
----- >8 -----
It's still mildly heavy-handed, in that it could silence legitimate
Apple deprecations, but it does give us a clean build with little
fuss. An alternative would be to relegate these #defines to the Darwin
section of the Makefile if placing them in git-compat-util.h seems too
invasive.
Considering that Mac OS X is now at 10.10 and these deprecations
commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
still has not provided drop-in CommonCrypto equivalents, it seems
unlikely that they will do so any time soon. Consequently, suppressing
these otherwise unavoidable warnings may be the best we can do.
I'm willing to formalize and submit this as a proper patch if it's not
considered too disgusting by the powers-that-be.
Tweaking those internal #defines can only come back to bite us
in the future when the functions are finally ripped out.
CommonCrypto seemed like a viable option at the time, but the
remaining deprecated functions don't have any replacements and
I wouldn't hold my breath waiting for CC to provide them.
It seems like a better approach might be something like [1].
I'd even suggest ripping out all of the commoncrypto stuff if it
makes the final curl-ified code easier to read.
libcurl 7.30.0 ships with OS X 10.9 (maybe even father back?)
so making imap-send default to using openssl for <= 10.8 and
curl for newer OS X seems like a good long-term solution.
[1] http://thread.gmane.org/gmane.comp.version-control.git/255171
Yes, but this patch needs 7.34 :-(
7.30 (as shipped with Mac OS X 10.9) is missing the CURLOPT_LOGIN_OPTIONS
Try
rm imap-send.o
NO_GETTEXT=yes NO_DARWIN_PORTS=Yes USE_CURL_FOR_IMAP_SEND=yes make
imap-send.o
From: Eric Sunshine <hidden> Date: 2016-06-15 23:03:11
On Wed, Dec 3, 2014 at 5:04 AM, David Aguilar [off-list ref] wrote:
On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote:
quoted
The potentially lesser evil would be this small patch (minus Gmail
whitespace damage) which disables the deprecation warnings only for
Apple's headers:
----- >8 -----
Considering that Mac OS X is now at 10.10 and these deprecations
commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
still has not provided drop-in CommonCrypto equivalents, it seems
unlikely that they will do so any time soon. Consequently, suppressing
these otherwise unavoidable warnings may be the best we can do.
I'm willing to formalize and submit this as a proper patch if it's not
considered too disgusting by the powers-that-be.
Tweaking those internal #defines can only come back to bite us
in the future when the functions are finally ripped out.
If Apple ever does remove those deprecated functions, the build will
break badly regardless of whether or not the Apple-specific
deprecation warnings are suppressed. This patch does not make the
situation any worse, so I don't understand the argument.
If a full set of drop-in equivalents was available, on the other hand,
then your argument would make perfect sense, but it does not seem
apply to the current situation since there is no evidence that Apple
will be providing those replacements any time soon (or ever).
From: David Aguilar <hidden> Date: 2016-06-15 23:03:11
On Wed, Dec 03, 2014 at 01:54:51PM +0100, Torsten Bögershausen wrote:
On 12/03/2014 11:04 AM, David Aguilar wrote:
quoted
On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote:
quoted
On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume [off-list ref] wrote:
quoted
On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine [off-list ref] wrote:
quoted
On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support
added in 4dcd7732 (Makefile: add support for Apple CommonCrypto
facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC
deprecation warnings on Mac OS X, 2013-05-19)? [...]
In the Makefile we seem to have this:
# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
# and do not want to use Apple's CommonCrypto library. This allows you
# to provide your own OpenSSL library, for example from MacPorts.
which makes it sound like using APPLE_COMMON_CRYPTO is the default
for Mac. Perhaps those who do want to use CommonCrypto to avoid
warnings should not define that macro?
It's been a long time [1] since I looked at it, but I believe that
David's CommonCrypto patch series only replaced OpenSSL calls for
which Apple had provided CommonCrypto replacements. If my memory is
correct, there were still plenty of OpenSSL deprecations warnings
remaining after his patches (the warnings which started this thread)
even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches
reduced the number of warnings but did not fully eliminate them.
Checking again, it still seems to be the case that Apple neglects to
provide CommonCrypto replacements for these OpenSSL functions which
Apple itself deprecated.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833
If there's actually no way to address this, is there a simple way to
silence deprecation warnings only in this file? I only ask because
overall the git build seems to be extremely quiet, and it seems
valuable to preserve that, so that warnings we want to act on stick
out.
An individual developer can add '-Wno-deprecated-declarations' to
CFLAGS to suppress these warnings, however, that's pretty much a
sledge hammer which would impact deprecations from all included
headers, not just Apple's. For this reason, we probably wouldn't want
to make this the default.
The potentially lesser evil would be this small patch (minus Gmail
whitespace damage) which disables the deprecation warnings only for
Apple's headers:
----- >8 -----
It's still mildly heavy-handed, in that it could silence legitimate
Apple deprecations, but it does give us a clean build with little
fuss. An alternative would be to relegate these #defines to the Darwin
section of the Makefile if placing them in git-compat-util.h seems too
invasive.
Considering that Mac OS X is now at 10.10 and these deprecations
commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple
still has not provided drop-in CommonCrypto equivalents, it seems
unlikely that they will do so any time soon. Consequently, suppressing
these otherwise unavoidable warnings may be the best we can do.
I'm willing to formalize and submit this as a proper patch if it's not
considered too disgusting by the powers-that-be.
Yes, but this patch needs 7.34 :-(
7.30 (as shipped with Mac OS X 10.9) is missing the CURLOPT_LOGIN_OPTIONS
Try
rm imap-send.o
NO_GETTEXT=yes NO_DARWIN_PORTS=Yes USE_CURL_FOR_IMAP_SEND=yes make
imap-send.o
It looks like 10.10 Yosemite has curl 7.37.1 [1], so maybe it's
better there (I can't verify myself).
Silencing the warnings is a sensible thing to do for older
versions since it looks like there's a smooth upgrade path
via the curl patches.
My original caution was that not having the warnings would make
us forget that the issue existed, but (warning) silence is golden.
[1] http://curl.haxx.se/mail/archive-2014-10/0053.html
--
David