-
Notifications
You must be signed in to change notification settings - Fork 7
Code quality, unit tests, exceptions, scopes, etc. #51
Conversation
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.
Hello @kasahiti, thank you for your contributions! I made a quick inspection.
Most changes you propose are a very nice code cleanup. Some of them, however, require additional work.
Please let me go through this PR with @romanstrobl first. We need to decide if it is easier for us to ask you for implementing the changes and accept the PR (in such case, we will need to ask you to fill in our contributor license agreement), or open isolated issues and fix them separately on our end.
sike-java/src/main/java/com/wultra/security/pqc/sike/crypto/RandomGenerator.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/crypto/Sike.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/math/optimized/Fp2PointProjective.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/model/EncryptedMessage.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/math/optimized/fp/Fp2ElementOpti.java
Show resolved
Hide resolved
I can implement the changes on this draft without problem if it is easier for you. Do not hesitate to ask me ! |
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.
We are getting there - still several issues to fix! 🙂
sike-java/src/main/java/com/wultra/security/pqc/sike/math/optimized/fp/Fp2ElementOpti.java
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/model/EncryptedMessage.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/crypto/RandomGenerator.java
Outdated
Show resolved
Hide resolved
sike-java/src/main/java/com/wultra/security/pqc/sike/math/optimized/fp/Fp2ElementOpti.java
Outdated
Show resolved
Hide resolved
@@ -44,7 +46,7 @@ public static String toOctetString(BigInteger n, int length) { | |||
char[] chars = hex.toCharArray(); | |||
int expectedLength = length * 2; | |||
if (chars.length > expectedLength) { | |||
throw new InvalidParameterException("Number is too large, length: " + chars.length + ", expected: " + expectedLength); | |||
throw new InvalidParameterException(Constants.Exceptions.NUMBER_TOO_LARGE + ", length: " + chars.length + ", expected: " + expectedLength); |
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 "partial localization" seems a bit weird to me. If we externalize the strings (as a part of a "programming figure skating":)), we should probably stick to it and use MessageFormat
(also, everywhere else where we append some string like this).
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/text/MessageFormat.html
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.
Would something like this be ok ? :
MessageFormat form = new MessageFormat("{0}, length: \"{1}\", expected: {2}.");
Object[] args = {Constants.Exceptions.INVALID_SECRET, chars.length, expectedLength};
throw new InvalidParameterException(form.format(args));
I've never really used MessageFormat
.
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.
@kasahity In situations like this, I usually look at what the JDK team does to see if what I do is "an improvement" or just "a change". JDK team uses inline Strings when throwing exceptions, see: https://github.com/openjdk/jdk/search?q=throw+new
So I think that one option is to fully externalize Strings and use MessageFormat
like this:
// Constants.Exceptions.NUMBER_TOO_LARGE = "Number is too large, length: {1}, expected: {2}."
throw new InvalidParameterException(
MessageFormat.format(Constants.Exceptions.NUMBER_TOO_LARGE , new Object[] {
chars.length, expectedLength
})
);
The other option is to revert this approach back to inline strings (which would probably be my choice since I am not sure that externalizing exception messages improves code readability):
throw new InvalidParameterException(
"Number is too large, length: " + chars.length + ", expected: " + expectedLength
);
@kasahiti I'd like to ask you: next time when you open a pull request, please try to keep the number of changes small. The current pull request is trying to fix many things, most of which are not errors, just code style issues. However, such issues are rather subjective. Furthermore, when the fixes are not well thought out, like in case of several changes included in this pull request, new issues may be caused. Examples from this pull request so far:
I suggest an alternative approach - when you find an issue in the code, either by yourself or using a code analysis tool (which seems to be the case in this pull request), at first raise an issue for each problem found in the code. One problem found = one issue. The developer who is responsible for the project can comment whether this is an issue or not and how it should be fixed. Then open pull requests which fixes individual issues. This way you will make the pull request more focused and there will be a smaller chance of causing new issues. It will make both your life and the developers life easier. The situation would be different if you were already contributing to the project for some time, but as a new contributor it is hard to think through the impacts of your changes. Thank you. |
@romanstrobl Thank you for your message. I would like to clarify the following points :
I will stick to your alternative approach! I'm sorry that I didn't follow all your best practices in this open-source project. Small suggestion : what about adding a |
@kasahiti You are right about the unit tests, the removal of |
@kasahiti I disagree about the usefulness of the error message change. Please check popular Java cryptography libraries, such as the Bouncy Castle library, Google Tink, and others, how the error messages in exceptions are created for low level cryptography code. Your change makes it harder to investigate exceptions when they occur. Your advantage about sharing a message is not practical, because it is a good idea to create unique error messages for each error, because this makes error investigation easier. |
@kasahiti Good point about |
I agree with @romanstrobl in general - I opened issues for the problems we should address: #52: Fix double-checked locking when constructing SecureRandom Let's focus on addressing those in this PR and nothing else. Regarding renaming Regarding the exceptions, I think using an inline String is the correct way to go:
Regarding the contributor guidelines... We currently have over 70 repositories (including the private ones) and we want to avoid placing guidelines in each of them. It is a good idea to prepare some guidelines, though! We will do this in the scope of the wultra/wultra-docs#12 (separate docs repo) and link this from the developer portal. At this moment, we only have a nice guide (inspired by Netbeans) team on how to report issues here: |
May I suggest to fix individual issues @petrdvorak raised in separate pull requests instead of this one? It will be easier to review the pull requests, we'll be fixing issues we agreed that they definitely are an issue, and the github history will not include commits which are partial attempts for fixes. We can close this pull request when all discussions are concluded and all issues are raised and handled. I already opened #55 for the |
@romanstrobl : agreed. I will close this draft, and fix the following issues in two separate PRs :
|
See :