Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSS_C_DELEG_POLICY_FLAG not available on FreeBSD #228

Closed
jborean93 opened this issue Nov 12, 2020 · 4 comments
Closed

GSS_C_DELEG_POLICY_FLAG not available on FreeBSD #228

jborean93 opened this issue Nov 12, 2020 · 4 comments

Comments

@jborean93
Copy link
Contributor

jborean93 commented Nov 12, 2020

What went wrong?

While the package for FreeBSD 12.2 states that the version of Heimdal that is used is 7.7.0 when running krb5-config --version after installing that package it is reported as

FreeBSD heimdal 1.1.0

This is an issue as the 1.6.10 release includes #218 and this flag was added in Heimdal 1.3. When attempting to install gssapi with pip install gssapi on FreeBSD it is now failing with

    cc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -I/usr/local/include/python3.6m -c gssapi/raw/types.c -o build/temp.freebsd-12.1-RELEASE-amd64-3.6/gssapi/raw/ty
pes.o -I/usr/include                                        
    gssapi/raw/types.c:8152:41: error: use of undeclared identifier 'GSS_C_DELEG_POLICY_FLAG'      __pyx_t_5 = __Pyx_PyInt_From_uint32_t(GSS_C_DELEG_POLICY_FLAG); if (unlikely(!__pyx_t_5)) __PYX_ERR(0, 59, __pyx_L1_error)

I'm not sure how to fix this issue as Heimdal 1.3.0 is from 2008 and surely any distro today packages something newer but maybe not. I prefer that we didn't remove the flag as I have some use for it but I don't know how to conditionally set it.

How do we reproduce?

On FreeBSD

pkg install heimdal
pip install gssapi

Component versions (python-gssapi, Kerberos, OS / distro, etc.)

FreeBSD 12.2, Heimdal 7.7.0 (or 1.1.0 I have no idea why they are different)

@jborean93
Copy link
Contributor Author

jborean93 commented Nov 12, 2020

Looking a bit further it looks like FreeBSD ships with an existing Heimdal build at 1.1.0 and the port installed with pkg install heimdal is installed to /usr/local. When python-gssapi goes to build the extensions it is running various commands like krb5-config gssapi --prefix to get the library and include paths for the compiler but on FreeBSD it is ultimately running the base Heimdal version at /usr/bin/krb5-config and not the newer port install at /usr/local/bin/krb5-config.

To force the installation against the port copy of Heimdal I can run PATH=/usr/local/bin:$PATH pip install gssapi so that the newer Heimdal krb5-config is chosen with the newer headers and libs.

From the current situation I can see the following options:

  • Do nothing, force people to have the port's version of Heimdal higher in the PATH and fail otherwise
    • Not very user friendly
    • Doesn't work out of the box - may change at some point in the future
    • It at least forces the user to use a newer version that hopefully isn't riddled with bugs/missing features
    • Another plus is no further work needs to be done, except maybe some docs
  • Find a way to conditionally add the GSS_C_DELEG_POLICY_FLAG to the RequirementFlag enum so it will still compile with the older version
    • When implementing Added ok_as_delegate flags #218 I couldn't find a way in Cython to detect if an identifier exists or not
    • Issue is further compounded in the fact that we pre generate the C files in the sdist so we are limited to a check that must translate from Cython to C
    • It means that people will still continue to use the ancient version that FreeBSD ships with but is more flexible for other platforms that might be similar
  • Make the libs and prefix check in setup.py check for the Heimdal ports existence and act accordingly when on FreeBSD
    • Automatically uses the newer lib but will still fail if it isn't present
    • It will "fix" FreeBSD but I'm unsure if other platforms might be affected
    • Adds more complication to setup.py
    • Might be nice to also add an env var that allows someone to specify the location of krb5-config so it can be overriden globally

This check would look something like

if os.uname[0] == 'FreeBSD' and os.path.exists('/usr/local/bin/krb5-config'):
    prefix = get_output('/usr/local/bin/krb5-config gssapi --prefix')

else:
    prefix = get_output('krb5-config gssapi --prefix')

Another option would be to revert #218 but I'm hoping we don't have to get that.

@jborean93
Copy link
Contributor Author

https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018998.html is some more background info but TLDR seems to be that it's a massive task to update Heimdal in base without breaking other packages.

@frozencemetery
Copy link
Member

Good summary, thanks. To add:

  • setup.py will probably get more complicated no matter what. This is acceptible - after all, every other major OS has a stanza; why shouldn't freebsd? :)
  • There shouldn't be any issues with respect to feature detection if python-gssapi is built against the old version but run against something newer.
  • Whether to use base's Heimdal or the something from ports strikes me as a maintainer decision, not one that we should be forcing as upstream. (We might encourage them to use something more reasonable given there's a packaging system in place, though.)
  • This means we're only concerned with behavior on e.g. pip install gssapi, not pkg install python3-gssapi (or so).
  • Based on IRC conversations, FreeBSD handles paths backward from what I'm used to in Linux - which is to say, /usr/local will be last. So our existing preference logic is flawed.

DTRT when the port exists certainly seems the most attractive. If other platforms are affected, we can just expand the breadth of the check. The check could also be made conditional on whether /usr/local/bin is in $PATH to begin with (which gives the override) - but I'm not opposed to an env var or flag if they're needed.

Then the problem would become turning off the flag conditionally at build-time.

@frozencemetery
Copy link
Member

I guess the other question is whether we want to support the heimdal that's in base. I'd taken it as a given, but upon reflection I'm not so sure.

frozencemetery added a commit to frozencemetery/python-gssapi that referenced this issue Nov 19, 2020
Base has heimdal-1.1.0 at the time of writing, while ports have
krb5-1.18.2 and heimdal-7.7.0.

Related: pythongssapi#228

Signed-off-by: Robbie Harwood <rharwood@redhat.com>
frozencemetery added a commit to frozencemetery/python-gssapi that referenced this issue Nov 19, 2020
Related: pythongssapi#228

Signed-off-by: Robbie Harwood <rharwood@redhat.com>
frozencemetery added a commit to frozencemetery/python-gssapi that referenced this issue Nov 19, 2020
Base has heimdal-1.1.0 at the time of writing, while ports have
krb5-1.18.2 and heimdal-7.7.0.

Related: pythongssapi#228

Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants