Re: Translator Release for /cvsroot/fink/web/xml/security/sec-policy.en.xml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Michèle 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 is
| 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 both
| 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 root
| exploit in section response time as its response time is shorter? The
| same for remote data corruption. I mean it seems more logical to present
| 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 info
| 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). Should
| 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=
=mRI9
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com