From: <dm...@us...> - 2004-06-25 06:17:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Mich=E8le Garoche wrote: | Hi David, | Hello :) | The French translation is ready, not added though, since adding it may | lead to an unfortunate activation later, while translating other documents. | | Apart some misspelling and wrong punctuation, I have noted two things | that are not perfectly clear to me: | | 1 - in preface | | ... Fink recognizes the necessity to offer a uniform policy | | offer seems to me a mild word as this is an enforcement. Maybe: to put | in place a.... that every maintainer should follow be it the case. | Actually I chose to phrase it that way becxause a) it is a known pharse in british english and b) we can only offer this security policy. The maintainer needs to stick to it. I really do not care though if you feel a stronger wording is more appropriate, please go ahead and change it. | 2 - The location of the maintainer's email address is stated twice in a | row in section who is responsible and whom shall I contact, maybe one i= s | sufficient, as both sections are below one another. | That is up to oyu guys. I really do not have that m,uch experience writing docs, but I want to avoid that people come rushing in, asking howe they can find the email of package foo, because there is a security issue. | 3 - The maintainer's role is not clear to me. Say the user notifies bot= h | the maintainer and Fink Core, the maintainer acknowledges the | notification, then what should he do? Nothing, just sitting awaiting | that the Fink Core Team answers? That's what appears to me when reading | section pre-notifications, unless I'm missing something obvious. | Actually I think that is made pretty clear in the preface. The maintainer has to take full responsibility and since this document is meant for package maintainers and security professionals I am sure they will know how we mean it. But, by all means, feel free to find a better wording or add a statement that everythign remains with the maintainer and Fink ASecurity Team only jumps in in special cases. | 4 - Should not the remote DOS exploit be presented before the local roo= t | exploit in section response time as its response time is shorter? The | same for remote data corruption. I mean it seems more logical to presen= t | them in order of responsiveness than in order of type of security | issues, as the the whole paragraph is about response time. | Well that depends on the point of view. I wrote this from the viewpoint of a security specilaist and to us the type of exploit is the more important information. Those repsonse times are only recommendations and we cannot possibly enforce them anyways. A security report will usually state the type of exploit as the more prominent thing, so I find it more useful this way. | 5 - The section forced update seems to contradict the section | pre-notifications from the point of view of the maintainer's role. Here= , | he is supposed to take action. Which ones? (as he is not supposed to | answer according to pre-notification section). | Pre-notifications are sent in some very special cases. When a critical flaw is deteced in a certain piece of wide spread softaware (like CVS), the author of the security advisory (some guy in the internet) might choose to contact KDE, Gnome, Debain, Fink and so on, so that those project can _silently_ patch their software andf server BEFORE and official update is made. Is that what confused you? | 6 - What the user should do when he discovers a security incident, but | it is not yet reported in the official sources? Not clear from section | acceptable incident sources. Well I thought that was clear. The <em>MISC</em>: generic reference from an URL </li> (as shown in the template) can be used to make us aware of such issues. However I forgot to add, that a MISC entry requires also another valid source. So if it is no pre-notification which one of the security members has to verify, the author simply has to wait until it shows up on one of the lists he submitted the stuff to. | | 7 - What happens when none of the conditions stated on section security | update procedure are met? Does the package remains as is in Fink? | I have not evaluated that yet. | 8 - Section unstable to stable moves: it is stated that the package inf= o | file is moved to stable. It can be also that there is a patch file. Well yes, but that is part of the package to me, so , to me, it is implied that the patch moves as well. However if you feel that needs to be mentioned as well, please do go ahead and do so. | | 9 - While it is good that the Fink announcement list be used, is that | certain that many users read it? (section sending notifications). Shoul= d | not a notification be sent to beginners and users mailing lists as soon | as the correction are made, to ensure that most users see it? | Well as far as I remeber fink-announce has over 1000 members and personally I feel it is the users responsibility to stay on top when it comes to security news. I, as aindividual, am against sending the notification to any other list than announce, but I am of coursde flexible there :) | 10 - Template | Should the package's version be stated too? | Actually, that is a good point, The version from when to where the softawre in question is vulnerable is missing. Thank you. I will add that. Thank you for the valuable input -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA28NFPMoaMn4kKR4RA4vGAJ0dsx2IJBFQRoGqvM0W5zAPIsZLHgCdEeOM C4FkhjtQ7fPAjH1IiQp5CyI=3D =3DmRI9 -----END PGP SIGNATURE----- |