Keynames used for the secrets for Package Configuration Provider config instead of values

[Etsija]

We are using the same secret dosToken for both DOS Scanner and DOS Package Configuration Provider to enable the plugins to communicate with DOS back-end. The secret is defined in Docker Compose in secrets/compose/secrets.properties with (an example)

# DOS credentials
dosToken=1234567890abcde

1. For the Scanner job, the relevant part of the configuration object is

scanners: ['DOS'],
config: {
  DOS: {
    options: {
      readFromStorage: 'false',
      writeToStorage: 'true',
      url: 'https://dos/api/url/',
      frontendUrl: 'https://dos/frontend/url/',
      pollInterval: '5',
      timeout: '300',
    },
    secrets: {
      token: 'dosToken',
    },
  },
},

The value of dosToken is used properly for DOS scanner, which is also verified from PostgresDB from the table scanner_configuration_secrets.

2. For the Evaluator job, the relevant part of the configuration object is

packageConfigurationProviders: [
  {
    type: 'DOS',
    options: {
      url: 'https://dos/api/url/',
      timeout: '300',
    },
    secrets: {
      token: 'dosToken',
    },
  },
],

But we have verified from our back-end that instead of the value of dosToken, the server tries to use a literal key dosToken as the value, leading to communication failure with DOS back-end.

[Etsija]

If the reason for this behaviour is that the same secret cannot actually be reused for two different workers, this is not documented, nor does the back-end indicate this in any way in logs.

[sschuberth]

the server tries to use a literal key dosToken as the value

I'm very surprised that this is not always the case, also for the scanner. Is there maybe some config transformation or so configured for the scanner, that is not configured for the evaluator?

[haikoschol]

Looks like the function that resolves dosToken to the actual secret is WorkerContext.resolveConfigSecrets(). It's called in ScannerRunner.run() but not in EvaluatorRunner.run().

[Etsija]

Looks like the function that resolves dosToken to the actual secret is WorkerContext.resolveConfigSecrets(). It's called in ScannerRunner.run() but not in EvaluatorRunner.run().

That could explain why a literal dosToken is used as the value of the secret - because the real value is not resolved anywhere for the worker?

[Etsija]

the server tries to use a literal key dosToken as the value

I'm very surprised that this is not always the case, also for the scanner. Is there maybe some config transformation or so configured for the scanner, that is not configured for the evaluator?

I don't think so. This is DOS scanner config code, and for the DOS PCP, the config class is inlined to the same file as the implementation.

We have been using the same configuration structure as given in the description of this issue for both plugins for a long time now, with no problems.

[mnonnenmacher]

I will prepare a fix.

[Etsija]

I will prepare a fix.

Thanks! This is our (almost) last hurdle in integrating our solution into ORT server, so let's hope the fix isn't too complicated.

[Etsija]

Thanks @mnonnenmacher nice work fixing this. We have successfully integrated both our scanner and package config provider into ORT server now.