Comment 10 for bug 686690

Leonard Richardson [2010-12-13 23:15 -0000]:
> I don't think you can completely separate the "load from file" case from
> the "open a browser" case. You're assuming a file with the credentials
> already exists. What if it doesn't exist? How does it get created in the
> first place? You have to open a browser.

Of course there needs to be an interaction once, for the initial
setup. You once run the cron job manually, then see that it stops at
the credential stage, and open the URL in your local browser. Once you
ack'ed the auth in Launchpad, you go back to your ssh window for the
server and press Enter there. Henceforth you'll have a credential file
on the server which isn't going to go away or become invalid.

The nice thing here is that there is no IP check or so, i. e. the
machine requesting LP access doesn't need to be the same machine that
has the browser open.

Alternatively you can create it locally and copy it to the server
(which is impossible if you locally use a GNOME keyring).

> You shouldn't have an unencrypted credential lying around on your
> computer just because I like to run the script as a cronjob on my
> computer.

I don't understand the rationale behind this. For server cron jobs we
need the unencrypted file, and on desktops it doesn't matter much, as
you can just always read the (unencrypted) cookie from your Browser
profile and use that to obtain a new credentials file.

> Idea #1: Let's package a script with launchpad that does the browser
> open and writes the unencrypted credential to disk. If you need to run
> launchpadlib cronjobs, you run this script. If you don't, you don't.
> [...]
>
> login_with() would check the GNOME keyring, then the KDE wallet, then
> the encrypted file, then the unencrypted file.

That would work mostly fine, I think. It would be great if
login_with() can continue to support the credentials_file argument, so
that you can put your auth file into a more controlled location.

Except that you should turn around the order here to retain backwards
compatibility: First check the unencrypted file, then the other three.
If you already have an unencrypted file, there is no reason not to use
it (it's cheaper), and existing setups would continue to work.

> Idea #2: We could change our usage of python-keyring so that if the
> GNOME Keyring and KDE Wallet are not available, the credential is
> written to an unencrypted file instead of an encrypted file. This would
> mean that GUI users get their credential encrypted, and console users
> don't.

This also will work from my POV, with the added benefit that you don't
need a separate script for the initial setup, but it's all built in.

> You would still have to run a cronjob script manually

Right, no way around that (but that's fine).

> , and use a console web browser to set up the credential.

That really shouldn't be necessary. If for some reason the usage of a
console web browser would now become required, that would certainly be
a step backwards. (See above).

So, I slightly prefer idea #2, as it's easier to use, but I'm fine
with either.

Thank you!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)