Re: policy change is needed to keep debian secure

[Ben Bucksch]

Matt Zimmerman wrote:


I guess you aren't reading my mail, then.


He may well be. Which browser are you using?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Matt Zimmerman wrote:


Ben has now explained that this is in fact not sufficient.
 


No, I have not. Please read again what I wrote.


There is clearly a communication gap.

And it's not on my end. You still haven't answered my very specific 
questions about your problems and what you want.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

antgel wrote:


2) Mozilla security patches are not easy to find and isolate.

Ben has disputed this, saying that we should be able to extract all
necessary patches.  Public ones from
http://www.mozilla.org/projects/security/known-vulnerabilities.html then
bugzilla, and embargoed ones via mdz.
 

Note that I do *not* recommend that approach. I cannot garantee that all 
security fixes are listed there. Even more so for pro-active security 
changes which will prevent exploits in the future. (I'm not saying that 
this *does* happen, I just don't know. Here, communication between the 
groups would be useful, if nothing else to establish garantees.)


Also, this is far more work than just taking an existing branch and ship 
that.



3) Backporting the patches, once isolated, is a ballache.  (Is it that
security patches are applied to aviary as well as trunk, and that the
problem, more specifically, is that aviary itself is too far ahead of
Debian, or that the patches are only applied to trunk?)

I'd like to hear a comment from Ben about this.
 

Given that the "aviary" branch (1.0.x) is maintained by mozilla.org, it 
does have all the critical security fixes.

As I said, I don't know what the problems with backporting are.

I mean, right now, you are shipping FF 1.0.4 with sarge. If the 1.0.5/6 
patches don't apply to *that*, then I don't know either...


Ben


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Adeodato Simó wrote:


 "Publish to distributions" is effectively the same as making it
 completely public, so they won't.


Wrong.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Thomas Bushnell BSG wrote:


It would be very nice if Mozilla would publish to distributions like
ours a description of the security problem, and then a separate patch
for that specific problem.


  1. You to be going to
 
  2. You to be following links to bugzilla entries
  3. You to be downloading patch there or better yet search for CVS
 checkin, which has that bug number in commit log.

This is only possible after a release, like right now, i.e. when it's 
already too late. Distributions like yours, in your case Matt Zimmerman, 
have access to the resources before that, including bug report details 
under embargo. It does involve watching the list to see when releases 
are upcoming and why.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Matt Zimmerman wrote:


To organize their development processes such that patches can be backported
with a reasonable amount of effort.

I wrote a response, but deleted it, because I simply don't understand 
what you mean. Please be concrete, very very concrete.



I'm in Los Angeles, California, US.

If you happen to be in the SF Bay Area sometime, maybe schedule a 
meeting with Dan. I guess he'd welcome you.



Can Mozilla 1.7.11 even be *built* on woody


huh? Try it? Or are you expecting me to?

And I thought we were talking about sarge. All hope is lost for woody.

My question remains unanswered.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Matt Zimmerman wrote:


I'm guessing that you're not going to volunteer on the manpower side

Actually, he did, in the previous posting. Which is admirable, because 
this is a dauntingly huge task (and he seems semi-aware of it) - in the 
area of a few hours *per week*, on average. mozilla.org (and before it 
Netscape) has a full-time staff position just for security (he also does 
security features, though).



You're welcome to attempt to convince the Mozilla project to change
the way that they work for the benefit of distribution security teams.

I don't even know what exactly you do want the Mozilla project to 
change. You are officially part of the Mozilla security group since some 
time, so you are the right person to discuss a collaboration, and 
execute on it. Note that a discussion involves more than 1-2 emails with 
statements and requests.


BTW: Where are you located physically? Maybe you can meet with 
mozilla.orgians in person. I think you'll like Daniel Veditz in 
particular. And Mozilla Foundation needs more of the SPI spirit than the 
OSAF spirit anyways.


I hope you can understand, though, that the Mozilla project can't 
maintain whatever version you pick for Debian stable, for *3 years*. 
1.7.x already lives since almost a year. But, as I said, that's not the 
problem right now.


At the moment, I am still waiting for an answer to the question at the 
end of my first posting, which Alex repeated:


What's preventing you from shipping Moz 1.7.11 and FF 1.0.6 right now?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Importance of browser security (was: On Mozilla-* updates)

[Ben Bucksch]

Stefano Salvi wrote:

I prefer to have no X on the server and administer it from command 
line or Web interfaces (command line is better).


