[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] minimalistic emerge
From:       Igor <lanthruster () gmail ! com>
Date:       2014-08-09 15:25:56
Message-ID: 53e63d85.68aa700a.1e9a.16eb () mx ! google ! com
[Download RAW message or body]

Hello Paweł,

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-reliability-engineering.html>

>>> The number of bugs is the same. It's more difficult to hack into 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.

> 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 
than in 2014. In most cases unless you're an expert on 96 software which 
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 
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 
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 
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? 
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 
platform.

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

Usually 1996 system is patched or protected against known issues and you 
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 
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 
and offer them money to introduce a subtle bug into the main tree. After 
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 
if the bug is artificial or not - how? 

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

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com
[Attachment #3 (text/html)]

<html><head><title>Re: [gentoo-dev] minimalistic emerge</title>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 10pt;">Hello Paweł,<br>
<br>
Saturday, August 9, 2014, 1:34:29 PM, you wrote:<br>
<br>
<span style=" font-size: 9pt; color: #800000;"><b>&gt; Possibly relevant article \
would be<br> &gt; &lt;</b></span></span><a style=" font-family:'courier new'; \
font-size: 9pt;" href="http://www.site-reliability-engineering.info/2014/04/what-is-si \
te-reliability-engineering.html">http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html</a><span \
style=" 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 into 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<br>
&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 many<br>
&gt; of these tasks.<br>
<br>
</b><span style=" font-size: 10pt; color: #000000;">In my experience - hacking 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&nbsp;<br> is difficult nowadays due to human \
memory. To really break in you need to<br> 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;<br> 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&nbsp;<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&nbsp;<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?&nbsp;<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&nbsp;<br>
platform.<br>
<br>
If you compare the number of bugs you find in 1996 software and in 2014&nbsp;<br>
- the numbers would approximately be the same.<br>
<br>
Usually 1996 system is patched or protected against known issues and you&nbsp;<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&nbsp;<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&nbsp;<br>
and offer them money to introduce a subtle bug into the main tree. After&nbsp;<br>
the software is adopted then you have open doors in EVERY "updated"&nbsp;<br>
linux on the planet.&nbsp;<br>
<br>
Personally I belive Heart Bleed bug is one of such. You can never proof&nbsp;<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&nbsp;<br>
the government's methods. They used to keep them secret.&nbsp;<br>
<br>
<span style=" 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=" font-family:'arial';" \
href="mailto:lanthruster@gmail.com">mailto:lanthruster@gmail.com</a></body></html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic