Le vendredi 24 août 2018 à 00:05:35+0200, Mattia Rizzolo a écrit : > Package: nm.debian.org > Severity: important > > I don't quite understand how it happened, nor I tried to reproduce, but > HAYASHI Kentaro managed to create a new account on nm.d.o and link to it > a gpg key (D92025640886D27D14A9EE02D22C1A883455D448) that was already > linked to another account with different uid (kenhys) and email. > > This caused a lot of grief in the housekeeping job: > |2018-08-23 21:47:28,907 ERROR dsa.NewGuestAccountsFromDSA: run_main failed > |Traceback (most recent call last): > | File "/srv/nm.debian.org/nm2/django_housekeeping/run.py", line 206, in > run_task > | method(self) > | File "/usr/lib/python3.5/contextlib.py", line 30, in inner > | return func(*args, **kwds) > | File "/srv/nm.debian.org/nm2/dsa/housekeeping.py", line 43, in run_main > | format_person=self.hk.link, > | File "/srv/nm.debian.org/nm2/backend/models.py", line 212, in > get_from_other_db > | format_person(person), match_type, match_value)) > |backend.models.MultipleObjectsReturned: LDAP has fingerprint > D92025640886D27D14A9EE02D22C1A883455D448, which corresponds to two different > users in our db: https://nm.debian.org/person/kenhys (by uid kenhys) and > https://nm.debian.org/person/ken...@gmail.com (by fingerprint > D92025640886D27D14A9EE02D22C1A883455D448) > > Plus it seemed to have caused some oddities around the website as well, > e.g. the keycheck for https://nm.debian.org/process/531 looked > inconsistent as he didn't report some signatures apparently. > > Note that I've now mangled the users around, so the links in the > traceback aren't really valid anymore, plus the situation is solved in > the production website. But still it shouldn't have allowed this > situation to happen at all, so I'm reporting this bug.
I gave a look at this, and I think I have an explaination. Please mind that I had no access to any DB, so I'm trying to deduce from what Mattia told me, from this bug, and from nm.d.o's code. It's plausible that kenhys created a NM user with his email address @clear-code.com but didn't add the GPG fpr. In a parallel shot, he got a guest account and added his FPR in the LDAP database. Then, he decided to become DM, and forgot about his old account. He decided to create a new one, and got the uid/email problem, but the FPR being not reserved, he succeeded at requesting it in nm.d.o. Then the hk job extracted data from LDAP, and as it searches in the nm.d.o db with a "or" clause (get_from_other_db searches against each and every field one after another), it found two accounts, the old one, via the uid, and the new one, via the fingerprint. I don't think there's a way to prevent such things to happen, as it's a dual-db inconsistency, except if you consider the (rather brutal) solution where the HK job adds the missing data to a nm.d.o account from LDAP entries. --- Mattia, it seems there is no way for two accounts to share a fingerprint. The FPR value is set to unique since the beginning of the django project, and there's a ForeignKey for the person linked to the Fingerprint object. Hence, I'm pretty sure there was no fpr on the uid=kenhys account on nm.d.o. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
