-
Notifications
You must be signed in to change notification settings - Fork 36
Mechanism to error out on removed configuration options #164
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
Mechanism to error out on removed configuration options #164
Conversation
1940e16
to
c00ddf3
Compare
c00ddf3
to
dffa814
Compare
2aa51b4
to
28e29ba
Compare
28e29ba
to
c2d9805
Compare
c2d9805
to
11f8e95
Compare
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Run a C compiler, not just the preprocessor. This allows capturing static assertions (`MBEDTLS_STATIC_ASSERT`). Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use the latest patch release at this time, namely 3.6.4. This is the last release made before the first non-beta release of the next major version. ``` scripts/save_config_history.sh mbedtls-3.6.4 3.6 ``` Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use today's `development` head and the crypto submodule there. We may update this again before the release. Once the release is out, we should update to the release tags. ``` scripts/save_config_history.sh 06bae1e110ce71b44c3f4d17974d24feea4d2a92 1.0 scripts/save_config_history.sh 07912c9e3693d7ae5d62bfcbb8aef4daa9e3cafc 4.0 ``` Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
11f8e95
to
8943efa
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.
Looks pretty good to me, the only blockers are the two issues with option handling in the shell script.
I have generated the files locally using the instructions in the commit messages and verified with sha256sum that I'm getting identical outputs.
before_generator.write(os.path.join(root, | ||
'include', | ||
branch_data.header_directory, | ||
'config_check_before.h')) |
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.
In general, I don't think "before" without saying before what is a great name. Suggesting before_user
here.
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.
This used to be before/after [the user config] and changed to before/user/final. I agree that the names aren't ideal, but I don't think before_user/user/final
is better. It should be before_user/after_user/final
. Or it could be just before_user/after_user
, since final
is currently unused. But then we could go back to before/after
since there's only one thing to be before/after and it's a pretty natural one (we're doing config checks, so before/after refers to reading the config.)
I'm not very happy about the “user” part, whether on its own or in after_user
, because of the ambiguity between “the whole configuration provided by the user” and “MBEDTLS_USER_CONFIG_FILE
(or crypto equivalent) specifically”. Any ideas for a better name?
Note that we'd better commit to names now, because once Mbed-TLS/TF-PSA-Crypto#269 is merged, changing the names will require back-and-forth between the framework and the consuming branches,
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.
I've handled (or replied to) all your comments except this name change. A name change will require coordinated action over the three PR so I'd rather get a consensus first.
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.
I don't think
before_user/user/final
is better. It should bebefore_user/after_user/final
.
Yes, that's how I meant it, but didn't express it clearly.
I'm not very happy about the “user” part, whether on its own or in
after_user
, because of the ambiguity between “the whole configuration provided by the user” and “MBEDTLS_USER_CONFIG_FILE
(or crypto equivalent) specifically”.
Good point. I'm not sure what would be a better name. Perhaps "input"? Or "editable" (sounds a bit weird, but perhaps less ambiguous)? Or config_file
? Ah, perhaps editable_config_files
- a bit long, but probably clearer: the plural suggests it includes the main config.h
and MBEDTLS_USER_CONFIG_FILE
if it exists.
For "final", I'm wondering about "after_adjust"? But I'm happy with "final" too.
A name change will require coordinated action over the three PR so I'd rather get a consensus first.
Sure. Also, if we can't converge on better names quickly, I wouldn't block this series of PRs over this. Since this is internal and unlikely to be edited every other day, we can probably just compensate sub-optimal naming with comments.
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.
Given that the main users of this script would be us, I think we can get away with it with a comment, just giving some nomeclature on the names, rather than effectively changing the code.
If as we polish it we come up with better ones, we can do it later.
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.
Since we're pressed for time and we don't have a consensus on better names, I'm going ahead and merging with the current names.
There's only one subproject and that's unlikely to change, so being able to specify a subproject at runtime is overkill. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
"""Checker for an internal-only option.""" | ||
|
||
|
||
class SubprojectInternal(Checker): |
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.
The final
file, introduced in a previous pull request, is currently unused. It was strongly needed in an earlier incarnation (back when the config checks were public headers, included every time build_info.h
was included, we needed to clean up macros defined by the previous files). Now there's no immediate need for it, but it might become useful in the future. For example, I think it would be needed if we wanted to reject user config files that try to #undef
something (which is not a feature, currently, because I'm guessing that nobody does that).
At this point, removing it is more work than leaving it in, which is why I've kept it in.
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.
LGTM, thanks!
I don't consider the remaining naming issue to be a blocker: I'm happy to improve naming if we quickly find a scheme we can all agree on, otherwise getting this merged in time for the release seems more important than getting internal names right.
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, just one note on portability of the newly introduced code.
for header in "$@"; do | ||
git -C "$project_root" show "$commit:$header" >>"$temp_file" | ||
done | ||
sed -n 's![/ ]*# *define *\([A-Z_a-z][0-9A-Z_a-z]*\).*!\1!p' <"$temp_file" | |
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.
Given that we just introduced config_checks_generator.py it would make sense to do this whole functionality in python, and not rely on external tools like sed and temporary files?
This is even more important if we consider that sed is not using the same syntax across GNU and BSD/MacOS
It would only need to pull regex, subprocess and argparse
The equivalent would be.
parsing_rex = re.compile(r'^[\s/*]*#\s*define\s+([A-Za-z_]\w*)\b', re.MULTILINE)
I wont be blocking the PR for this
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.
I agree that for maintainability this script should be probably in Python. But I had started to write it in sh, and we needed the result urgently, so I polished and commited the sh code that I had rather than rewrite the thing in Python.
This script won't run on the CI and we'll probably only ever run it manually a couple of times each time we make a new major version. I almost left it in a commit message, but the adjust part was getting a bit too complicated for that.
AFAICT I haven't used any non-POSIX sed feature.
Set up a mechanism for erroring out if users try to use removed options in their configuration file. Resolves Mbed-TLS/mbedtls#10147. Specification in #184.
In this PR:
config_checks_generator.py
: classes for options of a subproject.Status: ready for review. If the consuming brnaches require extra work in the framework, I'll do that in new commits.
PR checklist