Upgrading to 1.4.1 PREVIOUS_SECRET_KEY UnicodeDecodeError

[fmaritato]

I am upgrading an existing superset 1.3.2 to 1.4.1 . I did not previously have a SECRET_KEY defined. In reading the Updating.md file it says to set PREVIOUS_SECRET_KEY but if I didnt have one set previously, what do I set this to?

I tried PREVIOUS_SECRET_KEY = "" and ran superset re-encrypt-secrets but I get an error:

superset.utils.encrypt:Collecting info for re encryption
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/sqlalchemy_utils/types/encrypted/encrypted_type.py", line 128, in decrypt
    decrypted = decrypted.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 1: invalid start byte

I'm using a postgres database that has data in it that I can't lose, so I'm stuck here. Any help would be appreciated.

Is there a specific table/row that I can manually delete to get past this?

Environment

I'm using the apache/superset:1.4.1 docker image

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• [ x ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
• [ x ] I have reproduced the issue with at least the latest released version of superset.
• [ x ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Add any other context about the problem here.

[villebro]

@fmaritato if you were already using a custom SECRET_KEY (=not the default one) you don't need to take any further action unless you want to rotate the key (=replace the old one with a new one).

[fmaritato]

@villebro as i stated above i did not have a custom secret key. I was using the default. What is the solution?

[villebro]

@fmaritato uhh, sorry, I misread; check the steps here: #18785 (comment)

[fmaritato]

ok thank you @villebro it wasn't clear to me before that I had to set the previous key to that literal string. The other comments said it was an example. Thanks!

[ziggekatten]

I still do not understand this. Must be stupid. If I have the default key, what should I set PREVIOUS_SECRET_KEY to?

[villebro]

I still do not understand this. Must be stupid. If I have the default key, what should I set PREVIOUS_SECRET_KEY to?

This is a one time breaking change to force admins of existing installations who had forgotten to set a secret key to set one (failure to do so would make the installation vulnerable to data leaks and other vulnerabilities).

@ziggekatten did you do what was instructed in this message? #18785 (comment) Did this not work?

[ziggekatten]

Yes it did, but it was not really clear that the PREVIOUS_SECRET_KEY string in that comment was not an example, but in fact the default key. I just tried that string with no hope, and it worked. Documentation is not that clear.....:-)

[villebro]

Yes it did, but it was not really clear that the PREVIOUS_SECRET_KEY string in that comment was not an example, but in fact the default key. I just tried that string with no hope, and it worked. Documentation is not that clear.....:-)

Oh, ok, sorry for the confusion; I updated the comment to make it slightly more clear that it's actually a literal string 🙂 :