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

Expand security.exec.osEnv to make "hugo mod get" etc. work better out of the box on common OS setups #9333

Closed
dvdksn opened this issue Dec 30, 2021 · 22 comments · Fixed by #11217

Comments

@dvdksn
Copy link
Contributor

dvdksn commented Dec 30, 2021

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.91.2-1798BD3F+extended windows/amd64 BuildDate=2021-12-23T15:33:34Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

Yes

Observation

With Hugo v0.90.1 and earlier versions, I'm able to hugo mod get -u modules from a private registry from an on-prem gitlab instance. But with v0.91 and later, the hugo mod get -u command just hangs.

Steps to reproduce:

> hugo new site my-site
> cd .\my-site\
> Add-Content .\config.toml "
>>
>> [[module.imports]]
>> path = 'private.gitlab.instance/module/path'"
> cat .\config.toml
baseURL = 'http://example.org/'
languageCode = 'en-us'
title = 'My New Hugo Site'

[[module.imports]]
path = 'private.gitlab.instance/module/path'
> hugo version
hugo v0.91.0-D1DC0E9A+extended windows/amd64 BuildDate=2021-12-17T09:50:20Z VendorInfo=gohugoio
> hugo mod get -u
hugo: downloading modules …

Then it proceeds to hang on downloading modules. With a different Hugo version:

> hugo version
hugo v0.90.1-48907889+extended windows/amd64 BuildDate=2021-12-10T10:56:41Z VendorInfo=gohugoio
> hugo mod get -u
hugo: downloading modules …
go get: added private.gitlab.instance/module/path v0.0.0-20211230124009-6e6c34460737
hugo: collected modules in 2667 ms
@bep bep added this to the v0.92.0 milestone Dec 30, 2021
@bep
Copy link
Member

bep commented Dec 30, 2021

Can you check if setting HUGO_SECURITY_EXEC_OSENV=".*" OS env makes it work for you?

@dvdksn
Copy link
Contributor Author

dvdksn commented Jan 3, 2022

Can you check if setting HUGO_SECURITY_EXEC_OSENV=".*" OS env makes it work for you?

This worked! Should I run with this configuration, or set something more specific?

@khayyamsaleem
Copy link
Contributor

On my machine, without this environment variable, it started asking for my Username via an interactive prompt, despite having the .gitconfig replacement configurations in place to use SSH instead of https. Would fail on any hugo mod commands. After adding the env var as @bep mentioned, it was able to fetch the private modules as usual.

@UtkarshVerma
Copy link

I have also faced the same issue on the same Hugo version as OP. bep's suggestion works for me as well.
HUGO_SECURITY_EXEC_OSENV=".*"

@jmooring
Copy link
Member

@dvdksn @khayyamsaleem @UtkarshVerma

If you have some time, see if you can determine which environment variable(s) are required, starting with the usual suspects (HOME, LANG, USER, USERNAME, PWD, GOPROXY, etc.). Keep in mind that you might have to add more than one to security.exec.osEnv.

Reference: https://gohugo.io/about/security-model/#security-policy

@bep bep modified the milestones: v0.92.0, v0.93.0 Jan 12, 2022
@nathlaroche
Copy link

We're also having the same issue here, and Bep's suggestion works as well. Thanks for the workaround!

@jmooring
Copy link
Member

@nathlaroche Please see my previous comment, and help narrow this down if you can. Thanks.

@UtkarshVerma
Copy link

@jmooring I tried the above-mentioned env-vars, with no difference. What else should I test?

@jmooring
Copy link
Member

@UtkarshVerma Look at the env vars that are set on your system. With Linux that's the env command.

@UtkarshVerma
Copy link

@jmooring I investigated this bug. I narrowed down the requirements to the following:

export HUGO_SECURITY_EXEC_OSENV="(?i)^(PATH|XDG_CONFIG_HOME|SSH_AUTH_SOCK)$"

I can understand SSH_AUTH_SOCK being needed by go for authentication purposes, but XDG_CONFIG_HOME has me clueless.

@dvdksn
Copy link
Contributor Author

dvdksn commented Jan 21, 2022

On my end, I managed to narrow it down to these variables:

[security]
[security.exec]
osEnv = ['(?i)^(Path|USERPROFILE)$']

Thanks everyone for your support, I'll close this ticket as I consider the problem (user error) resolved.

@dvdksn dvdksn closed this as completed Jan 21, 2022
@UtkarshVerma
Copy link

UtkarshVerma commented Jan 21, 2022

Could you please not close this issue until this is fixed upstream.

By that, I mean until acceptable defaults have been set for the config.

@jmooring jmooring reopened this Jan 26, 2022
@acalvo
Copy link

acalvo commented Jan 26, 2022

FYI just adding HOME to de default osEnv worked in my case (CI environment).

@jmooring
Copy link
Member

@UtkarshVerma I'm pretty sure the XDG_CONFIG_HOME dependency is related to git, or to how you have configured git.

See https://git-scm.com/docs/git-config#FILES

@UtkarshVerma
Copy link

@UtkarshVerma I'm pretty sure the XDG_CONFIG_HOME dependency is related to git, or to how you have configured git.

