Develop Reference

how to run a scripted scan with openVAS [Python]

I have recently installed the scanner openVAS in my kali linux operating system ... what I would like to do is run scans of my ip from a python executable and then print the results on the screen. I have seen the OpenVAS python API documentation and tried some examples, but it always comes up with an error or something that does not allow me to achieve my goal.
Could you recommend a working example or where is it explained correctly in the docuementation?
thank you.

Is it possible to embed Jedi in an application on a system where Python is not installed?

I'm working on an (Windows and Mac) application that uses Python as an embedded scripting language.
The application includes an internal text editor, implemented using Scintilla, and I'm using Jedi for autocompletion, which generally works great.
However, when attempting autocompletion on a computer that does not have a separate installation of Python, Jedi raises an error:
jedi.api.environment.InvalidPythonEnvironment:
Could not get version information for 'python':
FileNotFoundError(2, 'The system cannot find the file specified', None, 2, None)
Digging into the code, I can see that the underlying code that is throwing the FileNotFoundError is when Jedi attempts to run python using subprocess.Popen. Python is not installed on the computer, so this fails.
I can also reproduce the same issue on a computer that does have Python installed by editing my Path environment variable not to include the location of python.exe.
Ideally, we don't want users of our application to have to install Python just to get autocompletion working.
My questions:
Is it possible to get Jedi not to spawn subprocesses, and instead run its code inside the same instance of Python within which it itself is running? I couldn't find anything about this in the documentation or the source code that deals with Environments, and extrapolating from the discussion here I suspect the answer might be no.
Is it possible somehow to get Jedi to use the same python37.dll that our application is using for its functionality, instead of looking for a .exe file that does not exist?
Is there any way we could make some kind of minimal Python installation within our existing app installation that uses the same DLLs/Python Lib etc? How could I go about doing this?
Is there any other way to get Jedi autocompletion working in our app without requiring the user to install Python, or including a full Python installer as part of our build process?

Is it possible to get Jedi not to spawn subprocesses, and instead run its code inside the same instance of Python within which it itself is running? I couldn't find anything about this in the documentation or the source code that deals with Environments, and extrapolating from the discussion here I suspect the answer might be no.
This is definitely possible. All the tools are there. There are discussions ongoing here: https://github.com/davidhalter/jedi-vim/issues/870.
IMO a patch to Jedi is needed that uses an jedi.api.environment.InterpreterEnvironment in some cases like yours. It's definitely possible, it's just buggy at the moment.

Intellij IDEA OSX Python Development Headaches

I recently started working at a Java shop where staff primarily use IntelliJ IDEA on Macs for development. I am in charge of writing automated tests for a data centric project, and my go-to language for this is Python. In the past, I have used PyCharm on Linux and Windows with great success, but configuring IntelliJ IDEA for Python on OSX has been confusing to me. So far, I have had no issues setting up a project and getting it to run Python scripts, but each time I try using the debugger, I get the following error:
/usr/bin/python: can't open file '/Users/{USER}/Library/Application Support/helpers/pydev/pydevd.py': [Errno 2] No such file or directory
So far, Googling around has turned up hardly anything useful - and most of JetBrains's help manuals are PyCharm focused, which is rather unhelpful in the IntelliJ context. Has anyone else come across something like this? I'm looking for insight into what exactly is going wrong here.

Try uninstalling and re-installing the plugin? There's definitely something wrong with the path above, it should have an IntelliJ<version number> between the Application Support/python and the helpers (at least by what's on my system). I am running IntelliJ 13 with the python plugin and have been able to debug without any problems with it.

PyOpenCl: how to debug segmentation fault?

I have PyOpenCL code with OpenCL C kernel code. I catch segmentation fault error when I run my app. How to debug such error with some debugger or some other development tool? I don't know what exactly to do to find out the problem. I have in mind option with printf or something but I want use more powerful stuff.
I believe that error in kernel code, so I want to debug kernel code firstly.
UPD. I'm on linux (Arch Linux, 3.6.11), python 2 or 3, PyOpenCl 2012.1

