[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian services and Debian infrastructure

Hash: SHA256

On 05/01/14 14:55, Stefano Zacchiroli wrote:
> On Sun, Jan 05, 2014 at 02:28:59PM +0100, Joerg Jaspert wrote:
>>>> Q3. What should be our definition of "official services"?
>>> Even if this is highly preferable, I don't think that official
>>> services (.d.o services) should necessarily be running on
>>> Debian hardware managed by DSA, provided that: - the service is
>>> clearly useful and used - the service has a sustainable
>>> maintainance model (active team + instructions on how to
>>> contribute, run a local copy, etc. + DFSG-free) - the service's
>>> design does not raise security or scalability concerns
>> I disagree on that, official services should run under project 
>> overview. So far that the project can take it over and move it,
>> should all of the team go away. Active team today doesn't mean
>> they are there tomorrow to properly hand it over. Having the
>> project itself have access (via DSA at least) ensures it can
>> continue.
> I very much agree with Joerg on this.
> A team like DSA offers to the Debian Project two key features.
> One, which is the most visible one, is the technical output and
> continued service of a team of talented sysadmins.
> The other is the governance guarantee that we, as a project, can
> always take over the maintenance of a service whose current
> maintainers go MIA or become unwilling to work with the rest of the
> project for any reason. As Joerg points out.

Disclaimer/conflict of interest: I'm currently proposing a lightweight
SIP service to run on DSA maintained infrastructure

For any service, there are some general issues that come to mind for me:

a) credentials: many services need TLS certificates these days.
debian.org private keys probably have to be on boxes that DSA control
and secure and not floating around in shared cloud storage or
outsourced boxes at arms length

b) delegated services: that said, some types of application can
delegate their security checks (e.g. SIP can use a RADIUS server to
verify DIGESTs).  In these situations, the service hosting equipment
does not need to have any copy of the user credentials.  The
verifications are made in the RADIUS server.  By exposing services
such as RADIUS, DSA could allow other people to run servers that don't
need any copies of keys or credentials on their local disks.

c) purpose: we should define some criteria that make the service
compelling.  For example, DSA doesn't provide a full mailbox service,
but a mail forwarding is available.  Personally, I feel that it is
compelling for Debian to offer some SIP and XMPP service on a similar
level to mail forwarding, in particular, because of the strong
position that proprietary alternatives in that space - but maybe that
isn't a criteria that everybody else would value.  What, then, should
the list of criteria be for a service that we value or can't be without?

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


Reply to: