-----BEGIN PGP SIGNED MESSAGE----- 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? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSyx0kAAoJEOm1uwJp1aqDk14P/R9HqlkhaLrjQ5oExZmj2M46 B6lVTKY3kVUL4dUamkhJ+IiLvl4zJ9ZV4sb4shxFEEPuKt95r18DdnB3EnzcDn7W SXcENMZgMyCrfsWmrLfjL7ignqpuOnJbJ1TLvVU6S5vcSHnmnrpVSxgZuqYRjevA ydq+6pM4mtaBiPkuOOKsp0YvQJUe2glTx3gW489ieNEu3Knzj1319g8/qqB7w2K0 mI8LN9nNP6d2Fxi5RwPS2XWSyIXwUc0FhXnBPjWbJVp0bPg7+39CJm4paXKNzk4W U79mC6u2q6A+ts5rfUVCoycfzfXK067KemRSKSzgZVg8B6FJ4Ez65kTQ5n8K6VNd hgFYRgXJ9jMpBlWOUAqeiDCMD/MxDKhTQdrhqd5fJO2Cwj/cbbCgZ7oplHha+T6W hOLgo6ib6iPs297EWl5hD3D9mG07ThCnJGqNtxBM3uESlcCzpBGlp3+DI/zTYALd 24OpswTDa/COIB23C9CwYc0omasSo4pWXm7H8wGoycsRmriYDRV3XOrDC6lltOqm Vik2SMs+qNBo3GG+BJl/C0s3BK2LgYpavaxecHBKUXeex1fxh5RESUoQmXzVXIZN QvKJl2T104wxVoKqsi1v9DacSV1Fh4eVmag2Ta9T7/KIYDtNAQSz9XKJ9/eOv9VM +ZYlb1Bc4jTg/9WOaaYk =/SaF -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cb1d24.9090...@pocock.com.au
