I am unable to use email correctly today. I apologize for the extra email. On 22 November 2016 at 10:14, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > 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. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
