Python 2.7 is being depreciated soon.

[4g0tt3nSou1]

So while installing this, the installer notified me that Python 2.7 is gonna be depreciated, Any chance that we might see an update to Python 3 (Maybe 3.8?) any time in the future?

This is less of a typical "issue" and more just an inquiry and notifying you if you didn't know that Py2.7 will be depreciated soonTM.

Thank you for your time, and your work on this nice tool!

[glides]

2.7 is already depreciated. I don't believe there is a plan to migrate to 3

[jayrod]

I would love to volunteer some time and effort. Can we get a few people together and try to migrate it?

[alxchk]

Well, there are several problems which we have with python2. First - likely this will be not be available in regular installations. So pupysh will not work by default. This will be covered with podman/docker. Actually this is almost done, but because of this work-from-home mess don't have time to test properly. For the client itself - as it's carrying built-in library and pythonlib deprecation is not an issue.

Second - some dependencies may not support python2 soon. It's also not a vital thing, because most of them forked|patched|assimilated anyway.

Third - this may be inconvenient to the user to continue use legacy language.. Well.. Maybe.

I checked possibility to migrate to 3 december last year. There are two phases. First is to futurize existing codebase. I made some changes to the memory loaded to make at least possible to use future in bootstrap code. So in theory this is possible. There are some silent issues with divisions and byte|string conversions. Likely codebase (without dependencies) may be converted with 2-3 months. Dependencies is another story.. I postponed futurization because started refactoring of launchers/transports to be more flexible. But this work was not finished (yet), and I stuck somewhere in the middle.

Second big story is native clients. Python3 is fat. Unfortunately nothing changed here. As for me it's better to stay with Python2. But if migrate, then toolchains need to be updated as well. For python2 build procedures were more or less obvious in case of cross-compiling. Python3 requires newer MSVC, so I expect issues. Backward compatiblity with ancient OSes will be lost as well.

In case somebody want's to put time into migration, I suggest next steps.

1. Make stable podman/docker python Py2 first.
2. Participate or wait until new transports framework will be there (likely july)
3. Futurize and test to be compatible with Py2 and Py3 at least at the level of python code
4. Update extensions and native clients code to be able to built|work on Py3
5. Update toolchains for Py3

Something like that..

[cclauss]

Python 2 was deprecated on 1/1/2020 is likely not available in regular installations.

Legacy Python is no longer present in current versions of most major Linux distros and Apple is doing the same on macOS. No Python is installed by default on Windows but the Microsoft App Store will currently install Python 3.8.2. Are the pupy exploits ineffective on up-to-date OSes? Currently the only way to use pupy is to hope that the sys admins or OS vendor has purposefully installed an unsupported package. This is a bit like shooting fish in a barrel.

The purely sequential approach mentioned above is neither required and nor helpful. Pupy contributors will be required to spend the weeks ahead mostly indoors so let’s use that time to modernize pupy in parallel with the other activities on the list above. Only pupy’s detractors should be encouraging us to wait and miss this opportunity.

The purely sequential approach is not what was done to achieve Python 3 compatibility in pupy dependencies LaZagne and WinPwnage. Instead they removed all Python 3 incompatibilities from their codebase while ensuring that it continued to pass its tests and run as expected on Python 2. They added Python 3 to their test suites, at first in allow_failures mode and later in must pass mode. Let’s try to follow their example. The pupy codebase currently has > 150 files that contain Python 3 syntax errors and I see no advantage to waiting several more months before starting to fix those issues.

[alxchk]

Are the pupy exploits

There are no "exploits".

Currently the only way to use pupy is to hope that the sys admins or OS vendor has purposefully installed an unsupported package. This is a bit like shooting fish in a barrel.

The main supported way of using it, which makes sense - is to use with "clients", which embeds whole runtime. It was always like that, because there are too many variations of "host pythons", also too many cases when there are no python present at all.

The purely sequential approach mentioned above is neither required and nor helpful. Pupy contributors will be required to spend the weeks ahead mostly indoors so let’s use that time to modernize pupy in parallel with the other activities on the list above.

Pupy contributors are free to do whatever they like to do. Personally I have more need in flexible transports than python3. This requires /huge/ refactoring, and I'm going to focus there. If somebody want to put time to go any other way - why not. Just be sure your result still works. And be sure I will be able to merge my branch after that. Because otherwise you will stay with what you have right now.

