Edge-home-orchestration-go: [Discussion] Devons-nous rectifier SecurityMgr ? (Traitement des données sensibles)

@tdrozdovsky Plus, pourriez-vous rectifier si err est utilisé sur notre plateforme ?

https://github.com/lf-edge/edge-home-orchestration-go/blob/22ce49b4b76ae78dfb75e14ef64399e5805c7d02/src/orchestrationapi/orchestration_api.go#L180

@tdrozdovsky Cela est dû à mon analyse en cours avec l'outil lgtm comme suit.

https://lgtm.com/projects/g/lf-edge/edge-home-orchestration-go/alerts/?mode=list

Personnellement, je pense que les données sensibles sont renvoyées par un accès à passPhraseJWTPath . Qu'est-ce que tu penses? @tdrozdovsky

https://github.com/lf-edge/edge-home-orchestration-go/blob/22ce49b4b76ae78dfb75e14ef64399e5805c7d02/src/controller/securemgr/authenticator/authenticator.go#L70

Cela pourrait être le même risque de sécurité potentiel que ci-dessous.

https://github.com/lf-edge/edge-home-orchestration-go/blob/22ce49b4b76ae78dfb75e14ef64399e5805c7d02/src/controller/securemgr/authenticator/authenticator.go#L84

Bon point, je connais et me souviens de ce problème de sécurité.

Ceux-ci informent uniquement d'une tentative infructueuse de création du fichier passPhraseJWTFilePath .
Mais bien sûr, stocker de telles informations dans des fichiers (passPhrase, edge-orchestration.key, etc.) est un risque pour la sécurité.
Je pense qu'à l'avenir, cela devrait être résolu avec un stockage sécurisé ou avec un système de contrôle d'accès tel que : SeLinux, SMACK, etc.

Merci pour le rappel

@tdrozdovsky Merci d'avoir accepté ma suggestion. Je viens de vous confier ce problème. Nous sommes impatients de voir votre autre contribution précieuse bientôt!

@tdrozdovsky Plus, pourriez-vous rectifier si err est utilisé sur notre plateforme ?

https://github.com/lf-edge/edge-home-orchestration-go/blob/22ce49b4b76ae78dfb75e14ef64399e5805c7d02/src/orchestrationapi/orchestration_api.go#L180

J'ai fait des recherches en utilisant la variable err . La gestion des erreurs est effectuée ci-dessous.

if len(deviceScores) <= 0 {
        return errorResp
} else if deviceScores[0].score == scoringmgr.INVALID_SCORE {
    return errorResp
}

Un traitement supplémentaire rendra le code plus complexe.

Par conséquent, je suggère d'ignorer la variable err .

    deviceResources[i].score, _ = orcheEngine.GetScoreWithResource(dev.resource)

@tdrozdovsky Plus, pourriez-vous rectifier si err est utilisé sur notre plateforme ?
https://github.com/lf-edge/edge-home-orchestration-go/blob/22ce49b4b76ae78dfb75e14ef64399e5805c7d02/src/orchestrationapi/orchestration_api.go#L180

J'ai fait des recherches en utilisant la variable err . La gestion des erreurs est effectuée ci-dessous.

if len(deviceScores) <= 0 {
      return errorResp
} else if deviceScores[0].score == scoringmgr.INVALID_SCORE {
  return errorResp
}

Un traitement supplémentaire rendra le code plus complexe.

Par conséquent, je suggère d'ignorer la variable err .

  deviceResources[i].score, _ = orcheEngine.GetScoreWithResource(dev.resource)

@tdrozdovsky C'est raisonnable. ^^ Pourriez-vous suggérer le PR concernant cela?