From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 64CB913877A for ; Sat, 9 Aug 2014 15:26:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 70C83E093E; Sat, 9 Aug 2014 15:26:01 +0000 (UTC) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3E20AE08F4 for ; Sat, 9 Aug 2014 15:25:59 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id c11so4753733lbj.9 for ; Sat, 09 Aug 2014 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:to:subject:in-reply-to:references :mime-version:content-type; bh=/PsdUKIhjOkyVomPOQZCZe74detkEkB4nXODtOmsfo0=; b=Wbvj9fGQAbfMitT1wo6nzNWFOINS8evQMP6Z9eMjwFo6roXZaSeYioZvgyKAF+Iog0 JFFUfG9LbwPOxlaVuqxM1kROlpGRjIomrZGK6KUA65ginX/xj/4ARHgu0yRQsCB93+2E 6AxuyRUID8EOohB4rCIJ8blp1LulqUvoVmSaOV3RidSJkIChSrBgbMCCBmwWRFXaSGlZ FcvlyRgmUEqY3ZeNh3Une1FSQUnDjix/q5ufD6hq8TeRh6RL1FP/wKvsadNj6BGSO5UA 8zQZPLI2JViYQJm8PWA103svzKV9dMt1xxiOuaNeSCLeO21gBbj6hNRGoCleGGKV9cXT FVjA== X-Received: by 10.152.36.73 with SMTP id o9mr1236697laj.88.1407597958533; Sat, 09 Aug 2014 08:25:58 -0700 (PDT) Received: from [192.168.60.64] (office.healtech.ru. [89.208.21.2]) by mx.google.com with ESMTPSA id al8sm3792650lbc.11.2014.08.09.08.25.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 09 Aug 2014 08:25:57 -0700 (PDT) Message-ID: <53e63d85.68aa700a.1e9a.16eb@mx.google.com> X-Google-Original-Message-ID: <176949240.20140809192556@gmail.com>> Date: Sat, 9 Aug 2014 19:25:56 +0400 From: Igor X-Priority: 3 (Normal) To: =?utf-8?Q?=22Pawe=C5=82_Hajdan=2C_Jr.=22?= Subject: Re: [gentoo-dev] minimalistic emerge In-Reply-To: <53E5EB25.5060500@gentoo.org> References: <53e4ccbd.c2b4700a.3bec.2414@mx.google.com> <20140808142203.777a1818@googlemail.com> <53e4eb6b.0190700a.5f01.2a15@mx.google.com> <53E4F0B4.9000806@gentoo.org> <53e4fa56.2679980a.47a0.27e3@mx.google.com> <53E5EB25.5060500@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------12500624301B74086" X-Archives-Salt: e96e9ac1-ad1e-417d-a753-adbdbe5a2c78 X-Archives-Hash: 7be89f2e6471b108e2eb215be1468734 ------------12500624301B74086 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Pawe=C5=82, Saturday, August 9, 2014, 1:34:29 PM, you wrote: > Possibly relevant article would be > >>> The number of bugs is the same. It's more difficult to hack into 1996 s= ystem=20 >>> than in 2012. > Do you have any evidence to back that claim? There are tons of known > vulnerabilities in '96-era software, and automated exploits for them. > By the way, I can see a point in your thread. Our updates and package > manager could be improved. They have improved greatly in the last few > years. I think I can safely say we welcome further contributions of > patches, packaging and testing effort, especially helping automate many > of these tasks. In my experience - hacking into 96 system with a 0 door is much harder=20 than in 2014. In most cases unless you're an expert on 96 software which=20 is difficult nowadays due to human memory. To really break in you need to reproduce server environment as close as possible or/and have a clear=20 understanding how this particular software works. Try to assemble a=20 96 system on modern hardware or assemble it as they were back in 96, not all sources are online any longer, that is a hard job. 2014 systems=20 are much easier to assemble and get a peek to the sources is a trifle. As Linux software is open-source it's often easier to break in Linux=20 than in Windows systems. The open source is only theoretically safer.=20 Many belive that because the code is open - it's reviewed and checked=20 and the number of critical bugs is low. But the reality is that there=20 is usually no time to review code. Many modern software is very complex=20 with millions lines and it's not realistic to check or=20 understand how it works before you use it in your project. Tell me=20 how many libraries that you use right now are reviewed by you personally?= =20 Not many. And that is a door that is NEVER going to be closed. There are bugs, rest assured, if you pull any soft right now and spend time=20 you will find them. If you have an expertise on cross platforms - you=20 will find even more as developers used to focus on one platform the birth= =20 platform. If you compare the number of bugs you find in 1996 software and in 2014=20 - the numbers would approximately be the same. Usually 1996 system is patched or protected against known issues and you=20 have to deal with "unknown" which in case of 1996 is much harder. Another weak link with open source is software developers. Many of them=20 spend a lot of time on their software not always getting a fair monetary reward. So if you a very shrewd and have resources - you go to developers= =20 and offer them money to introduce a subtle bug into the main tree. After=20 the software is adopted then you have open doors in EVERY "updated"=20 linux on the planet.=20 Personally I belive Heart Bleed bug is one of such. You can never proof=20 if the bug is artificial or not - how?=20 The same true for Microsoft soft. You can basically go to a ntkernel=20 developer offer him 500 000$ if have them and he would add a bug and=20 explain you how to use it and you're everywhere :-) but this is usually=20 the government's methods. They used to keep them secret.=20 --=20 Best regards, Igor mailto:lanthruster@gmail.com ------------12500624301B74086 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re: [gentoo-dev] minimalistic emerge Hello Pawe=C5= =82,

