Author Topic: Commercial product source code  (Read 25543 times)

0 Members and 1 Guest are viewing this topic.

Offline MasterBuilder

  • Regular Contributor
  • *
  • Posts: 61
Commercial product source code
« on: April 15, 2014, 11:22:59 am »
Is there any complete source code for commercial products publicly available?

Preferably in C, using GCC with AVR ucontroller.

Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.
 

Online Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: Commercial product source code
« Reply #1 on: April 15, 2014, 11:25:21 am »
The issue you will face there is the more parts in the program the more likely you are to find errors, still if there is a place packed full of example code i could use the learning experience as well,
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9206
  • Country: my
  • reassessing directives...
Re: Commercial product source code
« Reply #2 on: April 15, 2014, 12:10:38 pm »
not preferably but the one i know "commercialled" in millions https://source.android.com/
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline miceuz

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: lt
    • chirp - a soil moisture meter / plant watering alarm
Re: Commercial product source code
« Reply #3 on: April 15, 2014, 12:11:06 pm »
I've seen some commercial production code and I must say, it's a sad story usually...

opensource != bad code
commercial != good code

want to see a good clean code and architecture? check out springframework or hibernate - those in my opinion are rare jewels.

Otherwise it's hellishly HARD to produce good quality code for any substantially large product.

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4310
  • Country: us
  • KE7GKP
Re: Commercial product source code
« Reply #4 on: April 15, 2014, 12:25:13 pm »
opensource != bad code
Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?
 

Offline MasterBuilder

  • Regular Contributor
  • *
  • Posts: 61
Re: Commercial product source code
« Reply #5 on: April 15, 2014, 12:36:22 pm »
not preferably but the one i know "commercialled" in millions https://source.android.com/

Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff, or other stuff like washing machine

Not to say opensource is bad in any way but commercial software Id expect is validated and peer reviewed which is the attraction for me.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6541
Re: Commercial product source code
« Reply #6 on: April 15, 2014, 01:04:02 pm »
Probably very difficult to find some as it's almost certainly going to be proprietary and confidential.

(That being said, some of that stuff does get leaked, and you may find it on some sites in China, but then it also tends to be for Chinese products...)
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9206
  • Country: my
  • reassessing directives...
Re: Commercial product source code
« Reply #7 on: April 15, 2014, 01:36:15 pm »
Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff
oh now you say it. good luck finding OSHW in safety critical area involving lifes, my best bet will be in IEEE or whatnot, thats not open and thats not free. but they are the domain that you have mentioned. even if i have to make my own safety, expertise alone is not enough, i need to be so intimate with everything, the code, the design mechanical or electrical everything down to the last screw. they are all customly and specifically tied together. the idea of grabbing other people's work (OSHW) that we are not so "intimately" understand and not so specifically tied to our specific need is bothersome imho. i dont know anyone that are so intimate with other's people work at some (high) threshold of complexity do you? by "intimate" i mean, when there is a bug report from someone, just by "imagining" it you'll know the spot where to fix in your thousands of code lines without having to go through retracing or debug process. and hoping this mission critical code works with any systems in the world at the first compile is even more delusional imho. the one that works with everythings are elementary books back in the college. no offense ;)
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 4832
  • Country: de
  • A qualified hobbyist ;)
Re: Commercial product source code
« Reply #8 on: April 15, 2014, 02:03:01 pm »
opensource != bad code
Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

Trolling? ;-) If openSSL would be closed source following would happen:
- vendor ignores report about security issue for some weeks
- after the media picks up the story vendor starts investigating the issue
- if the vendor is in a bad mood he'll sue the security expert who reported the issue with computer fraud
- some 6+ months later the vendor releases a patch

Especially the point about suing caused a lot of security researchers to sell the exploit or to go for anonymous immediate full disclosure.

Another very interesting question is which of the large tech companies using openSSL to make money are supporting openSSL? I've read that Google is giving US$100k per year and Apple US$0.00 for example.
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 4832
  • Country: de
  • A qualified hobbyist ;)
