-
Notifications
You must be signed in to change notification settings - Fork 28
Add kmod CI Workflow #237
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
Add kmod CI Workflow #237
Conversation
| kmod_ref: [ 'v33' ] | ||
| wolfssl_ref: [ 'master', 'v5.8.0-stable' ] | ||
| openssl_ref: [ 'openssl-3.5.0' ] | ||
| # Note: No WOLFPROV_FORCE_FAIL needed - kmod is only a signature parser, |
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.
If this is true, then are we actually testing wolfprovider?
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.
Because WP is used to parse it just doesn't verify. WPFF shouldn't have any effect on the parsing functions that are used so there is no reason to test WPFF. We should still test WP for the parsing functions however since WP does use these.
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.
WPFF shouldn't have any effect on the parsing functions
Can you elaborate on the reasoning behind this? I thought WPFF was our main mechanism for ensuring that WP is actually being used by the test.
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.
Yep it is. Honestly the main reason is for IGEL
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.
Any idea why we don't use WPFF in the parsing functions? Should we add it? Maybe @ColtonWilley can chime in 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.
Im not sure why we do not. This is a @ColtonWilley question for sure.
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.
@padelsbach Colton and I have verified that kmod does use openssl to be able to do the parsing operation d2i_PKCS7_bio but this doesn't dispatch to any real crypto implementation that would call wolfProvider. So Basically Kmod needs openssl but it doesn't actually call any provider functionality. Either way we need this workflow to be implemented for IGEL.
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 doesn't dispatch to any real crypto implementation that would call wolfProvider
So this doesn't actually call into wolfProvider? If that's true, why do we need this workflow?
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 with @padelsbach if there is no crypto usage this should not be a workflow
|
Jenkins retest this please Retesting to see if this is a consistent failure with FIPS |
Description
v33