Security Working Group - Wednesday October 27 - results

[Patrick Williams]

On Wed, Oct 27, 2021 at 03:31:37PM -0500, Patrick Williams wrote:
> On Wed, Oct 27, 2021 at 02:11:15PM -0500, Joseph Reynolds wrote:
> > On 10/26/21 8:12 AM, Joseph Reynolds wrote:
>  
> > 1 FYA: Changing the os-release BUILD_ID back to its default value of 
...
> > DISCUSSION:
> > 
> > This was resolved: the project defaults are not being changed.
> 
> Can we get some more details on this decision and a reply to the original ML
> post?  It seemed like almost everyone was on-board with the initial proposal and
> then a separate meeting with limited minutes was held which came to a different
> conclusion.  This is out of sync.

I missed Adriana's follow up and thus I also misunderstood what you wrote here.
I think what you intended (please correct me) to communicate was:

    "It appears that the direction of this is now to not make the change, so
    there is nothing for us to discuss."

> I don't understand how "deterministic builds" is directly related to security
> and I'd be immensely surprised if you could actually, today, build two images
> from the exact same git commit and end up with a byte-wise identical build as
> it is.

I still stand by this part.  Can someone educate me on how deterministic builds
is related to security?  And, are deterministic builds already a stated security
goal for us?

> If someone seriously wants a reproducible build on their system they can easily
> override this BUILD_ID value but it seems odd to me that:
> 
>     1. We would choose to purposefully deviate from what upstream Yocto does.
>     2. We would punt on the usability issue that originally pushed us down
>        pursuing any change here.

I'll move this to the original thread.


-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20211027/3ca1060e/attachment.sig>