Sure, everything could probably be tracked back to the good golden years, but who was really doing TDD before Rails?
I was doing Java back (during Kent Beck days of XP etc) and although I had heard of JUnit (and even heard Kent Beck preach about this at a conference) and it sounded cool, no team or company I knew was using it seriously.
It's only when Rails came around where if (I believe if memory serves me right) the default controller/views generators created tests automatically. Ruby being a dynamic language and no compile step, you couldn't prove correctness before running it, meant you were skating on thin ice if you didn't write tests.
I know someone people that worked at Xerox (when Steve Jobs visited) and they pretty much invented everything. lol.
I've been told stories that pretty much technology after Xerox is a derivative from that time. Sure, I take that with a pinch of salt, but I half/mostly believe it.
I’ve got two first gen HomePods here which died slightly out of warranty, and AppleCare wanted $300 a piece just to take a look at them. Makes me quite gunshy about spending yet another $300 on a product which may not last more than 2-3 years.
Exact same experience here. Mine died after a botched firmware update. Woke up one morning after it had auto-updated the night before. 100% Apple's fault because they pulled the update shortly after but the damage was done. Took it in thinking they would just reset it and shocked they wanted $300 to repair. Unless this one has a UCB-C port like the mini that allows user resetting I'll skip this one.
And I think it works out to about $80 once you include shipping. Ive got a dead one right now - trying to decide if I want to source air gun to fix it myself or just send it to him. Less than $100 to have it fixed is kind of a steal.
Very helpful y’all, thanks! Gonna see if I feel up to tackling the repair (good excuse to buy a reflow setup) and or get in touch with this gentleman. Cheers!
The best publicly known attacks on RSA reduce the attack time by a few orders of magnitude at best. A functional quantum CPU could reduce that by a few more orders. Your 4096-bit RSA key is still 2^3072 times harder to break, so even with reductions we're still talking about "heat death of the universe" amounts of time to brute force.
RSA has issues but as of yet hasn't yielded entirely to cryptanalysis.
As the article says, it's easier to attack the system and try to get the plaintext, or coerce you into giving up your key through legal means.
Edit: adding a link to Wikipedia's article on post-quantum crypto, it's a good place to start understanding how to answer these type of questions:
"Your 4096-bit RSA key is still 2^3072 times harder to break,"
No, because the difficulty of breaking RSA keys doesn't scale in the same way as symmetric encryption. Integer factorisation is much easier than a brute force search of the keyspace. A 1024-bit RSA key is believed to be roughly equivalent to an 80-bit symmetric key. A 3072 bit key is about as hard to brute force as an 128-bit symmetric key.
Ah shoot, you're right. I'm an armchair crypto geek at best.
In any case, you can choose a public key exponent large enough to still make it a hard problem to crack in a reasonable amount of time. Barring some huge vulnerability in RSA that hasn't been discovered in 30 years of public scrutiny, of course.
Are you sure about that? As far as I understand it, generic quantum computation would cut that '3072' in half, and using quantum computers specifically for factoring reduces problems to a low polynomial time.
Correct. Shor's algorithm renders any use of RSA... pointless.
And while there are limits to the applicability of Grover's algorithm, you're correct that it effectively cuts the number of bits in any cryptosystem it applies to in half. Which, to my nonexpert eyes, looks to be most of them.
Hmm, yes, I think I conflated the asymmetric vs symmetric cases.
Shor's algorithm is very tasty, but when the real world demonstrations at top research facilities are saying, "yes, we factored 21 into 7x3, but WITH ENTANGLEMENT"[1] it makes me think that scaling to RSA-size prime factors is still a good way off.
Listen, the US government is powerful, but building a full scale quantum crypto decoder ring in complete secrecy _decades_ ahead of everyone else? I just don't think so. Maybe I'm a sheep for not wanting to believe the government so powerful and corrupt, but the whole thing sounds like a tin foil fantasy.
I don't doubt they would if they could, though. And they've done as much as they can with present day tech: supercomputers, mass data collection, penetration of target systems, exploiting SSL's many weaknesses, tapping undersea lines, and legally strong-arming perceived threats into giving up their encryption keys. I just don't think we need to get science fiction involved.
Hey, I wasn't claiming practical quantum computers existed. Just that, at whatever point running Shor's algorithm becomes practical, RSA will be pointless.
Yes: call/SMS forwarding. It depends on how good your first factor (e.g. password policies) are, and how your reset process works. Getting someone's phone number and setting up call forwarding doesn't require much social engineering savvy to pull off.
Call forwarding doesn't forward SMS. I don't think you can do SMS forwarding (at least for any carrier I'm aware of). You'd need to social engineer the carrier to port your target's number to a different phone -- in which case the target is going to be exposed to a ton of trouble...
Looks like it's built around KVM (Kernel Virtualization Modules), i.e. "containers", rather than full-blown virtual machine emulation like Xen or VirtualBox/Vagrant.
It appears to be a configuration management / deployment tool for KVM containers. New to me too, gonna dive in and check it out.
KVM is full machine emulation (i.e. hardware is emulated, and you can run different kernels inside the guests than you do on the host).
Docker uses LXC which is like BSD Jails, most of the advantages of VMs but you don't have to emulate a whole system, there's only one kernel atop which multiple containers/jails can run different software and have thorough isolation. Very fast and light-weight, but you can't run different OS kernels.
nitpicking: KVM stands for "Kernel Virtual Machine". It's an implementation of virtual machines, just like VirtualBox or VMWare. Containers are completely separate from KVM.
Wow, that comment thread... does not lend itself to confidence in their project's security.
It also illustrates a really key point about crypto: because it looks simple (oh, just run the bytes through that function/hash/send them over SSL), people assume that it is simple they know enough to hack together a decently secure system.
At the very least, a healthy respect of crypto theory is called for. In my experience most developers do not have this healthy respect and see crypto as a magic black box that makes data unreadable.
I find attacks on cryptosystems illustrative for the "oh CRAP" moment. Oh CRAP salted hashes are a terrible idea. Oh CRAP you can pad a hash to make a remote system accept "signed" data. The more I learn and the older I get, the more cautious I am.
Hackers built Facebook. They hire hackers. If there's a group that's hardest to pigeonhole in terms of beliefs it's hackers.
The idea that a company composed if hackers could have not a single whistleblower, no single person that objects so strongly that they must speak up regardless of their personal situation is betting against human nature. Nay, hacker nature.
Freedom ain't looking good nowadays, but this is not the vast conspiracy it may seem.
I have a theory that the accelerometer-linked 3D "layer" effects might make the flat interface more usable in person. As in, the subtle perspective shift would make it obvious that a button is a button, etc. Can you comment on that? Are those effects extended to all of the UI elements?
It seems like a pretty gimmicky effect right now, although if you hold it in a certain way it does have a cool 3D effect. The scrolling animation stutters quite a bit currently. I anticipate they'll have that fixed by release.
They aren't, and even the little layer effect on the home screen is nothing but a gimmick. I don't wave around with my phone while I use it and would never have noticed the iOS6 volume slider effect if blogs hadn't pointed it out.
A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct?
As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway.
Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.
Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure?
And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop.
After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections.
If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)
The problem with these attacks on SSL is that they're not protracted; They're trivial. Python's httplib doesn't check SSL certificates at all by default, for example, so you just hijack the TCP connection, negotiate SSL, and then you're done.
With libcurl, I think you have to set CURLOPT_SSL_VERIFYHOST to 2. If you set it to TRUE (i.e. 1), it skips part of the certificate check, rendering the whole thing trivially insecure.
Most (all?) crypto libraries have terrible APIs, or have APIs that are far too low-level to be safely used by most developers. SSL shouldn't be the easiest thing to attack, but in the current state of affairs, it often is.
https://agileforall.com/history-of-tdd-as-told-in-quotes/
Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”