Traceback in all requests from maintainers

[rubenskuhl]

Describe the bug
Every update to IRR fails, except ones with override password

To Reproduce
Upgrade from 4.2.5 to 4.3.1 and then to 4.4.2
Send an object with maintainer password

Traceback (most recent call last):
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/email.py", line 51, in handle_email_submission
handler = ChangeSubmissionHandler().load_text_blob(
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/handler.py", line 56, in load_text_blob
self._handle_change_requests(change_requests, reference_validator, auth_validator)
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/handler.py", line 177, in _handle_change_requests
result.validate()
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/parser.py", line 309, in validate
auth_valid = self._check_auth()
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/parser.py", line 320, in _check_auth
self._auth_result = self.auth_validator.process_auth(self.rpsl_obj_new, self.rpsl_obj_current)
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/validators.py", line 359, in process_auth
new_mntners_result = self._check_mntners(rpsl_obj_new, mntners_new, source)
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/updates/validators.py", line 520, in _check_mntners
valid_scheme = mntner_obj.verify_auth(self.passwords, self.keycert_obj_pk)
File "/home/irrd/.local/pipx/venvs/irrd/lib/python3.8/site-packages/irrd/rpsl/rpsl_objects.py", line 441, in verify_auth
return verify_auth_lines(self.parsed_data["auth"], passwords, keycert_obj_pk)
KeyError: 'auth'

Expected behaviour
The update to either be accepted (if mntner password was correct) or denied (if mntner password was incorrect)

IRRd version you are running
4.4.2

Additional context
irrd_load_pgp_keys was run again to ensure that it was not a keychain issue, but keychain files remain with date of initial IRRd 4.x installation.
Command:
sudo -u irrd /home/irrd/.local/pipx/venvs/irrd/bin/irrd_load_pgp_keys --config /etc/irrd.yaml TC

This is the output:

Loading key-cert PGPKEY-107FB81E
Loading key-cert PGPKEY-72810193
Loading key-cert PGPKEY-8965C533
Loading key-cert PGPKEY-DB970985
Loading key-cert PGPKEY-ED12A6DB
All valid key-certs loaded into the GnuPG keychain.

[rubenskuhl]

Just for completeness, irrd_database_upgrade was used at each step of the upgrade. It was also attempted now in case there was some database insanity.
Curious thing is that the system ran a few days without those issues.

[rubenskuhl]

This is the code where Traceback happens:

440 def verify_auth(self, passwords: List[str], keycert_obj_pk: Optional[str] = None) -> Optional[str]:
441 return verify_auth_lines(self.parsed_data["auth"], passwords, keycert_obj_pk)

[mxsasha]

Interesting. I'll dig into it.

[rubenskuhl]

Just tried to disable AS-SET specific auth, but that didn't change the outcome for AS-SET creation:

auth:
set_creation:
COMMON:
prefix_required: true
autnum_authentication: disabled

It was just a thought.

[rubenskuhl]

Updating maintainers work without the issue, so it seems restricted to update of non mntner objects. Coincidences or not, for updating a maintainer an "auth" key has to be provided.

[peterle-qwerty]

I had similar issue until enabling crypt-pw hasher:

irrd.yaml

auth:
password_hashers:
crypt-pw: enabled

[rubenskuhl]

I had similar issue until enabling crypt-pw hasher:

irrd.yaml

auth: password_hashers: crypt-pw: enabled

Thanks, it worked for us as well.
Note that we were fine with the default crypt-pw situation as legacy, because we moved scripts to use BCRYPT-PW and informed users, but it seems there is a bug with defining crypt-pw as legacy and maintainers with crypt auth.

[rubenskuhl]

I had similar issue until enabling crypt-pw hasher:

irrd.yaml

auth: password_hashers: crypt-pw: enabled

BTW, have you tried auth: password_hashers: crypt-pw: legacy ? Just to know if the issue is the lack of config entry or an issue with the legacy crypt-pw operation.

[mxsasha]

Do the affected maintainers have CRYPT-PW passwords only? So is the issue that IRRD isn't gracefully handling the lack of any supported hash on those mntners? Or is the presence of a disabled CRYPT-PW causing it in an otherwise valid request?

[rubenskuhl]

Do the affected maintainers have CRYPT-PW passwords only? So is the issue that IRRD isn't gracefully handling the lack of any supported hash on those mntners? Or is the presence of a disabled CRYPT-PW causing it in an otherwise valid request?

100% of our maintainers had CRYPT-PW until a few days ago... note that auth: config is said to be only for variating from default. So what I understood was that I should only insert password_hashers clauses to change from:
bcrypt-pw enabled
md5-pw enable
crypt-pw legacy

But as said, I haven't tried adding "crypt-pw legacy" to see if that solved the issue. I used "crypt-pw enabled" to recover from days of mntner downtime and that did it, while we sort out what to do next.

So it is not that there are no enabled methods, there should be methods (some with enabled, some with legacy) available according to the docs.

[mxsasha]

I see your point, and I think the legacy setting is broken for password hashers, on top of the bug I already found.

[mxsasha]

#894 should fix this, will backport and make a release soon

[mxsasha]

Released in 4.4.3 / 4.3.2