Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSupport IOV functions on macOS #210
Conversation
242c6eb
to
9ddd1d2
|
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. |
|
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 | |||
frozencemetery
Jun 10, 2020
Member
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.
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.
jborean93
Jun 10, 2020
Author
Contributor
What would you suggest, I can do # optional DCE (IOV only) support and the same for the AEAD imports below?
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): |
frozencemetery
Jun 10, 2020
Member
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.
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.
jborean93
Jun 10, 2020
Author
Contributor
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.
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