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.

Holy bad example, Batman! A guy who robs a liquor store for $100 doesn't get 20 years for stealing $100. He gets 20 years for pointing a gun at the liquor store attendant and threatening his life for personal gain. Possibly as a repeat offender.

What a lot of commenters don't seem to get is that the sort of pollution that hardcore offenders engage in over there often results in human deaths. So the potential for punishment is merely being brought in line with the crime. You won't deter serious polluters with a fine.

That said, sure, many crimes are not proportional to their sentences. No news here. While we're making improbable demands, i think the act of spitting chewing gum on the street or sidewalk should be treated as vandalism, and enforced accordingly.

It doesn't, actually. The definition of "permission" with respect to contracts has a well-established (legal) definition that is not vague in the slightest.

This. Sort of. Well, almost. You started off on the right track, anyway. But neither "top end Dell" nor "$1000 Eizo" will get you a monitor without PWM.

For the uninitiated, PWM stands for Pulse Width Modulation, and essentially, the PWM component blinks the LED backlight quickly in order to dim the brightness. The dimmer your backlight, the longer the "off" time. Sometimes, PWM use causes a perceptible flicker. What is perceptible and what isn't is subjective, however, and sometimes the flicker is imperceptible to a person, but still causes eye strain. Some PWMs blink faster than others, and faster-blinking units are generally regarded as easier on the eyes. Note that the use of a PWM isn't necessary -- LEDs _can_ dim, but since LEDs don't have linear electricity->lumens output and dimmer LEDs can experience a color shift, it's the easy way out. Most monitor backlight engineers take it.

I'm quite sensitive to PWM flicker. LED monitors especially tend to drive me nuts, so I did my research on this.

A couple of months ago, I compiled a list of no-PWM monitor options, from scouring tftcentral.co.uk, prad.de, and message boards around the internet. My criteria:
- IPS, or comparable (though all TN panels would use PWM anyway)
- no PWM, period -- not even really, really fast ones.
- preferably non-glossy, but any options will be considered.
- minimum resolution: 1920x1080

That's it. No size restrictions. These are the options I came up with:
- DGM IPS-2701WPH
- Dell U2713HM
- HP zr2740w
- Samsung S27B970D
- ViewSonic VP2770-LED

[Note that the Samsung, while it doesn't utilize typical PWM tech, does fluctuate according to some tests. For this reason, I did not consider it further.]

I found it interesting that all options were 27".

I, personally, bought the HP zr2740w, and I enjoy coding on it quite a bit. It's worlds easier on my eyes than any LCD monitor I've used in the past. Newer models such as mine (which was made in late 2012) apparently have a less aggressive anti-glare coating than older versions. Fine text is crisp using either gray-on-black (my preference) or black-on-white (the web's preference). White screens do not seem at all "dirty", as some people complain about the older revision.