- 
          
 - 
                Notifications
    
You must be signed in to change notification settings  - Fork 4.6k
 
Harden SSE key generation #22018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harden SSE key generation #22018
Conversation
           | 
    
1cab40a    to
    0bc7ba5      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See inline comments
There might be cases where multiple requests trigger the key generation at the same time and the instance ends up with a non-fitting public/private key pair. Therefore the whole key generation should be locked. Other than that this makes sure that user key generation return values are properly validated. Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
5340f57    to
    00e6217      
    Compare
  
    | 
           🤖 beep boop beep 🤖 Here are the logs for the failed build: Status of 31784: failuremariadb10.4-php7.3Show full logmysql8.0-php7.2Could not fetch logs acceptance-app-files
 Show full log | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good beside the typo in the error message. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good indeed besides the typo
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
| 
           /backport to stable19  | 
    
| 
           /backport to stable18  | 
    
There might be cases where multiple requests trigger the key generation at the same time and the instance ends up with a non-fitting public/private key pair. Therefore the whole key generation should be locked.
Other than that this makes sure that user key generation return values are properly validated.
Somehow related to #8349 but I did not see any reason why the key might be overwritten during operation or upgrade from the existing code, so it is rather related than a fix for this. There is also not much we can do if the keys don't match. We could probably add a setupcheck to warn the admin if the modulus of both keys doesn't match, but this of course just helps to understand the issue.