>> Yes, that could be a solution for the problem we discuss, providing 
>> both integrity and confidentiality, without any major OpenBMC 
>> development necessary - but it would mean more operational burden for 
>> BMC admins. The problem with SCP/SFTP in this context is that for 
>> this to work in the same manner as TFTP, the BMC must be an SSH 
>> client - i.e. have some sort of identity/credentials for the SCP/SFTP 
>> server provisioned first. That might not be the easiest solution to 
>> setup, but it's of course possible and can be automated if OpenBMC 
>> provides respective config knobs.
>>
>> Existing ways we have in code-update.md either don't require 
>> credentials (TFTP), so being a client is easy, or are not making a 
>> "client" from BMC, it's the admin who uploads stuff (SCP/REST).
>
> Yes, that's what I was thinking.  (And no, I am not going to recommend 
> setting up a SCP or SFTP server that allows anonymous access.)
>
> This highlight the need for OpenBMC to put together a guide to 
> provisioning your BMC.    Such as guide would give us a place to talk 
> about uploading to the BMC SSH client certificates needed to access 
> and download the firmware images.
>
> - Joseph 

Agree, the provisioning guide could be a good point to have this 
discussion. However I beieve updates in general is a broader and more 
"operational" (i.e. "continuous" as opposed to provisioning being rather 
"one-time") topic, so the approach in the organization/of a given BMC 
admin can change and I believe whatever configuration mechanism we 
develop for this (if at all), should be available at any point during 
BMC lifetime, not only at provisioning, and be architected respectively.


regards,
Alexander