Re: Debian services and Debian infrastructure
-----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-----
Reply to: