Forwarding to fedora-devel as well
Associate Software Engineer
Python Maintenance Team, Red Hat
----- Original Message -----
From: "Michal Cyprian" <mcyprian(a)redhat.com>
Sent: Wednesday, April 26, 2017 11:19:00 AM
Subject: What is your opinion on "sudo pip" fix for Fedora 27?
At the present time, running sudo pip3 in Fedora is not safe.
Pip shares its installation directory with dnf, can remove
dnf-managed files and generally break the Python 3 interpreter.
Our first attempt to make sudo pip safe on Fedora  was
based on using a different binary (/usr/libexec/system-python)
for RPM packaging purposes and changing the behavior
of /usr/bin/python3 (and pip that uses its settings) to install
under /usr/local by default. Switching all the Python 3 packages
to system-python turned out to be much more problematic than
expected and we had to postpone the Change for F27.
We decided to try a different approach. The main idea is to detect
an ongoing RPM build and modify the behavior of the Python 3
executable only when in normal user environment so that RPM builds
won't be affected at all.
The adjustment of the behavior can be done on different levels.
The first option is to set the sys.prefix variable to /usr/local
when the interpreter is initialized. This will affect
all the install methods, but the solution can cause some
problems in applications that rely on the value of sys.prefix.
A prototype of this implementation can be seen here .
The other possibility is to limit the pip install location change
to distutils and pip . This is the "safer" option, but does
not cover all corner cases. For example, Python software built
locally using cmake or similar tools will be installed into
/usr/lib and can conflict with system tools. Debian chose to
implement similar solution.
I would like to ask which solution would work for your applications
better, and what is in your opinion the right way to go. I will
appreciate any costructive comments or ideas on how to improve these
patches. If you want to check some specific use-case you can use the images
to try out the two mentioned implementations.
python-devel mailing list -- python-devel(a)lists.fedoraproject.org
To unsubscribe send an email to python-devel-leave(a)lists.fedoraproject.org
This is actually just a very late heads-up about challenges with OpenVPN
in Fedora 26.
Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and
good step forward. Unfortunately, that gives OpenVPN a real challenge.
The OpenSSL v1.1 support is not completed. Patches have been sent to
the upstream devel mailing list for review, but only half of them have
been processed and applied so far.
So, to be able to provide OpenVPN in Fedora 26 it was decided to switch
to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have
revealed several issues:
- mbed TLS 2.3+ does by default not support certificates hashes
"older" than SHA1. And RSA keys must be 2048 bits or more.
This have been fixed by a couple of additional patches on top
of the upstream OpenVPN code base. It supports now RSA keys
of 1024 bits or more. In addition for OpenSSL support of the
OPENSSL_ENABLE_MD5_VERIFY, a quirk have been added to also enable
MD5 support if that environment variable have been set.
- mbed TLS build in Fedora lacked PKCS#11 support. This have
been resolved. But there are concerns how well this plays along
with another dependency OpenVPN have, pkcs11-helper. This is being
investigated and tested. Feel free to help out on bz #1432152 if
you depend on PKCS#11/Smart Card functionality. Your feedback is
- mbed TLS completely lacks support for PKCS#12 files.
Now, there is kind of an alternative by using compat-openssl-10. But
that does not play well with pkcs11-helper; which is compiled against
Currently the plan is to stay with mbed TLS support until PKCS#11
support is fully confirmed working or not working at all. If not
working, we can at least move to compat-openssl10 without PKCS#11
support, which enables PKCS#12 support again. If PKCS#11 support works
with mbed TLS, then we will stay on mbed TLS for now as I value that
support more important than PKCS#12.
Once OpenVPN have released a version with full OpenSSL v1.1 support (or
at least have all the needed patches reviewed and applied to their
upstream git repos), then I will switch back to the default openssl
This is far from ideal. But I do consider this the best compromise than
not having an OpenVPN package in Fedora 26 at all.
For those of you having PKCS#12 files, there is a kind of workaround
where you can split up that file into CA, Certificate and Private Key
PEM files - which OpenVPN can use directly.
$ openssl pkcs12 -nokeys -cacerts -in $PKCS12FILE > ca-cert.pem
$ openssl pkcs12 -nokeys -clcerts -in $PKCS12FILE > cert.pem
$ openssl pkcs12 -nocerts -nodes -in $PKCS12FILE > private-key.pem
If switching from '-nodes' with for example '-aes256' on the last line,
the private key will be encrypted and password protected; similar to
what your PKCS#12 files may already use today.
I am sorry for not having sent this heads-up earlier. I took over
package maintenance mid-March, and I've taken this package through a
very much needed overhaul to align the packaging with improvements in
the upstream packaging. The previous maintainers have done a good job
keeping this package alive, but the gap against upstream began to be a
bit too big. There are still a few things which needs to be ironed out.
But once the mbed TLS/OpenSSL issue and a few other more minor issues
gets resolved, I'd say we're pretty much in a reasonable shape.
If you have questions, issues or comments ... feel free to reach out!
Could someone with write-access to mc solve
we currently have a situation where users accidentally might delete
data. The situation is a mess. mc 4.8.19-1 changed from curses to slang
and now several keybindings are plain wrong for at least fedora 25 and
maybe fedora 24, too.