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

Le 25 juin 2004, à 8:16, D. Höhn a écrit :
> | 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.
Maybe I'll add just that the maintainer should stick to 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.
I'd bet you could not avoid that, even if you put it 20 times within 
the file :-) I'll put a remainder.

> | 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.
Yes, I'll add a statement.

> | 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.
Oh, Ok, perfect.

> | 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?
Yes, thank you for the explanation.

> | 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.
Maybe explain that.

> | 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.
I'll do it.

> || 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 :)
I fully agree with you here, I was just wondering if this list was 
commonly read. It seems the answer is yes, so that's good enough for 
me.

Michèle
<http://micmacfr.homeunix.org>