4 ms·

> . So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers

> . So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them. Not everyone has security as a requirement. Some people jsut want to write something that is both fast, predicable. Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do.

humanrebar 11y ago
On the other hand, banks want numbers that actually add up properly, at least in the code that deals with money. If you use undefined behavior in C or C++, the languages do not guarantee that your bank account balances won't all be rounded down to the nearest prime number on Thursdays in odd numbered months in leap years.
smtddr 11y ago
>>Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do. This is a bad way of doing things. That means as soon as someone finds a way to get inside the network, the bank is wrecked. You need to look at security from the point of assuming the attacker somehow got inside because it'll happen one day. http://digg.com/2015/ashley-madison-hack http://digg.com/2015/ashley-madison-hack """ MOTHERBOARD: How did you hack Avid Life Media? Was it hard? The Impact Team: We worked hard to make fully undetectable attack, then got in and found nothing to bypass. MOTHERBOARD: What was their security like? The Impact Team: Bad. Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers. """
jerven 11y ago
Safe, also means that the application does not crash in funny ways with segmentation faults. Which is something that banks like a lot.
cjcole 11y ago
"Some people jsut want to write something that is both fast, predicable." And debuggable? Not crashing in random places due to stack or heap corruption helps there.
lucozade 11y ago
Let me know which banks you've worked at with this attitude. I just want to check I have no accounts with them. This most definitely is not the view taken at the financial companies I've worked in/with including a number of banks. They take internal security very seriously. There's the obvious threat of some form of break-in (no-one I know seriously believes that an unbreachable connected system is buildable). But there's also the issues of insiders taking stuff, Chinese walls and regulatory restrictions on access. It simply doesn't make economic sense to take security lightly any more.
aswanson 11y ago
"Why do you rob banks?" "Because that's where all the exploitable attack vectors in unsafe code are."
kjdal2001 11y ago
Others have commented that security type safety can be important even in applications that are not externally facing, but thats even sort of besides the point. When people talk about 'safety' in Rust, often times they are talking about the predictability that you mention. Highly threaded code can seem to run perfectly for some time before obscure bugs pop up. Rust's abstractions around thread and memory safety can help in those situations.
raesene4 11y ago
I'm going to have to disagree with your point about banking applications based on my experience (~15 years) in banking IT and security. Whilst obviously Internet facing apps are treated with more caution, it's definitely not true in my experience to state that there are no security demands on internal applications. I would expect that most/all banks these days realise that there's no such thing as a fully trusted network...

humanrebar 11y ago

On the other hand, banks want numbers that actually add up properly, at least in the code that deals with money. If you use undefined behavior in C or C++, the languages do not guarantee that your bank account balances won't all be rounded down to the nearest prime number on Thursdays in odd numbered months in leap years.

smtddr 11y ago

>>Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do. This is a bad way of doing things. That means as soon as someone finds a way to get inside the network, the bank is wrecked. You need to look at security from the point of assuming the attacker somehow got inside because it'll happen one day. http://digg.com/2015/ashley-madison-hack http://digg.com/2015/ashley-madison-hack """ MOTHERBOARD: How did you hack Avid Life Media? Was it hard? The Impact Team: We worked hard to make fully undetectable attack, then got in and found nothing to bypass. MOTHERBOARD: What was their security like? The Impact Team: Bad. Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers. """

jerven 11y ago

Safe, also means that the application does not crash in funny ways with segmentation faults. Which is something that banks like a lot.

cjcole 11y ago

"Some people jsut want to write something that is both fast, predicable." And debuggable? Not crashing in random places due to stack or heap corruption helps there.

lucozade 11y ago

Let me know which banks you've worked at with this attitude. I just want to check I have no accounts with them. This most definitely is not the view taken at the financial companies I've worked in/with including a number of banks. They take internal security very seriously. There's the obvious threat of some form of break-in (no-one I know seriously believes that an unbreachable connected system is buildable). But there's also the issues of insiders taking stuff, Chinese walls and regulatory restrictions on access. It simply doesn't make economic sense to take security lightly any more.

aswanson 11y ago

"Why do you rob banks?" "Because that's where all the exploitable attack vectors in unsafe code are."

kjdal2001 11y ago

Others have commented that security type safety can be important even in applications that are not externally facing, but thats even sort of besides the point. When people talk about 'safety' in Rust, often times they are talking about the predictability that you mention. Highly threaded code can seem to run perfectly for some time before obscure bugs pop up. Rust's abstractions around thread and memory safety can help in those situations.

raesene4 11y ago

I'm going to have to disagree with your point about banking applications based on my experience (~15 years) in banking IT and security. Whilst obviously Internet facing apps are treated with more caution, it's definitely not true in my experience to state that there are no security demands on internal applications. I would expect that most/all banks these days realise that there's no such thing as a fully trusted network...