Let's say

  1. You use Mozilla from sarge
  2. Somebody cracks you through known holes in that old Mozilla,
 either a mass exploit or an enemy of you specifically targetting
 you. Which is probably the easiest way to attack you, through all
 firewalls. So much for browser/email security.
  3. He controls your desktop
  4. He downloads all your local mail and photos/images, including your
 confidental company mail, private mail and nude photos of your
 girlfriend. He posts it on the Internet, your company's billboard,
 and your supermarket's billboard.
  5. He also installs a keyboard sniffer and downloads your private SSH
 keys.
  6. He logs into all servers and other computers that you have access
 to. Including those desktops of your friends, which you remote
 administrate or use the password that they use for your server.
 And the attacker goes on from there. So much for desktop/server
 security.
  7. One of your friends did things which are strictly legal, but your
 boss didn't like it at all, and fired him. Another one happened to
 be a dissident and gets in jail or maybe shot. So much for
 efficiency (this has nothing to do with efficiency).
  8. Because all this costs some time, the attacker needs to live, too.
 He drafts your bank accounts and those of your friends as a fair
 compensation. The Half Life 2 source code got indeed stolen via
 desktop compromitation, too. But all that is insignificant in
 comparison to your dead friend.

That's what's at stake here.

I don't care, if a Mozilla security update breaks some badly written 
extensions. And if it breaks Galeon's print function, so be it, you can 
still use Mozilla in this rare case. But there's *no* recovery from a 
bad breakin.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On Mozilla-* updates

[Ben Bucksch]

Hi Martin,

thanks for raising this publically. Sorry, if I sound provocive here, 
but this discussion has a history for me. As I said since several years, 
the only practical way for Debian to stay up-to-date with Mozilla 
security updates is to stay current with the latest "stable" release.


For Mozilla SeaMonkey, this means you shipped Mozilla 1.7.6 or whatever 
was current with Sarge and by now already distribute Mozilla 1.7.11 debs 
on security.debian.org.


Moz 1.7.11 was in cvs since a few days, so enough time to prepare ("a 
few days" from patch to end-user is all you get in the security world, 
and it's doable). It implies that you keep a close eye on what's 
happening at mozilla.org - if you see the announcement at 
www.mozilla.org, it's already too late. To faciliate cooperation, I have 
invited the Debian security people to the Mozilla security team long 
ago, with no result.


I personally maintain 1 or 2 browsers intended for the mass-market on 
all platforms based on Mozilla 1.7, and the source code changes in the 
releases were indeed very small, and close to (or at) the minimum 
possible to fix the security holes. Updates were surprisingly painless.


In one case (1.7.7), they did break some functionality, but that was 
inherent to the security update, because the "API" (a certain, obscure 
way to use JavaScript in combination with the DOM) was insecure and I 
don't think ever intended. As was visible on blogs, the mozilla security 
was very much trying to find a solution that wouldn't break things. That 
said, I had no problems at all with our code (although I expected lots). 
What's more important, everything that *did* break most likely had 
security hole itself, so arguably *should* break and not be used anymore.


So, basically, you can't *always* keep things running as they were and 
still be secure. What comes to me, the tradeoff is clear: An insecure 
system is completely unacceptable, and not usable *at all*. So given the 
choice of some extensions breaking and having gapping security holes, 
there's IMHO only one choice. What I'm getting at is that you *cannot* 
maintain your stance of "we'll never break or change anything noticable 
in a stable release for 3 years". If a user wants that, he should cut 
all network connections and never update.


I'm speaking mainly about SeaMonkey, I can't speak about Firefox and 
Thunderbird, esp. once they hit 1.5. What's hurting you in this case is 
the ultra-long release cycle of Debian stable. The problem you are 
*then* facing with backporting security fixes is the same that the 
mozilla security team would face - very often, it's unjustifiably 
time-consuming. As far as I know, caillon from and for Redhat (also a 
Mozilla contributor) is doing that, or at least used to, with Mozilla 
1.6. Maybe talk to him? But be prepared: this means real work.


But that's not the problem right now. What's wrong with just shipping 
Firefox and Thunderbird 1.0.6? Frankly, that's what they are meant for. 
The patches *are* backported from the trunk to 1.0.x for you. And using 
a different version number only confuses users (who check their 
vulnerability) and extensions.


Concretely, I don't understand what you base your introduction on:

it seems that less than two months after the release of sarge it is 
not possible to support Mozilla, Thunderbird, Firefox ... packages 
anymore. (in terms of fixing security related problems)


What hard reasons are there that prevent you from shipping Firefox 1.0.6 
and Mozilla 1.7.11 right now?


In the end, though, you have to drop the idea of keeping the everything 
as-is, no user-noticable changes, for 3 years. You have to lose your 
current ideas and put security first. (I'm not including freedom etc. 
here :-) .)


I am more than willing to help establish cooperation between Debian and 
mozilla.org, if there's interest.


--
Ben Bucksch
If replying privately, please remove ".news".


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]