This is not a bug, as far as I can tell, or at least your description does not give me confidence this is a bug.

I think you want to control where the git plugin (and possibly the rest of Jenkins) writes its temporary files. Have you tried adjusting the values of the environment variables (TMP) and properties (java.io.tmpdir) from the command line, or from the environment which starts the Jenkins server and / or the relevant slave agent? Refer to stackoverflow for one source of that information.

If you have made those adjustments and still see a requirement for a specific directory, please provided a detailed list of the steps you take to show the problem. For an even better chance of having your concerns addressed, submit a pull request to the git plugin and/or git client plugin with a test which shows the failure, and a code change which fixes the failure.

If you still believe this is a bug, please provide the additional information suggested in how to report an issue

markewaite Since version 2.0.0 of the git-client, both git SSH and HTTPS authentication requires that Jenkins has such permission on the Temporary folder.

1. User who were using HTTP/s authentication and had restriction on the temp folder would be impacted by this change.

• Can we maybe add a notice/warning on the plugin documentation about this ?

2. It is common and a good practice to restrict execution on the temporary folder

• Maybe we should move this file to Workspace temp folder or re-implementing in some other way that is *not forcing jenkins users to violate best practices* ?

Thanks for the recommendation. You're welcome to update the documentation on the wiki to include that information.

You're also welcome to submit a pull request to propose alternate techniques for temporary file handling. Could you also include references to those locations which describe it as a common and a good practice to restrict execution on the temporary folder? That's new information for me. I'd like to read more about it.

Thanks for the answer. I am gonna update the wiki accordingly.

> Could you also include references to those locations which describe it as a common and a good practice to restrict execution on the temporary folder?

Also some documentation suggests that setting the /temp to no exec is a standard recommendation for hardening a linux machine

https://www.cyberciti.biz/faq/linux-add-nodev-nosuid-noexec-options-to-temporary-storage-partitions/
https://static.open-scap.org/ssg-guides/ssg-sl7-guide-index.html)

> You're also welcome to submit a pull request to propose alternate techniques for temporary file handling.

I wanted to open the discussion about this to understand what could be the best approach.

A workaround is to set the temporary folder via the system property `-Djava.io.tmpDir=<pathToDirectory>` on the master and the agents. That way, the content executed by Jenkins is somehow contained... This is documented here: https://support.cloudbees.com/hc/en-us/articles/115003082887-Jenkins-with-Git-Client-needs-permission-on-Temporary-directory

My ultimate preference would be to not use the temporary directory for scripts, but that requires a significant change to the authentication techniques in the plugin. When submodule authentication was added in git client plugin 2.0.0, it switched from one form of using the temporary directory to another, but didn't remove the need to write sensitive information to files in the temporary directory.

There are other ways to send secrets into git which don't require that the plugin write a script (or a data file) to the file system. I started on a development line (part of PR207 and PR207 exploration) which would switch from a script in the temporary folder to a data file in the temporary folder, but have not had time to complete that work. If you're interested in that area and have time available to investigate, that would resolve other bugs as well (like the report that you can't embed an ampersand in a Linux username / password pair).

Thanks for the link to these PRs markewaite.
I updated the Wiki for Git Client plugin by the way.

Another workaround is to use JGit as the git implementation instead of command line git. Add JGit as an implementation from the Global Tools configuration, then each freestyle job will include a pick-list to select the git implementation to use for that repository. Pipeline jobs can select the implementation with an argument to `checkout`