Support IOV functions on macOS #210
Conversation
jborean93
force-pushed
the
macos-dce
branch
5 times, most recently
from
242c6eb
to
9ddd1d2
Compare
|
Uuuggh hairy .... |
|
You're telling me, unfortunately WinRM message encryption requires the IOV functions as it needs the header/trailer length to encode in the exchange messages. Without something stupid like this we can't do that on macOS. Really I just wanted to see whether it was possible to achieve this in gssapi and see what everyone's thoughts are in trying to expose it for end users. Willing to hear alternatives if available. |
There was a problem hiding this comment.
I think you're the only one with macOS set up, so this means any "does this work" questions are unfortunately yours to resolve. If it comes to that, I'm not opposed to macOS wheels if it helps with something (and it's easier than the Linux ones, though I imagine it is).
As long as we're confident that our detection works, I don't see anything wrong with exposing it to users.
| @@ -111,14 +111,20 @@ | |||
| except ImportError: | |||
| pass | |||
|
|
|||
| # optional DCE (IOV/AEAD) support | |||
| # optional DCE (IOV) support | |||
There was a problem hiding this comment.
I think we should make it more clear (here and below) that DCE != IOV. That is, this is the IOV part of the DCE functions.
There was a problem hiding this comment.
What would you suggest, I can do # optional DCE (IOV only) support and the same for the AEAD imports below?
| void *wrap_iov_length_fn = NULL | ||
| void *release_iov_buffer_fn = NULL | ||
|
|
||
| cdef void * _dlsym(void *handle, name): |
There was a problem hiding this comment.
How likely are we to need these for other GSSAPI functions on macOS? Wondering if it'd make sense to put this glue in a common file somewhere.
There was a problem hiding this comment.
Honestly I'm not sure, I had a brief check for some other extensions that are not available on macOS, like the aead stuff, but it doesn't seem to be present in the symbols. There's probably other stuff so I can move it out if you would like it.
|
Thanks for replying @frozencemetery. I'll try and have a look at what will go into creating the wheels when I find some time in the future, can't guarantee I'll get to it anytime soon unfortunately. One question I do have with the sdist that is currently created and published to pypi. Is the cython build just run on a system that has all the extensions present or can Cython create the .c files without the actual C headers potentially being present on the system? |
|
Apologies, I didn't mean to make it sound like I'm dumping a lot of work on you. Creating and uploading wheels should be fairly simple - we have logic for doing it on Windows that should translate, especially https://github.com/pythongssapi/python-gssapi/blob/master/ci/release-win.sh#L11-L13 Inspection suggests that the C files are part of the sdist - the pyx files aren't shipped there. (Our build logic detects this case.) It happens that all extensions are present on our build system, but the C files are generated regardless. When running |
The DCE IOV functions on macOS are not exported by any public header on the GSS.Framework. They can still be accessed by dynamically getting the address of the known symbols for each function and invoking that. This allows users of this library on macOS to better interop with Windows SSPI message encryption which typically require the IOV wrapping functions that were previously unavailable.
The DCE IOV functions are not exported in any public header on macOS which means the
ext_dcefunctions cannot be used on that platform using the normal way. The actual framework has actually implemented these functions but they need to be loaded dynamically.This PR uses dlsym to lookup the symbol of the GSS.Framework binary and get the address of the function based on the symbol name. The symbols names does not seem to have changed ever since the release of
GSS.Frameworkand if they are removed/renamed in a future version the worst thing to happen is for the functions to no longer be available just like before.One part I'm not sure on is whether we can use the Cython compile time definitions. If I understand the process correctly we create the sdist with the C files already generated which means the compile time directives won't be in place for macOS. As I see it we could either