POSS Chap 6 Part 6

De Framalang Wiki.

Sommaire

Publicity / Les annonces

In free software, there is a fairly smooth continuum between purely internal discussions and public relations statements. This is partly because the target audience is always ill-defined: given that most or all posts are publicly accessible, the project doesn't have full control over the impression the world gets. Someone—say, a slashdot.org editor—may draw millions of readers' attention to a post that no one ever expected to be seen outside the project. This is a fact of life that all Open Source projects live with, but in practice, the risk is usually small. In general, the announcements that the project most wants publicized are the ones that will be most publicized, assuming you use the right mechanisms to indicate relative newsworthiness to the outside world.

For major announcements, there tend to be four or five main channels of distribution, on which announcements should be made as nearly simultaneously as possible:

Dans le monde des logiciels libres on passe facilement des discussions internes aux communiqués officiels. Cela est en partie dû au fait que l'on ne sait jamais exactement à quel publique on s'adresse : comme tous ou la plupart des messages sont accessibles publiquement le projet ne contrôle pas entièrement l'appréciation du public. Quelqu'un, disons un éditeur de slashdot.org, pourrait attirer l'attention de millions de lecteurs sur un message que personne ne s'attendait à voir sortir du projet. C'est un aléa de la vie avec lequel tous les projets Open Source doivent composer, mais dans la pratique le risque est d'habitude très faible. En général les annonces que le projet veut rendre publiques sont celles qui seront le plus mises en avant, à la condition que vous utilisiez les bons outils pour indiquer l'importance relative de votre communiqué au monde extérieur.

