ui: fails after first use from a given process

[Sam Hartman]

The first time gss_init_sec_context is called it calls out to libmoonshot and the UI is invoked.
However any additional call to gss_init_sec_context from the same process results in falling through to the default credentials logic.
This is fairly critical as it means you cannot use moonshot from a web browser with the UI. This will soon be a blocker for trust router as well.

[Kevin Wasserman (krwasserman)]

Fixed with ui restructuring

[Sam Hartman (hartmans)]

What seems to be happening is that after the moonshot ui displays an id and sends one, it exits. So, the dbus name is unbound, so messages sent to that name fail. The libmoonshot code needs to restart the service if needed. The UI may also need to stick around for a bit (without window) to avoid huge churn under high load.

What I suspect happened when we tested is that the ui was run manually and didn't exit when the ID card was sent.

[Dan Breslau (dbreslau)]

This was apparently re-opened by mistake.

If this were still a bug, then running a command such as

gss-client -ccount 4 -mech "{1.3.6.1.5.5.15.1.1.17}" localhost test@localhost "FooBar"

would succeed on the first attempt, but fail on the next three (probably with an error indicating invalid credentials.) However, it succeeds on all four attempts.