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

Traffic Ops Portal/API CDN DNSSEC generate will break the world #2723

Closed
rob05c opened this issue Aug 21, 2018 · 0 comments
Closed

Traffic Ops Portal/API CDN DNSSEC generate will break the world #2723

rob05c opened this issue Aug 21, 2018 · 0 comments
Assignees
Labels
bug something isn't working as intended high impact impacts the basic function, deployment, or operation of a CDN Traffic Portal v1 related to Traffic Portal version 1

Comments

@rob05c
Copy link
Member

rob05c commented Aug 21, 2018

So, whether this is a Portal or API bug is a little ambiguous.

The problem:

  1. Riak DNSSEC keys effectiveDate must be a UNIX epoch.
  2. The cdn/dnsseckeys/generate endpoint documentation is completely missing the effectiveDate field.
  3. the Perl UI sends the effectiveDate as a string 2018-08-21+14:26:06, and the Perl UI server side converts that to a UNIX epoch.
  4. the Perl API accepts whatever effectiveDate type and value is sent, and puts that in Riak. You can send foo and it shove that in Riak.
  5. the Portal UI calls the Perl API with a string 2018-08-21 14:14:42. The API, per Fix server scripted graph #4, shoves this into Riak. The world subsequently breaks.

This is a problem today, in master, and has been since the Portal and API were written. This is a critical bug. Pressing the CDN DNSSEC "generate" button in the Portal will break all of DNSSEC for the given CDN.

Again, where the bug lies and how to fix it are a big ambiguous. The API endpoint is currently being rewritten in Go. Per the Robustness Principle, I propose:

  1. Making the API accept either an RFC3339 date string, a date string in the format that Perl currently sends, that the Portal currently sends, or a UNIX timestamp number.
  2. Changing the Portal to send a UNIX epoch.
  3. Documenting the long-existing API behavior of a UNIX epoch, but not documenting the other formats. APIs should be well-defined, and there should be One Right Way. This will document the behavior that's always existed, but not encourage or formally support the API accepting the other string timestamp format (which we're only putting in to fix the critically dangerous bug as robustly as possible).

This will:

  1. Fix the Go endpoint to behave how the undocumented Perl did, for any users correctly using the API.
  2. Fix the bug if a user deploys a new Traffic Ops, but not a new Portal
  3. Fix the bug if a user deploys a new Portal, but not a new Traffic Ops

Normally, users should always upgrade both TO and the Portal; but with a bug as critical as this, IMO it's worth the extra effort to make the bug fixable by just upgrading one of them.

@rob05c rob05c added bug something isn't working as intended Traffic Portal v1 related to Traffic Portal version 1 critical labels Aug 21, 2018
@rob05c rob05c self-assigned this Aug 21, 2018
rob05c added a commit to rob05c/trafficcontrol that referenced this issue Aug 21, 2018
@mitchell852 mitchell852 added the high impact impacts the basic function, deployment, or operation of a CDN label Nov 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something isn't working as intended high impact impacts the basic function, deployment, or operation of a CDN Traffic Portal v1 related to Traffic Portal version 1
Projects
None yet
Development

No branches or pull requests

2 participants