> You can use /proc/FIREFOX-PID/environ.

Ah, good to know that still works as expected.

> The inconsistency there is only the update.go warnings, if I'm reading
it right. That is an old issue, unrelated to the investigation here.

That's the visible inconsistency, yes, but it shows there's some kind of
hysteresis between the two commands.  My concern would be that the first
command sets state that doesn't get set in the second command.  For
example, if the first command sets up some kind of "environment" and
pulls 'KRB5CCNAME', but only on the first invocation after boot, so if
'KRB5CCNAME' wasn't set for the first command but was set for the second
then 'KRB5CCNAME' would never get pulled.  Hypothetically.  It's the
kind of thing I tend to watch out for when running the same command
unexpectedly gives different results on subsequent runs.

> Anyway, case 2 could not work out-of-the-box anyway because the
environment variable is not set after Kinit and the Snapd magic relies
on that variable. It still does not explain the failure even after
passing the ticket manually, the library may have some expectations
about user running the process and user encoded in the ticket (if there
even is such a thing, speculating here).

Oof.  That's gnarly.

> For this bug I will set case 2 aside because we do not want to block
case 1. But I'm not disregarding case 2, I will open a bug for it.

Okay, please let me know what the bug ID is.  Thanks again for looking
into this!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849346

Title:
  [SRU] kerberos GSSAPI no longer works after deb->snap transition

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to