Yes, I believe that your understanding is correct, as confirmed in a discussion on Telegram Developers Channel pasted below--Todd Fleming is a contributor to EOSIO codebase:
16th of August
User: is there any way for an user to remove RAM allocated that they own ? let’s say that I own a malicious contract that once an action hit,
check ram of user, and ...
Signatures are not just a list which can be copied and pasted, they're a key which is generated from the transaction. if the transaction changes, the signature is invalidated and will need resigning.
Therefore, if you push a transaction to contract A, if A was a bad actor and wanted to steal your funds, a new transaction to eosio.token -> transfer would be ...
The short answer is Yes it is vulnerable to government censorship but not because it is dPOS. Dan Larimer has argued that having 21 Block Producers is enough for decentralization and this number can be increased if needed. Additionally, the block producers will be worldwide beyond any one country's jurisdiction.
However, decentralization does not ...
Apparently the media report missed several details.
Block.One apparently issued a bug finding bounty, in an attempt to remove as many security holes as possible before launch. 360 apparently responded by finding the bug reported.
The reddit user that reported finding no issue or commit relating to it in Github was apparently mistaken.
It was assigned ...
The Web Assembly Website has information on the potential security issues for both users and developers when coding in WASM.
With regards to arbitrary code execution in EOS, @confused00 points out that these bugs were fixed before the report was even published.
EOS has a very quick turn around for serious bugs. If a vulnerability is found it can be fixed ...
A stop-gap fix has been issued in v1.2.3 of EOS
Deprecation of the ability of a notified contract to bill RAM to authorizers of the original action
EOSIO blockchains enable a useful feature which allows one contract executing an action to notify another contract of the action because it may pertain to it. EOSIO blockchains have up to now had an ...
If the contract owner wants to give up rights to update the contract or make transfers, they can change the contract owner and active permissions to eosio using cleos set account permission:
$ cleos set account permission <contract> active eosio owner -p <contract>
$ cleos set account permission <contract> owner eosio -p <contract>
You can do an SHA256 of the .wasm code to see its hash, and you can verify that on chain by doing cleos get code ACCOUNT_NAME. So it wouldn't be very difficult to write a script to check that the hash is as you expect it to be before performing a transaction.
What do you mean by deriving keys? Are you using the key to seed the randomness generator for other keys?
If that's the case and you're also trying to create EOS owner account keys with this method, then I see a security risk.
You could alternatively create a custom permission level that only applies to your application and create keys for that. This ...
EOS uses C ++, and C ++ assert can be used to check for overflow or underflow.
ex) assert( quantity + a.quantity >= a.quantity,"integer overflow adding token balance" );
See the link below for this.
Also, eosio provides eosio_assert to enable various assertions.
there's a write-up on how exchanges should deal with deposits and withdrawals on the eos blockchain. It deals with irreversible blocks, might be useful: