Bug#823180: SSO certificates for tracker.debian.org broken

[Russ Allbery]

Enrico Zini  writes:
> On Mon, Jan 16, 2017 at 09:26:10PM -0800, Russ Allbery wrote:

>> Is there any way that I or someone can help with the current issue with
>> enrolling on sso.debian.org?  It looks like this was originally
>> reported in May of last year on this bug.

> Sure. Although I'm bad at project managing myself[1], I'm very happy to
> help.

Well, this was also rather embarassing on my part.  I sent that message in
January in a burst of optimism and energy, coming off vacation, and then
promptly ran out of any time and never followed this up.

> Ack. I refactored sso.debian.org when we got rid of DACS, and now there
> are two login pages, one for debian.org and one for alioth.debian.org,
> because sso.debian.org has now been setup with two views of the same
> functionalities each with a different apache authentication.

> That link should probably just be changed to https://sso.debian.org/

I confirm this is now fixed.

>> If one goes directly to sso.debian.org, clicks on Debian account
>> certificates, and logs in, clicks on Get new certificate, and then
>> submits, it just produces "/usr/bin/openssl failed" as an error message
>> at the top of the page.

> That would be with chrome/chromium, I suppose? They disabled the
> certificate generation functionality by default:
> https://wiki.debian.org/DebianSingleSignOn#chromium_.2F_chrome

> I know of no way of doing certificate generation on recent chromes
> without explicitly enabling it as described on the wiki link above, and
> I read somewhere months ago[citation needed] that the chrome devs
> decided it's a feature that they intend to remove altogether. It'd be
> nice if they changed their mind or started suggesting alternatives.

Oh!  Yes, that's indeed the problem, and that makes sense.  I thought the
old error message (about openssl failure) indicated some server-side issue
rather than a client issue.  I see that the error message is now much
nicer (thank you!).

> I started playing with the idea of a command line tool that would take
> care of browsers: https://github.com/spanezz/debsso-client and it looks
> like a promising avenue, in that it's possible to feed client
> certificates to chromium and firefox from the command line:
> https://lists.debian.org/debian-devel/2016/10/msg00131.html

> debsso-client could do SPKAC with sso.debian.org and inject the
> resulting certificate into the browsers key store:

>  1. openssl genrsa -out user.key 2048
> openssl spkac -key user.key -challenge FvIu8NDJZxGmpKmA5pp3asMDZChXD4rc | 
> cut -d= -f2-
>  2. Post it to https://sso.debian.org/debian/certs/enroll_manually or
> https://sso.debian.org/alioth/certs/enroll_manually authenticating
> with HTTP basic auth, together with the validity and comment fields
> that you see on the page
>  3. get the client certificate as the result of the POST
>  4. feed it into the browser key store

I went through the equivalent of that process manually using the manual
certificate generation instructions, and it works great.  This seems like
the right approach to me as well.

I should probably take the five month delay in even responding to this
message as a sign that I have no business trying to dive into new
responsibilities and help out more with this at the moment.  :(  Apologies
for offering help and then going totally silent; my reach exceeded my
grasp.  But thank you *very* much for taking the time to describe the
problem and the proposed approach, and if I manage to pry free any time to
work on SSO stuff again, I will take a look at the code and also look at
the problem area and see if there's something better we can do.

(That said, I suspect that an external script to inject the certificate
into the browser is probably the best approach.  There are various
security worries about letting the browser generate certs directly, and
I'm not sure if the browser authors will be particularly excited about
supporting this functionality.  I think people in the industry have
largely given up on client-side browser certs in favor of U2F, although
that doesn't solve exactly the same problem.)

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Policy 4.0.0.0

[Russ Allbery]

Antonio Terceiro  writes:
> On Sun, Apr 30, 2017 at 05:50:13PM -0700, Russ Allbery wrote:

>> I think Debian Policy 4.0.0.0 is ready for release.

> One thing I was always curious about: is there a reason to use such a
> deep versioning scheme?

> A shorter version number would make package maintainers life a bit
> easier when keeping Standards-Version: up to date. For example noticing
> 4.0 vs 4.1 is way easier than noticing 3.9.7.0 vs 3.9.8.0.

A couple of people have asked about this.  I think where I'm at is that,
if we could go back in time, I'd use semvar with only three versions.  But
the semantics of the Policy version number is baked into enough stuff that
the minor clarity gain isn't really worth it.

Having the last number of Policy reserved for non-normative changes that
don't create a new Standards-Version for packages is very valuable, so
we'd always want to keep that.  So basically, as you mentioned above, we'd
go to two versions for Standards-Version instead of three.  Basically,
what we'd drop is the distinction between "minor changes" and "moderate
changes," and probably be a bit more willing to bump the most significant
version number when merging some major bit of new policy.

I think that would be totally fine, and somewhat superior to what we have
now.  But to get there we'd have to change the Policy text about the
version, change Lintian to understand the new numbers, change the other
bits on the package tracker that understand Policy version numbers, and
there are probably lots of other bits of software that would need minor
changes (automated tools that maintainers use to update things, for
instance).  This is all doable, but since the gain seems fairly minor, I'm
dubious it's worth asking people to go make all of those changes.

> Another nice to have would be having the major version number matching
> the target Debian release.

This I'm not sure is a great idea mostly because Policy doesn't really
care about the target Debian release, in the sense that we almost never
make some sort of change that's targeted at a specific release.  That just
generally isn't how Debian works, or how Policy works, right now.  It's
far more likely that the change that first rolls out in some Debian
release will finally get properly documented in Policy a full release (or
more) later.

I can definitely imagine a world in which this would make sense to do, but
it would be a world in which we're managing Policy far more proactively
than we currently are (and had the resources to do that).

-- 
Russ Allbery (r...@debian.org)