Re: Commercial product source code
« Reply #9 on: April 15, 2014, 02:14:57 pm »
Im more interested in source code for control of machines, and  the bigger and more dangerous machines the better.
For example, automotive ECU, ABS/ stability control, other vehicle control sytems, MIRSA compliant stuff, or other stuff like washing machine

Such code doesn't assume anything, it checks everything. In conjunction with the hardware it will fail safe. That's the theory :-)

Quote
Not to say opensource is bad in any way but commercial software Id expect is validated and peer reviewed which is the attraction for me.

The reality offers things like cost reduction and time to market which contradict QS.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7242
  • Country: us
    • SiliconValleyGarage
Re: Commercial product source code
« Reply #10 on: April 15, 2014, 02:59:08 pm »
opensource != bad code
Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

Trolling? ;-) If openSSL would be closed source following would happen:
- vendor ignores report about security issue for some weeks
- after the media picks up the story vendor starts investigating the issue
- if the vendor is in a bad mood he'll sue the security expert who reported the issue with computer fraud
- some 6+ months later the vendor releases a patch

Especially the point about suing caused a lot of security researchers to sell the exploit or to go for anonymous immediate full disclosure.

Another very interesting question is which of the large tech companies using openSSL to make money are supporting openSSL? I've read that Google is giving US$100k per year and Apple US$0.00 for example.

You have somevalid points, but i cant help but wonder about a few things
-the source is available. This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Second, i have read the report about the problem. Turns out this is a stupid memcopy error.
Will someone please kill the C language ? Or at least make a runtime lib that does boundary checking so that this kind of crap can never occur ?
 Arrays should have a structure in them telling their size, as opposed to allowing memcopy to take whatever size you feed it.

The runtime for memory operation must do two things : store the real size of the array in the array, flush a newly created array with all zeroes, upon resize flush the released space or claimed space with zeroes.

Cpu's these days are fast enough that this will be unnoticable.
Just initialising and flushing an array would have prevented this bug.
C may be very powerful but it is a friggin nightmare security wise as it does not perform any safety check. Security applications should not be written using that language.
« Last Edit: April 15, 2014, 03:05:46 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline cyr

  • Frequent Contributor
  • **
  • Posts: 251
  • Country: se
Re: Commercial product source code
« Reply #11 on: April 15, 2014, 03:08:07 pm »
The wast majority of all code is a horrible mess. For FOSS it usually comes down to "That's good enough, it works for me. If a user finds a problem they can fix it and send a patch". For commercial software it's "That's good enough, we need to ship it next week. If a user finds a problem they can submit a bug report (that will be ignored in reverse proportion to how much money they spend)".

What you are looking for is probably "good code" not "commercial code". There is little correlation, and the former is rare indeed.
 

Offline miceuz

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: lt
    • chirp - a soil moisture meter / plant watering alarm
Re: Commercial product source code
« Reply #12 on: April 15, 2014, 03:24:38 pm »
This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Well, what has happened? Somebody has *finally* looked at the code and the patch was ready in minutes. Yes, it's a shame that no white hat has looked into it for two years, but at least now we all know the hole is patched up.

Now consider all the holes in windows operating system which allow all the botnets of the world to run.

Yes, I agree, having something like memcpy in a hard-core security related library is a bad design in my opinion too.

To not derail the thread, we have to make the distinction - good structured code is not necessarily bug free code and some explosion in spaghetti factory mess does not necessary contain bugs, but bugs are easier to spot and fix in a good structured code.


Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4310
  • Country: us
  • KE7GKP
Re: Commercial product source code
« Reply #13 on: April 15, 2014, 03:58:58 pm »
Quote
Yes, it's a shame that no white hat has looked into it for two years,

Quote
Seems the people that supposedly 'look over' code were asleep for two years.