Pour les annonces majeures on peut distinguer quatre à cinq voies principales de distributions au travers desquelles les annonces devraient être faites autant simultanément que faire se peut :
     1. Your project's front page is probably seen by more people than any other part of the project. If you have a really major announcement, put a blurb there. The blurb should be a very brief synopsis that links to the press release (see below) for more information.
  2. At the same time, you should also have a "News" or "Press Releases" area of the Web site, where the announcement can be written up in detail. Part of the purpose of a press release is to provide a single, canonical "announcement object" that other sites can link to, so make sure it is structured accordingly: either as one Web page per release, as a discrete blog entry, or as some other kind of entity that can be linked to while still being kept distinct from other press releases in the same area.
  3. If your project has an RSS feed, make sure the announcement goes out there too. This may happen automatically when you create the press release, depending on how things are set up at your site. (RSS is a mechanism for distributing meta-data-rich news summaries to "subscribers", that is, people who have indicated an interest in receiving those summaries. See http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html for more information about RSS.)
  4. If the announcement is about a new release of the software, then update your project's entry on http://freshmeat.net/ (see the section called “Announcing” about creating the entry in the first place). Every time you update a Freshmeat entry, that entry goes onto the Freshmeat change list for the day. The change list is updated not only on Freshmeat itself, but on various portal sites (including slashdot.org) which are watched eagerly by hordes of people. Freshmeat also offers the same data via RSS feed, so people who are not subscribed to your project's own RSS feed might still see the announcement via Freshmeat's.
  5. Send a mail to your project's announcement mailing list. This list's name should actually be "announce", that is, announce@yourprojectdomain.org, because that's a fairly standard convention now, and the list's charter should make it clear that it is very low-traffic, reserved for major project announcements. Most of those announcements will be about new releases of the software, but occasionally other events, such as a fundraising drive, the discovery of a security vulnerability (see the section called “Announcing Security Vulnerabilities”) later in this chapter, or a major shift in project direction may be posted there as well. Because it is low traffic and used only for important things, the announce list typically has the highest subscribership of any mailing list in the project (of course, this means you shouldn't abuse it—consider carefully before posting). To avoid random people making announcements, or worse, spam getting through, the announce list must always be moderated.


1. La page d'accueil de votre site Web est certainement la partie la plus visible du projet. Si vous devez faire une annonce particulièrement importante, affichez-y votre petit discours. Cela doit rester concis, un petit résumé qui renvoi vers le communiqué de presse (voir ci-dessous).

2. Parallèlement, vous devriez avoir aussi une section « Nouvelles » ou « Communiqués de presse » sur votre site Web où vous pourrez afficher toutes les annonces en détail. Les communiqués de presse servent de vitrine vers laquelle les autres sites peuvent re-diriger leurs lecteurs. Assurez vous donc qu'ils soient structurés en fonction : soit sous la forme d'une page Web par communiqué, soit par un nouvel article distinct ou sous n'importe quelle forme tant que l'on peut y accéder grâce à un lien sans qu'il y ait confusion possible avec d'autres communiqués.

3. Si vous avez créé un flux RSS pour votre projet, assurez vous qu'il relaie également l'annonce. Cela peut se faire automatiquement lorsque vous créez le communiqué de presse selon la configuration de votre site Web (Les flux RSS sont des outils pour distribuer des résumés de nouvelles contenant des meta-données aux « abonnés », c'est-à-dire aux personnes qui ont fait en sorte de recevoir ces résumés. Voir http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html pour plus d'informations à propos des flux RSS).

4. Si l'annonce que vous passez concerne une nouvelle version vous devez aussi modifier la page du projet sur http://freshmeat.net (voir la section nommée «  Annoncer » pour savoir comment créer cette page). Dès que vous modifier votre page sur Freshmeat la modification est annoncée sur la liste des changements du jour de Freshmeat. Cette liste est mise à jour sur Freshmeat mais aussi sur d'autres portails (slashdot.org compris) qui sont avidement surveillées par des hordes de gens. Freshmeat relaie également ces informations par son flux RSS. Ainsi, les gens qui ne sont pas abonnés à votre propre flux RSS pourront quand même recevoir l'annonce par celui de Freshmeat.

5. Envoyer un e-mail à la liste de diffusion d'annonces de votre projet. Le nom de cette liste devrait d'ailleurs êtres « annonce », c'est-à-dire que l'adresse devrait être annonce@domaineduprojet.org parce que c'est devenu une règle standard maintenant et que la charte de la liste devrait annoncer clairement qu'elle engendrera l'envoi de peu de mails et qu'elle est réservée aux annonces du projet. La plupart des annonces concerneront les nouvelles versions du logiciel mais aussi à l'occasion d'autres évènements comme une collecte de fonds, la découverte d'une faille de sécurité (voir la section « Annoncer les failles de sécurité » plus tard dans ce chapitre) ou encore un bouleversement dans la vie du projet pourront y être postés. Parce qu'elle génère peut de trafic et qu'elle n'est employée que pour des choses importantes, la liste d'annonces possède en général le plus grand nombre d'abonnés parmi toutes les listes du projet (ce qui implique donc que vous ne devriez pas en abuser, tournez sept fois vos doigts au dessus du clavier avant d'y poster). Pour éviter que n'importe qui y fasse des annonces, ou pire encore, qu'elle serve à renvoyer des spams, la liste d'annonces doit toujours être modérée.


Try to make the announcements in all these places at the same time, as nearly as possible. People might get confused if they see an announcement on the mailing list but then don't see it reflected on the project's home page or in its press releases area. If you get the various changes (e-mails, Web page edits, etc.) queued up and then send them all in a row, you can keep the window of inconsistency very small.

For a less important event, you can eliminate some or all of the above outlets. The event will still be noticed by the outside world in direct proportion to its importance. For example, while a new release of the software is a major event, merely setting the date of the next release, while still somewhat newsworthy, is not nearly as important as the release itself. Setting a date is worth an e-mail to the daily mailing lists (not the announce list), and an update of the project's timeline or status Web page, but no more.

However, you might still see that date appearing in discussions elsewhere on the Internet, wherever there are people interested in the project. People who are lurkers on your mailing lists, just listening and never saying anything, are not necessarily silent elsewhere. Word of mouth gives very broad distribution; you should count on it, and construct even minor announcements in such a way as to encourage accurate informal transmission. Specifically, posts that you expect to be quoted should have a clearly meant-to-be-quoted portion, just as though you were writing a formal press release. For example:

Just a progress update: we're planning to release version 2.0 of Scanley in mid-August 2005. You can always check http://www.scanley.org/status.html for updates. The major new feature will be regular-expression searches.

   Other new features include: ... There will also be various bugfixes, including: ...


Il faut que les annonces soient faites aussi simultanément que possible sur tous ces outils. Les gens pourraient trouver ça bizarre de voir l'annonce faite sur la liste de diffusion et de ne pas la retrouver sur la page d'accueil du projet ou dans la section « Communiqués de presse ». Si vous pouvez préparer les différentes modifications (e-mails, modifications de pages Web, etc.) et les envoyer d'un coup, les uns à la suite des autres, la période de « contradiction » pourra être largement réduite.

Pour un évènement de moindre importance vous pouvez réduire le nombre de canaux employés, voir même n'en utiliser aucun. L'évènement sera quand même remarqué par le monde extérieur à hauteur de son importance. Par exemple, alors que la sortie d'une nouvelle version d'un logiciel est un évènement important, le simple fait d'annoncer la date de la future version, même si cela reste une nouvelle importante, est loin d'être aussi important que la sortie en elle-même. Quand une date est arrêtée pour la prochaine version vous pouvez très bien vous contenter d'envoyer un mail sur les listes de diffusions générales (pas la liste d'annonces) et mettre à jour les prévisions du projet ou la page d'avancement.

Vous verrez malgré tout cette date apparaître dans les discussions sur d'autres sites Internet, partout où des gens sont intéressés par votre projet. Les gens qui suivent votre liste de diffusion, qui ne font que la consulter sans jamais y participer, ne sont pas nécessairement muets ailleurs. Le bouche à oreille peut porter rapidement les nouvelles, vous devriez compter dessus et rédiger les annonces même mineures de manière à encourager la transmission exacte de l'information. En particulier, les messages que vous espérez voir cités devraient contenir une partie explicitement faite pour être citée, comme si vous écriviez un communiqué de presse officiel. Par exemple :

Quelque nouvelles sur l'avancement : nous pensons sortir la version 2.0 de Scanley vers la mi-août 2005. Nous vous invitons à consulter la page http://www.scanley.org/status.html régulièrement pour connaître les dernières nouvelles. La grosse nouveauté sera la recherche par expression habituelle.

   Parmi les autres nouvelles fonctionnalités vous retrouverez : ... Nous ajouterons également différentes corrections de bogues, à commencer par : ...   


The first paragraph is short, gives the two most important pieces of information (the release date and the major new feature), and a URL to visit for further news. If that paragraph is the only thing that crosses someone's screen, you're still doing pretty well. The rest of the mail could be lost without affecting the gist of the content. Of course, sometimes people will link to the entire mail anyway, but just as often, they'll quote only a small part. Given that the latter is a possibility, you might as well make it easy for them, and in the bargain get some influence over what gets quoted.


Le premier paragraphe est succin et donne les deux informations principales (la date de sortie et la grande nouveauté) ainsi que l'URL à visiter pour plus d'informations. Si ce paragraphe est le seul à être repris vous aurez quand même réussi à passer l'information. Le reste du mail peut-être « oublié » sans amputer le message de son essence. Il y aura toujours des personnes qui mettront un lien vers le mail complet, mais il est aussi probable qu'ils n'en citeront qu'une partie. Puisque cette possibilité existe, autant leur simplifier la tâche et par la même occasion contrôler un peu mieux ce qui sera cité.

Announcing Security Vulnerabilities / Annoncer les failles de sécurité

Handling a security vulnerability is different from handling any other kind of bug report. In free software, doing things openly and transparently is normally almost a religious credo. Every step of the standard bug-handling process is visible to all who care to watch: the arrival of the initial report, the ensuing discussion, and the eventual fix.

Security bugs are different. They can compromise users' data, and possibly users' entire computers. To discuss such a problem openly would be to advertise its existence to the entire world—including to all the parties who might make malicious use of the bug. Even merely committing a fix effectively announces the bug's existence (there are potential attackers who watch the commit logs of public projects, systematically looking for changes that indicate security problems in the pre-change code). Most Open Source projects have settled on approximately the same set of steps to handle this conflict between openness and secrecy, based on the these basic guidelines:


La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'en suit et le correctif.

Les bogues de sécurité sont différents. Ils peuvent mettre en danger des données des utilisateurs voir même leur système entier. Parler de ce problème ouvertement reviendrait à lui faire de la publicité devant le monde entier, y compris ceux qui voudraient en faire un usage malveillant. Le simple fait d'envoyer un correctif annonce l'existence du bogue (des agresseurs potentiels surveillent les journaux de commit des projets publiques à la recherche de modifications qui indiquent des problèmes de sécurité). La plupart des projets Open Source se sont mis d'accord sur une série d'étapes à peu près standard pour gérer ce conflit entre ouverture et discrétion, elles sont basées sur ces quelques grandes lignes :


  1.  Don't talk about the bug publicly until a fix is available; then supply the fix at exactly the same moment you announce the bug.
 
  2. Come up with that fix as fast as you can—especially if someone outside the project reported the bug, because then you know there's at least one person outside the project who is able to exploit the vulnerability.
In practice, those principles lead to a fairly standardized series of steps, which are described in the sections below.


  1. Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue.
  2. Concocter un correctif aussi rapidement que possible, surtout si c'est quelqu'un d'étranger au projet qui a rapporté le bogue, parce qu'alors vous savez qu'au moins une personne en dehors du projet est capable d'exploiter la vulnérabilité.
Dans la pratique, ces principes ont donné naissance à une série de mesures plus ou moins standardisées qui sont décrites dans les parties suivantes.
Receive the report / Réception du rapport
Obviously, a project needs the ability to receive security bug reports from anyone. But the regular bug reporting address won't do, because it can be watched by anyone too. Therefore, have a separate mailing list for receiving security bug reports. That mailing list must not have publicly readable archives, and its subscribership must be strictly controlled—only long-time, trusted developers can be on the list. If you need a formal definition of "trusted", you can use "anyone who has had commit access for two years or more" or something like that, to avoid favoritism. This is the group that will handle security bugs.


Il semble évident que pour commencer le projet doit pouvoir recevoir un rapport de bogue de sécurité de n'importe qui. Mais l'adresse normale pour rapporter les bogues n'est pas adaptée ici parce qu'elle peut être vue par tout le monde. Il vous faudra donc une adresse différente pour recevoir les rapports de bogue de sécurité. Les archives de cette liste de diffusion ne doivent pas être visibles publiquement et les abonnés doivent être triés, seuls les développeurs présents de longue date et surs peuvent être sur cette liste. S'il vous faut une définition plus concrète de « surs » voyez cela comme « toute personne qui possède l'accès de commit depuis deux ans au moins » ou quelque chose comme ça pour éviter le favoritisme. C'est le groupe qui devra gérer les failles de sécurité.


Ideally, the security list should not be spam-protected or moderated, since you don't want an important report to get filtered out or delayed just because no moderators happened to be online that weekend. If you do use automated spam-protection software, try to configure it with high-tolerance settings; it's better to let a few spams through than to miss a report. For the list to be effective, you must advertise its address, of course; but given that it will be unmoderated and, at most, lightly spam-protected, try to never to post its address without some sort of address hiding transformation, as described in the section called “Address hiding in archives” in Chapter 3, Technical Infrastructure. Fortunately, address-hiding need not make the address illegible; see http://subversion.tigris.org/security.html, and view that page's HTML source, for an example.


Idéalement cette liste de sécurité ne devrait pas être protégée du spam ou modérée ou alors vous risqueriez d'évincer un rapport important ou de le retarder parce qu'aucun modérateur n'était disponible ce week-end. Si par contre vous utilisez un logiciel pour vous prémunir du spam utilisez des réglages tolérants, il vaut mieux laisser passer quelques spams que de manquer un rapport. Pour que cette liste soit efficace vous devez évidemment rendre son adresse bien visible, mais comme elle ne sera pas modérée et qu'au mieux elle sera faiblement protégée contre le spam ne l'affichez jamais sans transformation, masquez la comme nous l'avons vu dans la section « Masquer les adresses dans les archives » dans le Chapitre 3, Infrastructure technique. Heureusement, le masquage de l'adresse ne la rend pas nécessairement illisible, voir http://subversion.tigris.org/security.html et jetez un oeil à son code source pour y trouver un exemple.
Develop the fix quietly / Développer le correctif en secret

So what does the security list do when it receives a report? The first task is to evaluate the problem's severity and urgency:

1. How serious is the vulnerability? Does it allow a malicious attacker to take over the computer of someone who uses your software? Or does it, say, merely leak information about the sizes of some of their files?

2. How easy is it to exploit the vulnerability? Can an attack be scripted, or does it require circumstantial knowledge, educated guessing, and luck?

3. Who reported the problem to you? The answer to this question doesn't change the nature of the vulnerability, of course, but it does give you an idea of how many other people might know about it. If the report comes from one of the project's own developers, you can breathe a little easier (but only a little), because you can trust them not to have told anyone else about it. On the other hand, if it came in an e-mail from anonymous14@globalhackerz.net, then you'd better act as fast as you can. The person did you a favor by informing you of the problem at all, but you have no idea how many other people she's told, or how long she'll wait before exploiting the vulnerability on live installations.


Que doit donc faire la liste de sécurité quand elle reçoit un rapport ? La première chose à faire est d'évaluer la sévérité du problème et son urgence :

1. Quelle est la gravité de la vulnérabilité ? Est-ce qu'elle permet à un agresseur malintentionné de prendre le contrôle de l'ordinateur d'une personne utilisant le logiciel ? Ou ne fait-elle, par exemple, que divulguer des informations à propos de la taille de certains fichiers ?

2. Avec quelle facilité peut-on exploiter cette vulnérabilité ? Une attaque peut-elle être scriptée ou requiert-elle une connaissance détaillée, du raisonnement et de la chance ?

3. Qui a rapporté le problème ? La réponse à cette question ne change pas la nature de la vulnérabilité évidemment, mais cela vous donne une idée du nombre de personnes qui pourraient être au courant. Si le rapport provient de l'un des développeurs du projet vous pouvez vous détendre un peu (mais seulement un peu), en effet, vous pouvez lui faire confiance pour ne pas l'avoir crié sur les toits. A l'opposé, si le rapport provient d'un mail de anonyme14@globalhackers.net vous devriez agir au plus vite. Cette personne vous a rendu service en vous informant du problème, mais vous n'avez aucune idée du nombre de personnes qu'elle a pu mettre au courant ou de combien de temps elle attendra avant d'exploiter la faille à grande échelle.


Note that the difference we're talking about here is often just a narrow range between urgent and extremely urgent. Even when the report comes from a known, friendly source, there could be other people on the Net who discovered the bug long ago and just haven't reported it. The only time things aren't urgent is when the bug inherently does not compromise security very severely.


Comme vous l'avez remarqué, l'éventail d'urgence ne s'étend que de « urgent » et « extrêmement urgent ». Même si le rapport provient d'une source connue et inoffensive il peut très bien y avoir d'autres personnes sur le Net qui ont découvert le bogue depuis longtemps mais qui ne l'ont pas rapporté. Le seul cas de figure où il n'y a pas vraiment urgence est quand par sa nature le bogue ne pose pas de risque important de sécurité.


} The "anonymous14@globalhackerz.net" example is not facetious, by the way. You really may get bug reports from identity-cloaked people who, by their words and behavior, never quite clarify whether they're on your side or not. It doesn't matter: if they've reported the security hole to you, they'll feel they've done you a good turn, and you should respond in kind. Thank them for the report, give them a date on or before which you plan to release a public fix, and keep them in the loop. Sometimes they may give you a date—that is, an implicit threat to publicize the bug on a certain date, whether you're ready or not. This may feel like a bullying power play, but it's more likely a preëmptive action resulting from past disappointment with unresponsive software producers who didn't take security reports seriously enough. Either way, you can't afford to tick this person off. After all, if the bug is severe, he has knowledge that could cause your users big problems. Treat such reporters well, and hope that they treat you well.


