Move everest headers

[bjwtaylor]

Description

Move everest headers. Depends Mbed-TLS/mbedtls-framework#153. Contributes to #229 depends Mbed-TLS/mbedtls#10091 re-added old everest path to allow merge. Will be removed in a seperate PR.

PR checklist

• changelog provided
• framework PR not required
• mbedtls development PR provided Move everest headers mbedtls#10091
• mbedtls 3.6 PR not required because: No Backports
• mbedtls 2.28 PR not required because: No Backports
• tests not required because: No changes

[felixc-arm]

Generally LGTM (apart from 1 point + framework conflict). The approach of duplicating and then removing the headers seems fine to me 👍

[felixc-arm]

I can't quite see why the p256-m line was removed here.

[bjwtaylor]

Neither can I, good spot. I'll re-add it and we can see if it causes issues with the CI.

[felixc-arm]

You might have noticed already, but the ) here is causing some issues...

[gilles-peskine-arm]

I guess that 8706d77 is some kind of workaround to merge successive steps in different repositories with all steps having a green CI. But I don't understand why this particular workaround is needed. At the very least, the commit message should explain.

I'm surprised that duplicating files is the best workaround. I presume that this is because mbedtls expects those files in a particular location. But I'd expect to resolve this by first patching mbedtls to accept both the old location and the new location, then patching crypto to move the files, and finally patching mbedtls to stop accepting the old location. Why duplicate files instead?

Please describe the piecewise merge plan. Without this, I can't review effectively.

[bjwtaylor]

So, yes you are correct this a giant workaround to make each PR in the chain green, so it can be merged. Unfortunately we can't simply duplicate the paths as the dependencies are such that some of the tests search for the paths across repos. If they don't exist they will fail, as we cannot remove both the test and the path simultaneously the only way we can get it to merge cleanly is to duplicate the files and then remove once these paths are cleaned up. So briefly the merge plan is as follows:

1. Merge this PR Move everest headers #235, this basically duplicates the paths.
2. Merge Move everest headers mbedtls#10091, this redirects the path's in mbedtls to the new locations.
3. Merge Remove Old Everest Paths #303, remove the old paths.
   Let me know what you think.

[gilles-peskine-arm]

I've lost track.

some of the tests search for the paths across repos

Which tests are those?

[bjwtaylor]

So, I think the problem is caused by the paths in scripts/generate_visualc_files.pl from the mbedtls repo. Though there maybe another way round it. When I was re-orging it, I was coming up against a number of issues when getting this to merge cleanly and I was trying to avoid a 4th PR. So this seemed the fastest way to get this to work as a non dependent merge. We were discussing this in the morning standup and were thinking maybe we do this as a dependent merge, as the non dependent merge it too complex? However I thought now it's already split we may as well merge it as is. Let me know what you think though, if you don't like the way it currently works maybe we just go back to a dependent merge? I'm also starting to loose track with all the various reworking of PR's to get them to do non-dependent merges, so maybe it might be better to keep it simple? Let me know what you think though?

[gilles-peskine-arm]

Looking at generate_visualc_files.pl, the only thing I see that would break is that it insists that all (@thirdparty_header_dirs, @thirdparty_source_dirs) must exist. I think I understand the intent: if an entry doesn't exist, it's probably a typo and suggests that some necessary directory is missing. But we could temporarily relax the check. That wouldn't break the CI since we don't test with Everest or p256-m on Windows.

Incompatible merges are hard to understand and disrupt everyone, so I'd rather avoid them if there's another sensible way. And here so far I don't see anything complicated with a series of compatible merges.

[valeriosetti]

Superseded by #319