Reporter plugins need access to secrets

[oheger-bosch]

Recently, the classes ScannerConfiguration and AdvisorConfiguration were changed to split the plugin-specific configuration into (plain) options and secrets, to make sure that secrets are not serialized into ORT results.

There are also some reporter plugins - namely FossIdReporter that require secret credentials to obtain the required data. Therefore, the ReporterConfiguration class and the plugin interface for reporters should be changed accordingly.

[sschuberth]

Hmm, I think we might gave a design issue here: Is it really a good idea to generally give any reporter that's available in the classpath access to the secrets e.g. used by my private scanner? Could we instead find a way for e.g. scanners to expose their secrets only to specific reporters?

[oheger-bosch]

Hmm, I think we might gave a design issue here: Is it really a good idea to generally give any reporter that's available in the classpath access to the secrets e.g. used by my private scanner? Could we instead find a way for e.g. scanners to expose their secrets only to specific reporters?

It is not the case, that a reporter plugin can access all secrets. It is rather passed its specific PluginConfiguration object. This object contains only the secrets that have been configured for this plugin. The situation is analogous to the scanner and advisor plugins, so I don't think that we have a special security issue here.

[sschuberth]

This object contains only the secrets that have been configured for this plugin.

Ah, I though you're suggesting e.g. the FossId reporter to have access to the secrets of the FossId scanner.

But if reporters just should have the new options / secrets themselves, this issue pretty much related to #6507 for the reporters, right?

[oheger-bosch]

But if reporters just should have the new options / secrets themselves, this issue pretty much related to #6507 for the reporters, right?

True, if reporter plugins implemented the TypedConfigurablePluginFactory interface, they would have access to secrets. This would be a slightly bigger refactoring, because of the additional factory class that needs to be added to each Reporter implementation.

I can open a draft PR with what I have currently. Then we can decide if this is a valid intermediate step or if the full refactoring should be done.

[oheger-bosch]

Here is the PR: #7837

[sschuberth]

This would be a slightly bigger refactoring, because of the additional factory class that needs to be added to each Reporter implementation.

Not only that, but reporter-specific options should also get moved from "first-class" CLI options to config.yml options (which imply CLI options) then.

[oheger-bosch]

Hm, not sure whether I fully understand this. Currently, the reporter command already reads options from the configuration, but those can be overridden via the command line IIUC. I guess you mean something different?

[sschuberth]

but those can be overridden via the command line IIUC. I guess you mean something different?

Actually, I meant quite that: Any config.yml option can be overridden on the CLI via -P, so having dedicated reporter-specific CLI options available is not necessary and probably only creates confusion regarding precedence. There should be only one way to overwrite reporter options from the CLI, and this code should be removed after your PR:

ort/plugins/commands/reporter/src/main/kotlin/ReporterCommand.kt

Lines 184 to 195 in 1534d39

	private val reportOptions by option(
	"--report-option", "-O",
	help = "Specify a report-format-specific option. The key is the (case-insensitive) name of the report " +
	"format, and the value is an arbitrary key-value pair. For example: " +
	"-O PlainTextTemplate=template.id=NOTICE_SUMMARY"
	).splitPair().convert { (format, option) ->
	require(format in Reporter.ALL.keys) {
	"Report formats must be one or more of ${Reporter.ALL.keys}."
	}
	format to Pair(option.substringBefore("="), option.substringAfter("=", ""))
	}.multiple()

[oheger-bosch]

Thank you for explaining.