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

Hotfix: Ignore invalid expire timer sync resets #2086

Merged
merged 4 commits into from
Mar 1, 2018

Conversation

gasi
Copy link
Contributor

@gasi gasi commented Feb 28, 2018

iOS omits expireTimer protobuf property to denote disappearing messages have been turned off. However, that doesn’t allow us to distinguish it from old clients that are not aware of this property. This change ignores these invalid values until we consistently use 0 to denote disabled disappearing messages.

  • Ignore non-numeric expireTimer values during contact sync. Long-term, we’ll use 0 to denote turning off expire timers.
  • Log what value expireTimer is set to.
  • Log changes to expireTimer in handleDataMessage until it uses ConversationController::updateExpirationTimer.

iOS inadvertently sends `null` `expireTimer` for groups during contact sync.
Ignore these resets until we have fixed the issue.

See: #2079
js/background.js Outdated
// TODO: Remove once
// https://github.com/signalapp/Signal-Desktop/issues/2079
// is resolved:
const isInvalidIOSExpireTimerReset = expireTimer === null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this work?

My understanding of the iOS bug was not that we set the field with a weird value, but that we just never set it.

Copy link
Contributor

Choose a reason for hiding this comment

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

In the future, we will use zero (`0`) to denote disabling of expire timer.
Copy link
Contributor Author

@gasi gasi left a comment

Choose a reason for hiding this comment

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

Annotated PR.

source,
receivedAt,
{fromSync: true}
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should dedupe the two identical code snippets above but I didn’t to reduce risk for the hotfix.

@gasi
Copy link
Contributor Author

gasi commented Mar 1, 2018

Tested this with Signal iOS 2.19.6 and Signal Android 4.15.5 and it ignores (and logs) all non-numeric expireTimer until we consistently use 0 to denote turning off expire timers.

@gasi gasi changed the title Hotfix: Ignore iOS group expire timer sync resets Hotfix: Ignore invalid expire timer sync resets Mar 1, 2018
Copy link
Contributor

@scottnonnenberg scottnonnenberg left a comment

Choose a reason for hiding this comment

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

Looks good. Also testing locally.

@gasi gasi merged commit caa579f into master Mar 1, 2018
@gasi gasi deleted the hotfix-ignore-ios-group-expire-timer-sync-resets branch March 1, 2018 01:02
scottnonnenberg added a commit that referenced this pull request Mar 1, 2018
Fixed: In some cases contact/group syncs would turn off disappearing
messages in all conversations (#2086)

Fixed: On initial setup, conversations with disappearing messages
enabled would be at the top of the conversation list (#2084)
scottnonnenberg added a commit that referenced this pull request Mar 1, 2018
Note: This release is equivalent to v1.5.2

Fixed: If interrupted in the middle of an import, next registration
would leave that imported data in the database (#2072)

Fixed: In some cases on OSX, View menu would not have Debug Log option
(#2089)

Fixed: In import/registration flow, choosing View -> Debug Log would do
nothing (#2089)

Fixed: In some cases contact/group syncs would turn off disappearing
messages in all conversations (#2086)

Fixed: On initial setup, conversations with disappearing messages
enabled would be at the top of the conversation list (#2084)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants