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>> Possibly relevant =
article would be<br>
> <</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>><br>
<br>
>>> The number of bugs is the same. It's more difficult to hack in=
to 1996 system <br>
>>> than in 2012.<br>
<br>
> Do you have any evidence to back that claim? There are tons of known<b=
r>
> vulnerabilities in '96-era software, and automated exploits for them.<=
br>
<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<br>
> patches, packaging and testing effort, especially helping automate man=
y<br>
> 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 <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 =
<br>
understanding how this particular software works. Try to assemble a <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 <=
br>
than in Windows systems. The open source is only theoretically safer. =
<br>
Many belive that because the code is open - it's reviewed and checked =
<br>
and the number of critical bugs is low. But the reality is that there =
<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 <br>
understand how it works before you use it in your project. Tell me <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 <br>
you will find them. If you have an expertise on cross platforms - you =
<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" <b=
r>
linux on the planet. <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? <br>
<br>
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;<br>
the government's methods. They used to keep them secret. <br>
<br>
<span style=3D" font-family:'arial'; font-size: 8pt; color: #c0c0c0;"><i>--=
<br>
Best regards,<br>
Igor &=
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--