-
Notifications
You must be signed in to change notification settings - Fork 291
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
CTAP library move #602
Merged
Merged
CTAP library move #602
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'll look into Coveralls, but you can probably review everything else. |
ia0
reviewed
Mar 7, 2023
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.
Now that we plan to have proper published libraries, I think we should change a few things:
- We should have one workflow per published library.
- We should specify the MSRV (minimal supported rust version) in the
Cargo.toml
underpackage.rust-version
. - The workflow of each library should have a strategy matrix to check build with the main toolchains: MSRV, latest stable, latest nightly.
EDIT: This can/should probably be in a follow-up PR. Just mentioning it here because those files were touched.
kaczmarczyck
force-pushed
the
full-move
branch
2 times, most recently
from
March 7, 2023 14:04
e441ed7
to
96c7a44
Compare
ia0
previously approved these changes
Mar 7, 2023
ia0
approved these changes
Mar 7, 2023
DavidKorczynski
pushed a commit
to google/oss-fuzz
that referenced
this pull request
Mar 8, 2023
OpenSK moved its CTAP code into a library, and all fuzzing has moved with it. As an advantage, we are now independent of other dependencies that restricted the compiler versions we could use. Therefore, we are now fuzzing on the latest nightly, hopefully fixing some issues that came with the compiler restriction before. The corresponding PR on our GitHub is google/OpenSK#602
2 tasks
eamonnmcmanus
pushed a commit
to eamonnmcmanus/oss-fuzz
that referenced
this pull request
Mar 15, 2023
OpenSK moved its CTAP code into a library, and all fuzzing has moved with it. As an advantage, we are now independent of other dependencies that restricted the compiler versions we could use. Therefore, we are now fuzzing on the latest nightly, hopefully fixing some issues that came with the compiler restriction before. The corresponding PR on our GitHub is google/OpenSK#602
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Moves all source files into its own library
I removed the
Cargo.lock
files from all libraries. As a consequence of this decision and the CTAP move, I changed the workflows andrun_desktop_tests.sh
a bit to reflect the new reality better.What might be interesting is that some tests and fuzzing now run on nightly. This is because some of our dependency and
cargo fuzz
don't work with Tock's older nightly, if we don't properly pin to older versions. I'd say we care that the OpenSK binary builds and works with the pinned toolchain, and our libraries build and test correctly with the latest toolchain. This might cause sudden and unrelated problems, but I think we want to know.Also I hope that the local test script runs on a fresh computer that doesn't have my Rust setup, with the new usage of 2 compiler versions. Otherwise, this PR contains no actual code changes.