Skip to content
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

start valid date a day before to account for timezone mismatch #209

Merged
merged 2 commits into from
May 7, 2020

Conversation

mikaelarguedas
Copy link
Member

apparently #205 broke Connext

Opening as draft for now pending testing and then CI

@@ -87,7 +87,7 @@ def build_key_and_cert(subject_name, *, ca=False, ca_key=None, issuer_name=''):
).serial_number(
x509.random_serial_number()
).not_valid_before(
utcnow
utcnow - datetime.timedelta(days=1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels hacky. Can we localize this? Even starting at midnight that day feels a little nicer, although is arguably just as arbitrary 😛 .

Copy link
Member Author

@mikaelarguedas mikaelarguedas May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's literally how it was before the refactor #138 😉

https://github.com/ros2/sros2/blame/9f22e40b25b7c1486fbbc6cfdfdb19267ba3e05b/sros2/sros2/api/__init__.py#L236

I'm fine with more or less whatever alternative arbitrary value you prefer to that one though

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm against this hack on principle.
Folks should really fix/synchronize there time sources.
I'm not sure what localizing it would do, given timezones are always changing in terms of geography and UTC offset dates.

Copy link
Member

@kyrofa kyrofa May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's literally how it was before the refactor #138 😉

Ha! Some genius thought it would be a good idea to throw away that hack 😇 .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikaelarguedas what is the actual breakage observed in connext?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! Some genius thought it would be a good idea to throw away that hack innocent .

At least your consistent in your perception of the hack 😉

what is the actual breakage observed in connext?

Oh my bad, it came up here ros2/ci#436 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm against this hack on principle.
Folks should really fix/synchronize there time sources.

I'm in agreement with that.

The one thing that's not clear to me is if it's a machine time sync issue or a connext issue that's not parsing it correctly.
The spec seems pretty clear about it though:

<!-- Format is CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm] The time zone may
be specified as Z (UTC) or (+|-)hh:mm. Time zones that aren't
specified are considered UTC.
-->
<not_before>2013-10-26T00:00:00</not_before>
<not_after>2018-10-26T22:45:30</not_after>

Copy link
Contributor

@sloretz sloretz May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one thing that's not clear to me is if it's a machine time sync issue or a connext issue that's not parsing it correctly.

Time seems ok. If it's off, it couldn't be more than a few minutes.

Time in permissions.p7s (time when I built test_security?)

      <validity>^M
        <not_before>2020-05-05T21:57:05</not_before>^M
        <not_after>2030-05-04T21:57:05</not_after>^M
      </validity>^M

Time on mini1 after running test_security tests

$ date
Wed May  6 15:02:58 PDT 2020

Current time UTC after formatting the above text 22:05 https://www.timeanddate.com/worldclock/timezone/utc

Copy link
Member Author

@mikaelarguedas mikaelarguedas May 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the info, this seems consistent with the idea that Connext is not parsing it properly and interpreting it as local time and not UTC.

If your clock was off, the date in the certificate will be off and the one extracted from the certificate and copied into the permission file would be off too. So I think it rules out a "time sync" issue.


We can find a nicer fix than this. I can try a thing or 2 tomorrow. If this fix the MacOS jobs I'm fine merging this and #205 for now

@codecov
Copy link

codecov bot commented May 6, 2020

Codecov Report

Merging #209 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #209   +/-   ##
=======================================
  Coverage   77.95%   77.95%           
=======================================
  Files          16       16           
  Lines         576      576           
  Branches       52       52           
=======================================
  Hits          449      449           
  Misses        107      107           
  Partials       20       20           
Flag Coverage Δ
#unittests 77.95% <ø> (ø)
Impacted Files Coverage Δ
sros2/sros2/api/_utilities.py 86.48% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d4b32b4...71cac20. Read the comment docs.

@mikaelarguedas mikaelarguedas marked this pull request as ready for review May 6, 2020 22:25
@mikaelarguedas
Copy link
Member Author

mikaelarguedas commented May 7, 2020

As #205 broke nightly builds (smart guy didnt run CI on the PR thinking all tests were disabled :| ) and that nicer alternatives don't seem to fix the issue Build Status.
I suggest we merge this to fix CI.

Below are some CI jobs (testing sros2 and test_security in Debug mode) 🤞

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS: not ran as tests are known to be failing
  • Windows Build Status

@sloretz
Copy link
Contributor

sloretz commented May 7, 2020

CI (testing just sros2 and test_security)

Not using ros2/ci#436 because the RTI version of openssl is installed on mini1 instead of osrf/homebrew-ros2#8

  • OSX (special job to run on mini1, which is only machine configured right now)
    • Build Status
  • Linux
    • Build Status
  • Linux amd64
    • Build Status
  • windows
    • Build Status

Copy link
Contributor

@sloretz sloretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI LGTM

Signed-off-by: Mikael Arguedas <[email protected]>
@mikaelarguedas
Copy link
Member Author

Alright this is going in, additional approvals came from @kyrofa and @ruffsl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants