Bonsoir, Une relecture. Merci. A+ Jérôme#use wml::debian::template title="Check-list pour les responsables de candidature" #use wml::debian::translation-check translation="1.22" maintainer="Jérôme Schell"
Voir également le Mini-HOWTO pour les responsables de candidature.
Si le candidat fournit une clef publique signée par un membre Debian en place, alors le processus d'identification est accompli. La pièce d'identité du candidat ne sera nécessaire que si la clef n'est pas signée par un membre Debian. Veuillez vous reporter à la page identification de la check-list.
Il existe un problème de compatibilité avec certaines versions de GnuPG. Veuillez vous reporter à la section compatibilité de version GnuPG.
Veuillez consulter également ces notes pour d'importantes informations concernant la vérification de signatures.
Si votre candidat a besoin de l'ancienne clef pour vérification, il/elle peut l'envoyer avec la nouvelle clef.
De même, si le candidat possède uniquement une clef PGP signée par un membre Debian, il/elle peut l'utiliser pour vérification.
Des options de vérification supplémentaires peuvent être appliquées si il existe des doutes à propos d'une information particulière ou de la personne l'ayant fournie. Aux États-unis certains sites internet font de la « résolution inverse » à partir d'un numéro de téléphone et vous fournissent ainsi le nom et l'adresse de l'abonné. Utiliser ces services pour faire des vérifications croisées sur les informations fournies par le candidat peut faire émerger des incohérences, mais l'existence de ces incohérences n'implique pas le rejet automatique du candidat. Dans ces situations, les négociations devraient trouver leur place.
Par exemple, si la recherche grâce à la résolution inverse fournit un autre nom que celui du candidat, demandez au candidat quel numéro de téléphone il/elle vous a donné. Il/elle peut vous répondre : « C'est le numéro de mon collocataire » ou « C'est le numéro de mon père » ou encore « C'est le numéro de ma résidence universitaire » ce qui vous donne alors un autre contact. Si vous pouvez vérifier l'information fournie par le candidat, le contact nécessaire est obtenu.
Si, du fait d'une incertitude, il ne manque plus qu'un contact au candidat, (c.à.d. le contact dit qu'il ne pense pas connaître cette personne), il est possible, en dernier recours, d'utiliser le FAI du candidat pour résoudre le problème. La plupart du temps, le candidat devra autoriser son FAI à donner les informations sur son adresse et son numéro de téléphone. Contactez ensuite le FAI pour lui demander confirmation des informations.
Il n'y a pas grand chose à dire sur la vérification de la philosophie du candidat. Voir le paragraphe du mini-HOWTO qui parle de cela.
Pour s'assurer que les candidats connaissent les procédures utilisées dans Debian, on pourra vérifier qu'ils savent ce que dit la « Référence du développeur » à propos d'une procédure en particulier, par exemple comment fermer un bogue, faire des NMUs, etc.
Si un candidat rejoint Debian en tant qu'empaqueteur, il/elle doit avoir un paquet prêt à l'emploi ou un programme à mettre en paquet, peu importe. Il n'est pas nécessaire que son travail soit prêt à être mis à disposition au moment où il/elle devient responsable, mais il/elle doit au moins être en train de travailler sur un paquet particulier. Le responsable des comptes des développeurs n'acceptera pas les candidats qui ont peut-être l'intention de mettre quelque chose en paquet à une date non encore déterminée.
Si un candidat rejoint Debian pour rédiger de la documentation, il est également recommandé qu'il/elle ait une vision lucide du type de documents à écrire ou à améliorer dans Debian. (la vérification de documentation éventuellement rédigée auparavant est envisageable.)
Le rapport final d'un responsable de candidature sur un candidat comporte deux étapes :
[1] Les candidats ne doivent PAS avoir (absolument PAS) qu'une clef signée. Vous pouvez le vérifier en effectuant sur leur clef « gpg --list-key <nom du candidat ou ID clef> ». Si vous obtenez uniquement « <nombre>D/ » (généralement 1024) et pas « <nombre>E/IDclef », « <nombre>e/IDclef », ni « <nombre>g/IDclef », alors c'est une clef signée DSA. Dans ce cas vous, responsable de candidature, devez demander à votre candidat de générer une clef correcte. Ceci est indispensable pour être enregistré.
[2] Les noms de comptes doivent comporter au minimum 2 caractères, 3 serait mieux.
Ceci achève la liste des obligations du responsable de candidature dans le processus de candidature. Le responsable des comptes des développeurs doit à présent décider si la candidature s'est terminée correctement.
Contexte : actuellement, le meilleur moyen de mettre la candidature « en attente » est de la rejeter avec commentaires. Lorsque le candidat est mieux préparé à travailler sur sa candidature, il/elle n'a qu'à envoyer une demande à son ancien responsable de candidature.
À noter : tous les refus des responsables de candidature sont procéduraux. À tout moment, quand le candidat sent qu'il remplit mieux les conditions pour la candidature, il est libre de postuler à nouveau, et de réessayer.
À tous les responsables de candidature : libre à vous de mettre en attente tout candidat qui ne serait ni prêt, ni volontaire, ni capable de poursuivre avec tenacité sa candidature, au même titre qu'un autre qui n'aurait pas les compétences ou les intentions requises par la check-list.
<Voici une note de notre responsable des comptes des développeurs à propos de problèmes d'incompatibilité avec GnuPG.>
Malheureusement, du fait d'un bogue dans la gestion des clefs ElGamal de GnuPG, il existe maintenant un problème déplaisant de compatibilité.
La version posant problème : les clefs ElG générées avec GnuPG <= 1.0.1 peuvent générer anormalement de mauvaises signatures quand vérifiées avec GnuPG >= 1.0.2. Et vice versa, les clefs ElG générées avec GnuPG >= 1.0.2 peuvent générer anormalement de mauvaises signatures quand vérifiées avec GnuPG <= 1.0.1.
La version sans problème : tous les responsables de candidature doivent mettre à jour leur version de GnuPG à la version 1.0.4 (elle se trouve dans Debian 2.2 r2 et dans woody. À noter que la version 1.0.3 comporte également des bogues, et quiconque utilise GnuPG devrait mettre à jour à la version 1.0.4) ; si vous rencontrez des problèmes pour vérifier les signatures d'un candidat, essayez d'ajouter « --emulate-md-encode-bug » à la ligne de commande. Si cela résout le problème, c'est que votre candidat possède une clef ElG boguée. Faites lui installer GnuPG 1.0.4 et générer une nouvelle clef. (Si il/elle a besoin de l'ancienne pour vérification, joignez simplement les deux dans le rapport à da-manager@)
Il est essentiel que vous utilisiez --check-sigs pour vérifier les signatures de clefs des candidats et non pas --list-sigs, ceci ne validant pas les signatures.
Rappelez-vous également qu'il est toujours mieux de faire référence à « l'empreinte digitale » (fingerprint) d'une clef plutôt qu'à l'identifiant court, la probabilité d'une collision étant nettement plus faible du fait du plus grand univers.