Re: Debians security features in comparison to Ubuntu
Hello, Le 17 mai 2014 à 17:34, Richard van den Berg a écrit : > Joel Rees wrote On 17-05-14 03:19: >>> He gave me a link to the following site: >>> https://wiki.ubuntu.com/Security/Features >> None of the meaningful items in that list are unavailable on Debian, and >> the defaults are reasonably secure in Debian. > > I might be misinterpreting your definition of "meaningful", but I have been > looking for a public entropy source for my Debian system for quite a while. > If you can point me to the Debian equivalent of pollinate and > https://entropy.ubuntu.com/ that would be highly appreciated. Isn't it a better idea to use local entropy generators such as haveged instead of online ones ? I'm quite disturbed about using a online (and moreover third-party) service to improve security of a local system. In my sense, this requires a huge level of trust towards the considered service. In term of usage, i personally tested haveged on my servers to generate various GPG keys and it performs remarkably well. Best regards Emmanuel Thierry -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/24050730-4e5b-45d8-9c35-6cc63e7c7...@sekil.fr
Re: NSA software in Debian
Le 24 janv. 2014 à 14:17, Andrew McGlashan a écrit : > Hi, > > On 19/01/2014 6:30 AM, Marco Saller wrote: >> i am not sure if this question has been asked or answered yet, please do not >> mind if i would ask it again. >> Is it possible that the NSA or other services included investigative >> software in some Debian packages? > > I've read all the posts so far in this and related threads (each tree of > this top thread actually). > > It is definitely not beyond the realms of possibility that hardware is > compromised WORLDWIDE, from hardware additions to firmware > /adjustments/. It might not be cheap to compromise as many machines as > you want, but it might be cheaper to consider every machine a possible > target, so the NSA could modify every single machine they could get > their hands on and many that they can remotely access via other means. > > There are problems at every level, including hard drive firmwares, > ordinary looking USB cables, tricked VGA leads ... and these > revaluations come from a document with a date of 2008. > > Also, it is not impossible for *any* organization to have a /ghosted/ > version; we might be installing Debian from a ghost version of Debian > that is compromised and for all intents and purposes, it appears 100% to > be Debian. DNS can be taken over at any point to allow the /ghost/ > version to be *the* version that any one of us sees. Then DNSSEC appeared ! :) I remind you it is really difficult to compromise DNS zones protected by DNSSEC, even if you have control on root DNS servers (they probably have it) and the knowledge of the complete root DNS key (they likely don't have it). There is no point in considering DNS as compromised, since it would be much easier (and as difficult to hide) to subvert IP routing. By the way if you succeeded in redirecting DNS traffic to your box, you probably have the power of redirecting all the traffic to your box. Best regards Emmanuel Thierry -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f024e55e-4687-4db6-9c06-1e3abb33c...@sekil.fr
Re: Security updates realized by new releases, case for backports?
Hello, Le 4 oct. 2013 à 13:39, Demetris Demetriou a écrit : > Hi all, > long time reader, first time responder. Me too ! > IMHO this backporting, support of version 0.001 etc. etc. should be dropped. > Linux is already the mess it is with all the developer fragmentation. Don't > like the way the file menu is? Fork the program and take a couple of the best > developers with you, teaching them to hate the people they used to work with > and you are done. It's the GPL way! > > Security fixes should NOT be patches affecting old code, but instead a > security fix found by someone should be pushed upstream to be incorporated in > a newer upstream release. I understand the need to support extremely old > versions of software. After all it makes a lot more sense to have 10 > developers patching old code so that person X can run Linux on his old > Pentium (1) machine, than to spend the 400 euros to get a brand new laptop > that's able to run newer software versions. Never mind the used computers > available at better prices. Spending your money is always a bad thing, > therefore developers should invest their time scratching their head on how to > support your outdated software. Do I really need a sarcasm disclaimer in this > post? I guess so, since this IS the facebook generation. This paragraph is > pure sarcasm. In no way should developers be forced to maintain old code. > > (…) I think ArchLinux is made for you ! :) About the initial topic, the problem i see is that Debian may operate both as a desktop or as a server (among other usages), and people usually don't have the same needs for both usages : * Most of people i know who use Debian as a desktop use the testing repositories. They want to be up to date with newest versions. (For this usage, i personally prefer a Ubuntu desktop) * Most of people i know (me either) who use Debian as a server use the stable repositories. They want to have a secure, stable, and almost deterministic system. For my Debian servers, i personally don't want to have backports pre-configured, because i'm ok with old but very-stable versions of apache, php, mysql, unbound, nsd, postfix, dovecot and so on. And i know it won't break nor change its behavior all along the life of the distribution. I think the reflexion about this topic should consider these distinct usages. Best regards. Emmanuel Thierry -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6773f9bc-c670-45b3-8b24-846dfb2de...@sekil.fr