See https://git-scm.com/docs/git-config#FILES

Yes, I do keep my git config in XDG_CONFIG_HOME.

@jmooring
Copy link
Member

jmooring commented Jan 26, 2022

Summarizing what we know so far...

The current (v0.92.0) default is:

[security.exec]
  osEnv = ['(?i)^(PATH|PATHEXT|APPDATA|TMP|TEMP|TERM)$']

Based on the comments above, it looks like this would need to be:

[security.exec]
  osEnv = ['(?i)^(PATH|PATHEXT|APPDATA|TMP|TEMP|TERM|HOME|SSH_AUTH_SOCK|USERPROFILE|XDG_CONFIG_HOME)$']

@bep bep modified the milestones: v0.93.0, v0.94.0 Mar 1, 2022
@bep bep modified the milestones: v0.94.0, v0.95.0, v0.96.0 Mar 9, 2022
@bep bep modified the milestones: v0.96.0, v0.97.0 Mar 24, 2022
@bep bep modified the milestones: v0.108.0, v0.109.0 Dec 14, 2022
@UtkarshVerma
Copy link

UtkarshVerma commented Dec 17, 2022

I tracked down the env vars which were exactly required in my case - $XDG_CONFIG_HOME and $SSH_AUTH_SOCK. Both of these are as @jmooring suggested. My Git config is placed in $XDG_CONFIG_HOME so hugo could only switch to SSH based authentication for cloning modules if this rule would be applied, which it wasn't:

[url "ssh://git@github.com/"]
	insteadOf = https://github.com/

After that, git subprocess should also be able to use the SSH socket, hence the need for $SSH_AUTH_SOCK. I hope these variables are added upstream.

The final regex with which I tested was:

(?i)^((HTTPS?|NO)_PROXY|PATH(EXT)?|APPDATA|TE?MP|TERM|XDG_CONFIG_HOME|SSH_AUTH_SOCK)$

@bep bep changed the title Downloading private modules not working with Hugo v0.91.0 or higher Expand security.exec.osEnv to make "hugo mod get" etc. work better out of the box on common OS setups Dec 17, 2022
@bep bep modified the milestones: v0.109.0, v0.111.0, v0.110.0 Jan 26, 2023
@bep bep modified the milestones: v0.111.0, v0.112.0 Feb 15, 2023
@bep bep modified the milestones: v0.112.0, v0.113.0 Apr 15, 2023
@UtkarshVerma
Copy link

Please let me know if you need additional information on this issue. #9333 (comment) has been working for me consistently. It would be great to have this fixed upstream.

@giuliohome
Copy link

giuliohome commented May 6, 2023

This is relevant for hugo modules from private (under adfs sso) gitlab repositories, when GOPRIVATE env is needed. Eventually I had to set osEnv = ['.*'] in the security section of toml configuration! A better error message hint would help.

[security]
  exec.osEnv =".*"

@bep bep modified the milestones: v0.113.0, v0.115.0 Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@rhcarvalho
Copy link
Contributor

I was having problems with Hugo Modules and a private git repository as well.

I have a insteadOf configuration in my .gitconfig, but that is ignored under hugo mod tidy, etc.

The fix is to add HOME to security.exec.osEnv -- I see it has been added and then removed in previous versions.

Is there a problem adding it there by default again? Right now, without HOME, it is harder to use Hugo Modules with private repositories.

@rhcarvalho
Copy link
Contributor

Upon further investigation, and as cited in previous comments, I also needed SSH_AUTH_SOCK to make fetching private repositories over SSH work.

So my hugo.toml became:

# other configs...

[security]
  [security.exec]
    osEnv = '(?i)^((HTTPS?|NO)_PROXY|PATH(EXT)?|APPDATA|TE?MP|TERM|GO\w+|HOME|SSH_AUTH_SOCK)$'

A consequence of putting this in our project config is that if the default ever changes, we won't automatically pick up the changes (could be seen as positive or negative).

dvdksn added a commit to dvdksn/hugo that referenced this issue Jul 6, 2023
To fetch modules from private repositories,
Hugo requires access to additional environment variables.
The exact environment variables depend on the operating system.

This change adds some variables that help address this issue,
for common OS setups. The default config now includes
the following environment variables:

- HOME
- XDG_CONFIG_HOME
- USERPROFILE
- SSH_AUTH_SOCK

Fixes gohugoio#9333

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
dvdksn added a commit to dvdksn/hugo that referenced this issue Jul 7, 2023
To better support private Hugo modules and automatically
launching a text editor on content creation, this change
adds the following environment variables to the default
security policy:

- HOME
- XDG_CONFIG_HOME
- USERPROFILE
- SSH_AUTH_SOCK
- DISPLAY
- LANG

Fixes gohugoio#9333

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
@bep bep closed this as completed in #11217 Jul 7, 2023
bep pushed a commit that referenced this issue Jul 7, 2023
To better support private Hugo modules and automatically
launching a text editor on content creation, this change
adds the following environment variables to the default
security policy:

- HOME
- XDG_CONFIG_HOME
- USERPROFILE
- SSH_AUTH_SOCK
- DISPLAY
- LANG

Fixes #9333
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants