exactly.

In no way will this law help people who have trouble thinking on their own, think on their own. In no way will this strengthen democracy but only strengthen control of what state government considers influence or product sale to silence competitors to those who pay them kickbacks. So I am going to pass in support of this idea.

The worst part about donating isn't the lingering banners (adblock can be set to take care of them easily). It's the WMF spam. I donated once, a mistake I'll never make again. Once I donated, I was automatically subscribed to a "donators" mailing list, which they used to bombard me with requests to ask my friends to donate, subscribe to a recurring donation model, etc.. Instead, I told my friends that if they donate to Wikipedia, they'll have to deal with such unsavory practices.

As a man-in-the-middle, how difficult do you think it would be to add 250 AUTH PLAIN to a cleartext server response?

Since you're having trouble reading between the lines, I'll explain:

1. Unfortunate client is set to prefer (not require) encryption.
2. Client connects to server.
3. Client sends STARTTLS request.
4. MITM rejects STARTTLS request.
5. Client sends AUTH command, with username and password, over unencrypted channel.
6. Server rejects unencrypted AUTH command.
7. MITM issues STARTTLS request.
8. MITM issues AUTH command with the password it just stole.

This can, incidentally, be done over any public network by a MITM. Rejecting that unencrypted AUTH command helps combat users who disable (or don't enable) encryption in their clients, simply because they'll try it once, then enable encryption when they can't send mail (hopefully it isn't too late at that point). But it does nothing against users with mail clients that are not set to require that encryption succeed. It does nothing to address the case of the ISP stripping STARTTLS requests.

s/GNOME/Apple/
s/Apple/Android/
s/Android/Windows/
s/Windows/Palm/
s/Palm/Whirlpool/
s/Whirlpool/Whole Foods/

Clearly, all trademarks should be meaningless and indefensible.

If all clients were somehow correctly configured (which they won't be, because Users), then OP wouldn't have any need to configure his mail server to reject unencrypted authentication attempts in the first place.

So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?

Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?

Ehh...

First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.

This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.

The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.

So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.

That said, if they performed some meager sanitization, it could go a long way to improve the situation.

It's worse than that. Most browsers don't check certificate revocation lists, and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.

Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.

Web-SSL was already a broken system. Now that it's been cracked open even wider, maybe we can throw it out and implement something better.

Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.

There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.

I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.

That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.

This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):

char *rec_p = record; // record pointer
uint16_t rec_len = SSL3_RECORD_LEN; // hi! i'm ignored.
uint16_t user_len = *(uint16_t*)rec_p; // user_len = user-supplied length
rec_p += sizeof(uint16_t); // rec_p points to start of user payload
char *buf = malloc(user_len); // allocate using user-supplied length
memcpy(buf, rec_p, user_len); // copy user_len bytes from record
reply(buf); // reply with said data

Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

Most keys marked "Do Not Duplicate" are not standard keys. Assuming that the kiosk carries only certain types of blanks instead of fully machining each key from a block (likely, but unspecified in TFA), it shouldn't be able to duplicate non-standard or "security" or vehicle keys anyway.

If you happen to have a normal house key marked "Do Not Duplicate", and you really want to duplicate it anyway, ten minutes with some sandpaper will take care of that problem, and then any random locksmith will do.