mirror of
https://github.com/nsupdate-info/nsupdate.info.git
synced 2026-04-25 16:45:55 +03:00
[GH-ISSUE #453] fail to create ns secret #327
Labels
No labels
bug
bug
duplicate
easy
easy
enhancement
enhancement
invalid
needs help
pull-request
scalability
security
task
urgent
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nsupdate.info-nsupdate-info#327
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @adrienb4 on GitHub (Jan 17, 2020).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/453
Hi
We can't generate a ns secret.
Logs :
HMAC_SHA512 secret need to have a length to 89, but you set it to 88 in the last migration file.
Commit
0a625d6853Thx
@ThomasWaldmann commented on GitHub (Jan 17, 2020):
@elnappo ^^^
@elnappo commented on GitHub (Jan 20, 2020):
Hmm, we haven't changed the length of this field. It was always 88
https://github.com/nsupdate-info/nsupdate.info/blob/master/src/nsupdate/main/models.py#L103
https://github.com/nsupdate-info/nsupdate.info/search?q=nameserver_update_secret&unscoped_q=nameserver_update_secret
@adrienb4 commented on GitHub (Jan 20, 2020):
In my case all HMAC-SHA512 secrets have 89 for length.
I recently upgraded nsupdate and now I can't add new domains.
All domains secret are been generated by nsupdate before upgrading.
@elnappo commented on GitHub (Jan 20, 2020):
On nsupdate.info my nameserver update secrets are 88 chars long. @ThomasWaldmann do you have an idea?
@ThomasWaldmann commented on GitHub (Jan 20, 2020):
I tried to add a new domain: len = 88
Then I created a new configuration / new secret for the same domain: len = 88, too.
So, I can't reproduce.
@ThomasWaldmann commented on GitHub (Jan 20, 2020):
@adrienb4 how do your generated secrets look like?
@ThomasWaldmann commented on GitHub (Jan 20, 2020):
is it related to #447?
@adrienb4 commented on GitHub (Jan 21, 2020):
For example with a domain secret created by nsupdate :
Len is 89.
@adrienb4 commented on GitHub (Jan 21, 2020):
I just generated a new secret domain in CLI :
Len is 89 too
@adrienb4 commented on GitHub (Jan 21, 2020):
Hummm as much for me :/
Vscode misled me in error. The first character is 1 not 0.
@adrienb4 commented on GitHub (Jan 21, 2020):
We have found the origin of the problem.
We think when you have upgrade Django to 2.2.9, you introduce a bug with domain secret.
Django tries to update domain secret with a wrong format. The expected format is a string, however we have a binary.
Domain secret in str mode has a length of 88. In binary mode the length is 91.
I also discovered that sqlite was not looking at the size of these fields.... You can put more than 88 characters in this case. Not possible with MySQL (my backend).
See : https://sqlite.org/faq.html#q9
@ThomasWaldmann commented on GitHub (Jan 23, 2020):
ok, guess it is fixed by #454 - but do we now have invalid secret data in the (sqlite) db?
and why did that even work when reading b'...' from the db?
@brice-gros commented on GitHub (Jan 23, 2020):
good point, I assume that switching from django 1 to 2, make the secrets in sqlite invalid anyway, invalidating any comparison string vs bytes.
By the way, regarding #445, switching from sqlite to postgresql (or mysql), won't be possible either, due to the insertion failing since the varchar's max length constraint is not respected.
So, a migration step verifying and fixing nameserver_update_secret would fix the whole issue, I guess