Kernel debugging is an implementation-dependent affair. On Linux, the best I've found is to use AMD's CL implementation on the CPU, compile the kernel with -g, and use gdb. They've got instructions on this in their programming guide, here:
AMD CL Documentation page

If you're using nvidia instead of ATI/AMD GPU, the OpenCL support in nvidia SDK is...less than desired.
Intel provides a CPU-based OpenCL SDK for their recent processors, see http://software.intel.com/en-us/vcsource/tools/opencl-sdk-2013 -- (to use the RPM packages they provide on Ubuntu, you need to run "fakeroot alien --to-deb" on each package, then "dpkg -i").
With that SDK, you need to add the "-g" and "-s filename" flags to the compiler options in build(). (If your kernel only exists as a string in your program, you can add code to save it to a file just before you run it.) Then try "gdb --args python-cmd", you can start debugging by typing "break mykernel", answer Y when asked if you want to wait for the "mykernel" symbol to be dynamically loaded, then type "run".
Once you have the debugger running manually typing the command, I suggest making an executable shell script to launch your favorite .py file with the debugger (which will also be a convenient place to add hackery to your application's launch, e.g. python -m unittest, PYTHONPATH, virtualenv, LD_LIBRARY_PATH, LD_PRELOAD, etc.).

I wouldn't jump into conclusions without fully testing your software suite. You are running the last released version of PyOpenCl. Chances are you are passing in something to the module that isn't being populated correctly and the backend module doesn't do the necessary error-checking before using something that isn't properly populated (impossible to really help you debug without any code being made available)
Have you tried using the python debugger to set different breakpoints (import pdb; pdb.set_trace()) right before different pyopencl calls to even see where in your code it is seg faulting? This should definitely be your first task. When you find out where it is seg faulting, you need to closely look at pyopencl examples/api to see why you've errored out.

Segmentation fault is usually because of a bad memory access in your kernel. There is a cool tool to detect bad memory accesses, similar to valgrind: https://github.com/jrprice/Oclgrind . In combination with some printfs in the kernel code it makes it quite a bit easier to localize the problem.

Debug crashing C Library used in Python project

complete Python noob here (and rusty in C).
I am using a Mac with Lion OS. Trying to use NFCpy, which uses USBpy, which uses libUSB. libUSB is crashing due to a null pointer but I have no idea how to debug that since there are so many parts involved.
Right now I am using xcode to view the code highlighted but I run everything from bash. I can switch to Windows or Linux if this is going to be somehow easier with a different environment.
Any suggestions on how to debug this would be much appreciated ;-)
PS: It would be just fine if I could see the prints I put in C in the bash where I run the Python script

You should see your printf() you put in C in your terminal, something is already wrong here. Are you sure that you're using the latest compiled library? To be sure, instead of print, you can use use assert(0) (you need to include assert.h).
Anyway, you can debug your software using gdb:
gdb --args python yourfile.py
# type "run" to start the program
# if you put assert() in your code, gdb will stop at the assert, or you can put
# manual breakpoint by using "b filename:lineno" before "run"

Enable core dumps (ulimit -Sc unlimited) and crash the program to produce a core file. Examine the core file with gdb to learn more about the conditions leading up to the crash. Inspect the functions and local variables on the call stack for clues.
Or run the program under gdb to begin with and inspect the live process after it crashes and gdb intercepts the signal (SIGSEGV, SIGBUS, whatever).
Both of these approaches will be easier if you make sure all relevant native code (Python, libUSB, etc) have debugging symbols available.
Isolating the problem in a program which is as small as you can manage to make it, as Tio suggested, will also make this process easier.
PS: It would be just fine if I could see the prints I put in C in the bash where I run the Python script
You didn't mention anything about adding prints "in C" elsewhere in your question. Did you modify libUSB to add debugging prints? If so, did you rebuild it? What steps did you take to ensure that your new build would be used instead of the previously available libUSB? You may need to adjust your dylib-related environment variables to get the dynamic linker to prefer your version over the system version. If you did something else, explain what. :)