Off-list: On 22 November 2016 at 01:12, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > Dennis Gilmore wrote: >> koji authentication will be switching to Kerberos. Koji supports multiple >> authentication mechanisms. Fedora infrastructure has set up a freeipa >> instance internally that has credential syncing to fas. We are working on >> ensuring that gssapi caching is supported so that you can have multiple >> TGT's and the ability to work in multiple reams at once. you can get >> started today by doing kinit <fas username>@FEDORAPROJECT.ORG if you move >> your ~/.fedora.cert file out of the way authentication will still work. > > Maybe a crazy idea, but couldn't Koji just use our SSH keys for > authenticating somehow? Those just work without any extra setup, they never > expire, and unlocking passphrase-protected keys is also an already solved > problem (ssh-askpass including GNOME and KDE versions, ssh-agent). All that > would have to happen is to tunnel the Koji CLI's communication through SSH > to koji.fedoraproject.org or to some trusted tunnel server that you can > delegate authentication to. It would be a good idea if we could enforce that the keys were private and well kept. However I have had to clean up unencrypted private keys from developers so many times on people01 and other servers that I would worry that someone making a mistake could cause a problem for everyone. [And while I could turn off people's access if I found them on people, how do I protect them when they copy them to the university server I don't have access to?] The amount of damage someone getting hold of a key could be large and the amount of time to detect it would also be long as there aren't any tools to do so. When problems do happen it also brings all sorts of social witch hunts (from dealing with this in the past with a project set up like that). People think oh its because joe fucked up, but it usually turns out that bob fucked up, and the attacker used social engineering as bob to become joe. [They then do so again after bob is kicked out if the investigation isn't thorough because people want action fast.] In this case if the keys get broken, it is on one group (us in infrastructure) who fucked up. We get kicked to the curb and some other group can take it over and try again. That said, having keys like ssh or gpg could work but i believe it would take a massive ground up engineering of other processes. [EG if we use ssh keys and it turns out there is a fundamental crypto flaw that shows up because they aren't engineered for this sort of process but it doesn't show up when they are used as ssh keys. ] Does that make sense? -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
