You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 24, 2025. It is now read-only.
So, whether this is a Portal or API bug is a little ambiguous.
The problem:
Riak DNSSEC keys effectiveDate must be a UNIX epoch.
The cdn/dnsseckeys/generate endpoint documentation is completely missing the effectiveDate field.
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.
the Perl API accepts whatevereffectiveDate type and value is sent, and puts that in Riak. You can send foo and it shove that in Riak.
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:
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.
Changing the Portal to send a UNIX epoch.
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:
Fix the Go endpoint to behave how the undocumented Perl did, for any users correctly using the API.
Fix the bug if a user deploys a new Traffic Ops, but not a new Portal
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.
So, whether this is a Portal or API bug is a little ambiguous.
The problem:
effectiveDatemust be a UNIX epoch.effectiveDatefield.effectiveDateas a string2018-08-21+14:26:06, and the Perl UI server side converts that to a UNIX epoch.effectiveDatetype and value is sent, and puts that in Riak. You can sendfooand it shove that in Riak.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:
This will:
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.