On Wed, Jan 3, 2018 at 8:50 PM, Matti Picus wrote:
> On 1/4/2018 3:15 AM, Nathaniel Smith wrote:
>> None of Linux, Windows, or MacOS provide reasonable pre-existing
>> OpenSSL installs you can use. So it seems to me that if PyPy's going
>> to ship any binaries at all and take that seriously, then
Looks like they ship a shared lib on osx which is different from how they
handle 2.7:
mattb@mattb-mbp2:/Library/Frameworks/Python.framework/Versions $ find . -name
'*ssl*.so' | xargs otool -L
./2.7/lib/python2.7/lib-dynload/_ssl.so:
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8
On 1/4/2018 3:15 AM, Nathaniel Smith wrote:
On Wed, Jan 3, 2018 at 3:51 PM, Alex Gaynor wrote:
If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
in the business of issuing new releases whenever upstream has a security
release, we can't be shipping people OpenSSLs with
On Wed, Jan 3, 2018 at 3:51 PM, Alex Gaynor wrote:
> If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
> in the business of issuing new releases whenever upstream has a security
> release, we can't be shipping people OpenSSLs with known security issues.
>
> Of LibreSSL an
On Wed, Jan 03, 2018 at 07:06:13PM -0500, Alex Gaynor wrote:
>pyca/cryptography issues a new release on all platforms for any OpenSSL
>security releases.
Yeah, but that's part of the library ecosystem -- not really an end product?
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.co
pyca/cryptography issues a new release on all platforms for any OpenSSL
security releases.
:-),
Alex
On Wed, Jan 3, 2018 at 7:05 PM, Matt Billenstein wrote:
> On Wed, Jan 03, 2018 at 06:51:21PM -0500, Alex Gaynor wrote:
> >If PyPy releases include a copy of OpenSSL (or LibreSSL) then we nee
On Wed, Jan 03, 2018 at 06:51:21PM -0500, Alex Gaynor wrote:
>If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to
>be in the business of issuing new releases whenever upstream has a
>security release, we can't be shipping people OpenSSLs with known security
>iss
If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
in the business of issuing new releases whenever upstream has a security
release, we can't be shipping people OpenSSLs with known security issues.
Of LibreSSL and OpenSSL, I'd choose to ship OpenSSL -- I've found LibreSSL
On Jan 3, 2018 02:17, "Matt Billenstein" wrote:
So, I think updating LibreSSL branches every 6-12 months and using the
latest
point release for a new pypy release is probably a good plan.
BTW you should consult your local cryptographic engineer – I guess that's
probably Alex Gaynor? – before de
On Wed, Jan 03, 2018 at 09:08:22AM +0100, Armin Rigo wrote:
> Given that situation my own vote would be to find the easiest solution
> that seems to work (maybe just link to the outdated openssl) and add a
> warning next to the download link on our web page, with a link to the
> homebrew version.
Hi,
On 3 January 2018 at 06:53, Yury V. Zaytsev wrote:
> Basically only bloat (not an argument) and necessity to track OpenSSL
> security updates & release new versions when they come out...
...which I'm sure will not be done, because there is no-one in the
PyPy core group that is both security-
On Wed, 3 Jan 2018, Matti Picus wrote:
Perhaps we should break with CPython here and statically link on macosx.
Is there a downside to statically linking ssl and libffi?
Basically only bloat (not an argument) and necessity to track OpenSSL
security updates & release new versions when they com
On Wed, Jan 03, 2018 at 07:45:07AM +0200, Matti Picus wrote:
> Perhaps we should break with CPython here and statically link on
> macosx. Is there a downside to statically linking ssl and libffi?
Seems like a great solution given you've already sorted this out on pypy3. No
telling what Apple migh
On 03/01/18 02:04, Matt Billenstein wrote:
On Tue, Jan 02, 2018 at 03:25:17PM -0800, Nathaniel Smith wrote:
I'm pretty sure that the right solution is to ship your own copy of
openssl with the build, so that you're totally independent from Apple's
ssl shenanigans. Maybe look at how C
Which version of CPython are you looking at? Here's the patch that switched
the official MacOS builds to always using a private copy of openssl:
https://hg.python.org/cpython/rev/bfd0a73cf907
(Found here: https://bugs.python.org/issue17128)
On Jan 2, 2018 16:04, "Matt Billenstein" wrote:
> On T
I'm pretty sure the LibreSSL that macOS includes is not intended for public
linkage.
If you want to ship binaries on macOS that use OpenSSL, the thing to do is
to ship your own OpenSSL and update whenever OpenSSL performs a security
release.
Alex
On Tue, Jan 2, 2018 at 7:04 PM, Matt Billenstein
On Tue, Jan 02, 2018 at 03:25:17PM -0800, Nathaniel Smith wrote:
>I'm pretty sure that the right solution is to ship your own copy of
>openssl with the build, so that you're totally independent from Apple's
>ssl shenanigans. Maybe look at how CPython handles this.
That does seem more c
I'm pretty sure that the right solution is to ship your own copy of openssl
with the build, so that you're totally independent from Apple's ssl
shenanigans. Maybe look at how CPython handles this.
On Jan 2, 2018 2:28 PM, "Matt Billenstein" wrote:
> Hi all,
>
> So the general issue seems to be Ap
I think supporting just the more recent OS X releases (Sierra, High Sierra) is
fine. I recently had to upgrade my Mac to Sierra because I was running into
packages that wouldn't work on the older version. (There seems to be a
"get_entropy" function in Sierra, and things were failing because it w
Hi all,
So the general issue seems to be Apple not shipping the header files for these
shared libs-- not linking to the brew libffi works (I'm not sure it's linking
to the system libffi at all now however -- or if it needs to), but then the
problem became openssl headers. I've hacked around this
On 31/12/2017 10:59 AM, blanch wrote:
hello, thanks for the 5.10 release!
just a problem on the mac: it seems that the pypy3 binaries are linked against
a libffi provided by a package manager (homebrew?), since dyld is looking for
/usr/local/opt/libffi/lib/libffi.6.dylib (see below the error
hello, thanks for the 5.10 release!
just a problem on the mac: it seems that the pypy3 binaries are linked against
a libffi provided by a package manager (homebrew?), since dyld is looking for
/usr/local/opt/libffi/lib/libffi.6.dylib (see below the error reported and
otool output).
since i do n
Hi Matti
The build on downloads for OS X works only on High Sierra (10.13),
since it expects utimesat in libc, which is only available from High
Sierra. I will build a Sierra version on my computer that (hopefully)
works on older OS X too.
Otherwise looks good to go, I will update the website and
I have uploaded the pypy 5.10 release tarballs for both pypy2.7 and
pypy3.5 to https://bitbucket.org/pypy/pypy/downloads, sha256 hashes are
available from
https://bitbucket.org/pypy/pypy.org/src/41427b24c7395f4a5a6636ef0d072c83982d8945/source/download.txt?at=extradoc&fileviewer=file-view-default
24 matches
Mail list logo
