Microsoft thought Java was a good idea in that they liked the JVM a lot, but the language itself they saw as flawed and missing key features that would make it a truly modern language, in particular they heavily disagreed with Sun's approach to FFI (foreign function interface) [Java's slow, laborious efforts eventually building JNI, the Java Native Interface], because of their many years of experience for better and worse with COM (component object model).
J++ was never meant to be "Java", and never technically was even in branding, it was essentially a second language (that Microsoft saw at the time as C++ is to C, it was to Java, and that's very clearly represented in that brand name) that also targeted the Microsoft version of the JVM, and used a couple Microsoft-specific escape hatches for FFI and COM.
(So it absolutely was an "embrace and extend", but it wasn't of the Java language itself so much as it was the JVM that Microsoft wanted to embrace and extend that seemed to fright Sun so badly. That's probably why so much of the legal drama and the consequent blows to the rest of the Java ecosystem at the time was Sun withdrawing JVM licenses from just about everyone as a part of that battle. Originally Sun seemed rather happy licensing the JVM to whoever wanted to implement it, which is why Microsoft had a JVM in the first place, thinking controlling the Java language was enough. Sun worked to put that genie back in the bottle and move everyone back to mostly a single JVM again. There's no lack of irony in the exact same battle playing out between Oracle and Google decades later in the battle of Dalvik [Google's JVM] and Android.)
It wasn't that Sun didn't want Microsoft using Java, they didn't want Microsoft using the JVM any longer, and without a license to build their own JVM, J++ wouldn't run on any other JVM and wasn't a useful language.
When Microsoft lost their JVM they decided to start from scratch, moved the J++ team (including and particularly Anders Hejlsberg, C# lead) to a new VM that they could control from top to bottom (including its FFI mechanics), and much of what had directly been the J++ team used what they learned from the whole mess to create C#.
That's not really how it works in practice in my experience. In some time, some thing you use needs to be patched and the latest version only runs on the newer platform.
Doesn't matter if the underlying platform is supported if the entire ecosystem moved elsewhere.
The most recent versions of the .NET Framework (including 4.8, the final version) are supported for as long as the OS they are installed on is supported.
I think that because of that longevity, you're going to see lots of the main libraries etc. supporting .NET Framework for years to come.
Developing to the right .NET Standard spec will ensure compatibility between ‘old’ .NET Core and the legacy .NET Framework 4.8. Libraries that do so would be limited in their ability to use new language and framework features though.
Here's probably a silly question: Shouldn't this work automatically? I just assumed they would have an intermediate CA or whatever it's called and have that certificate be signed by some widely trusted CA.
Or have they done it in a different way for security reasons?
Not silly at all. Certainly there are some database clients that will access a system default CA trust store. ISTR the PostgreSQL JDBC client may have this behaviour, although perhaps depending on which Java runtime & packaging is in use. And there'll be others besides.
And behold, Amazon are themselves a globally trusted root CA! (Have a peek in /etc/ssl/certs, on must current 'nixen I would expect to see the four Amazon roots). So why not have the Amazon root sign the RDS CA certificate as an intermediate CA, so that clients who could trust an RDS-issued cert that way, will magically trust it?
I've met some of the RDS team and they are smart cookies. If you will agree to my use of cookies, then I can think of at least three good enough reasons (and just to be clear, this is speculation and extrapolation, not insider chapter and verse):
1. Changes in behaviour during another potentially disruptive change are the province of the unwise, the unwary, and the otherwise soon to be fired for cause.
2. Not all clients can use a default trust store; even different clients for the same database may differ. For example, the PostgreSQL C client (as used by the command-line tools and many language bindings) cannot access the system certificate store; the bundle must be configured explicitly. For one client to have a magic behaviour that others do not, in the realm of cryptography and trust, is going to make security admins and auditors very unhappy. Inconsistency is the enemy of policy, and policy makes the DevSecOps world go round.
3. Not all clients support a certificate chain, so the RDS team already has to maintain a bundle of the regional intermediates. Making the RDS CA an intermediate just adds more complication to that activity, more special cases to document, and more potential for confusion in client configurations.
So these are security reasons, although they're more from a policy and human factors and software inadequacy perspective than anything to do with, say, large prime numbers. It's quite possible the service team have more reasons besides; I would certainly agree to their use of cookies or indeed any baked product. For me, those reasons alone would suffice, and I am not surprised to see that the new RDS root is another standalone self-signed CA.
Re: anything w/ security (esp how it works), if you don't know ASK. ASK. ASK.
PLEASE ASK.
Security is incredibly complex and minor/subtle mistakes can destroy companies and other potentially catastrophic consequences (especially to your employment.) If you're not sure about something, ASK. End-users are bad enough when it comes to security, but engineers should always feel empowered to "make sure" about all matters of security, large or small.
Obviously it's best to to be familiar with best practices, but if you're not a security "expert" and you're unclear about something, ASK.
There no dumb questions in security, just dumb practices. The dumbest thing of all is not asking your question because you think it's "obvious."
> Security is incredibly complex and minor/subtle mistakes can destroy companies
For better or for worse, that's not the case. These days, security mistakes just end up in 2 years of free credit monitoring. Ironic case in point, Equifax.
I'm not saying you shouldn't take security seriously. But it's not fair to say that insecurity could destroy your company. Mainly, most end users just really don't care (or have a choice).
It depends on the company. What you say is true for a consumer website, but much less true for a SaaS product which depends on customer trust. For example, imagine an AWS or Salesforce or Github security breach that released very private business data.
As ever, the #1 tip to maximise confidence in your configuration is to automate it, write a failing test case, then fix the test.
> Any specific examples?
Some of the new-wave SSL implementations (including yaSSL, with which mysql-client can/could be built) didn't always support them (not sure where yaSSL is at now), and the AWS documentation hints that it's cropped up in some circumstance in GovCloud, but I think the most likely circumstances will be enterprise folks using appliances and/or appliance-like software that's configured only via a web UI, one in which they just didn't think chains were necessary (or that only supports a small bundle etc etc; the sky's the limit in this class of software gore). I've seen this exact issue, albeit for an LDAP client not a RDBMS.
For mysql at least you need to specify what CA or cert to trust. There is no default CA which mysql will try to use. So once a CA expires you will have to rotate it
> Here's probably a silly question: Shouldn't this work automatically? I just assumed they would have an intermediate CA or whatever it's called and have that certificate be signed by some widely trusted CA.
Yeah, that would work if someone at AWS would make a bit of sense and would sign them using their pubic CA, but they decided not to and instead generate new RDS CA every 5 years.
Anyway at least with PostgreSQL clients that rely on libpq (the main postgres client library) by default while it prefers SSL when available it won't verify the certificate unless you explicit use verify-ca or verify-full sslmode.
I never touched Bitcoin so maybe you can clarify how this makes sense:
> If Microsoft decides to terminate your license, what happens to your Bitcoin?
Your Bitcoin is represented by some kind of data stored on your computer I assume. So this data should be backed up, right? So the anwser is that you would access the bit coins from some device which you have a license to use?
If my understanding is right then I would consider the quoted statement to be a bit FUD:y.
if you're using security methods like bitlocker (an MS product that encrypts your disk), it's possible that, after losing your license to use that program, your data would become unrecoverable without some serious reverse engineering efforts.
I'm probably just adding to the paranoia though. In reality, this whole thing is a very unrealistic attack. What hluska has stated is mostly true, but I'd like to add that an employee that could write code into an OS that would steal bitcoin and stay undetected would have to have a lot of skill. More than that random engineer that they just hired, think a guy with a PhD. Those types of people generally don't risk their jobs to steal because they're usually committed to their work and make a lot of money.
Sorry, but I'm not sure what point you are trying to make here. Is your scenario that the users license to use the OS is revoked combined with there not being any backups?
If you store data on a computer without backups you can expect to lose that data. Disks breaks, files are corrupted, computers are stolen, node.js deletes your crap. Or whatever.
As for employees embedding stuff in OS code. Sure, that can happen. Open source developers can also embed such code into any code they write, which has happened many times already. Unless you are writing your OS yourself from scratch or manually reviewed all source code for all code running on your machine (which I suspect no one has done the last decades), this is a risk. Open source or not.
I’m not the person you’re replying to, but Grifball is talking about BitLocker. BitLocker is a device encryption tool that ships with certain versions of Windows (I think only Pro, but don’t trust that.)
I believe that what Grifball is saying is that if your disc was fully encrypted and you lost the ability to decrypt, you’d be in a lot of trouble. In the BitLocker case, if you had a valid Windows license, encrypted your disc and lost your license, it would be a very bad day.
As for your comments about backups, you’re correct though in this case, a backup wouldn’t be much use if you lost access to BitLocker. That would take a really serious ops failure, but far stranger things have happened.
If your backup requires the original machine to be fully functioning, it's a bad backup. If it requires complete reliance on a third party holding a key, that they have the right and ability to revoke, it's also a bad backup. You're giving them the ability to cryptolock you at a whim.
