Avainsanana Mattermost

”Unlock increased productivity” spam

15. toukokuuta 2022 klo 15.42
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Summary

I’m getting these unrequested emails from my self-hosted instance, with no apparent way to disable them. This is bad, bad behavior.

Steps to reproduce

Host an instance running Mattermost 6.6.1. Leave it ”collecting a bit of dust”.

Expected behavior

Not to get spammed with unwanted emails.

Observed behavior (that appears unintentional)

Screenshot from 2022-05-15 15-35-12

Vastaa viestiin sen kontekstissa (Github)

Signing (public) key missing from Keybase

17. huhtikuuta 2022 klo 18.11
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Keybase, Mattermost

Summary

Keybase key for verifying the tar archive’s signature is missing.

Steps to reproduce

  1. try to download https://keybase.io/mattermost/key.asc

Expected behavior

Get a public key to verify the tar archive’s signature.

Observed behavior (that appears unintentional)

404 not found

Vastaa viestiin sen kontekstissa (Github)

auth login exits with status 0 even for a non-working URL

4. helmikuuta 2022 klo 11.14
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Steps to reproduce

Note the literal use of example.com here; don’t replace it with an actual, working MM instance URL.

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl  auth login http://example.com --name example --access-token 123456890abcdefghijklmnopq`
# echo $?

What I expect happen

For a non-zero exit status to be printed.

What happens instead

The exit status is 0.

Vastaa viestiin sen kontekstissa (Github)

–config with auth login only works correctly with ”config” as filename

30. tammikuuta 2022 klo 16.24
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Go, Mattermost

Issue

When a custom configuration file is supplied via --config to auth login, and reading credentials from the given file doesn’t succeed, an attempt is made to create the supplied directory path. This path is constructed by stripping a fixed ”config” (without a directory separator) from the user-supplied path.

When the custom configuration file doesn’t exist, this results in an unnecessary mkdir when the given filename ends with the hardcoded value of ”config” (case 1 below), or that plus a ”is a directory” failure when it doesn’t (case 2).

If the custom configuration file does exist, the useless mkdir is still triggered when the given filename ends with the hardcoded value of ”config” (case 3), or a ”not a directory” failure when it doesn’t (case 4).

Cause

The problematic mkdir call is issued here. I have no experience in Go, but instead of the TrimSuffix() call nested on that line, I think there should be a Go equivalent of a dirname instead, using the user-supplied path as parameter, and without referencing the value of configFileName (the source of the hardcoded ”config”).

Steps to reproduce

Case 1

A useless, empty mmctl_ directory gets created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/mmctl_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:27 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:27 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:27 mmctl_
-rw-------  1 mattermost mattermost   244 tammi  30 15:27 mmctl_config

/tmp/mmctl_test/mmctl_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:27 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:27 ..

Case 2

Saving the credentials fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com--name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: cannot save the credentials: open /tmp/mmctl_test/test: is a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 20
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:31 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:31 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:31 test

/tmp/mmctl_test/test:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:31 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:31 ..

Case 3

A useless, empty test_ directory is created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test_config
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:58 .
drwxrwxrwt 22 root       root       12288 tammi  30 15:58 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:58 test_
-rw-rw-r--  1 mattermost mattermost   244 tammi  30 15:58 test_config

/tmp/mmctl_test/test_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:58 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:58 ..

Case 4

Saving the credentials again fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: mkdir /tmp/mmctl_test/test: not a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 16
drwxrwxr-x  2 mattermost mattermost  4096 tammi  30 16:00 .
drwxrwxrwt 22 root       root       12288 tammi  30 16:00 ..
-rw-rw-r--  1 mattermost mattermost     0 tammi  30 16:00 test

Vastaa viestiin sen kontekstissa (Github)

–quiet not honored by auth login (possibly others)

30. tammikuuta 2022 klo 15.02
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Steps to reproduce

  1. Log in using mmctl.

What I expect to happen

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq
# 

What happens instead

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq

  credentials for "example": "Personal Access Token@https://example.com" stored

# 

Potential cause

