I ran into JENKINS-62566 when trying to configure a SecretFile with the kubeconfig for a kubernetes cluster using the kubernetes plugin. This fails in an incredibly unobvious way, which took a lot of digging to troubleshoot.

Since the text of the exception is just the word `null`, the 'test config' button for the kubernetes cloud configuration page just displays the word 'null' in red text. This led me to believe the problem was in the kubernetes plugin's cloud component, but I couldn't figure out how it was throwing due to the exception not being logged at default log levels either. I originally assumed this was an issue with the kubeconfig file, or something wrong with cluster connectivity, until I'd ruled all that out successfully and created a new logger at ALL which showed the actual stacktrace in question, pointing to the AWS Secrets Manager credential provider plugin.

Finally, for ease of reproduction, I created a freestyle job in which I just used the file as a credential and saw the same stacktrace:

FATAL: null
java.lang.NullPointerException
	at io.jenkins.plugins.credentials.secretsmanager.factory.file.AwsFileCredentials.getContent(AwsFileCredentials.java:39)
	at org.jenkinsci.plugins.credentialsbinding.impl.FileBinding.write(FileBinding.java:54)
	at org.jenkinsci.plugins.credentialsbinding.impl.FileBinding.write(FileBinding.java:42)
	at org.jenkinsci.plugins.credentialsbinding.impl.AbstractOnDiskBinding.bindSingle(AbstractOnDiskBinding.java:39)
	at org.jenkinsci.plugins.credentialsbinding.Binding.bind(Binding.java:150)
	at org.jenkinsci.plugins.credentialsbinding.impl.SecretBuildWrapper.setUp(SecretBuildWrapper.java:87)
	at hudson.model.Build$BuildExecution.doRun(Build.java:158)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:516)
	at hudson.model.Run.execute(Run.java:1889)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:100)
	at hudson.model.Executor.run(Executor.java:433)
Finished: FAILURE 

While the documentation shows a FileCredential created by using awscli with the -secret-binary flag, it is not made obvious in the documentation that a SM secret created by using the AWS web console or the -secret-string flag to awscli is unsupported, and if I hadn't stumbled across JENKINS-62566 I would have no idea what was going wrong without a deep dive into the plugin source.

JENKINS-62566 was closed because it wasn't a common problem, but given how hard to troubleshoot it can be when credentials are used in system configuration, I'd love to see either a fallback where it gets the SecretString value if SecretBytes is null, or at the least, a more instructive stacktrace

I'd think the SecretBytesSupplier.get() method would want to `return SecretBytes.fromString(str)` on line 71 here instead of returning null.

I can try to toss together a PR for this with some test coverage if it's a wanted change; I'd think it would be expected that the contents of the secret will be available to people regardless of whether it is a binary or string.