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 agreed > 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 http://www.crowdrise.com/SupportDebian
Attachment:
signature.asc
Description: Digital signature