Et au fait, l'exemple de « anonyme14@globalhackers.net » n'est pas facétieux. Il est fort probable que vous receviez des rapports de bogues de personnes masquant leur identité et qui, par leurs mots ou leur comportement, n'établissent jamais clairement s'ils sont de votre côté ou contre vous. Cela n'a pas d'importance : s'ils vous ont rapporté la faille de sécurité ils se diront qu'ils vous ont fait une faveur et vous devriez répondre en conséquence. Remerciez les pour le rapport, donnez leur un délai dans lequel vous prévoyez de fournir un correctif public et gardez les dans la confidence. Parfois ils vous donneront une date, c'est une menace implicite de publier le bogue à une échéance donnée, que vous soyez prêt ou non. Ca peut ressembler à de l'intimidation, mais il faut plutôt y voir une action préventive, fruit de déceptions passées dues au manque de réactivité de fabricants de logiciels qui n'ont pas pris ces rapports de sécurité au sérieux. Quoiqu'il en soit vous ne pouvez pas vous permettre de simplement mettre cette personne de côté. Après tout, si le bogue est important, elle dispose des connaissances nécessaires pour vous causer de gros ennuis. Traiter ces rapporteurs correctement en espérant qu'ils en feront de même en retour.


Another frequent reporter of security bugs is the security professional, someone who audits code for a living and keeps up on the latest news of software vulnerabilities. These people usually have experience on both sides of the fence—they've both received and sent reports, probably more than most developers in your project have. They too will usually give a deadline for fixing a vulnerability before going public. The deadline may be somewhat negotiable, but that's up to the reporter; deadlines have become recognized among security professionals as pretty much the only reliable way to get organizations to address security problems promptly. So don't treat the deadline as rude; it's a time-honored tradition, and there are good reasons for it.


Un autre cas fréquent est le rapport de bogue rédigé par un professionnel en sécurité, quelqu'un qui gagne sa vie en inspectant les codes et qui garde toujours un œil sur les dernières vulnérabilités des logiciels. Ces personnes possèdent en général la double expérience d'avoir déjà reçu des rapports de bogues et d'en avoir envoyé aussi, sûrement plus que la plupart des développeurs de votre projet. Ils sont aussi coutumier des dates limites imposées avant lesquelles vous devez réparer le problème avant qu'il ne dévoile la faille au public. Dans certains cas vous pouvez négocier cette date, mais tout dépend du rapporteur. Le fait d'imposer une date limite s'est imposé petit à petit dans le monde des professionnels en sécurité comme le seul moyen sûr pour que les organisations répondent rapidement aux problèmes de sécurité. Ne voyez donc pas ces dates limites comme une pratique grossière, si cette manière de faire s'est imposée avec le temps c'est qu'il y a de bonnes raisons.


Once you know the severity and urgency, you can start working on a fix. There is sometimes a tradeoff between doing a fix elegantly and doing it speedily; this is why you must agree on the urgency before you start. Keep discussion of the fix restricted to the security list members, of course, plus the original reporter (if she wants to be involved) and any developers who need to be brought in for technical reasons.


Une fois la sévérité et l'urgence établis vous pouvez commencer à travailler sur le correctif. Il faut trouver le bon équilibre entre faire les choses avec élégance et faire les choses rapidement. C'est la raison pour laquelle il faut déterminer l'urgence de la situation avant de commencer. Il faut que la discussion concernant le correctif reste entre les membres de la liste de sécurité et le rapporteur initial (s'il veut être impliqué) et tout développeur dont les compétences seront nécessaires.


Do not commit the fix to the repository. Keep it in patch form until the go-public date. If you were to commit it, even with an innocent-looking log message, someone might notice and understand the change. You never know who is watching your repository and why they might be interested. Turning off commit e-mails wouldn't help; first of all, the gap in the commit mail sequence would itself look suspicious, and anyway, the data would still be in the repository. Just do all development in a patch and keep the patch in some private place, perhaps a separate, private repository known only to the people already aware of the bug. (If you use a decentralized version control system like Arch or SVK, you can do the work under full version control, and just keep that repository inaccessible to outsiders.)


N'enregistrez pas le correctif dans le dépôt. Il faut le garder à l'écart jusqu'à la date de publication. Si vous l'enregistriez, même avec un message de journal innocent, quelqu'un pourrait le remarquer et comprendre la modification. Vous n'êtes jamais sûr de qui surveille votre dépôt ni de ses motivations. Arrêter les e-mails de commit n'arrangerait rien, en premier lieu parce qu'un trou dans la suite des courriers serait suspicieux et de toute façon les données se retrouveraient dans le dépôt. Contentez vous de mener tout le développement hors du dépôt et conservez ce travail dans un endroit secret, pourquoi pas un dépôt privé, distinct, connu des seuls personnes déjà au courant du bogue (Si vous utilisez un logiciel de gestion de version décentralisé comme Arch ou SVK vous pouvez travailler sous gestion de version et simplement empêcher l'accès à ce dépôt aux personnes externes).
CAN/CVE numbers / Les numéros CAN/CVE

You may have seen a CAN number or a CVE number associated with security problems. These numbers usually look like "CAN-2004-0397" or "CVE-2002-0092", for example.

Both kinds of numbers represent the same type of entity: an entry in the list of "Common Vulnerabilities and Exposures" list maintained at http://cve.mitre.org/. The purpose of the list is to provide standardized names for all known security problems, so that everyone has a unique, canonical name to use when discussing one, and a central place to go to find out more information. The only difference between a "CAN" number and a "CVE" number is that the former represents a candidate entry, not yet approved for inclusion in the official list by the CVE Editorial Board, and the latter represents an approved entry. However, both types of entries are visible to the public, and an entry's number does not change when it is approved—the "CAN" prefix is simply replaced with "CVE".


Vous avez déjà peut-être rencontré un numéro CAN ou CVE associé à un problème de sécurité. Il se présente en général sous cette forme : « CAN-2004-0397 » ou « CVE-2002-00923 ».

Ces deux types de numéros représentent la même chose : une entrée dans la liste des « Common Vulnerabilities and Exposures » ou « Vulnérabilités et Failles Classiques », cette liste est maintenue à l'adresse http://cve.mitre.org/. Son but est de fournir des noms standardisés pour tous les problèmes de sécurité connus afin que chacun ait un nom canonique unique que l'on peut employer pour le désigner et aussi de fournir un site de centralisation où l'on peut se rendre pour obtenir plus d'informations. La seule différence entre les numéros « CAN » et « CVE » est que le premier représente une demande d'inclusion (candidate entry), par encore approuvée pour l'ajout à la liste officielle par l'équipe rédactionnelle de CVE et que le dernier désigne une entrée approuvée. Ces deux types d'entrées sont de toute façon visible par le public et le numéro de l'entrée n'est pas modifié lorsqu'elle est approuvée, le préfixe « CAN » est simplement remplacé par « CVE ».


{{{2}}}
{{{2}}}


If your vulnerability meets the CVE criteria, you may wish to acquire it a CAN number. The process for doing so is deliberately gated: basically, you have to know someone, or know someone who knows someone. This is not as crazy as it might sound. In order for the CVE Editorial Board to avoid being overwhelmed with spurious or poorly written submissions, they take submissions only from sources they already know and trust. In order to get your vulnerability listed, therefore, you need to find a path of acquaintance from your project to the CVE Editorial Board. Ask around among your developers; one of them will probably know someone else who has either done the CAN process before, or knows someone who has, etc. The advantage of doing it this way is also that somewhere along the chain, someone may know enough to tell you that a) it wouldn't count as a vulnerability or exposure according to MITRE's criteria, so there is no point submitting it, or b) the vulnerability already has a CAN or CVE number. The latter can happen if the bug has already been published on another security advisory list, for example at http://www.cert.org/ or on the BugTraq mailing list at http://www.securityfocus.com/. (If that happened without your project hearing about it, then you should worry what else might be going on that you don't know about.)


