Search for an existing bug:
Making good bug reports is a great way to help increase the software quality of GIMP. A good bug report provides unambiguous step-by-step instructions on how to reproduce the bug, what result is expected, and what the actual result is. Good bug reports make it easy for the developers to reproduce and fix the bug.
Related to bug reports are enhancement requests. An enhancement request should never be filed without prior discussion on the gimp-developer mailing list. This is to make sure that the enhancement requests that are filed are well-specified and aligned with the overall goals the developers have for GIMP.
Since correctly submitting a bug report requires you to use tools you may have not used previously, we have created two documents. The first helps you to learn GitLab issues, which is the bug system used by GIMP developers to track bug reports. If you are fixing a problem yourself, the second document shows you how to properly create and submit a patch.
Below are different links into GitLab which show you lists of open and closed bugs. You can also search manually, but these links are often more convienient. With the help of the lists below you should be able to see if the bug you have found has already been reported. If it has been reported, and you have additional information, please add a comment with the additional information!
Some bug reports may be related to security issues. For example, a file plug- in may be vulnerable to a buffer overflow allowing arbitrary code execution when loading an image. We believe that the best way to report these vulnerabilities is through our GitLab issues, as described above. This will ensure that the bug is reviewed and handled quickly (if necessary, a developer may decide to hide a sensitive bug report from other users until it is fixed). But if you really do not want to use GitLab for security reports and you do not mind some extra delay, you can also contact a limited set of GIMP developers by mail @gimp.org, using the special alias “security”. What will happen next is that a developer will review the issue and submit it in GitLab, usually as a hidden bug report only visible to developers. This will take a bit longer than if you directly submit the bug yourself, but we know that some people have a policy of not disclosing security vulnerabilities publicly, so we provide that address for their convenience.