Native golang puts unique buildids into a .note.go.buildid section, with a much longer textual string than our normal 20-byte blob. debuginfod would need to add these to the index, and golang debuginfo consumers would have to learn to pass it. hex-encoding the textual golang buildid should make it fit right into the webapi, instead of worrying about '/' characters embedded inside. RHEL packaged golang binaries get a normal gnu-style buildid also as a part of package postprocessing, so this functionality may not be required there.
Debuginfod can scan rpms including golang executables, debuginfo, and source and serve them so long as the golang binary has an associate gnu build.
(In reply to Noah Sanci from comment #1) > Debuginfod can scan rpms including golang executables, debuginfo, and source > and serve them so long as the golang binary has an associate gnu build. Debuginfod functions with golang binaries so long as the binary has an associated .note.gnu.build-id