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.)
> 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.
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.
> 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.
The infrastructure really needs to work for us, not against us.
As for the other reply:
Stephen John Smoogen wrote:
> Off-list:
Not quite. :-)
> [snip]
> Does that make sense?
No. See my reply to Peter Robinson above.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