Quote
If "everybody" is in charge, then nobody is in charge.
 

Offline MasterBuilder

  • Regular Contributor
  • *
  • Posts: 61
Re: Commercial product source code
« Reply #14 on: April 15, 2014, 04:22:45 pm »
Cpu's these days are fast enough that this will be unnoticable.
Just initialising and flushing an array would have prevented this bug.
C may be very powerful but it is a friggin nightmare security wise as it does not perform any safety check. Security applications should not be written using that language.

I would like to make the distinction between good code from a security perspective and good code from a safety perspective. What I'm interested in here is code where safety of the operator was taken into consideration during design.


Im sure there is source code from some projects about, due to companies going bankrupt or commercial projects going opensource, stuff like the code from the NASA guidance system that can be found online.

 Does anyone have any good links?
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 4832
  • Country: de
  • A qualified hobbyist ;)
Re: Commercial product source code
« Reply #15 on: April 15, 2014, 04:26:02 pm »
You have somevalid points, but i cant help but wonder about a few things
-the source is available. This bug sat there for two years , and did not get fixed until the big stink afew weeks ago

So far for the 'open source is safer because anyone can look over it'... Seems the people that supposedly 'look over' code were asleep for two years.

Who loves to check code written by another person? Not many, I'd guess. There is more motivation when payed well. Another argument is that, open source is screened by the bad guys to find security holes for their benefit. They won't report them to the dev team of course but sooner or later the attacks will be detected or some white hat reports the issue. That means issues are detected earlier than for closed source.

Quote
Second, i have read the report about the problem. Turns out this is a stupid memcopy error.
Will someone please kill the C language ? Or at least make a runtime lib that does boundary checking so that this kind of crap can never occur ?

The problem started when the programmer forgot the most important rule for internet protocol implementations: always check any input! If someone asks you to send him a known junk of data with a specific size you should check if the given size matches the real size.

Quote
Cpu's these days are fast enough that this will be unnoticable.

For the client, yes. But a server runs several thousands of sessions usually. Simply multiply the number of sessions by the overhead and you'll see it matters. Unfortunately security comes with a performance penalty. You can run PHP in apache with modphp or fast-cgi but you don't get fast and secure.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Commercial product source code
« Reply #16 on: April 15, 2014, 04:29:53 pm »
heartbleed was discovered by pen testing it, not by looking at the code.

At work we code review our peer's work and we probably take more time reviewing it than it took to code it.

But look at Nasa's peer review and coding standards for guidance, those guys do everything with check lists.

And for publicly available, and not sure how good their code in here is because it might not be maintain solely by nasa engineers:
https://claraty.jpl.nasa.gov/man/software/index.php
 

Offline tjaeger

  • Regular Contributor
  • *
  • Posts: 101
Re: Commercial product source code
« Reply #17 on: April 15, 2014, 05:43:07 pm »
heartbleed was discovered by pen testing it, not by looking at the code.

At work we code review our peer's work and we probably take more time reviewing it than it took to code it.

Oh, the hilarity.  Someone who is on record displaying an utter lack of understanding of the security implications of memcpy and an unwillingness to learn is lecturing others on how to avoid security issues involving -- get this -- memcpy.
 

Offline Jarrod Roberson

  • Regular Contributor
  • *
  • Posts: 71
Re: Commercial product source code
« Reply #18 on: April 15, 2014, 05:48:57 pm »
Im interested in this purely from an educational point of view. I find much of the published source code and educational examples are full of errors, Id like to see how the pros do it.

Same way, full or errors, they just cost more to produce and you aren't legally allowed to fix them! :-)
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3333
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Commercial product source code
« Reply #19 on: April 15, 2014, 06:42:19 pm »
Find some released code which was previously under commercial license. Didn't Microsoft release some parts of .NET?
Or buy something, an RTOS or Networking stack for example. Will cost a few thousand dollars, but you'll have full source.
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 671
  • Country: ca
    • VE7XEN Blog
