Author Topic: Binary blobs have no place in BitShares Toolkit source tree  (Read 1896 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Is it used by linux builds? Does it even have makefiles for linux or a ppa? If its win only id say ya go with that until code freeze in the core engine.. Otherwise if its cross platform and useful might make sense to integrate into build.

It is windows only.
Well then :)
lol ..

i feel ignored .. seems I am missing out a CRUSIAL feature here  ;D

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Is it used by linux builds? Does it even have makefiles for linux or a ppa? If its win only id say ya go with that until code freeze in the core engine.. Otherwise if its cross platform and useful might make sense to integrate into build.

It is windows only.
Well then :)
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline bytemaster

Is it used by linux builds? Does it even have makefiles for linux or a ppa? If its win only id say ya go with that until code freeze in the core engine.. Otherwise if its cross platform and useful might make sense to integrate into build.

It is windows only.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Is it used by linux builds? Does it even have makefiles for linux or a ppa? If its win only id say ya go with that until code freeze in the core engine.. Otherwise if its cross platform and useful might make sense to integrate into build.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline bytemaster

Its on codeproject and google code.. I replaced mine to make sure its the right one amd fix a compiling issue so I deduced its fine. Its mainly for a debug environment maybe once bugs are gone we take it out of production?

I am not opposed to having it removed from the source... it would be easy enough for any 3rd party to remove it from the source and let people audit that version.

I don't like having it in there once we hit version 1.0... but it does help us track down bugs.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Its on codeproject and google code.. I replaced mine to make sure its the right one amd fix a compiling issue so I deduced its fine. Its mainly for a debug environment maybe once bugs are gone we take it out of production?

I compiled openssl using mingw and maybe the code should be pulled in similar to leveldb since not a well known dependency.
« Last Edit: October 16, 2014, 03:39:20 am by jsidhu »
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline theoretical


I think that it should, in principle, be possible to run BitShares on a completely open source system where the user could theoretically audit the source code of any component.  In particular, there should be no closed-source or pre-compiled components in the BitShares toolkit itself.  The BitShares Toolkit should allow users to audit every line of code that could potentially gain access to the private keys controlling their funds.

Of course, if some individual user want to make an individual choice based on individual convenience / security tradeoff preferences, they should also be free to choose to trust OS vendors, binary package repos, PPA's, precompiled binaries, etc.

There is a binary blob in the BitShares toolkit source tree at https://github.com/BitShares/bitshares_toolkit/tree/c58b14c6dc923929368022af6c1c54a45b67dc2f/CrashRpt/bin.  This binary blob is apparently used for crash reporting functionality.  I requested it to be removed.  This request was overruled; see https://github.com/BitShares/bitshares_toolkit/issues/658.  (However, the dependency was made optional in the build.)  The issue has not been revisited in approximately two months since then.  I'm starting this thread to discuss why it's still there and try to build consensus about how to satisfy the goal of making the source code (in principle) more auditable by (if possible) removing the binary blobs.

What is stopping us from managing this CrashRpt dependency the same way we manage OpenSSL dependency?  We don't put precompiled OpenSSL binaries in the source tree.  Instead we have DLL's, so's or statically linked libraries that come from somewhere else (the package manager on Ubuntu; I'm not really sure what Windows and Mac do, perhaps they require the user to separately, perhaps manually, download and compile OpenSSL from source?).

What is stopping us from managing this CrashRpt dependency the same way we manage LevelDB dependency?  We don't put precompiled LevelDB binaries in the source tree.  Instead we have the LevelDB source code in a submodule, and its build is integrated with the main project's build.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk