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