verify-sig.eclass: Workaround GPG problems with long TMPDIR #28180
Conversation
Force using TMPDIR=/tmp to workaround GPG failing when TMPDIR happens to be long enough to cause UNIX socket paths to exceed the system limit. Closes: https://bugs.gentoo.org/854492 Signed-off-by: Michał Górny <mgorny@gentoo.org>
Pull Request assignmentSubmitter: @mgorny @gentoo/github Linked bugsBugs linked: 854492 New packagesThis Pull Request appears to be introducing new packages only. Due to limited manpower, adding new packages is considered low priority. This does not mean that your Pull Request will not receive any attention, however, it might take quite some time for it to be reviewed. In the meantime, your new ebuild might find a home in the GURU project repository: the ebuild repository maintained collaboratively by Gentoo users. GURU offers your ebuild a place to be reviewed and improved by other Gentoo users, while making it easy for Gentoo users to install it and enjoy the software it adds. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
need assignment
| @@ -141,6 +141,9 @@ verify-sig_verify_detached() { | |||
| einfo "Verifying ${filename} ..." | |||
| case ${VERIFY_SIG_METHOD} in | |||
| openpgp) | |||
| # gpg can't handle very long TMPDIR | |||
| # https://bugs.gentoo.org/854492 | |||
| local -x TMPDIR=/tmp | |||
There was a problem hiding this comment.
does it definitely clean up after itself?
Pull request CI reportReport generated at: 2022-11-08 04:58 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
| @@ -141,6 +141,9 @@ verify-sig_verify_detached() { | |||
| einfo "Verifying ${filename} ..." | |||
| case ${VERIFY_SIG_METHOD} in | |||
| openpgp) | |||
| # gpg can't handle very long TMPDIR | |||
| # https://bugs.gentoo.org/854492 | |||
| local -x TMPDIR=/tmp | |||
There was a problem hiding this comment.
Are we sure we want /tmp directly and not an mktemp dir? That would head of certain classes of vulnerabilities, I guess, but I've not investigated the potential in depth.
There was a problem hiding this comment.
gemato does use a tempfile.TemporaryDirectory() on top of that.
Force using TMPDIR=/tmp to workaround GPG failing when TMPDIR happens to be long enough to cause UNIX socket paths to exceed the system limit.
Closes: https://bugs.gentoo.org/854492
Signed-off-by: Michał Górny mgorny@gentoo.org