BIND update?

Wesley Shields wxs at FreeBSD.org
Wed Jul 9 18:28:25 UTC 2008


On Wed, Jul 09, 2008 at 08:17:10PM +0200, Remko Lodder wrote:
> Wesley Shields wrote:
> > On Wed, Jul 09, 2008 at 01:27:06PM -0400, Josh Mason wrote:
> >> On 7/9/08, Remko Lodder <remko at freebsd.org> wrote:
> >>> Remko Lodder wrote:
> >>>> Josh Mason wrote:
> >>>>
> >>>> Thanks, you really showed how you are by sending these replies. I wish you
> >>> goodluck with your quest, perhaps someday someone can help you.
> >>>> Goodbye.
> >>>>
> >>>>
> >>> Hi,
> >>>
> >>> I am sorry for this reply, it was an expression of my frustation towards
> >>> you. The frustation is just easily generated by people demanding support
> >>> from volunteers, that are trying to service you and others in their own
> >>> spare time. Time that they can also spend on different items, yet we
> >>> crazy people decide to work on a Free Operating System, getting nothing
> >>> payed for it, only happy users (Where possible) around us.
> >>>
> >>> I think you can understand my frustration, because I think you would reply
> >>> the same if someone demanded even more free time from you.
> >>>
> >>> I hope you can understand this.
> >>>
> >>> //Remko
> >>>
> >> I completely understand and took no offence from your previous email -
> >> I know I am being confrontational. I myself have been in that position
> >> many a time before and know exactly how it feels. Unfortunately that
> >> doesn't negate the responsibility of the security team to produce
> >> patches quickly.
> >>
> >> The initial response of "the sec team is aware of the situation and
> >> will investigate" was basically just fluff. If you weren't already
> >> aware of it you aren't much of a sec team. What is needed is an
> >> expected delivery. I would say considering the nature of the exploit
> >> but honestly that shouldn't change anything at all. If the delivery
> >> isn't going to be immediate there should always be an ETA provided. If
> >> for nothing else other than so your users can plan around it (i.e.
> >> "this is too long I need to take action myself" - "or X time or date
> >> is sufficient I'll wait for the official release and apply it then").
> >> Without that people are twiddling their thumbs wondering if there is
> >> ever going to be one.
> > 
> > You have a good point there.  I'm not aware of any page which describes
> > the current issues under investigation by the security team.  If such a
> > thing does not exist I think it would be a good thing to have,
> > especially if it details rough timelines for things.  By that I mean
> > recording historic information and expected information (we received
> > notification on this date, we expect to have a final advisory on this
> > date).
> > 
> > In the security world there is a balance which must be maintained
> > between providing information to consumers so that they may plan
> > accordingly, and not providing too much information so that the
> > attackers can write exploits; this is the sensitive nature of the
> > information which often leads to opaque processes by security teams
> > around the world.  There is the case where full details are released
> > without advance notice to the vendors/projects, in which case the
> > balance has been lost from the start.
> > 
> > Remko, do you - or anyone else - on the security team have any thoughts
> > on this?  I'd be willing to step up and keep a wiki page (or something
> > else) up to date with the information.
> > 
> > -- WXS
> 
> There will be no such page with information about pending items. 
> Sometimes we are bound to non-disclosures etc. We handle this internally
> and will continue to do so. If people cannot live with that (like Josh) 
> then that's their challenge.
> 
> Note I speak largely for myself in this case. I am not going to support 
> a wiki page or something. I do not know what the other secteam members 
> think about that, but I expect something like my opinion.

That's certainly a fair statement.  I understand the non-disclosure
aspect of the situation, but I also feel a more transparent process
where ever possible is a good idea.  I suspect more thought on the
matter is necessary.

-- WXS


More information about the freebsd-security mailing list