Incomplete build on AIX

[aixtoolsgmailcom]

BPO	24046
Nosy	@malemburg, @pitrou, @giampaolo, @tiran, @alex, @dstufft, @kadler, @iritkatriel

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2022-01-23.18:34:02.660>
created_at = <Date 2015-04-24.02:54:41.736>
labels = ['extension-modules', 'build']
title = 'Incomplete build on AIX'
updated_at = <Date 2022-01-23.18:34:02.659>
user = 'https://bugs.python.org/aixtoolsgmailcom'

bugs.python.org fields:

activity = <Date 2022-01-23.18:34:02.659>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-23.18:34:02.660>
closer = 'iritkatriel'
components = ['Extension Modules']
creation = <Date 2015-04-24.02:54:41.736>
creator = 'aixtools@gmail.com'
dependencies = []
files = []
hgrepos = []
issue_num = 24046
keywords = []
message_count = 5.0
messages = ['241908', '241921', '248764', '380949', '411395']
nosy_count = 12.0
nosy_names = ['lemburg', 'janssen', 'pitrou', 'giampaolo.rodola', 'christian.heimes', 'alex', 'dstufft', 'David.Edelsohn', 'aixtools@gmail.com', 'trex58', 'kadler', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue24046'
versions = ['Python 2.7']

[aixtoolsgmailcom]

Actually, I have been building and using my builds of Python, when needed for ./configure requirements for a long time. In short, it is quite nice that make "completes" even when there are missing and/or failed modules.

I have just resolved the problem with ctypes not building (see https://bugs.python.org/issue6006) and that got me started to research others.

Failed to build these modules:
_elementtree _sqlite3 _ssl
bz2 pyexpat

While there are several - I am looking first at ssl.

My first attempt comes up with some failed defines - probably because the latest openssl provided by IBM is openssl-1.0.0 and openssl-1.0.1 is needed.

Rather than wait for that to happen I decided to experiment with LibreSSL. If you are not familiar with LibreSSL - I shall be quick - openbsd (who also maintains openssh) has been cutting out insecure and/or superfluous code.

One of the more insecure (because it can be a predictable source of enthropy) is RAND_egd() - so it is unavoidable that this occurs:

ld: 0711-317 ERROR: Undefined symbol: .RAND_egd

After patching _ssl.c to this:
--- _ssl.c.orig 2014-06-30 02:05:42 +0000
+++ _ssl.c      2015-04-24 02:47:00 +0000
@@ -1604,6 +1604,7 @@
 static PyObject *
 PySSL_RAND_egd(PyObject *self, PyObject *arg)
 {
+#ifndef LIBRESSL_VERSION_NUMBER
     int bytes;
 
     if (!PyString_Check(arg))
@@ -1618,6 +1619,12 @@
         return NULL;
     }
     return PyInt_FromLong(bytes);
+#else
+        PyErr_SetString(PySSLErrorObject,
+                        "external EGD connection not allowed when using LibreSSL:"
+                        "no data to seed the PRNG via PySSL_RAND_egd");
+        return NULL;
+#endif
 }
 
 PyDoc_STRVAR(PySSL_RAND_egd_doc,

The end result is:
Failed to build these modules:
_elementtree _sqlite3 bz2
pyexpat

In short, you can get ahead of the curve by depreciating/removing PySSL_RAND_egd() because any code that uses it may be receiving predictable input and thereafter everything may be predictable.

If you do not believe openbsd (or me) - just read the code. It calls anything configured (handy when /dev/urandom was hard to find anno 1999) but these days a backdoor waiting to be opened.

p.s. As I get time I shall continue with the other modules that do not build - just let me know if you prefer that I continue posting in this "issue", or make new one(s) for each module as I find a solution.

[malemburg]

On 24.04.2015 04:54, aixtools wrote:

Rather than wait for that to happen I decided to experiment with LibreSSL. If you are not familiar with LibreSSL - I shall be quick - openbsd (who also maintains openssh) has been cutting out insecure and/or superfluous code.

One of the more insecure (because it can be a predictable source of enthropy) is RAND_egd() - so it is unavoidable that this occurs:

ld: 0711-317 ERROR: Undefined symbol: .RAND_egd

After patching _ssl.c to this:
--- _ssl.c.orig 2014-06-30 02:05:42 +0000
+++ _ssl.c 2015-04-24 02:47:00 +0000
@@ -1604,6 +1604,7 @@
static PyObject *
PySSL_RAND_egd(PyObject *self, PyObject *arg)
{
+#ifndef LIBRESSL_VERSION_NUMBER
int bytes;

 if (!PyString_Check(arg))

@@ -1618,6 +1619,12 @@
return NULL;
}
return PyInt_FromLong(bytes);
+#else

•    PyErr_SetString(PySSLErrorObject,
  

•                    "external EGD connection not allowed when using LibreSSL:"
  

•                    "no data to seed the PRNG via PySSL_RAND_egd");
  

•    return NULL;
  

+#endif
}

PyDoc_STRVAR(PySSL_RAND_egd_doc,

The end result is:
Failed to build these modules:
_elementtree _sqlite3 bz2
pyexpat

In short, you can get ahead of the curve by depreciating/removing PySSL_RAND_egd() because any code that uses it may be receiving predictable input and thereafter everything may be predictable.

If you do not believe openbsd (or me) - just read the code. It calls anything configured (handy when /dev/urandom was hard to find anno 1999) but these days a backdoor waiting to be opened.

p.s. As I get time I shall continue with the other modules that do not build - just let me know if you prefer that I continue posting in this "issue", or make new one(s) for each module as I find a solution.

Please post this in a new issue, since it's really a separate one.

Thanks,

Marc-Andre Lemburg
eGenix.com

[trex58]

Fresh openssl versions are now available for AIX: 1.0.1p and 1.0.2d .
See: http://www.bullfreeware.com/search.php?package=openssl

[kadler]

Looks like RAND_egd was made optional in https://bugs.python.org/issue21356

Can this issue be closed?

[iritkatriel]

2.7 is no longer maintained. Please create new issues for build problems on current versions (>= 3.9).