Saturday, August 9, 2014, 1:34:29 PM, you wrote:

> Possibly relevant = article would be
> <http://www.site-reliability-engineeri= ng.info/2014/04/what-is-site-reliability-engineering.html>

>>> The number of bugs is the same. It's more difficult to hack in= to 1996 system 
>>> than in 2012.

> Do you have any evidence to back that claim? There are tons of known > vulnerabilities in '96-era software, and automated exploits for them.<= br>
> By the way, I can see a point in your thread. Our updates and package<= br> > manager could be improved. They have improved greatly in the last few<= br> > years. I think I can safely say we welcome further contributions of
> patches, packaging and testing effort, especially helping automate man= y
> of these tasks.

In my experience - ha= cking into 96 system with a 0 door is much harder 
than in 2014. In most cases unless you're an expert on 96 software which&nb= sp;
is difficult nowadays due to human memory. To really break in you need to reproduce server environment as close as possible or/and have a clear =
understanding how this particular software works. Try to assemble a  96 system on modern hardware or assemble it as they were back in 96,
not all sources are online any longer, that is a hard job. 2014 systems&nbs= p;
are much easier to assemble and get a peek to the sources is a trifle.

As Linux software is open-source it's often easier to break in Linux <= br> than in Windows systems. The open source is only theoretically safer. =
Many belive that because the code is open - it's reviewed and checked =
and the number of critical bugs is low. But the reality is that there =
is usually no time to review code. Many modern software is very complex&nbs= p;
with millions lines and it's not realistic to check or 
understand how it works before you use it in your project. Tell me 
how many libraries that you use right now are reviewed by you personally?&n= bsp;
Not many. And that is a door that is NEVER going to be closed. There are
bugs, rest assured, if you pull any soft right now and spend time 
you will find them. If you have an expertise on cross platforms - you =
will find even more as developers used to focus on one platform the birth&n= bsp;
platform.

If you compare the number of bugs you find in 1996 software and in 2014&nbs= p;
- the numbers would approximately be the same.

Usually 1996 system is patched or protected against known issues and you&nb= sp;
have to deal with "unknown" which in case of 1996 is much harder.

Another weak link with open source is software developers. Many of them&nbs= p;
spend a lot of time on their software not always getting a fair monetary
reward. So if you a very shrewd and have resources - you go to developers&n= bsp;
and offer them money to introduce a subtle bug into the main tree. After&nb= sp;
the software is adopted then you have open doors in EVERY "updated"  linux on the planet. 

Personally I belive Heart Bleed bug is one of such. You can never proof&nbs= p;
if the bug is artificial or not - how? 

The same true for Microsoft soft. You can basically go to a ntkernel <= br> developer offer him 500 000$ if have them and he would add a bug and <= br> explain you how to use it and you're everywhere :-) but this is usually&nbs= p;
the government's methods. They used to keep them secret. 

--=  
Best regards,
 Igor                   &= nbsp;        mailto:lanthruster@= gmail.com ------------12500624301B74086--