# python27: problem at packaging stage



## moosejaw (Apr 8, 2015)

Updating lang/python27 to the latest version (2.7.9_1, updated in the ports tree on Monday) yields the following error at the "package" step:


```
===>  Building package for python27-2.7.9_1
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_ssl.so: No such file or directory
*** Error code 1
```
The latest commit message mentions a change to SSL support:


```
Force a rebuild/upgrade to chase head r280306 which removed SSLv2 support.
This fixes head package users so they have working SSL support. There was
already a built-time fix for this.
```
Anyone else having this problem and/or have any pointers? Is this something that the port maintainer should be contacted about? This is a fairly important port, so if it's a problem with the port itself (rather than my machine) I imagine many people are encountering it.

Thanks in advance for any advice!


----------



## talsamon (Apr 8, 2015)

Compiles on my machine (10.1-RELEASE) fine. Try `cd /usr/ports/lang/python27` and `rm -rf *` and `portsnap extract lang/python27`. Or fetch a new portstree.


----------



## moosejaw (Apr 8, 2015)

Thanks for the replies. Tried re-extracting lang/python27 and recompiling, but still getting the same error. Hmm... (I'm on 10.1-RELEASE-p9 fwiw)


----------



## talsamon (Apr 8, 2015)

Something I can't understand: Freshports lists security/openssl as build and run dependency. But I have not installed security/openssl. (And it seems I have no problems).


----------



## talsamon (Apr 8, 2015)

Sorry, overlooked 
	
	



```
USE_OPENSSL=  yes
```
 in the Makefile.

(But I think - not sure - this calls OPENSSL_BASE and not OPENSSL_PORTS )


----------



## moosejaw (Apr 8, 2015)

Aha, this is in my /etc/make.conf:


```
WITH_OPENSSL_PORT=  yes
OPENSSL_PORT=  security/libressl
```
Perhaps there is a problem with compiling lang/python27 against security/libressl. When I initially installed python27, it was from packages. I don't have time to test this out now but will report back if I can confirm that switching to security/openssl (and/or `WITH_OPENSSL_PORT= no`) does the trick.

(Update: nope, still getting the same error with `WITH_OPENSSL_PORT= no` in /etc/make.conf.)


----------



## talsamon (Apr 8, 2015)

I have test it with security/openssl and security/libressl, without errors. In the moment no idea.


----------



## moosejaw (Apr 9, 2015)

Do you have `WITH_OPENSSL_PORT= yes` in /etc/make.conf? If not, you might be compiling python27 against the openssl in base.

As for me, I did a `portmaster -o security/openssl security/libressl`, rebuilt everything against openssl, and boom, it works, python27 packages up without a problem. Tried going back to libressl and the same problem recurred. Back again to openssl, and it works. So, at least on my box, it seems that the latest python27 has a problem compiling against libressl.

Thanks all for your thoughts/input.


----------



## protocelt (Apr 9, 2015)

Hi,

I believe there is some rough edges still being ironed out with regards to building ports against security/libressl. There is some information on this here if you haven't seen it already and specifically a PR 192511 that looks related to the issue in this thread that is open yet.


----------



## gessel (Feb 26, 2018)

I know this is a really old thread, but I'm having the same problem, and somewhat suddenly.  When I try to do a `# portmaster -Rafd` or a 

`# cd /usr/ports/devel/py-setuptools
# make FLAVOR=py27 install clean`

I get


```
running install_egg_info
Writing /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/Python-2.7.14-py2.7.egg-info
rm /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_sysconfigdata.py*
install  -m 0644 ./Misc/python.man  /var/ports/usr/ports/lang/python27/work/stage/usr/local/man/man1/python2.7.1
if test "xno" != "xno"  ; then  case no in  upgrade) ensurepip="--altinstall --upgrade --no-default-pip" ;;  install|*) ensurepip="--altinstall --no-default-pip" ;;  esac;  LD_LIBRARY_PATH=/var/ports/usr/ports/lang/python27/work/Python-2.7.14 ./python -E -m ensurepip  $ensurepip --root=/var/ports/usr/ports/lang/python27/work/stage/ ;
 fi
for i in /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/*.so; do  /usr/bin/strip $i; done
# Strip shared extensions
install  -m 0644 /var/ports/usr/ports/lang/python27/work/Python-2.7.14/Tools/gdb/libpython.py  /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/libpython2.7.so.1-gdb.py
====> Compressing man pages (compress-man)
===>>> Starting check for runtime dependencies
===>>> Gathering dependency list for lang/python27 from ports
===>>> Dependency check complete for lang/python27

===>>> All >> mysql56-client-5.6.39_1 >> devel/cmake >> devel/jsoncpp >> scons-3.0.1 >> devel/py-setuptools@py27 >> lang/python27 (49/64)

===>  Installing for python27-2.7.14_1
===>  Checking if python27 already installed
===>   Registering installation for python27-2.7.14_1 as automatic
pkg-static: Unable to access file /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_elementtree.so:No such file or directory
pkg-static: Unable to access file /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/pyexpat.so:No such file or directory
*** Error code 74

Stop.
make: stopped in /usr/ports/lang/python27
```

I've tried
`# portsclean -CDD
# cd /usr/ports && make clean
# portmaster -ty --clean-distfiles
# portmaster -RafFd`

And get the same error.  I'm at a bit of a loss as there are only two threads I can find with the same error message and the resolutions provided were a bit mysterious.  Also, I had lang/python27 installed with security/libressl on this box already.  The only major change was upgrading from lang/php56 to lang/php72 as I'm using the jail for www/nextcloud.


----------



## talsamon (Feb 26, 2018)

I am not clear if it is the same problem, but a similiar problem Is in work: PR 226135.


----------



## ShelLuser (Feb 26, 2018)

gessel said:


> I know this is a really old thread, but I'm having the same problem, and somewhat suddenly.


I'm quite convinced that this isn't related because why is your system messing around in /var/ports?

That seems a bit off to me.

(edit) You might want to try to see what happens if you keep /etc/make.conf out of the way for now. I can't help wonder if you're using a heavily customized setup, which could be a trigger for issues.


----------



## gessel (Feb 27, 2018)

I suppose heavily customized is subject to reasonable interpretation.  

`# ls /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/`

yields


```
Python-2.7.14-py2.7.egg-info    _curses_panel.so                _socket.so                      datetime.so                     readline.so
_bisect.so                      _elementtree_failed.so          _ssl.so                         dbm.so                          resource.so
_codecs_cn.so                   _functools.so                   _struct.so                      fcntl.so                        select.so
_codecs_hk.so                   _hashlib.so                     _testcapi.so                    future_builtins.so              strop.so
_codecs_iso2022.so              _heapq.so                       array.so                        grp.so                          syslog.so
_codecs_jp.so                   _hotshot.so                     audioop.so                      itertools.so                    termios.so
_codecs_kr.so                   _io.so                          binascii.so                     math.so                         time.so
_codecs_tw.so                   _json.so                        bsddb185.so                     mmap.so                         unicodedata.so
_collections.so                 _locale.so                      bz2.so                          nis.so                          zlib.so
_csv.so                         _lsprof.so                      cPickle.so                      operator.so
_ctypes.so                      _multibytecodec.so              cStringIO.so                    ossaudiodev.so
_ctypes_test.so                 _multiprocessing.so             cmath.so                        parser.so
_curses.so                      _random.so                      crypt.so                        pyexpat_failed.so
```

The two "missing" files are marked "_failed" which certainly explains why the installer can't find them.  The rest seems fine.


----------



## talsamon (Feb 27, 2018)

from the PR:
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_elementtree.so:No such file or directory
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/pyexpat.so:No such file or directory

Comment15 in the PR, includes a patch (I have not tested yet, but another user confirmed it works).


----------



## gessel (Feb 27, 2018)

Talsamon,
Patch applied, build complete.  Thank you very much.

I was in error to attach the problem to this thread, it is unrelated to _ssl.so.

Thank you for finding the PR.  I'll report build success there as well.


----------



## Toshiyuki Kamada (Apr 21, 2018)

I also had failed packaging stage with an error of missing _ssl.so.
I'm using security/libressl-devel for compiling ports.
Configuration of lang/python27 is a default (not changed anything with `make config`).

During the building progress, there are some *compile errors* in Modules/_ssl.c.

The patch (fix for libressl 2.7.1)
https://github.com/python/cpython/commit/edd541897b9c28ee0d0f0131746aa5f19665a104
resolved compiling errors even for libressl-2.7.2, and I could install python27 successfully.


----------



## gessel (Apr 30, 2018)

I just had massive problems with security/libressl 2.7.2 (and same with 2.7.2_1), does not seem to be building libssl.so.44 and libcrypto.so.42.  This breaks everything SSL.


----------



## tobik@ (Apr 30, 2018)

gessel said:


> I just had massive problems with security/libressl 2.7.2 (and same with 2.7.2_1), does not seem to be building libssl.so.44 and libcrypto.so.42.  This breaks everything SSL.


Yes, it's a major update to LibreSSL that is not ABI compatible with the old version. You _must_ rebuild everything that links with LibreSSL. There is no way around this. Synth or Poudriere do this automatically. Also see the /usr/ports/UPDATING entry for this:

```
20180428:
  AFFECTS: users of security/libressl
  AUTHOR: brnrd@FreeBSD.org

  The port has been updated to the latest stable version 2.7 of LibreSSL.
  The shared library versions of the libraries have been bumped.

  After upgrading, manually update all packages that depend on any of the
  libraries provided by LibreSSL (libssl, libcrypto and libtls) since the
  versions of these libraries have changed. Normally, you can obtain the
  list of dependent software by running the following command:

  # pkg info -r libressl

  Then you should rebuild all ports depending on libressl to avoid dangling
  shared library dependencies. Poudriere and pkg handle this correctly,
  portmaster and portupgrade users can use the following to rebuild all
  dependent ports.

  Portmaster users:
      portmaster -r libressl
  Portupgrade users:
      portupgrade -fr security/libressl
```


----------



## gessel (Apr 30, 2018)

Yah, and, just for anyone who comes across this:

It is not optional to`portmaster -r libressl`, indeed it must be the first thing done after updating ports tree.  If it isn't absolutely the first thing done, life gets very unhappy.  You cannot undo the damage by running `portmaster -r libressl` or even rebuildng all ports later.

Ports known to have issues (and the solutions where available) are at this link.  I would advise on not updating security/libressl to 2.7.2/2.7.2_1 if ports listed as having issues are installed.  Bernard is doing a great job of guiding the patch process, but there are still a lot of important ports (to me, anyway) that aren't patched in ports and at least one (databases/mysql56-server) that's quite alpha.


----------



## ShelLuser (Apr 30, 2018)

gessel said:


> It is not optional to`portmaster -r libressl`, indeed it must be the first thing done after updating ports tree.  If it isn't absolutely the first thing done, life gets very unhappy.  You cannot undo the damage by running `portmaster -r libressl` or even rebuildng all ports later.


No offense but I seriously doubt that.

In the end this is still a mere library which other ports use to build against. And those other ports don't include the actual building tools themselves. So it really doesn't matter when you're performing the rebuild. I can definitely agree that it's a better idea to start with such a commonly used libraries first, no arguments there, but the 'damage' can always be undone.

Might take a while longer, but it's not impossible. Heck, when all else fails you can always uninstall and re-install all ports. That won't affect your configuration and it would definitely fix things as well.


----------



## tsarya (Apr 30, 2018)

I am having an issue with security/py-certbot (FLAVOR=py36)
It depends on security/py-cryptography which fails to build against LibreSSL 2.7.2_1

```
root@test:/usr/ports/security/py-certbot # make FLAVOR=py36 install
...
48 warnings and 7 errors generated.
error: command 'cc' failed with exit status 1
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/security/py-cryptography
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/py-acme
*** Error code 1

Stop.
make: stopped in /usr/ports/security/py-certbot
```


----------



## gessel (Apr 30, 2018)

Try it, let me know if you find an easy way out.  I'm corresponding with Bernard, you can ask him too.  Maybe you can ask better questions than I have.

I've rebuilt all ports, as I pretty much do by default, twice now, after working through fails one by one.  now I'm manually applying patches.  So far the least critical, PR PR226903 for dns/bind-tools, has been successful so I'm optimistic I can get things running.  I'm a bit flumoxxed by www/apache24 not starting, the port builds fine on all jails as one would expect given the patch was integrated in 2.4.33 quite some time ago.  I still get:

# apachectl restart
Performing sanity check on apache24 configuration:
httpd: Syntax error on line 130 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_ssl.so into server: /usr/local/libexec/apache24/mod_ssl.so: Undefined symbol "OPENSSL_malloc_init"

All ports are up to date on this jail, everything security/py27-cryptography-2.1.4 builds successfully (working on that patch).  Once I have everything else and the somewhat alpha PR PR227178 integrated into databases/mysql56-server (on another jail, but definitely part of the Apache melange), I'll see what happens and if I can find any leads in https://github.com/apache/httpd/blob/2.4.33/modules/ssl/mod_ssl.c#L401

Certainly I'll check https://wiki.freebsd.org/LibreSSL/2.7 and make sure all the patches I need are actually in ports before I risk upgrading again.


----------



## gessel (Apr 30, 2018)

tsarya said:


> I am having an issue with security/py-certbot (FLAVOR=py36)
> It depends on security/py-cryptography which fails to build against LibreSSL 2.7.2_1



I'd be interested in your environment details and if you followed the advice in /usr/ports/UPDATING and did a  `portmaster -r libressl` before anything else, or if, like me, you followed a different protocol and ended up in trouble.

I haven't successfully patched security/py-cryptography and am not on 36 so haven't tried security/py-cryptography@py36, but this PR PR226906 applies and there is further information at https://wiki.freebsd.org/LibreSSL/2.7


----------



## tsarya (Apr 30, 2018)

I tried both:
1. On an existing installation where I have LibreSSL 2.6.4, ran `portmaster -r libressl` - no luck with security/py-certbot.
2. On a fresh installation, same thing, no luck with it, all other ports that I use build successfully - nginx, dovecot, opensmtpd, openntpd.

In both cases I see this during the build:

```
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2345:6: error: conflicting types for 'X509_get0_signature'
void X509_get0_signature(ASN1_BIT_STRING **psig, X509_ALGOR **palg,
     ^
/usr/local/include/openssl/x509.h:919:6: note: previous declaration is here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
     ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2479:7: error: redefinition of 'X509_VERIFY_PARAM_set1_host' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_host)(X509_VERIFY_PARAM *, const char *,
      ^
/usr/local/include/openssl/x509_vfy.h:564:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_host(X509_VERIFY_PARAM *param, const char *name,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2481:7: error: redefinition of 'X509_VERIFY_PARAM_set1_email' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_email)(X509_VERIFY_PARAM *, const char *,
      ^
/usr/local/include/openssl/x509_vfy.h:571:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_email(X509_VERIFY_PARAM *param,  const char *email,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2483:7: error: redefinition of 'X509_VERIFY_PARAM_set1_ip' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_ip)(X509_VERIFY_PARAM *, const unsigned char *,
      ^
/usr/local/include/openssl/x509_vfy.h:573:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param, const unsigned char *ip,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2485:7: error: redefinition of 'X509_VERIFY_PARAM_set1_ip_asc'
      as different kind of symbol
int (*X509_VERIFY_PARAM_set1_ip_asc)(X509_VERIFY_PARAM *, const char *) = NULL;
      ^
/usr/local/include/openssl/x509_vfy.h:575:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char *ipasc);
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2486:8: error: redefinition of 'X509_VERIFY_PARAM_set_hostflags'
      as different kind of symbol
void (*X509_VERIFY_PARAM_set_hostflags)(X509_VERIFY_PARAM *,
       ^
/usr/local/include/openssl/x509_vfy.h:568:6: note: previous definition is here
void X509_VERIFY_PARAM_set_hostflags(X509_VERIFY_PARAM *param,
     ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2525:7: error: conflicting types for 'X509_OBJECT_get0_X509'
X509 *X509_OBJECT_get0_X509(X509_OBJECT *x) {
```


----------



## gessel (Apr 30, 2018)

tsarya said:


> I tried both:
> 1. On an existing installation where I have LibreSSL 2.6.4, ran  portmaster -r libressl - no luck with security/py-certbot.



yeah, i did as well, but after a `portsnap fetch update` I ran a `portmaster -Rafd`, which failed at security/py-cryptography (I'm a bit chagrined to admit given the instructions in /usr/ports/UPDATING) with


```
/usr/local/include/openssl/x509.h:919:50: note: passing argument to parameter 'psig' here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
                                                 ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62265:27: warning: passing 'X509_ALGOR **' (aka 'struct X509_algor_st **') to parameter of type 'const X509_ALGOR **' (aka 'const struct X509_algor_st **')
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  X509_get0_signature(x0, x1, x2);
                          ^~
/usr/local/include/openssl/x509.h:920:24: note: passing argument to parameter 'palg' here
    const X509_ALGOR **palg, const X509 *x);
                       ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62317:25: warning: passing 'ASN1_OCTET_STRING **' (aka 'struct asn1_string_st **') to parameter of type 'const ASN1_BIT_STRING **'
      (aka 'const struct asn1_string_st **') discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  { X509_get0_signature(x0, x1, x2); }
                        ^~
/usr/local/include/openssl/x509.h:919:50: note: passing argument to parameter 'psig' here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
                                                 ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62317:29: warning: passing 'X509_ALGOR **' (aka 'struct X509_algor_st **') to parameter of type 'const X509_ALGOR **' (aka 'const struct X509_algor_st **')
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  { X509_get0_signature(x0, x1, x2); }
                            ^~
/usr/local/include/openssl/x509.h:920:24: note: passing argument to parameter 'palg' here
    const X509_ALGOR **palg, const X509 *x);
```
 
etc.  Same basic error.  If you ran anything before running`portmaster -r libressl`, your problem is the same as mine and PR PR226906 is (hopefully) both our solution.  If you updated your ports tree and first thing ran `portmaster -r libressl` and still had problems with security/py-cryptography@py36 as above, then it would seem to indicate that the instructions in /usr/ports/UPDATING aren't sufficient (maybe I'm a little less chagrined as I would normally share ShelLuser's skepticism).  However, in either case I think applying the patches in PR PR226906 is the way through.  I'll post if I'm successful.


----------



## gessel (May 1, 2018)

Hmm, so far no luck with security/py-cryptography.  I patched, got /usr/ports/security/py-cryptography/files/patch-src___cffi__src_openssl_x509.py ran `make clean` `make distclean` `make install` and got the same errors above.  Checking /var/ports/usr/ports/security/py-cryptography/work-py27/cryptography-2.1.4/src/_cffi_src/openssl/x509.py, the patches (below) are applied.  Just to double check, `mv files files.old` `make clean` `make distclean` `make install` results in the same build errors (above) but checking  /var/ports/usr/ports/security/py-cryptography/work-py27/cryptography-2.1.4/src/_cffi_src/openssl/x509.py the patches are not applied (as expected, meaning the patch was correctly applied the first time, but did not clear the errors).  

The patch file contains


```
--- src/_cffi_src/openssl/x509.py.orig  2017-11-30 01:53:32 UTC
+++ src/_cffi_src/openssl/x509.py
@@ -255,8 +255,7 @@ int X509_get_signature_nid(const X509 *)

const X509_ALGOR *X509_get0_tbs_sigalg(const X509 *);

-/* in 1.1.0 becomes const ASN1_BIT_STRING, const X509_ALGOR */
-void X509_get0_signature(ASN1_BIT_STRING **, X509_ALGOR **, X509 *);
+void X509_get0_signature(const ASN1_BIT_STRING **, const X509_ALGOR **, const X509 *);

long X509_get_version(X509 *);

@@ -339,7 +338,8 @@ void X509_REQ_get0_signature(const X509_
CUSTOMIZATIONS = """
/* Added in 1.0.2 beta but we need it in all versions now due to the great
    opaquing. */
-#if CRYPTOGRAPHY_OPENSSL_LESS_THAN_102
+#if CRYPTOGRAPHY_OPENSSL_LESS_THAN_102 && \
+    (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x2070000fL)
/* from x509/x_x509.c version 1.0.2 */
void X509_get0_signature(ASN1_BIT_STRING **psig, X509_ALGOR **palg,
                          const X509 *x)
@@ -383,9 +383,11 @@ X509_REVOKED *Cryptography_X509_REVOKED_
    opaquing. */
#if CRYPTOGRAPHY_OPENSSL_LESS_THAN_110

+#if (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x2070000fL)
int X509_up_ref(X509 *x) {
    return CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509);
}
+#endif

const X509_ALGOR *X509_get0_tbs_sigalg(const X509 *x)
{
```

Stuck pending further guidance on this one.  I might try patching the other x509.py locations just to see if that helps tomorrow.


----------



## tsarya (May 1, 2018)

Seems to be a wrong bug ID number: 'PR226906' is not a valid bug number nor an alias to a bug.


----------



## gessel (May 1, 2018)

The patch is hosted here:  http://cvsweb.openbsd.org/cgi-bin/c...y/patches/patch-src__cffi_src_openssl_x509_py

The others are here http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/py-cryptography/patches/  and much older than the last update in FreeBSD ports.

The bug report is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226906

It appears there is still more work to do as of 16 hours ago: https://github.com/pyca/cryptography/pull/4211


----------



## talsamon (May 1, 2018)

I got  security/py-cryptography to build. I commented out

```
CFLAGS+=       -I${OPENSSLINC}
LDFLAGS+=      -L${OPENSSLLIB}
```
in the Makefile.


----------



## gessel (May 1, 2018)

Talsamon - without the patches applied?  I just tried with this patch: https://bugs.freebsd.org/bugzilla/a...ty/py-cryptography/files/patch-issue4210_sec1

which generated, after `make makepatch`:

```
patch-src___cffi__src_openssl_crypto.py        patch-src___cffi__src_openssl_ct.py        patch-src___cffi__src_openssl_x509.py
patch-src___cffi__src_openssl_cryptography.py    patch-src___cffi__src_openssl_ssl.py
```

which resulted in a whole 'nother set of errors.  But if commenting out OpenSSL references is enough, that's much easier.  Switching SSL providers back to OpenSSL is something I'd rather not contemplate...


----------



## tobik@ (May 1, 2018)

talsamon said:


> I got  security/py-cryptography to build. I commented out
> 
> ```
> CFLAGS+=       -I${OPENSSLINC}
> ...


This is _not_ a solution. While it builds the port is not in a usable state afterwards. The lines are there to prevent it from picking up base OpenSSL headers. You can't even import basic things if it's compiled without them:

```
Python 2.7.14 (default, Apr 30 2018, 12:19:27)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (branches/release_60 325932)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import cryptography.hazmat.backends.openssl.backend
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/backends/openssl/__init__.py", line 7, in <module>
    from cryptography.hazmat.backends.openssl.backend import backend
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 54, in <module>
    from cryptography.hazmat.bindings.openssl import binding
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 13, in <module>
    from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError: /usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: Undefined symbol "d2i_DHxparams"
>>>
```
d2i_DHxparams is a function that LibreSSL does not provide.


----------



## gessel (May 1, 2018)

Here are my issues with LibreSSL 2.7.2+ and a current ports tree

dns/bind-tools - patch in PR 226903 worked

lang/ruby24 - failed, haven't started messing with it yet

security/py-cryptography  patches HERE WORKED (update) for me

www/apache24 - patches should be applied, port builds without errors, but I get `/usr/local/libexec/apache24/mod_ssl.so: Undefined symbol "OPENSSL_malloc_init"` and apache24 won't start (in progress)

databases/mysql56-server - should be an issue, but I haven't got that far yet.

I had problems with postgresql95-server-9.5.12, openssh-portable-7.7.p1_1,1, and amavisd-new-2.11.0_2,1 , but those were all resolved without explicit attention through incremental port builds and seem OK now.


----------



## rigoletto@ (May 1, 2018)

lang/ruby24 has a patch (same of ruby25), and works for me: PR 227851
security/py-cryptography I didn't tried the last patch (from today), but the previous worked in here: PR 226906


----------



## gessel (May 1, 2018)

I'll try the ruby patch later tonight.  The py-crypto patch seems to be actively under dev.  It may have some issues with my build environment.  If you get it to work successfully, LMK and perhaps between us we can narrow down what's causing me grief.


----------



## rigoletto@ (May 1, 2018)

The last py-cryptography patch is supposed to be the last one before be commited. The previous one needed to be re-worked due to breaking openssl-devel, not related with libressl. That is supposed to be up-streamed.


----------



## gessel (May 2, 2018)

security/py-cryptography patch file from attachment 192933 of PR 226906 works fine.  In moving it from web to GUI workstation to server, I borked a line and it wasn't patching right.  

Process (just FYI),  and patch file that worked for me is attached, py36 will have slightly different paths.  The same patch should work for both.  Sorry I can't test py36.

`cd /usr/ports/security/py-cryptography`
`make clean && make distclean && make install`
`cd /var/ports/usr/ports/security/py-cryptography/work-py27/cryptography-2.1.4/src/_cffi_src/openssl`
`patch -C < path.to.patch/py-cryptography27-PR226906-A192933.patch`
check output for any errors (important )
`patch < path.to.patch/py-cryptography27-PR226906-A192933.patch`
`cd /usr/ports/security/py-cryptography`
`mkdir -p files`
`make makepatch`
`make` `make deinstall` `make reinstall` or just `portmaster`)


----------



## gessel (May 2, 2018)

lang/ruby24 patch works (also for lang/ruby25) apply in /var/ports/usr/ports/lang/ruby24/work/ruby-2.4.4/ext/openssl/ (as above)

dns/bind-tools patch works (also for dns/bind9*) apply in /var/ports/usr/ports/dns/bind-tools/work/bind-9.12.1/lib/dns/ (as above)

patches I used are below, but check The LibreSSL wiki for updates


ruby-PR226852-A1920101.patch

```
--- ext/openssl/extconf.rb.orig    2018-04-02 09:57:14 UTC
+++ ext/openssl/extconf.rb
@@ -122,8 +122,11 @@ OpenSSL.check_func_or_macro("SSL_get_ser
 have_func("SSL_is_server")
 
 # added in 1.1.0
+if !have_struct_member("SSL", "ctx", "openssl/ssl.h") ||
+    try_static_assert("LIBRESSL_VERSION_NUMBER >= 0x2070000fL", "openssl/opensslv.h")
+  $defs.push("-DHAVE_OPAQUE_OPENSSL")
+end
 have_func("CRYPTO_lock") || $defs.push("-DHAVE_OPENSSL_110_THREADING_API")
-have_struct_member("SSL", "ctx", "openssl/ssl.h") || $defs.push("-DHAVE_OPAQUE_OPENSSL")
 have_func("BN_GENCB_new")
 have_func("BN_GENCB_free")
 have_func("BN_GENCB_get_arg")


--- ext/openssl/openssl_missing.h.orig    2018-03-22 19:37:19 UTC
+++ ext/openssl/openssl_missing.h
@@ -72,6 +72,9 @@ void ossl_HMAC_CTX_free(HMAC_CTX *);
 #if !defined(HAVE_X509_STORE_SET_EX_DATA)
 #  define X509_STORE_set_ex_data(x, idx, data) \
     CRYPTO_set_ex_data(&(x)->ex_data, (idx), (data))
+#endif
+
+#if !defined(HAVE_X509_STORE_GET_EX_NEW_INDEX)
 #  define X509_STORE_get_ex_new_index(l, p, newf, dupf, freef) \
     CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_X509_STORE, (l), (p), \
                 (newf), (dupf), (freef))
@@ -145,6 +148,7 @@ void ossl_X509_REQ_get0_signature(const
 #endif
 
 #if !defined(HAVE_OPAQUE_OPENSSL)
+#if defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x2070000fL
 #define IMPL_PKEY_GETTER(_type, _name) \
 static inline _type *EVP_PKEY_get0_##_type(EVP_PKEY *pkey) { \
     return pkey->pkey._name; }
@@ -196,6 +200,7 @@ IMPL_PKEY_GETTER(EC_KEY, ec)
 #undef IMPL_PKEY_GETTER
 #undef IMPL_KEY_ACCESSOR2
 #undef IMPL_KEY_ACCESSOR3
+#endif
 #endif /* HAVE_OPAQUE_OPENSSL */
 
 #if !defined(EVP_CTRL_AEAD_GET_TAG)
```

bind-PR226903-A191794.patch

```
--- lib/dns/openssldh_link.c.orig       2018-03-25 00:15:52 UTC
+++ lib/dns/openssldh_link.c
@@ -69,7 +69,7 @@ static isc_result_t openssldh_todns(cons

 static BIGNUM *bn2, *bn768, *bn1024, *bn1536;

-#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || ( defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x20700000L )
 /*
  * DH_get0_key, DH_set0_key, DH_get0_pqg and DH_set0_pqg
  * are from OpenSSL 1.1.0.
--- lib/dns/openssldsa_link.c.orig      2018-03-25 00:16:57 UTC
+++ lib/dns/openssldsa_link.c
@@ -49,7 +49,7 @@

 static isc_result_t openssldsa_todns(const dst_key_t *key, isc_buffer_t *data);

-#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || ( defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x20700000L )
 static void
 DSA_get0_pqg(const DSA *d, const BIGNUM **p, const BIGNUM **q,
             const BIGNUM **g)
--- lib/dns/opensslecdsa_link.c.orig    2018-03-25 00:17:52 UTC
+++ lib/dns/opensslecdsa_link.c
@@ -42,7 +42,7 @@

 #define DST_RET(a) {ret = a; goto err;}

-#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || ( defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x20700000L )
 /* From OpenSSL 1.1 */
 static void
 ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM **pr, const BIGNUM **ps) {
--- lib/dns/opensslrsa_link.c.orig      2018-03-25 00:18:28 UTC
+++ lib/dns/opensslrsa_link.c
@@ -121,7 +121,7 @@
 #endif
 #define DST_RET(a) {ret = a; goto err;}

-#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || ( defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x20700000L )
 /* From OpenSSL 1.1.0 */
 static int
 RSA_set0_key(RSA *r, BIGNUM *n, BIGNUM *e, BIGNUM *d) {
```


----------



## Peter Hesen (May 2, 2018)

The upgrade of LibreSSL 2.6.4 to 2.7.2 deletes libssl.so.44 from /usr/local/lib which is shared by a host of programs


----------



## talsamon (May 2, 2018)

tobik@ said:


> This is _not_ a solution. While it builds the port is not in a usable state afterwards. The lines are there to prevent it from picking up base OpenSSL headers. You can't even import basic things if it's compiled without them:
> 
> ```
> Python 2.7.14 (default, Apr 30 2018, 12:19:27)
> ...



Sorry, I was too fast, and did not check this.


----------



## gessel (Aug 6, 2018)

Version 2.3 of security/py-cryptography hit ports on the 6th of Aug.  This should resolve the build issues with security/libressl 2.7.2+


----------

