From gentoo-dev Sat Aug 09 15:25:56 2014 From: Igor Date: Sat, 09 Aug 2014 15:25:56 +0000 To: gentoo-dev Subject: Re: [gentoo-dev] minimalistic emerge Message-Id: <53e63d85.68aa700a.1e9a.16eb () mx ! google ! com> X-MARC-Message: https://marc.info/?l=gentoo-dev&m=140759796609767 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------12500624301B74086" ------------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--