[alxchk]

Before doing same job twice, you may be interested in this : https://github.com/alxchk/pupy/commits/futurize

[cclauss]

Your futurize branch is impressive and all done without using six or if PY2:, etc. However, its changes modify 326 files across 435 commits which means that merging it back to master (unstable) is going to be nearly impossible.

I have seen this divergent evolution movie before in many attempts to port to Python 3. Unfortunately it ends badly for codebases of significant size. If is impossible to review so many changes at once and it is extremely difficult to isolate and fix any breakage. Best practice is to keep merging incremental changes back to unstable to ensure that execution on Python 2 is not broken. The situation here is exacerbated by the fact that we need to be sure the result still works but continuous integration tests on all branches has been broken for more than six months. https://travis-ci.org/github/n1nj4sec/pupy

If you want help, then I would encourage the following steps:

• [ ] Get continuous integration on unstable back to passing
• [ ] Add flake8 linting on Python 3 in allow_failures mode so we have a basic progress report
• [ ] Merge a series of PRs to unstable that do not break Py2 but allow the linter to pass on Py3
• [ ] Rebase futurize to unstable and see where changes still need to be made.

[alxchk]

435 commits is not about futurize. Futurize is 3 commits. 435 commits is the diff between my current working branch and this repo. And it's perfectly possible to merge, because no work were done here.

If you want help, then I would encourage the following steps

If you want to help, I would encourage to make PRs there (futurize). I'm not going to merge anything here.

I can merge my current head here. The reason this was not done - significant amount of changes which are still tested.

[q2dg]

"...to ensure that execution on Python 2 is not broken."

Sincerely, I'd drop Python2 compatibility to trash.

[cclauss]

These repos are far from compatibility with Python 3 so that needs to be finished first.

[alxchk]

I made enough fixes to make possible at least start pupysh.py + pupy (python only) using python3

https://github.com/n1nj4sec/pupy/tree/futurize

Of course there are a lot of regressions, but it's enough to find @ fix bugs without pain.

[jayrod]

I just checked out this branch (futurize) and am going through an install. It appears create-workspace got mangled. When running it there is no "main" function that's being called. I would love to jump in and get my hands dirty helping to futurize pupy but not exactly sure where to start.

I'm running a new Kali VM that I was hoping to get pupy installed on but running into pip and virtualenv issues.

Point me in the right direction and maybe I can create a pull request.

--J

On Fri, 1 May 2020 at 13:40, alxchk [email protected] wrote:

I made enough fixes to make possible at least start pupysh + client using python3

https://github.com/n1nj4sec/pupy/tree/futurize

Of course there are a lot of regressions, but it's enough to find @ fix bugs without pain.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/n1nj4sec/pupy/issues/822#issuecomment-622486865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHHNYFBMQBFAN3NN3KONLRPMCPRANCNFSM4LTYXXIQ .

[alxchk]

Right now there is no reason to try to use regular flow for futurize branch. The easiest workflow will be:

1. Install dependencies (pupy/requirements.txt) either to venv or to the user
2. To run pupysh: cd pupy; python puypsh.py -l ec4 1234 --loglevel DEBUG
3. To run pupy client: cd pupy; python -m pupy --debug connect --host 127.0.0.1:1234 -t ec4

It's possible to generate pure python payload (-f py), but it's no reason to do that on this stage.

So, full python should be installed to windows/linux machine as well.

First thing to check is regressions for python2. If all fine, then regressions related to binary clients etc should be found@fixed. Once all found@fixed, branch can be safely merged to 'unstable'. Second phase is to check/fix regressions/dependencies/modules etc for python3. Binary clients for python3 will not be available in near future, so no need to put efforts to that direction.

Python3 <-> Python2 right now is not possible, also I'm not sure it's possible at all. No need to waste time to catch/fix issues related to that. I will make some research about that.

[jayrod]

I am stuck at step installing dependencies.

I submitted issue #835 as had the same issue in unstable branch and futurize.

 First thing to check is regressions for python2. 

I think I need a bit more information as to what you mean by "regressions" I know what regression testing is but are there a list of issues marked as regression?

[cclauss]

@4g0tt3nSou1 Please change the title of this issue to: Python 2 end of life was on 1/1/2020