Re: Abwesenheit
*** wrote: Ich bin in der Zeit vom 09.09.2005 - 16.09.2005 nicht im Büro und werde keinen Zugang zu meinen E-Mails haben. Wenden Sie sich bitte in dringenden Fällen an (***). Isn't sending such mails a security risk? Badhearts (why should a black hat as such be a bad thing?) might take advantage of a sysadmin's absence to break into systems, houses, relationships, ... Have fun Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press again...
On Thu, 25 Aug 2005, Jan Luehr wrote: again the debian security infrastructure has proofed to be accident sensitive. [...] Sometimes it's just bothers me to read this news on heise.de first. Nothing on deb-ann dev-ann or sec-ann. What's wrong here? Maybe you can plug into the same sensors as heise.de. Do they have some monitoring script? Or some monitoring people? (Might be interesting to know who: [disgruntled users? the competition?]) It could be that calling/mailing[/visiting...] heise.de will yield the necessary information, and you can learn more, quicker and directly, about what you care to know. Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Florian Weimer wrote: * Some upstream authors do not provide specific security fixes (PHP, Mozilla, GNU libc). Sometimes, no backports for the version in stable are available, and the packages are too complex that we can prepare them in a reasonable timeframe. * Some fixes are very invasive (because they address design issues) and thus impossible to backport. * security.debian.org is a single point of ownership. If we push out a malicious security update, really interesting things might happen. That's why it might be good to have a second, distinct security path (security essentially managed by upstream) (or whichever other path will be available). Integrated in the packet management system, but maybe with non-automatic upgrades (New upgrades available -- do you want package X ?), or automatic at the discretion of the trusting user. From a user point of view, I'd appreciate if the debian team could ensure that no data is lost while doing such upgrades. E.g., I'm not sure that while upgrading from one mozilla version to the next, every user data (profile, mail, plugins etc.) is always correctly imported. In such a case, perhaps the team could provide the necessary conversion scripts, urge such improvements from upstream, or both. Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security fixes for mozilla and firefox in Sarge?
Sam Morris wrote: Michael Stone wrote: IMO, if people really intend for the package to have no security support in the long term then it should exist only in volatile. I think it is dangerously irresponsible to ship software we do not intend to support. But back to Debian. The system we have at the moment is not working: users are installing packages from the stable release, in the assumption that the packages are supported; in reality these packages are not getting updated. From a user's point of view, this assumption is perfectly reasonable, especially given statements such as: Debian takes security very seriously. Most security problems brought to our attention are corrected within 48 hours. [1] It was easy to make such a promise back in 1997, but today Debian is much larger. If the security team is unable to function[2] such that the above statement still holds true, then either the statement, or the job that the team does, must be changed. - It seems to me that the active security team DOES take security very seriously. - Most is not all. - Who is debian? Can one identifiy debian of the above statement with the security team, as your statement implies? - Isn't debian the whole thing, e.g. including the individual maintainers -- who can support the security update supplier team? - Isn't debian also it's user community? Couldn't it collectively organize to supply ressources for a security team (manpower, money (salaries), ...)? Ok, it seems to me that this was already diskussed from a technical-organisational point of view. But what I mean here is making the users more aware if it. Maybe instead of letting people understand the above in a (somewhat) godlike manner, e.g. We (whoever this is exactly) supply everything for everybody for free, the statement should be explicited to something somewhat different, like We/the security team/... supply everything for everybody for free as long as we can and as long as there is a reasonable support, which the community of debian and it's users supply. Maybe this real-life reality of things is not obvious to everybody if it is not worded exactly as reality is. Making unsustainable promises always arouses suspicions and generally backfires. What if the person(s) having taking the responsibly on himself become sick, have an accident, want to found a family, whatever? Let's not forget all this is done by human beings, and maybe certain users with unduly high expectations should be told (or reminded of) the facts of life. In a certain way, the whole thing only depends on the free but active goodwill which everybody can forge in himself/herself. Debian is not a system. It's an agreement of people how to organize work collectively. Based on active, freely supplied (but supplied!) goodwill. That's what makes it profoundly human. When people don't supply that resource, the whole thing will stop. That's what differentiates it from many other models. In many of these, free was taken out. And that's what makes them (at least somewhat) robotic, producing disgruntling and many distortions, since not acting freely by one's own conscience of responsibilities is not really being human, it can't work as well. One way to solve the problem would be to partition the archive into supported and unsupported packages: deb http://mirror/debian sarge main contrib non-free deb http://mirror/debian sarge/unsupported main contrib non-free Maybe there should be an security managed externally package. Meaning that it is explicited that one may choose using some package and not updating it, or using another package, or using a package and trusting upstream to supply security. The debian maintainers would then assure that the upstream packages are compiled and available in the package system. In a certain way, this would mean there is kind of a pick your stability requirement option for individual packages which lets user choose between available options. Maybe a donation system (à la SourceForge) might help, too. Surely certain people might be able to help more if there were some way for them to get some funding in return (on voluntary basis). Or some kind of auction system, enabling people to express a willingness to fund certain features or specific works or people. Greetings Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing debsums and mismatches
... And finally: Shouldn't packages like 'make' and 'sed' have checksums generated? Yes. ;-) This could be included in the famaus automatic build and/or packaging system, coundn't it? And/or there could be an automatic email warning to a developer uploading a package without the appropriate md5sum (or a false one). Or so. Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hash database
Raffaele D'Elia schrieb: Unfortunatly not. I want to verify each file installed using .deb's against the md5sum written inside the .deb itself. Debsum does this storing the hashes locally. I want the same control over a central db, independent from the machine I'm running debsums on. There used to be a page http://www.nsrl.nist.gov/Downloads.htm (it seems to be down, at least from my non-us place), but it's in the google cache: http://64.233.183.104/search?q=cache:6XVCDNiTBSMJ:www.nsrl.nist.gov/Downloads.htm+NIST+NSRL+%22RDS+2.8%22hl=de. There you can/could download the NIST NSRL (NIST National Software Reference Library). These are hash databases which are used in forensics. They get/buy a lot of software and establish a big hash database of all these software. So if police takes your computer, they use these hashes to put aside all the known good files (standard software) and then check the rest for allowed/bad content. This cuts down 50-95% of their work. debian is probably in there, so this might be what you need. There is another sites called http://knowngoods.org/ with a similar purpose. I'm not sure if you can get the hashdb, maybe somewhere on their site it is. There are other similar projects. It would indeed be good if there were a debian database with all the hashes of all published programs (all files: the .debs AND all their contents, of simply everything). This would help to spot problems. You could have a disk to boot from which collects all the hashes, and then check these on another known good system with all the hashes. If then ls or any other program had a bad hash, you know what you need to replace. The disk could be a standalone mini-linux, which writes the hashes as .gz on a (or more) disk(s), or send them over the network. A complete hash database could also be put on a CD used to analyze the system and tell all known OS files which don't have the expected hash. For creating the hash database, it's only some script which looks at all the debs and their content, checks ths md5s/sha1s, and compiles the info at a single place. No rocket science. Peer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
