In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2? I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
Silviu Marin-Caea wrote:
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
there are necessarily vulnerabilities in the box, what ever will be the freeze date... so better make a YOU update after installing... jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Tue, Apr 25, 2006 at 04:56:40PM +0200, jdd wrote:
Silviu Marin-Caea wrote:
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
there are necessarily vulnerabilities in the box, what ever will be the freeze date...
so better make a YOU update after installing...
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now. Ciao, Marcus
Hi, Marcus Meissner wrote:
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now.
Ciao, Marcus
I don't want to discuss this thing, but maybe someone can explain to me (it's just because I'm interested in the reasons for this method), why distributors choose to manually patch applications, instead of applying minor version updates from upstream? Manually applied patches can't be verified by the user, so as in the Qt 4.1.0 vs. 4.1.2 issue, I would think "SUSE doesn't even bugfix stability issues" even if the patches maybe have been applied manually without increasing the version number.. Philipp
On Tue, Apr 25, 2006 at 05:17:19PM +0200, Philipp Wollermann wrote:
Hi,
Marcus Meissner wrote:
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now.
Ciao, Marcus
I don't want to discuss this thing, but maybe someone can explain to me (it's just because I'm interested in the reasons for this method), why distributors choose to manually patch applications, instead of applying minor version updates from upstream? Manually applied patches can't be verified by the user, so as in the Qt 4.1.0 vs. 4.1.2 issue, I would think "SUSE doesn't even bugfix stability issues" even if the patches maybe have been applied manually without increasing the version number..
Certification for products might list specific fixed versions. Because just "minor version updates" in the OSS world occasionaly mean massive changes and it is hard to decide. Or even "minor version updates" break binary compatibility if libraries are provided. There is a class of "leaf packages" like Firefox where this is not so important and where we do upgrades on occassion already. (We did for the Firefox series in older products occasionaly.). The internal policy however sets it to backport if possible, to avoid any problems like the above (or others still unknown). Ciao, Marcus
Marcus Meissner wrote:
The internal policy however sets it to backport if possible, to avoid any problems like the above (or others still unknown).
this is a very important question, as the burden of backporting is high (on some products). could it be possible to write down a page (for example on opensuse wiki) to make this clear, for users but also for programmers. For this I'm ready to help For example: "A server must be able to run several years without major change. So it's mandatory to have stable version of any product patched for security for at least 5 years (don't forget this impact mostly comercial products). To achieve this is already done by most major comercial distributions. For a product to be included in such a distribution, making such patches available is a great plus. (then example of what to do and what to avoid - I'm sure you have plenty :-)" I know this is a reason for having paid clients, but I beg that if the original developpers makes it easier, they product have a great chance to be included in major distributions and themselves could provide this for a fee, still cheaper than making it from scratch :-) is this worth continuing? thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On 25 Apr 2006 at 17:20, Marcus Meissner wrote:
On Tue, Apr 25, 2006 at 05:17:19PM +0200, Philipp Wollermann wrote:
Hi,
Marcus Meissner wrote:
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now.
Ciao, Marcus
I don't want to discuss this thing, but maybe someone can explain to me (it's just because I'm interested in the reasons for this method), why distributors choose to manually patch applications, instead of applying minor version updates from upstream? Manually applied patches can't be verified by the user, so as in the Qt 4.1.0 vs. 4.1.2 issue, I would think "SUSE doesn't even bugfix stability issues" even if the patches maybe have been applied manually without increasing the version number..
Certification for products might list specific fixed versions.
OK.
Because just "minor version updates" in the OSS world occasionaly mean massive changes and it is hard to decide.
I can be, but need not. For every rule there should be execptions.
Or even "minor version updates" break binary compatibility if libraries are provided.
OK, may be, but strictly speaking no security-patched binary is binary-compatible to the non-patched version ;-) So this also depends very much on the details.
There is a class of "leaf packages" like Firefox where this is not so important and where we do upgrades on occassion already. (We did for the Firefox series in older products occasionaly.).
The internal policy however sets it to backport if possible, to avoid any problems like the above (or others still unknown).
Gererally OK, but sometimes it seems easier to make an exception. Regards, Ulrich
On 25 Apr 2006 at 17:09, Marcus Meissner wrote:
On Tue, Apr 25, 2006 at 04:56:40PM +0200, jdd wrote:
Silviu Marin-Caea wrote:
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
there are necessarily vulnerabilities in the box, what ever will be the freeze date...
so better make a YOU update after installing...
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now.
Is there any other change between 1.5.0.1 and 1.5.0.2 other than the version number and the security fixes? This security by obscurity just confuses users. Or is the reason that someone just didn't want to touch the RPM spec file? Regards, Ulrich
On Wed, Apr 26, 2006 at 11:20:10AM +0200, Ulrich Windl wrote:
On 25 Apr 2006 at 17:09, Marcus Meissner wrote:
On Tue, Apr 25, 2006 at 04:56:40PM +0200, jdd wrote:
Silviu Marin-Caea wrote:
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
there are necessarily vulnerabilities in the box, what ever will be the freeze date...
so better make a YOU update after installing...
The latest security bugs in FF 1.5.x have been applied already, check the changelog... A version upgrade wont be done now.
Is there any other change between 1.5.0.1 and 1.5.0.2 other than the version number and the security fixes? This security by obscurity just confuses users.
Or is the reason that someone just didn't want to touch the RPM spec file?
Because we are in absolutely deep feature freeze. Ciao, Marcus
Marcus Meissner
On Wed, Apr 26, 2006 at 11:20:10AM +0200, Ulrich Windl wrote:
On 25 Apr 2006 at 17:09, Marcus Meissner wrote: [...] Is there any other change between 1.5.0.1 and 1.5.0.2 other than the version number and the security fixes? This security by obscurity just confuses users.
Or is the reason that someone just didn't want to touch the RPM spec file?
No, that's not the reason. Developers always like to increase the number ;-)
Because we are in absolutely deep feature freeze.
Looking at the diff between our patched 1.5.0.1 version and our patched 1.5.0.2, we decided to move forward and include 1.5.0.3 for RC3. The version number is IMO marketing ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 06/04/26 12:19 (GMT-0400) Andreas Jaeger apparently typed:
No, that's not the reason. Developers always like to increase the number ;-)
Looking at the diff between our patched 1.5.0.1 version and our patched 1.5.0.2, we decided to move forward and include 1.5.0.3 for RC3. The version number is IMO marketing ;-)
That x.x.x.# version increment is mozilla.org's way of helping the dozers know there's been a change worth upgrading to get, and making their automatic updating system work, while ensuring that the more knowledgeable understand the change is one of two types of serious unrelated-to-new-features issues, either a security fix, or a crashing fix. Leaving out either type of fix from distro builds seems bad policy to me, while incorporating them via backporting without matching the version seems counterproductive. People who want real version upgrades to mozilla.org products get the nightly builds of the development versions, which for the FF line is found at http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ for 2.0 or http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ for 3.0, while http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0... has the latest 1.5.0.x builds with the lastest security and/or crash fixes for the stable release version. -- "Have nothing to do with the fruitless deeds of darkness, but rather expose them." Ephesians 5:11 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/
Hi! I really don't understand why a media with dangerous software is released after a SuSE security announcement is out already. Maybe the Yast team should invent an Online Update for the release tree (to be applied before release then). Regards, Ulrich On 25 Apr 2006 at 16:56, jdd wrote:
Silviu Marin-Caea wrote:
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
there are necessarily vulnerabilities in the box, what ever will be the freeze date...
so better make a YOU update after installing...
jdd
-- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Wed, Apr 26, 2006 at 11:17:27AM +0200, Ulrich Windl wrote:
Hi!
I really don't understand why a media with dangerous software is released after a SuSE security announcement is out already. Maybe the Yast team should invent an Online Update for the release tree (to be applied before release then).
It is already fixed on the media. Just with source patches instead of a version upgrade. Ciao, Marcus
Am Mittwoch, 26. April 2006 11:21 schrieb Marcus Meissner:
On Wed, Apr 26, 2006 at 11:17:27AM +0200, Ulrich Windl wrote:
Hi!
I really don't understand why a media with dangerous software is released after a SuSE security announcement is out already. Maybe the Yast team should invent an Online Update for the release tree (to be applied before release then).
It is already fixed on the media.
Just with source patches instead of a version upgrade.
Ciao, Marcus
The one problem I have with this situation is when projects like Mozilla turn round and give out a press release that there are security issues with 1.5.0.1 and all users should upgrade to 1.5.0.2 (well, Secunia announced today that 1.5.0.2 has a new vulnerability, so I guess 1.5.0.3 will be the current version in a couple of days). If a user isn't on the security announce list or hasn't seen this conversation, then they will assume that the version 1.5.0.1 that they have is compromised and will be looking for a 1.5.0.2 coming as a security fix over YOU, and when it doesn't appear, they will be complaining about SUSE not updating for security fixes and complaining about how hard it is trying to install the .tar.gz from the Mozilla site... This doesn't do either side any good. I can understand some of the reasons for doing the patching this way, but it just confuses the ordinary user who doesn't join any of the mailing lists. If they have 1.5.0.1 and Mozilla are saying upgrade to 1.5.0.2 because all older versions are insecure, how are they to know that SUSE have back-patched the relevant fixes? Probably a very small portion of the total user base join the factory list or security-announce... For example, I've been a SUSE user for around 5 years, but I only joined the mailing lists in November/December last year. If I hadn't read the relevant mails on the lists, I'd probably be cursing SUSE and downloading .0.2 from the Mozilla site... Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On Wed, Apr 26, 2006 at 01:10:33PM +0200, David Wright wrote:
For example, I've been a SUSE user for around 5 years, but I only joined the mailing lists in November/December last year. If I hadn't read the relevant mails on the lists, I'd probably be cursing SUSE and downloading .0.2 from the Mozilla site...
I read this and think: why would you go and download? I will just wait and let YOU take care of the solution. You know (or at least should know) that when you start downloading things from non-SUSE it won't be updated with YOU. During the installation you are asked to do a security update. So when the final ISO comes out and an hour later there is a security fix, you will be able to get the update during installation. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
During the installation you are asked to do a security update. So when the final ISO comes out and an hour later there is a security fix, you will be able to get the update during installation.
i read recently that there are 1500+ package in SUSE (and not 170), are they _all_ maintained? if so, this is not advertised enough. Is it possible to say (in a wiki page) "SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package" if not, list the packages relevant. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 02:55:25PM +0200, jdd wrote:
houghi wrote:
During the installation you are asked to do a security update. So when the final ISO comes out and an hour later there is a security fix, you will be able to get the update during installation.
i read recently that there are 1500+ package in SUSE (and not 170), are they _all_ maintained?
Yes, they are all maintained.
if so, this is not advertised enough.
Is it possible to say (in a wiki page)
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The update will be released as soon as the bugfix is implemented. Wether this is after 5 minutes or after 5 days will depend on various factors. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The update will be released as soon as the bugfix is implemented. Wether this is after 5 minutes or after 5 days will depend on various factors.
usually the bugfix is implemented by the original delepment team. what I say is that the suse version will be updated less than 24h after the official patch will be released. of course we can say less or more, it's just a guess of my own, for the time suse must have before following the official fix release jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 07:18:38PM +0200, jdd wrote:
houghi wrote:
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The update will be released as soon as the bugfix is implemented. Wether this is after 5 minutes or after 5 days will depend on various factors.
usually the bugfix is implemented by the original delepment team. what I say is that the suse version will be updated less than 24h after the official patch will be released.
And that is not always the case. It might be possible that it takes longer.
of course we can say less or more, it's just a guess of my own, for the time suse must have before following the official fix release
Well, sometimes there is a solution before the official one. So there is only one correct answer. They are released when they are ready. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
only one correct answer. They are released when they are ready.
for me that say only never. and don't trust YOU. I don't think it's the good answer. I know sometimes the solution is very hard, but if your garage-man say "I'll fix your car when I can", you wont give your car to this man :-) I only try to see the user point of view: may I use the official mozilla fix or wait for YOU? (this is the thread, yes or no?) we can try to find an intelligent answer, not too threatening :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 07:51:14PM +0200, jdd wrote:
we can try to find an intelligent answer, not too threatening :-)
See the reply of Marcus Meissner: Fixes are released when ready. All other answers are incorrect and/or too long. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Wed, Apr 26, 2006 at 07:51:14PM +0200, jdd wrote:
houghi wrote:
only one correct answer. They are released when they are ready.
for me that say only never. and don't trust YOU. I don't think it's the good answer.
I know sometimes the solution is very hard, but if your garage-man say "I'll fix your car when I can", you wont give your car to this man :-)
I only try to see the user point of view: may I use the official mozilla fix or wait for YOU? (this is the thread, yes or no?)
You can also use the official mozilla fix. Ciao, Marcus
On 26 Apr 2006 at 19:51, jdd wrote:
houghi wrote:
only one correct answer. They are released when they are ready.
for me that say only never. and don't trust YOU. I don't think it's the good answer.
The basic discussion was not about the TTF (Time To Fix), because SuSe is quite fast there. The discussion was about confusing version numbering for security- equivalent patches. We got away from that a bit, but please don't start a completely different discussion on this thread -- start a new one of you think it's necessary. [...] Regards, Ulrich
On Thu, Apr 27, 2006 at 09:19:06AM +0200, Ulrich Windl wrote:
On 26 Apr 2006 at 19:51, jdd wrote:
houghi wrote:
only one correct answer. They are released when they are ready.
for me that say only never. and don't trust YOU. I don't think it's the good answer.
The basic discussion was not about the TTF (Time To Fix), because SuSe is quite fast there. The discussion was about confusing version numbering for security- equivalent patches. We got away from that a bit, but please don't start a completely different discussion on this thread -- start a new one of you think it's necessary.
This is unfortunately a fallout of "just apply security fixes". We can't rev the version if we don't include all the fixes and some might just be too dangerous. Ciao, Marcus
On 27 Apr 2006 at 10:41, Marcus Meissner wrote:
We can't rev the version if we don't include all the fixes and some might just be too dangerous.
Yes, but you also cannot not rev the version if not no (=some, not all) fixes were included. That's the original issue I think. Maybe the question is whether "can not" can be replaces with "should not" or "may not" ;-) Sorry for this kind comment... Regards, Ulrich
On Wed, Apr 26, 2006 at 02:55:25PM +0200, jdd wrote:
houghi wrote:
During the installation you are asked to do a security update. So when the final ISO comes out and an hour later there is a security fix, you will be able to get the update during installation.
i read recently that there are 1500+ package in SUSE (and not 170), are they _all_ maintained?
Supported by security and bugfix updates. "maintained" as in "you can call someone at Novell and have get bugs fixed" are only packages for the Enterprise Distributions. The level of available support is listed at this page: http://support.novell.com/products/linuxenterpriseserver/supported_packages/ for the Enterprise Server.
if so, this is not advertised enough.
Is it possible to say (in a wiki page)
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The security team is not working 24 hours a day ;) Fixes are released when ready. Ciao, Marcus
* Ulrich Windl
On 26 Apr 2006 at 15:28, Marcus Meissner wrote:
The security team is not working 24 hours a day ;)
At what time isn't that man working? ;-)
You could say this about M$ software, but not SUSE. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
Marcus Meissner wrote:
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The security team is not working 24 hours a day ;)
Fixes are released when ready.
I don't really know how you work. When apache or Mozilla release a bugfix, I can install the new version right now. I try to have an idea of how many time go between the _official bugfix release_ and the YOU update release. of course as a guess, but said like you do this could mean tomorrow or never, this is not done to make the user confident :-). I don't try to make pressure on your team, all the contrary. I know you are working fast and I would like to advertise it more and more precisely, at least rationally. This is measure if the trust we can have on YOU, not uninteresting :-) I I understand well what is said here, you fix the bug sometime _before_ it is annouced on the web (I beg you have good information sources :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 07:42:14PM +0200, jdd wrote:
Marcus Meissner wrote:
"SUSE Linux will be updated in less than 24h as soon as a bugfix is released for each and any official SUSE Package"
The security team is not working 24 hours a day ;)
Fixes are released when ready.
I don't really know how you work.
Hah! If you want to listen 50 minutes of my lecture on exactly this topic at FOSDEM, check out the Videos at http://en.opensuse.org/FOSDEM :) My slides are here: http://files.opensuse.org/opensuse/en/a/a1/FOSDEM_security_process.pdf
When apache or Mozilla release a bugfix, I can install the new version right now.
I try to have an idea of how many time go between the _official bugfix release_ and the YOU update release. of course as a guess, but said like you do this could mean tomorrow or never, this is not done to make the user confident :-).
I don't try to make pressure on your team, all the contrary.
I know you are working fast and I would like to advertise it more and more precisely, at least rationally. This is measure if the trust we can have on YOU, not uninteresting :-)
I I understand well what is said here, you fix the bug sometime _before_ it is annouced on the web (I beg you have good information sources :-)
Let me give a brief excerpt of how we work: - We get knowledge of the vulnerability. Sometimes this is before the actual date it gets known, sometimes at the same time. - We open a bug and assign it to the package maintainer of this package. - The packagemaintainer evaluates the problem, looks for (or uses our) fixes and applies them to the packages of the current development tree and all older supported products. Those fixed packages get submitted to the build system. There is some back and forth between the packager and my team if there is need. Ocassionaly fixes are incomplete, or broken, requiring to go back to this step. - The packages get checked in into the buildsystem after review of the buildsystem team member. Occasionaly this gets delayed due to high load of the buildsystem on other tasks, or high load on the buildsysteam team. - Once the package has build, a meta patch information file is checked in. The engine then builds patchsets (previously YOU patches, starting with 10.1 repomd data). - Our QA Team tests the fix. This is one timefactor, because they get lots of things to test. Security has priority, but we for isntance have multiple items in the queue to test. Testing an update takes an hour up to several hours, depending on how complicated the package is, on how much distributions it is, etc. Feedback is given, if something breaks. - Updates are released. All these steps are necessary and all these steps have however human components, which are heavily involved in other SUSE processes too. As seen above, the update process is interwoven with the rest of the development and other delivery processes, making giving out "fixed" times very difficult. Ciao, Marcus
Marcus Meissner wrote:
My slides are here: http://files.opensuse.org/opensuse/en/a/a1/FOSDEM_security_process.pdf
I wish I could attend :-( do you mean that you work in parallel with the original developpers of the application? for example if a vulnerability is seen in Apache, I guess apache team warn all the pro clients, not to make twice the same work. this is may be what lacks in your slides: what is the part SUSE/Novell have in the external teams. Do you have a Novell member in the Apache team (for example), at least time-sharing? is such work frequent? rare? case by case? I've seen very different numbers as of the number of SUSE/Novell employes working on Linux (SUSE and pro), from 100 to 1000 :-) What is the real approx number, and on this number what is the part that do security fixes? Its mean. If all the people work together, all fixes are released approx at the same time (You, Apache, Red hat, Debian....). If SUSE works mainly in it's side, may be it's first, may be it's late? I'll try to summarise all this on a page :-) thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 08:50:18PM +0200, jdd wrote:
Marcus Meissner wrote:
My slides are here: http://files.opensuse.org/opensuse/en/a/a1/FOSDEM_security_process.pdf
I wish I could attend :-(
do you mean that you work in parallel with the original developpers of the application? for example if a vulnerability is seen in Apache, I guess apache team warn all the pro clients, not to make twice the same work.
this is may be what lacks in your slides: what is the part SUSE/Novell have in the external teams. Do you have a Novell member in the Apache team (for example), at least time-sharing? is such work frequent? rare? case by case?
Yes, for instance: Peter Poeml is active at Apache, Lars Mueller is active in Samba, Wolfgang Rosenauer at Mozilla, Lots of kernel developers are active at the Kernel, etc....
I've seen very different numbers as of the number of SUSE/Novell employes working on Linux (SUSE and pro), from 100 to 1000 :-)
I can't really say exactly.
What is the real approx number, and on this number what is the part that do security fixes?
Total distribution development (people submitting code) are around 100 I guess. If you add Novell there are more.
Its mean. If all the people work together, all fixes are released approx at the same time (You, Apache, Red hat, Debian....).
If SUSE works mainly in it's side, may be it's first, may be it's late?
We _always_ work with the other vendors and the community. Its just our internal processes do more than just pushing out new built RPMs.
I'll try to summarise all this on a page :-)
I have created http://en.opensuse.org/Security_Incident_Handling right now which summarizes stuff. Ciao, Marcus
On Wed, Apr 26, 2006 at 08:59:40PM +0200, Marcus Meissner wrote:
Yes, for instance: Peter Poeml is active at Apache, Lars Mueller is active in Samba, Wolfgang Rosenauer at Mozilla, Lots of kernel developers are active at the Kernel, etc....
I asume also "No" I can't imagine that SUSE is active in all projects and programs. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Marcus Meissner wrote:
I have created http://en.opensuse.org/Security_Incident_Handling right now which summarizes stuff.
very nice, thanks :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 26, 2006 at 07:42:14PM +0200, jdd wrote:
Fixes are released when ready.
I don't really know how you work.
Easy: find out: http://files.opensuse.org/opensuse/en/a/a1/FOSDEM_security_process.pdf ftp://ftp4.gwdg.de/FOSDEM/FOSDEM2006-openSUSE-11-Security_Process-2006-02-26-video_full.ogg
When apache or Mozilla release a bugfix, I can install the new version right now.
Sure. You can. What if a patch somehow breaks YOU? Or something else that my sytem relies on? That is the differnce between using YOU or doing all the updates yourself. Using YOU will most likely have a delay. However you do not need to keep watch on secuitlists like bugtraq yourself and find out what applies to you and in what severity.
I try to have an idea of how many time go between the _official bugfix release_ and the YOU update release. of course as a guess, but said like you do this could mean tomorrow or never, this is not done to make the user confident :-).
Nobody said never. That is your interpretation. The answer is "when ready". That is really the only correct answer. Every other answer will be wrong. An example: 24 hours. What if it takes 48 hours? 48 hours. What if it takes 50 hours? one week. Why does it take so long?
I don't try to make pressure on your team, all the contrary.
I know you are working fast and I would like to advertise it more and more precisely, at least rationally. This is measure if the trust we can have on YOU, not uninteresting :-)
With each and every time you put fixed, it will be more and more followed by an excuse why it won't be always like that. Making it sound as if you can't commit. And if you can't commit, why put a time on it.
I I understand well what is said here, you fix the bug sometime _before_ it is annouced on the web (I beg you have good information sources :-)
Not only good information sources, also good informational source-codes. :-) houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Am Mittwoch, 26. April 2006 14:24 schrieb houghi:
On Wed, Apr 26, 2006 at 01:10:33PM +0200, David Wright wrote:
For example, I've been a SUSE user for around 5 years, but I only joined the mailing lists in November/December last year. If I hadn't read the relevant mails on the lists, I'd probably be cursing SUSE and downloading .0.2 from the Mozilla site...
I read this and think: why would you go and download? I will just wait and let YOU take care of the solution.
Because Mozilla are saying 1.5.0.1 is unsafe and YOU won't download 1.5.0.2 because the fixes are backported into 1.5.0.1... Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On Thu, Apr 27, 2006 at 03:09:50PM +0200, David Wright wrote:
Am Mittwoch, 26. April 2006 14:24 schrieb houghi:
On Wed, Apr 26, 2006 at 01:10:33PM +0200, David Wright wrote:
For example, I've been a SUSE user for around 5 years, but I only joined the mailing lists in November/December last year. If I hadn't read the relevant mails on the lists, I'd probably be cursing SUSE and downloading .0.2 from the Mozilla site...
I read this and think: why would you go and download? I will just wait and let YOU take care of the solution.
Because Mozilla are saying 1.5.0.1 is unsafe and YOU won't download 1.5.0.2 because the fixes are backported into 1.5.0.1...
SUSE 10.0 has 1.0.8, not 1.5. So if you are using 1.5, then on 10.0 it does not matter and on 10.1RCx (or better on 10.1 once it is released) YOU will take care of the security patches as always. This has always been the case. I fail to see the problem. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
Because Mozilla are saying 1.5.0.1 is unsafe and YOU won't download 1.5.0.2 because the fixes are backported into 1.5.0.1...
SUSE 10.0 has 1.0.8, not 1.5. So if you are using 1.5, then on 10.0 it does not matter and on 10.1RCx (or better on 10.1 once it is released) YOU will take care of the security patches as always.
This has always been the case. I fail to see the problem.
The problem we try to explain is, that SUSE backports security fixes without increasing the version number of an application (they can't, because they only backport security fixes and not all source code changes in a newer upstream version). So if you update with YOU, your system is safe. If you know about backporting etc. you say "I know that my Firefox 1.5.0.1 is safe, because SUSE already did backport the security fixes from upstream". But the average user will say "Oh my god, I'm still using Firefox 1.5.0.1, but the guys from Mozilla say, 1.5.0.3 fixes severe security bugs! Why doesn't SUSE update to the newer version then!?". The average user updates with YOU and *thinks* he is still vulnerable, because the version number didn't increase. My original question is answered, so thanks to all the people explaining this procedure :) Philipp
On Thu, Apr 27, 2006 at 03:49:39PM +0200, Philipp Wollermann wrote:
The problem we try to explain is, that SUSE backports security fixes without increasing the version number of an application (they can't, because they only backport security fixes and not all source code changes in a newer upstream version). So if you update with YOU, your system is safe. If you know about backporting etc. [...]
So the problem is not that SUSE backports fixes or that there is no increase in version. The problem is that communication about what YOU does must be improved. Whjile at it, it should also be explained what the consequences are when you do an external update instead of using YOU. e.g. people who now read the 1.5.0.1 to 0.2 thing might not read it the next time. No idea how to make this clear to end-users. There was a time you could wack them over the head with the two manuals. ;-) Seriouly, an explanation of what happens when not using it and what happens if you use it should be (more?) visably explained. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
Seriouly, an explanation of what happens when not using it and what happens if you use it should be (more?) visably explained.
I't exactly my point. And we have gone in the good direction: *the archive of the list now show all this thread and I think it's quite good for understanding *new pages are added to the wiki we ourselve understand better the problem and can spread to good words :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
Am Donnerstag, 27. April 2006 15:36 schrieb houghi:
On Thu, Apr 27, 2006 at 03:09:50PM +0200, David Wright wrote:
Am Mittwoch, 26. April 2006 14:24 schrieb houghi:
On Wed, Apr 26, 2006 at 01:10:33PM +0200, David Wright wrote:
For example, I've been a SUSE user for around 5 years, but I only joined the mailing lists in November/December last year. If I hadn't read the relevant mails on the lists, I'd probably be cursing SUSE and downloading .0.2 from the Mozilla site...
I read this and think: why would you go and download? I will just wait and let YOU take care of the solution.
Because Mozilla are saying 1.5.0.1 is unsafe and YOU won't download 1.5.0.2 because the fixes are backported into 1.5.0.1...
SUSE 10.0 has 1.0.8, not 1.5. So if you are using 1.5, then on 10.0 it does not matter and on 10.1RCx (or better on 10.1 once it is released) YOU will take care of the security patches as always.
This has always been the case. I fail to see the problem.
I am talking hyperthetically here, it doesn't matter which version of SUSE I am using and which version of the application I am using... If I am using package xyz 1.2.3 and the maintainer does a press release saying that xzy 1.2.3 contains serious security vulnerabilities and everybody should upgrade to 1.2.4, but SUSE backport the patches to 1.2.3, the average user who doesn't subscribe to the lists will assume that, even though the version of 1.2.3 they have from YOU has the vulnerabilities patched, that they are at risk and SUSE aren't doing a good job of keeping on top of the patching. I think maybe if the release notes for the package downloaded in YOU says version 1.2.3 - with security fixes from 1.2.4, or something similar in the help->about on a GUI app or --help page on a CLI tool... I think this policy needs to be cleary explained in a prominent place on the Wiki as well, for example, because I have seen similar questions popping up regularly on forums and newsgroups. I'm not trying to be negative here, but a clearer explanation is needed of the Novell/SUSE policy on backporting and it needs to be put somewhere where normal users who don't belong to the lists will find out about it. Maybe in cases like the Firefox example which started this thread, where a group like Mozilla put out an security warning press release for their product, where SUSE are backporting the fix, maybe their should be an announcement on the News page of the Wiki that the latest version through YOU has had said fixes applied to it. Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On Thu, Apr 27, 2006 at 06:16:54PM +0200, David Wright wrote:
Maybe in cases like the Firefox example which started this thread, where a group like Mozilla put out an security warning press release for their product, where SUSE are backporting the fix, maybe their should be an announcement on the News page of the Wiki that the latest version through YOU has had said fixes applied to it.
See my earlier reply. The policy might need to be clarified better. e.g. not only how YOU works, but also what happens if you decide to install a program that is not updated by YOU, like a newer KDE or Firefox version. I could imagine that there are people that trust YOU to do security updates and then fail to look at the packages they have installed themselves from various sources. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
On Thu, Apr 27, 2006 at 06:16:54PM +0200, David Wright wrote:
Maybe in cases like the Firefox example which started this thread, where a group like Mozilla put out an security warning press release for their product, where SUSE are backporting the fix, maybe their should be an announcement on the News page of the Wiki that the latest version through YOU has had said fixes applied to it.
We should not forget the aim behind the policy: Any vendor needs to backport, especially for commercial reasons. Otherwise YOU would propell the customer right into the next version and - because of logically necessary version freezes - even right further on, behind next version. The only way out of e.g. the Firefox 1.5.0.2 issue would be to have an OpenSUSE product with no version numbers anymore. Just some weekly or bi-weekly snapshots and YOU brings you from snapshot to snapshot until you stop it manually. Which might be an interesting concept, but commercially not viable at all, because the vendor needs "open" customers who test and help improve commercial products that have to come in frozen versions for reasons we all know very well. FMF
houghi wrote:
I could imagine that there are people that trust YOU to do security updates and then fail to look at the packages they have installed themselves from various sources.
on this respect if somebody can give a link to a page that says what are the most problematic packages... I mean if you work with -say- Audacity and want the last version, may be you don't put your machine really at risk. then if you use mediawiki and have it exposed to the net, may be you need to stock with YOU ore subscrube the mediawiki security list :-) the key word here is: SUSE Linux target the greated number of user, so many unexperienced ones. on this number, many will begin to do admin tasks without the inital skills professionals ones have (or are said to have :-), so we need at least some infos to be able to say "you have been warned... don't cry on us if you are stick :-) of course not more on this subject/thread, but on what list may we continue? opensuse-wiki? jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Thu, Apr 27, 2006 at 07:13:52PM +0200, jdd wrote:
houghi wrote:
I could imagine that there are people that trust YOU to do security updates and then fail to look at the packages they have installed themselves from various sources.
on this respect if somebody can give a link to a page that says what are the most problematic packages...
I think saying things like 'most problematic' is wrong. Either you make a list or you don't. Otherwise people will say that one thing on the list should alo be ther or something on the list should not.
the key word here is: SUSE Linux target the greated number of user, so many unexperienced ones. on this number, many will begin to do admin tasks without the inital skills professionals ones have (or are said to have :-), so we need at least some infos to be able to say "you have been warned... don't cry on us if you are stick :-)
That is the only reason the README's an documentation is there. :-) houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On 2006-04-25 at 17:27:52 +0300, Silviu Marin-Caea wrote (shortened):
In RC2 Firefox is 1.5.0.1. This version has security bugs. Shouldn't it be updated to 1.5.0.2?
I know about version freeze and all that. However the box should not go out with known security vulnerabilities for the sake of version freeze. And this is not a feature release, but a bugfix release.
as already said, we have all security fixes from 1.5.0.2 in our package (and some more as the JS/iframe crash which went public yesterday). Wolfgang -- SUSE LINUX GmbH -o) Tel: +49-(0)911-740 53 0 Maxfeldstr. 5 /\\ Fax: +49-(0)911-740 53 679 90409 Nuernberg, Germany _\_v
participants (12)
-
Andreas Jaeger -
David Wright -
Felix Miata -
Frank-Michael Fischer -
houghi -
jdd -
Marcus Meissner -
Patrick Shanahan -
Philipp Wollermann -
Silviu Marin-Caea -
Ulrich Windl -
Wolfgang Rosenauer