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

Re: Debian services and Debian infrastructure

On Mon, Jan 06, 2014 at 10:16:20PM +0100, Daniel Pocock wrote:
> 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.

we're also concerned about which passwords are entered where; hence
sso.debian.org and the desire to keep distinct the password used for SIP/XMPP
from that used for sudo

Luca Filipozzi

Attachment: signature.asc
Description: Digital signature

Reply to: