Why use paramiko-ng?
Closed this issue · 3 comments
Hi,
Some people might already depend on paramiko, so having both paramiko and paramiko-ng will result in a dependency hell.
What are the reasons to use paramiko-ng instead of paramiko==2.7.1?
Just want to say that we have successfully migrated to Python 3.7 + fab-classic==1.15.2. We have huge fabric files and everything works perfectly fine with fab-classic.
I've mentioned this repository in the issues of the original repo and on Stack Overflow to help other people find this project.
I believe there are no reasons to rewrite all the existing fabric 1.x tooling, so fab-classic is a really valuable project.
That's a good question :)
I've contributed a bit to paramiko upstream here and there for a few years now. It really seemed to have slowed almost to a halt by the beginning of 2019. There were still 2 or 3 releases per year (usually multiple patch-releases in a batch), but there were so many somewhat important pull requests that never got any attention from the maintainer, either positive or negative, and somewhat important pull requests were usually buried under other pull requests long before they had a chance. I do empathize with the maintainer not having the time to give the many pull requests attention, for a project like paramiko they can be very low-level technical issues, and very tricky to consider the compatibility with many different platforms and use-cases. Yeah yeah ideally the test suite takes care of all that, but this codebase is old and crufty, and the effort needed to clean it up is rather massive. I also may disagree at times with what would be appropriate cleanup. I don't think people should afraid to fork sometimes. Please allow me to indulge in telling a story...
In March of 2018, paramiko made a series of patch releases including a good selection of bug fixes.
In September of 2018, paramiko made a series of patch releases fixing pretty much just CVE-2018-1000805.
In May of 2019, I made releases of paramiko-ng (2.5 and 2.6) which added support for new-format openssh private keys, fixed noisy cryptography-2.5+ deprecation warnings, added Curve25519 kex, DH-group14, hmac encrypt-then-mac, and some other minor stuff.
The new-format openssh private key support first appeared in a pull request in paramiko/paramiko#618 in November 2015, and was refreshed/updated in paramiko/paramiko#1343 in November 2018. These pull requests were not perfect. There were some good comments and some bad comments. The PRs were updated a couple times, but the authors didn't know how much effort to put in because they maintainer did not show up for a long time. And when the maintainer did, they didn't have time to read the comments and determine which were legitimate.
The DH-group14 kex and hmac encrypt-then-mac PR was from June 2018: paramiko/paramiko#1233
The cryptography warnings-fix PR came in early February 2019, but quickly gained a lot of demand, because people are afraid of warnings on every server connection.
In June of 2019, paramiko released 2.5 and 2.6, which fixed the cryptography warnings, added Curve25519 kex, DH-group14 kex, hmac encrypt-then-mac, and added some minor features I had not added in my May releases, and included some other minor fixes which I had included.
In June of 2019, I released paramiko-ng 2.7, which included another batch of miscellaneous stuff, most of it from old upstream paramiko pull-requests.
In December of 2019, paramiko released 2.7, including the new-format openssh private key support. But, it had a few significant bugs that I had found, commented on in the upstream PR, and fixed in my release of paramiko-ng in May 2019. I submitted these fixes separately upstream, and they were merged and relased in paramiko 2.7.1 about a week later. But it later became apparent that there were other bugs I fixed when I cleaned-up the new-format private key work before the May 2019 paramiko-ng release, that are still buggy in paramiko upstream: paramiko/paramiko#1604 and paramiko/paramiko#1606
Please take a look at https://github.com/ploxiln/paramiko-ng/releases and https://www.paramiko.org/changelog.html for more details :)
There are still features (which I would call minor) which were added upstream in 2019, which I never added to paramiko-ng. I have some desire to add them in a different way, and also no strong need/motivation for them yet. Meanwhile, there are many small fixes, some over 2 years old and long buried multiple pages down the upstream pull-request list, which are included in my fork.
I really wasn't sure if upstream paramiko would see any more significant releases, back in May 2019. So, for my convenience, I made fab-classic use my fork by default. It's the only thing I really use paramiko-ng for (but I do use it a lot). I don't think python has the concept of "virtual-dependencies", of "replacing" a requirement by one with a different name. So in paramiko-ng I added a hack, where you can install "paramiko-ng" with the PARAMIKO_REPLACE environment variable set, in order for it to be installed with the package name "paramiko" and satisfy that requirement for other packages (like upstream Fabric):
PARAMIKO_REPLACE=1 pip install https://github.com/ploxiln/paramiko-ng/archive/2.7.4.tar.gz#egg=paramiko
Right now I'm thinking I'll add the same hack to fab-classic: if that same environment variable is set, fab-classic will require "paramiko" instead of "paramiko-ng". That "paramiko" might actually be paramiko-ng installed with PARAMIKO_REPLACE, or it might actually be upstream paramiko I guess. Odd and confusing perhaps, but I think it's work-able ...