Si votre vulnérabilité rempli les critères de CVE, vous pouvez postuler pour un numéro CAN. Le processus pour ce faire est délibérément fermé, vous devez connaître quelqu'un, ou quelqu'un qui connaît quelqu'un. Ce n'est pas aussi étrange que cela puisse paraître. Afin d'éviter que l'équipe rédactionnelle de CVE croule sous les demandes mal rédigées ils n'acceptent les soumissions que par des sources qu'ils connaissent et en qui ils ont confiance. Si vous souhaitez voir votre vulnérabilité listée vous devez donc d'abord trouver un intermédiaire entre votre projet et l'équipe rédactionnelle de CVE. Interrogez d'abord vos développeurs, il se peut très bien que l'un d'entre eux connaisse déjà quelqu'un qui serait passé par le processus CAN avant ou qu'il connaisse quelqu'un d'autre encore qui l'aurait déjà fait, etc. L'avantage de cette manière de procéder est que quelque part sur l'échelle de connaissances quelqu'un peut être suffisamment renseigné pour vous dire que a) votre demande ne répond pas aux critères de MITRE et que donc ce n'est pas la peine de la faire ou que b) cette vulnérabilité possède déjà un numéro CAN ou CVE. Ce dernier cas peut se produire si le bogue a déjà été publié sur une autre liste de sécurité, par exemple à l'adresse http://www.cert.org/ ou sur la liste de diffusion de BugTraq à l'adresse http://www.securityfocus.com/ (Si cela se produit sans que votre projet n'en entende parler alors vous devriez vous demander quels autres évènements vous avez loupés.)


