From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67181-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 64CB913877A
	for <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Sat,  9 Aug 2014 15:25:59 +0000 (UTC)
Received: by mail-lb0-f178.google.com with SMTP id c11so4753733lbj.9
        for <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>
        (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 <lanthruster@gmail.com>
X-Priority: 3 (Normal)
To: =?utf-8?Q?=22Pawe=C5=82_Hajdan=2C_Jr.=22?= <gentoo-dev@lists.gentoo.org>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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
> <http://www.site-reliability-engineering.info/2014/04/what-is-site-reliab=
ility-engineering.html>

>>> 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

<html><head><title>Re: [gentoo-dev] minimalistic emerge</title>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<span style=3D" font-family:'Courier New'; font-size: 10pt;">Hello Pawe=C5=
=82,<br>
<br>
Saturday, August 9, 2014, 1:34:29 PM, you wrote:<br>
<br>
<span style=3D" font-size: 9pt; color: #800000;"><b>&gt; Possibly relevant =
article would be<br>
&gt; &lt;</b></span></span><a style=3D" font-family:'courier new'; font-siz=
e: 9pt;" href=3D"http://www.site-reliability-engineering.info/2014/04/what-=
is-site-reliability-engineering.html">http://www.site-reliability-engineeri=
ng.info/2014/04/what-is-site-reliability-engineering.html</a><span style=3D=
" font-family:'courier new'; font-size: 9pt; color: #800000;"><b>&gt;<br>
<br>
&gt;&gt;&gt; The number of bugs is the same. It's more difficult to hack in=
to 1996 system&nbsp;<br>
&gt;&gt;&gt; than in 2012.<br>
<br>
&gt; Do you have any evidence to back that claim? There are tons of known<b=
r>
&gt; vulnerabilities in '96-era software, and automated exploits for them.<=
br>
<br>
&gt; By the way, I can see a point in your thread. Our updates and package<=
br>
&gt; manager could be improved. They have improved greatly in the last few<=
br>
&gt; years. I think I can safely say we welcome further contributions of<br>
&gt; patches, packaging and testing effort, especially helping automate man=
y<br>
&gt; of these tasks.<br>
<br>
</b><span style=3D" font-size: 10pt; color: #000000;">In my experience - ha=
cking into 96 system with a 0 door is much harder&nbsp;<br>
than in 2014. In most cases unless you're an expert on 96 software which&nb=
sp;<br>
is difficult nowadays due to human memory. To really break in you need to<b=
r>
reproduce server environment as close as possible or/and have a clear&nbsp;=
<br>
understanding how this particular software works. Try to assemble a&nbsp;<b=
r>
96 system on modern hardware or assemble it as they were back in 96,<br>
not all sources are online any longer, that is a hard job. 2014 systems&nbs=
p;<br>
are much easier to assemble and get a peek to the sources is a trifle.<br>
<br>
As Linux software is open-source it's often easier to break in Linux&nbsp;<=
br>
than in Windows systems. The open source is only theoretically safer.&nbsp;=
<br>
Many belive that because the code is open - it's reviewed and checked&nbsp;=
<br>
and the number of critical bugs is low. But the reality is that there&nbsp;=
<br>
is usually no time to review code. Many modern software is very complex&nbs=
p;<br>
with millions lines and it's not realistic to check or&nbsp;<br>
understand how it works before you use it in your project. Tell me&nbsp;<br>
how many libraries that you use right now are reviewed by you personally?&n=
bsp;<br>
Not many. And that is a door that is NEVER going to be closed. There are<br>
bugs, rest assured, if you pull any soft right now and spend time&nbsp;<br>
you will find them. If you have an expertise on cross platforms - you&nbsp;=
<br>
will find even more as developers used to focus on one platform the birth&n=
bsp;<br>
platform.<br>
<br>
If you compare the number of bugs you find in 1996 software and in 2014&nbs=
p;<br>
- the numbers would approximately be the same.<br>
<br>
Usually 1996 system is patched or protected against known issues and you&nb=
sp;<br>
have to deal with "unknown" which in case of 1996 is much harder.<br>
<br>
Another weak link with open source is software developers. Many of them&nbs=
p;<br>
spend a lot of time on their software not always getting a fair monetary<br>
reward. So if you a very shrewd and have resources - you go to developers&n=
bsp;<br>
and offer them money to introduce a subtle bug into the main tree. After&nb=
sp;<br>
the software is adopted then you have open doors in EVERY "updated"&nbsp;<b=
r>
linux on the planet.&nbsp;<br>
<br>
Personally I belive Heart Bleed bug is one of such. You can never proof&nbs=
p;<br>
if the bug is artificial or not - how?&nbsp;<br>
<br>
The same true for Microsoft soft. You can basically go to a ntkernel&nbsp;<=
br>
developer offer him 500 000$ if have them and he would add a bug and&nbsp;<=
br>
explain you how to use it and you're everywhere :-) but this is usually&nbs=
p;<br>
the government's methods. They used to keep them secret.&nbsp;<br>
<br>
<span style=3D" font-family:'arial'; font-size: 8pt; color: #c0c0c0;"><i>--=
&nbsp;<br>
Best regards,<br>
&nbsp;Igor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</i></span></span></span><a style=3D" font=
-family:'arial';" href=3D"mailto:lanthruster@gmail.com">mailto:lanthruster@=
gmail.com</a></body></html>
------------12500624301B74086--