From looking at the code, output and --quiet are implemented in Printer, but auth and a few other places appear to use fmt.Printf() directly instead.

Vastaa viestiin sen kontekstissa (Github)

New releases not published on Github

26. lokakuuta 2021 klo 11.18
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Github, Mattermost

Summary

Release v1.47.2 was mentioned in another issue’s comments, and Play Store version has indeed been updated, but that release is missing from Github releases.

Steps to reproduce

Open Github releases page for the project.

Expected behavior

Find release v.1.47.2 (or later).

Observed behavior (that appears unintentional)

The current latest release on Github is 1.47.0.

Possible fixes

I don’t know if it’s related, but v.1.47.0 has been tagged ”changeme” instead of the usual vX.Y.Z pattern.

Vastaa viestiin sen kontekstissa (Github)

No backup/recovery code mechanism for MFA

10. toukokuuta 2021 klo 17.28
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost, security

Summary

After setting up multi-factor authentication, losing the authentication code-generating device means losing access to the Mattermost account. While having MFA is excellent, I’m afraid to set it up for my admin user account (which is the one most critically needing it), because there’s no recovery mechanism in case I lose my authenticator device.

Steps to reproduce

  1. Enable up multi-factor authentication in the System Console
  2. Configure 2FA with an authenticator app on your phone
  3. Break/lose/have your phone stolen
  4. Try to log in

Expected behavior

Have a ”use a backup code instead” link next to the MFA token prompt.

Observed behavior (that appears unintentional)

There’s no alternative way to provide the MFA. You can not log in.

Possible fixes

None available AFAICT. There’s no way to add security keys as alternatives either.

There’s an existing Jira ticket ticket about this (and it’s linked to an abandoned PR), but it’s closed as ”moved to ProductBoard for prioritization”, and I don’t know what’s happened since then, as I don’t have access to ProductBoard (that I know of).

Mattermost version

v5.34.2

Vastaa viestiin sen kontekstissa (Github)

I see, so it’s a result of conflicting indicators from the user

19. joulukuuta 2020 klo 18.41
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost, saavutettavuus

@agnivade Oh I see, so it’s a result of conflicting indicators (”away” vs. being active) from the user. I’m trying to recalibrate my expectation based on this, but it’s difficult.

My immediate thought is perhaps (in the problematic case) sending the notification, but then clearing it only once I start typing (typing appears to have an event associated with it, at least based on the logs) would be better than the immediately clearing ghost notification, but you’re right, this is more complicated than immediately apparent.

Some UI/UX design wizardry would probably be needed to eliminate the possibility of mixed user signals, if at all possible. I don’t have a good solution for now, so feel free to close the issue if you deem it appropriate.

Vastaa viestiin sen kontekstissa (Github)

Yup, your description of the issue is exactly right

18. joulukuuta 2020 klo 15.23
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Yup, your description of the issue is exactly right @agnivade, and thanks for looking into this!

I set up the two users in parallel windows. Sending a normal message as userB this way does not trigger the issue (I do get a notification on userA’s phone, but it doesn’t go away by itself), but that’s because userA’s window is (obviously) not active, since I’m typing in userB’s window. The notification is only cleared once I activate userA’s window.

But I can trigger the issue by using (for instance) /echo 'hello A' 4 instead (as userB), then hopping on to activate userA’s window during the 4-second delay, so that userA’s window is active when receiving the message. That’s the crucial bit: the receiver’s window is active when receiving the message. If his status is ’Online’, there’s no push notification (as expected), but if it’s ’Away’, that’s when I get the ghost notification.

Here’s server log and MPNS log during one minute where (as userB) I first send a normal message, then (at about 30 seconds) using /echo.

Vastaa viestiin sen kontekstissa (Github)

Still reproducible here with the current server (v5.29.1)

18. joulukuuta 2020 klo 10.26
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Yes, this is still reproducible here with the current server (v5.29.1).

Here’s the server log and MPNS log during which

  1. I switch log level from error to debug
  2. I send one ”hello” message to a bot (from the web UI)
  3. the bot responds with one message
  4. I switch log level from debug back to error

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »