-
Notifications
You must be signed in to change notification settings - Fork 107
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
Address CodeQL warnings #558
Conversation
Note: There are 4 more issues
|
Hmmm, maybe I'd better close this pr since the network role does not have the codeql action added. What do you think, @richm? If so, sorry for the noise... |
I think the plan is for network to drop lgtm and use codeql, so they will need these fixes (unless they want to fix the code in some other way) - I guess it's up to @liangwen12year and the rest of the network team to decide what they want to do. |
@@ -3461,15 +3463,15 @@ def test_interface_name_ethernet_default(self): | |||
"""Use the profile name as interface_name for ethernet profiles""" | |||
cons_without_interface_name = [{"name": "eth0", "type": "ethernet"}] | |||
connections = ARGS_CONNECTIONS.validate(cons_without_interface_name) | |||
self.assertTrue(connections[0]["interface_name"] == "eth0") | |||
self.assertEqual(connections[0]["interface_name"], "eth0") |
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.
https://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertIs this is new in Python 2.7 - in the past we needed to support Python 2.6 - is this not necessary anymore?
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.
https://github.com/linux-system-roles/network/blob/main/contributing.md#where-to-start needs to be updated if we don't need to support Python 2.6 anymore.
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'm not sure if we still need to support 2.6, but if we don't, it should be a conscious, deliberate decision, in a separate PR. So for this change, please use a method that is compatible with 2.6
library/network_connections.py
Outdated
@@ -818,12 +818,14 @@ def connection_compare( | |||
try: | |||
con_a.normalize() | |||
except Exception: | |||
# It's already checked normalize is successful. |
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.
@thom311 what kind of exceptions are ignored 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.
Do you mean, which exceptions normalize()
is expected to throw? Probably they are all subtypes of GLib.Error
. But I don't know, and I don't want to find out -- because even if I check now, it's not clear that this check will hold for the future. The code really wants to catch and ignore any errors (that is, all Exception
types -- but not all BaseException
).
The code seems pretty clear in that. This is not a bug but done unintentionally. The code wants to normalize the profile, and if that fails, ignore the error. Any error.
The new code comment seems not clear to me. The proper comment would be # We ignore any errors that might happen
, which seems a pretty meaningless thing to say. This linter rule seems questionable to me, but OK, it needs to be worked around.
In the commit message, I would not say "fix issues" (but false positives or warnings) -- or does the patch also fix actual bugs? In that case, the actual bug fixes should be separate commits.
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 mean what can go wrong with normalization that it can be ignored but the connection is still fine without normalization so that we can safely ignore the error.
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 the commit message, I would not say "fix issues" (but false positives or warnings) -- or does the patch also fix actual bugs? In that case, the actual bug fixes should be separate commits.
Well, maybe "issues" means something quite benign (like a warning). In my ear, it sounds severe to fix "issues". I would not use the wording "fix issue" for adding a code comment. If the patch fixes actual issues, this patch should not be cluttered with low-severity changes. If it doesn't fix any bugs, the word "issue" seems unnecessarily alarming.
d0522e7
to
76e3274
Compare
library/network_connections.py
Outdated
@@ -2550,6 +2552,8 @@ def forget_nm_connection(self, path): | |||
] | |||
) | |||
except Exception: | |||
# Assume that NetworkManager is not present. |
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 is duplicating the doc string for the function, so IMHO it would be better to remove this and/or to properly ignore only the error cases when busctl is not available or if the NetworkManager dbus is not available instead of ignoring all exceptions. I feel guilty since this is technical debt from 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.
@liangwen12year, @thom311, could you please take a look at this exception? Thanks!
(If it's easier for you to work on, may I just revert this change and open an issue?)
self.assertRaises(ValidationError, v.validate, value) | ||
self.assertRaises( | ||
network_lsr.argument_validator.ValidationError, v.validate, value | ||
) |
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 others agree with this change, please put it into its own commit/PR, this seems to be a valid change that could be merged - also the other, similar lines. 👍
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.
Is this change due to a CodeQL error? If so, did CodeQL suggest this as the correction?
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.
CodeQL complains about duplicate import statements: Module 'network_lsr.argument_validator' is imported with both 'import' and 'import from'.
And no, CodeQL did not give us suggestions.
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.
https://github.com/linux-system-roles/network/security/code-scanning/13 has the suggestion to do
import network_lsr
ValidationError = network_lsr.argument_validator.ValidationError
to avoid importing it twice.
library/network_connections.py
Outdated
@@ -1493,8 +1495,7 @@ def check_activated(ac, dev): | |||
except AttributeError: | |||
ac_reason = None | |||
|
|||
if dev: | |||
dev_state = dev.get_state() | |||
dev_state = dev.get_state() if dev else None |
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 believe my previous comment was lost, if not, please excuse the duplicate.
CodeQL properly identifies this code as problematic. This change only makes CodeQL happy but does not really work towards refactoring the code to make it easier to understand. In the following lines dev
and dev_state
are used without checking whether they are None and I guess it is also not needed since there is some implicit understanding whether this function will actually be called with dev
not being a true value. I would rather see this function being properly refactored to make full use of CodeQL and creating additional benefit for the future.
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.
Thanks for the detailed explanation, @tyll ! Reverted.
@@ -271,6 +271,7 @@ def _validate_impl(self, value, name): | |||
except Exception: | |||
table = value | |||
except Exception: |
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.
@thom311 @liangwen12year what exceptions are we excepting here? Is it a ValueError from line 267? It seems like it could be excepted there specifically.
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 any exception can be raised here. The outer try/except should be dropped.
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.
Ah, I see now. So table = value
would be better in line 267, wouldn't it?
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 the value is already the int type, then the function int()
seems to me is not needed.
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.
isinstance()
does not check whether it's the same type, but of the type or a subtype.
the point of the code is of course to ensure that the result is really an int, and not a subtype.
"not needed", is if we never call the function with a subtype of int (bool
is also a subtype of int
, but already handled above).
I would leave it.
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.
What's the problem if it is a subclass? Regarding bool
, the check is there to avoid accepting boolean values but other subclasses are not rejected, so it is not clear to me why this would be useful.
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 idea is that the validation+normalization returns ... normalized values. That is, int
and not a subclass of an int
that was passed as input to the validation.
Anyway, since nobody is actually subclassing int
(aside bool
, which is handled already), it doesn't have any effect.
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.
Normalization can also mean to normalize it to int
or a subclass of it.
1d9bbd8
to
d889d95
Compare
library/network_connections.py - 'except' clause does nothing but pass and there is no explanatory comment. module_utils/network_lsr/argument_validator.py - 'except' clause does nothing but pass and there is no explanatory comment. module_utils/network_lsr/utils.py - Mixing implicit and explicit returns may indicate an error as implicit returns always return None. tests/unit/test_network_connections.py - Module 'network_lsr.argument_validator' is imported with both 'import' and 'import from'. - assertTrue(a == b) cannot provide an informative message. Using assertEqual(a, b) instead will give more informative messages. Signed-off-by: Noriko Hosoi <nhosoi@redhat.com>
@@ -818,12 +818,14 @@ def connection_compare( | |||
try: | |||
con_a.normalize() | |||
except Exception: | |||
# We ignore any errors that might happen |
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 comment does not provide any additional value since it just describes the code. The comment should include the reason why it is the right thing to do this 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 comment does not provide any additional value since it just describes the code. The comment should include the reason why it is the right thing to do this here.
The proper comment would be # We ignore any errors that might happen, which seems a pretty meaningless thing to say. This linter rule seems questionable to me, but OK, it needs to be worked around.
We could just say # Workaround CodeQL warning
, then?
Thank you for the discussions, @tyll, @richm, @liangwen12year, @thom311. |
library/network_connections.py
module_utils/network_lsr/argument_validator.py
module_utils/network_lsr/utils.py
tests/unit/test_network_connections.py