If you get a CAN/CVE number at all, you usually want to get it in the early stages of your bug investigation, so that all further communications can refer to that number. CAN entries are embargoed until the go-public date; the entry will exist as an empty placeholder (so you don't lose the name), but it won't reveal any information about the vulnerability until the date on which you will be announcing the bug and the fix.


Si vous réussissez finalement à obtenir un numéro CAN/CVE il vaut mieux l'avoir tout au début de vos recherches concernant le bogue afin que toutes les communications ultérieures puissent se référer à ce numéro. Il y a un embargo sur les entrées CAN maintenu jusqu'à leur date de publication, l'entrée reste vide mais sert à réserver le numéro afin de ne pas le perdre, mais elle ne révélera aucune information à propos de la vulnérabilité jusqu'à la date à laquelle vous annoncerez le bogue et le correctif.


More information about the CAN/CVE process may be found at http://cve.mitre.org/about/candidates.html, and a particularly clear exposition of one Open Source project's use of CAN/CVE numbers is at http://www.debian.org/security/cve-compatibility.


Vous trouverez plus d'informations à propos du processus CAN/CVE à l'adresse http://cve.mitre.org/about/candidates.html ainsi qu'une explication particulièrement claire de l'utilisation de la numérotation CAN/CVE par un projet Open Source à l'adresse http://www.debian.org/security/cve-compatibility.
Pre-notification / Pré-notification
Once your security response team (that is, those developers who are on the security mailing list, or who have been brought in to deal with a particular report) has a fix ready, you need to decide how to distribute it.


Une fois que votre équipe de sécurité (c'est-à-dire les développeurs de la liste de diffusion de sécurité plus les personnes à qui on a fait appelle pour leurs compétences) a préparé un correctif vous devez décider de la manière de le distribuer.


If you simply commit the fix to your repository, or otherwise announce it to the world, you effectively force everyone using your software to upgrade immediately or risk being hacked. It is sometimes appropriate, therefore, to do pre-notification for certain important users. This is particularly true with client/server software, where there may be well-known servers that are tempting targets for attackers. Those servers' administrators would appreciate having an extra day or two to do the upgrade, so that they are already protected by the time the exploit becomes public knowledge.


Si vous ajoutez simplement ce correctif à votre dépôt, ou si vous mettez le monde au courant d'une quelconque manière, vous faites peser la menace d'une attaque sur vos utilisateurs qui seront alors obligés de mettre à jour le logiciel. Il est donc par conséquent parfois de bon ton de pré-notifier certains utilisateurs importants. C'est particulièrement vrai pour les logiciels client/serveur qui peuvent être utilisés par des serveurs bien connus qui pourraient devenir des cibles privilégiées des agresseurs. Les administrateurs de ces serveurs vous seraient reconnaissants d'avoir un délai d'un jour ou deux pour faire la mise à jour afin d'être déjà protégés lorsque la faille est rendue publique.


Pre-notification simply means sending mails to those administrators before the go-public date, telling them of the vulnerability and how to fix it. You should send pre-notification only to people you trust to be discreet with the information. That is, the qualification for receiving pre-notification is twofold: the recipient must run a large, important server where a compromise would be a serious matter, and the recipient must be known to be someone who won't blab about the security problem before the go-public date.


Vous avez simplement besoin d'envoyer un mail à ces administrateurs avant la date de publication les informant de la vulnérabilité et des solutions. Vous ne devriez envoyer ces pré-notifications qu'aux personnes en qui vous avez confiance. Pour rentrer dans cette catégorie il y a deux conditions : le destinataire doit administrer un serveur important où un risque pourrait avoir des conséquences grave et le destinataire doit avoir la réputation de quelqu'un qui n'ira pas ébruiter le problème de sécurité avant la date de publication.


Send each pre-notification mail individually (one at a time) to each recipient. Do not send to the entire list of recipients at once, because then they would see each others' names—meaning that you would essentially be alerting each recipient to the fact that each other recipient may have a security hole in her server. Sending it to them all via blind CC (BCC) isn't a good solution either, because some admins protect their inboxes with spam filters that either block or reduce the priority of BCC'd mail, since so much spam is sent via BCC these days.

Here's a sample pre-notification mail:


Envoyez chaque mail de pré-notification individuellement (un par un) à chaque destinataire. Ne l'envoyez pas à une liste entière de destinataires en une fois parce qu'alors chacun verrait le nom des autres et ce serait comme les avertir que tous les autres destinataires ont peut-être une faille de sécurité sur leur serveur. Il ne faut pas non plus les envoyer en copie invisible (BCC pour Blind Carbon Copy) parce que les administrateurs protègent leurs boîtes de réception avec des filtres anti-spam qui bloquent ou abaissent la priorité des courriers reçus en BCC puisqu'énormément de spam est envoyé en BCC.

Voici un exemple de mail de pré-notification :


From: Your Name Here To: admin@large-famous-server.com Reply-to: Your Name Here (not the security list's address) Subject: Confidential Scanley vulnerability notification.

This e-mail is a confidential pre-notification of a security alert in the Scanley server.

Please *do not forward* any part of this mail to anyone. The public announcement is not until May 19th, and we'd like to keep the information embargoed until then.

You are receiving this mail because (we think) you run a Scanley server, and would want to have it patched before this security hole is made public on May 19th.

References:


  CAN-2004-1771: Scanley stack overflow in queries

Vulnerability:


  The server can be made to run arbitrary commands if the server's
  locale is misconfigured and the client sends a malformed query.

Severity:


  Very severe, can involve arbitrary code execution on the server.

Workarounds:


  Setting the 'natural-language-processing' option to 'off' in
  scanley.conf closes this vulnerability.

Patch:

  The patch below applies to Scanley 3.0, 3.1, and 3.2.
  A new public release (Scanley 3.2.1) will be made on or just before
  May 19th, so that it is available at the same time as this
  vulnerability is made public.  You can patch now, or just wait for
  the public release.  The only difference between 3.2 and 3.2.1 will
  be this patch.
[...patch goes here...]


Référence :

   CAN-2004-1771 : Scanley stack overflow in queries

Vulnérabilité :

   Il est possible de faire exécuter des commandes au hasard au serveur
   si le serveur est mal configuré et que le client envoi une requête mal
   conçue.

Contournements :

  Désactiver l'option 'natural-language-processing' dans scanley.conf
  ferme la faille.

Correctif :

  Le correctif qui suit s'applique à Scanley 3.0, 3.1 et 3.2
  Une nouvelle version publique (Scanley 3.2.1) sera publiée le
  19 mai ou juste avant afin d'être disponible au moment où
  la vulnérabilité sera divulguée. Vous pouvez appliquer le
  correctif maintenant ou simplement attendre la sortie publique.
  La seule différence entre les version 3.2 et 3.2.1 sera ce
  correctif
[...insérer le correctif ici...]


If you have a CAN number, include it in the pre-notification (as shown above), even though the information is still embargoed and therefore the MITRE page will show nothing. Including the CAN number allows the recipient to know with certainty that the bug they were pre-notified about is the same one they later hear about through public channels, so they don't have to worry whether further action is necessary or not, which is precisely the point of CAN/CVE numbers.


Si vous avez un numéro CAN indiquez le dans la pré-notification (comme ci-dessus) même si l'information est toujours sous embargo est que la page MITRE est donc encore vide. En ajoutant le numéro CAN vous êtes sûr que le destinataire sait avec certitude que le bogue pour lequel vous lui envoyez la pré-notification est le même que celui dont il entendra parler un peu plus tard par voie publique. Ainsi il n'a pas à se demander s'il doit prendre d'autres mesures ou pas, ce qui est précisément le but des numéros CAN/CVE.
Distribute the fix publicly / Distribuez le correctif publiquement
The last step in handling a security bug is to distribute the fix publicly. In a single, comprehensive announcement, you should describe the problem, give the CAN/CVE number if any, describe how to work around it, and how to permanently fix it. Usually "fix" means upgrading to a new version of the software, though sometimes it can mean applying a patch, particularly if the software is normally run in source form anyway. If you do make a new release, it should differ from some existing release by exactly the security patch. That way, conservative admins can upgrade without worrying about what else they might be affecting; they also don't have to worry about future upgrades, because the security fix will be in all future releases as a matter of course. (Details of release procedures are discussed in the section called “Security Releases” in Chapter 7, Packaging, Releasing, and Daily Development.)


La dernière chose qu'il vous reste à faire est de distribuer le correctif publiquement. Dans une annonce unique et complète vous devez décrire le problème, donner le numéro CAN/CVE s'il y en a un, décrire comment contourner le bogue et comment le régler définitivement. « Régler définitivement » implique souvent la mise à jour du logiciel même si parfois cela peut simplement vouloir dire appliquer un correctif, surtout si le logiciel est normalement utilisé sous forme de source. Si vous proposez une nouvelle version du logiciel, celle-ci ne doit différer de la précédente que par le correctif de sécurité. Ainsi les administrateurs plutôt conservateurs pourront faire la mise à jour sans se préoccuper d'autres conséquences. Ils n'ont pas à se soucier non plus des mises à jours futures puisqu'ils sauront que le correctif y sera également inclus (Les détails concernant les procédures de publication sont abordés dans la section nommée « Mises à jour de sécurité » dans le Chapitre 7, Création de paquets, sorties et développement quotidien).


Whether or not the public fix involves a new release, do the announcement with roughly the same priority as you would a new release: send a mail to the project's announce list, make a new press release, update the Freshmeat entry, etc. While you should never try to play down the existence of a security bug out of concern for the project's reputation, you may certainly set the tone and prominence of a security announcement to match the actual severity of the problem. If the security hole is just a minor information exposure, not an exploit that allows the user's entire computer to be taken over, then it may not warrant a lot of fuss. You may even decide not to distract the announce list with it. After all, if the project cries wolf every time, users might end up thinking the software is less secure than it actually is, and also might not believe you when you have a really big problem to announce. See http://cve.mitre.org/about/terminology.html for a good introduction to the problem of judging severity.


Que le correctif public implique une nouvelle version ou pas, faites l'annonce avec plus ou moins la même priorité que vous le feriez pour une nouvelle version : envoyez un mail à la liste de diffusion d'annonces, écrivez un nouveau communiqué de presse, mettez à jour votre entrée sur Freshmeat, etc. Vous ne devriez jamais essayer de minimiser l'existence d'une faille de sécurité si vous vous souciez un tant soit peu de la réputation de votre projet mais gardez toujours à l'esprit qu'il faut adapter le ton et la visibilité d'une annonce de sécurité à la sévérité concrète du problème. Si le bogue de sécurité n'est qu'un risque mineur de révélation d'informations, pas une faille qui permettrait la prise de contrôle totale de l'ordinateur de l'utilisateur alors il ne devrait faire tant de bruit. Vous n'aurez peut-être même pas besoin de déranger la liste d'annonce pour ça. Après tout, si le projet cri au loup à chaque fois, les utilisateurs finiront par croire que le logiciel est moins sécurisé qu'il ne l'est vraiment et pourront également ne pas vous croire si vous avez un vrai problème à annoncer. Voir http://cve.mitre.org/about/terminology.html, cette page constitue une bonne introduction à la détermination de la sévérité d'un bogue.


In general, if you're unsure how to treat a security problem, find someone with experience and talk to them about it. Assessing and handling vulnerabilities is very much an acquired skill, and it's easy to make missteps the first few times.


De manière générale, si vous n'êtes pas certain des suites à donner à un problème de sécurité, trouvez quelqu'un d'expérience avec qui vous pourrez en discuter. Évaluer et gérer les vulnérabilités ne s'apprend pas du jour au lendemain et il est courant de faire des erreurs les premières fois.


[18] There has been some interesting academic research on this topic; for example, see Group Awareness in Distributed Software Development by Gutwin, Penner, and Schneider (this used to be available online, but seems to have disappeared, at least temporarily; use a search engine to find it).


[18] Quelques recherches académiques intéressantes sont parues sur le sujet, je vous renvoie par exemple à Group Awareness in Distributed Software Development par Gutwin, Penner et Schneider (cet ouvrage était disponible en ligne mais il semble qu'il ne le soit plus, temporairement en tout cas, utilisez un moteur de recherche pour le trouver).
Outils personnels