On Fri, 25 Nov 2016 03:19:49 +0100 Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > Peter Robinson wrote: > > Well the koji web interface itself doesn't use authentication > > anymore, from a fedpkg PoV there's a lot of complexity with http(s) > > because it could be proxied or NATed (worst is CG-NAT) so the same > > connection from the same laptop might not even come via the same > > IP. Basically what you're describing is exactly what kerberos > > solves, tokens to authenticate various different connections. > > My point is, just use SSH instead of HTTP(S) as the transport. You > could even tunnel HTTP over an SSH tunnel after you let SSH > authenticate the other end, if you really need an HTTP API. (Not much > point in using HTTPS over the already encrypted SSH.) Do you know of any applications at all that use this? Is there any python code available to setup such authentication? Kerberos is used all over the place by lots and lots of groups and has had many years of auditing and actually you know, exists. > > A lot of companies and data security standards explicitly disallow > > ssh keys because of the fact it's client side pass phrases with no > > way to enforce a policy so there's no way to tell even if the key > > has a passphrase. > > And that is what I like about SSH. :-) I decide the level of security > I actually need for my key, not somebody else. Which is fine up until the point someone compromises your machines and uses your access to mess up everyone else. > And we already trust SSH authentication for access to dist-git, so I > don't see why it would not be good enough for Koji as well. Because it would require a bunch of coding and then we would be a special little snowflake. > > Personally I'd like to see eventually the move to kerberos to > > replace ssh- keys as it's easier to enforce a minimum policy and > > manage. > > Kinit just takes a password, automating it to pick the password from > any password store or even a plaintext file and then run > automatically on startup and automatically renew expired tickets is > not that hard. It will just be a minor annoyance until one of us > writes the automation tool, and do nothing to enforce any kind of > policy on us. No need to invent all this again, you can just use a keytab. > The infrastructure really needs to work for us, not against us. I'm happy to work with anyone to improve things. That said, we don't have a bunch of developers sitting around waiting to implement people's ideas, so sometimes we have to say "sorry, no" or "sorry, we can't do that now, but happy to look at it again later". I think kerberos is a very good improvement over the current setup. I hope (most)everyone else does too. kevin
Attachment:
pgp8iTKdXRQYf.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
