launchpadlib

Bug #686690
Comment #9

Comment 9 for bug 686690

Revision history for this message

Gary Poster (gary) wrote on 2010-12-14: Re: [Bug 686690] Re: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings

On Dec 13, 2010, at 6:15 PM, Leonard Richardson wrote:

> We broke backwards compatibility when we removed the ability to store
> credentials in an unencrypted store. We did this deliberately, but we
> didn't consider that a cronjob needs to get credentials without any user
> input.

If the new encrypted store were more powerful--if, for instance, the Gnome keychain had supported per-application credentials and generally had a better story--I think we might have had a better argument to support breaking backwards compatibility. As it is, the incremental improvement of our security is not convincing, in conversations externally or even when Benji and I talked over the situation.

AIUI, the big improvement between the old story and the new story is that, if someone were to steal your shut-down computer, they would not have easy access to your Launchpad authentication; and if someone were to root your machine, they would have a somewhat harder time getting to your password.

If they get your computer when you're machine is on and authenticated, the risk is essentially equivalent; if they install malware on your desktop, the risk is essentially equivalent; if they have rooted your machine, the risk is still not insignificant.

Is that increment worth breaking backward compatibility of cronscripts, which some people (Martin, for one, I believe) outnumber interactive scripts? Francis has gone on the side of "no". At the end of the day, it's a judgement call, and a balance.

When we consciously broke backwards compatibility, we also believed that the smooth interaction of interactive applications--Ground Control, Hydrazine, Quickly--was important to encourage. We felt that perhaps the combination of the security and the automatic increase of usability of interactive applications was worth it.

Again, it is a judgement call, and again, Francis has come down on the side of "no."

Barring Kees or someone else making a strong argument that the increment of security improvements warrants breaking backwards compatibility, we have our direction: make things backwards compatible.

Gary

On Dec 13, 2010, at 6:15 PM, Leonard Richardson wrote:

If the new encrypted store were more powerful--if, for instance, the Gnome keychain had supported per-application credentials and generally had a better story--I think we might have had a better argument to support breaking backwards compatibility.  As it is, the incremental improvement of our security is not convincing, in conversations externally or even when Benji and I talked over the situation.

Is that increment worth breaking backward compatibility of cronscripts, which some people (Martin, for one, I believe) outnumber interactive scripts?  Francis has gone on the side of "no".  At the end of the day, it's a judgement call, and a balance.

When we consciously broke backwards compatibility, we also believed that the smooth interaction of interactive applications--Ground Control, Hydrazine, Quickly--was important to encourage.  We felt that perhaps the combination of the security and the automatic increase of usability of interactive applications was worth it.

Again, it is a judgement call, and again, Francis has come down on the side of "no."

Barring Kees or someone else making a strong argument that the increment of security improvements warrants breaking backwards compatibility, we have our direction: make things backwards compatible.

Gary