Re: Commercial product source code
« Reply #20 on: April 15, 2014, 08:06:15 pm »
What I'm interested in here is code where safety of the operator was taken into consideration during design.
Therac 25?

(Yes this doesn't answer the question, and the source code isn't available AFAIK, but it's an interesting case study).
73 de VE7XEN
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6541
Re: Commercial product source code
« Reply #21 on: April 15, 2014, 08:17:59 pm »
stuff like the code from the NASA guidance system that can be found online.
http://www.ibiblio.org/apollo/links.html#Software_manuals_and_listings

Apollo guidance computer firmware.
 

Offline MasterBuilder

  • Regular Contributor
  • *
  • Posts: 61
Re: Commercial product source code
« Reply #22 on: April 15, 2014, 09:29:08 pm »
What I'm interested in here is code where safety of the operator was taken into consideration during design.
Therac 25?

(Yes this doesn't answer the question, and the source code isn't available AFAIK, but it's an interesting case study).

Very interesting
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Commercial product source code
« Reply #23 on: April 15, 2014, 09:30:49 pm »
There us no assurance that commercial code is of high(ER) quality, or open source code of high(ER) quality either.

an easy source of commercial code would be the OEM libraries. Microchip, luminary and ti all have, in my view, mediocre code. St has better but also buggy code.

the heart bleed is an example whereby a model that is advocated for high quality code fell flat on its face.

in general, I tend to trust code produced by people who livelihood is on the line. On the flip side, open source code has the advantage of having people,s hearts on the line.

so generalization is dangerous.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3072
  • Country: us
Re: Commercial product source code
« Reply #24 on: April 15, 2014, 10:46:55 pm »
Quote
Will someone please kill the C language ? Or at least make a runtime lib that does boundary checking so that this kind of crap can never occur ?

Spoken like an EE.  I might as well say "why don't op-amps have an error output when their inputs stray out of the legal range!"

OTOH, there's one example of avr source code used in commercial products: avr-libc.
Any other of many published libraries for other processors: Tivaware.  Microchip's USB and Ethernet Libraries.  C++ STL.  Newlib.  gcclib.

Arduino is a commercial product.  It's core code is all open source.

Several early 3D printers used OSSW in the AVR-based (arduino-like) hardware controllers.
That may be the closest thing to what you're looking for.  http://reprap.org/wiki/Generation_3_firmware

I don't expect any of this to be very impressive.  Vendor stacks and libraries have pretty bad reputations.  Eventually I realized that this is because they don't have enough cooks.  How many SW engineers do you think Microchip has working on their TCP stack?  How many engineers at Microsoft or Cisco work on THEIR (proprietary) TCP stacks?  Hint: I'd expect several decimal orders of magnitude difference.  Single digits for PICs, 1000s for cisco.  (now, there better NOT be 1000 engineers actively modifying TCP at the same time, or you have a different set of problems.  But if you have enough people total, you'll have a bunch of them like free_electron, frequently complaining how awful things are.  Sometimes they'll be wrong.  Sometime they'll improve things.   Sometimes they'll be listened to, and other people will improve things.  And sometimes they'll be ignored even when they're right.   Of course, not all commercial code is written by large SW teams, either.)


Quote
Wasn't the "Heartbleed" problem caused by buggy open-source code, which was then inadequately reviewed before release?

Well, I suppose you could define any SW with bugs as "inadequately reviewed", but I'd say that the Heartbleed bug was one of those things easily overlooked in a review (perhaps they concentrated too much out output buffer overflows!)  It was the Apple SSL/TLS bug that had "obviously inadequate" review.

Quote
Just initialising and flushing an array would have prevented this bug.
That's not the way I interpreted the analysis.  The source and destination were not arrays.  The destination was properly sized and zeroed.  There WAS data in the structure defining the length of the array (but it was provided from external sources, and did not match the actual size.)
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf