Skip to content

GPG renderer is Linux specific #18877

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

Closed
cedwards opened this issue Dec 10, 2014 · 10 comments
Closed

GPG renderer is Linux specific #18877

cedwards opened this issue Dec 10, 2014 · 10 comments
Assignees
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Milestone

Comments

@cedwards
Copy link
Contributor

The GPG renderer seems to only work on Linux systems. I'm having trouble getting it to work on FreeBSD without changes to the actual code. For example, it refers specifically to a hard-coded path of /etc/salt/gpgkeys, whereas FreeBSD should be found in /usr/local/etc/salt/gpgkeys.

I've made that change on my local system and still having problems. I'll dig in more and may append to this ticket later, but to begin with the hard-coded path should be fixed.

@cedwards
Copy link
Contributor Author

After updating the path within the source I still get the following error trying to query GPG encrypted pillar data:

    _errors:
        - Rendering Primary Top file failed, render error:
        - __init__() got an unexpected keyword argument 'gnupghome'

@s0undt3ch
Copy link
Collaborator

There's a gpg package and a gpg-python or python-gpg on pypi... It's on the opts requirements txt in Salt's root. For the last problem, you either have the wrong package installed or and old version of it...

@cedwards
Copy link
Contributor Author

I'm using this version and release [https://pypi.python.org/pypi/gnupg] / [https://github.com/isislovecruft/python-gnupg]. Is this not correct?

@s0undt3ch
Copy link
Collaborator

This is the right one https://pypi.python.org/pypi/python-gnupg/0.3.7

@cedwards
Copy link
Contributor Author

Thanks for the tip. That library isn't / wasn't packaged for FreeBSD but I've submitted a patch for that. Seems to work as expected with 1) the source patch re: the path and 2) the correct python-gnupg library installed.

@s0undt3ch
Copy link
Collaborator

Awesome! Should we close this issue?

@cedwards
Copy link
Contributor Author

The hard-coded path issue still needs to be addressed (unless I address it at the port level)..

@rallytime rallytime added Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists labels Dec 11, 2014
@rallytime rallytime added this to the Approved milestone Dec 11, 2014
@s0undt3ch
Copy link
Collaborator

The hard coded path can either be handled at the port level, or we consider this a "bug" and make sure the path uses salt.syspaths in order to get the "right" path everywhere....

@cedwards
Copy link
Contributor Author

I think I'd prefer for this to be handled at the code level as a bug.

@s0undt3ch
Copy link
Collaborator

@rallytime already tagge this as a bug. It will be properly handled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Projects
None yet
Development

No branches or pull requests

5 participants