Perhaps stories like this will make clear what the costs of disabling code signing really are, to be weighed against the incentive to disable it ...

Pistols, however, are used by criminals, by people committing suicide, and by kids playing around with them. As a direct result, over 30,000 people die every year after being shot with a pistol.

This is an example of a truthful but not useful statement. Yes, 30,000 people die every year as a result of being shot by a pistol. According to the CDC, in 2010 there were 11K firearm homocides and 19K firearm suicides.

That's a big difference in perspective, since a regulation that might be justifiable to prevent an individual from shooting his wife or neighbor might not be justifiable to prevent him from shooting himself. It's not dispositive, of course, but society has a much larger interest in preventing individuals from killing each other than killing themselves.

Do these bags simultaneously keep the phone powered on while preventing the internal clock from advancing? If so, I think there's some folks in Sweden that would like to award the creator some very nice jewelry.

Too bad for "standard forensics" that the passcode is mixed in with a hardware-specific key baked into the SOC. So you'll first need to be able to run arbitrary code on the individual's phone itself in order to keep guessing beyond the limit. That's going to require a significantly more intrusive examination.

Self incrimination has never applied to physical evidence that the individual has in his possession, it only applies to things that are "testimonial" (quotes because this is a term of art). After all, the 5A specifically talks about being a witness against one's self, not about providing evidence. See also Fisher v. United States, 425 U.S. 391 (1976), Schmerber v. California, 384 U.S. 757 (1966) and United States v. Wade, 388 U.S. 218 (1967).

The classic example is business or tax records related to fraud prosecutions. An individual served with a valid order cannot refuse to turn over documents because they would tend to incriminate him, that doesn't make sense. You can't force the individual to testify to anything, but you can compel them to produce physical objects that you have probable cause to believe are evidence relevant to the prosecution of a crime.

Another canonical example is a court order forcing an individual to provide a cheek swab for a DNA test. Again, not testimonial because it's not communicative in any way -- you are just talking about physical, tangible evidence.

So basically, in combination with your password, this tools let's you access resources secured by your password. Amazing! Next up you'll tell me there's a tool that lets you open my front door in combination with a copy of my house key!

Let's put this another way -- you tell some /.er that he can buy a new iPhone, enter his password and immediately restore from an iCloud backup. Logically then, we expect that he understands that the password controls access to the backup, since the only thing he needed to provide was that password.

Which is why clamd should provide a systemd.socket, unit in which case the init system installs the sockets and then hands them off to the spawned process as soon as the respective daemon is to be started.

It's just as easy to to do this in systemd as it is to bung together shell that does it, but it's not as familiar. In a few years, most system admins will be able to mash out a systemd.socket unit in their sleep.

Absolutely true for debugging. But there's a few steps you missed.

Somewhere near 3-4: Ok, how bad would it be if that happened? Does it recover without user intervention (i.e. service crashes and cron restarts it)? Does it recover with user intervention ("did you turn it off and back on?)? Does it lose user data (oh poop)?

The question here (which is altogether not trivial) is exactly this: "how bad would it be if we wrote an extra '\0' somewhere"? And what geohot did was answer that in the most productive way possible - by actually showing with a real example that the impact is major and permanent. If you aren't explicitly doing assessment of the impact of your bugs for schedule/priorities then you must be doing it implicitly somehow because most projects have more bugs than coders/time.

There's another step you missed, happens probably at step 10 or 11 and probably not by the developer that fixes the bug -- given the impact and the risk of the fix, when/how should this be deployed? Should it be backported to the stable releases? Do we have to ping everyone downstream? Is this so bad we should post on /. telling everyone to pull the emergency fix ASAP or else zombie Putin will kill Natalie Portman?

Again, if you aren't doing this step explicitly, it's either happening implicitly or else you are just letting it land whenever/however.

There's already binding precedent in the Circuit that covers NYS.

Tunick v. Safir, 228 F.3d 135, 137 (2d Cir. 2000)
loom v. Levy, 159 F.3d 1345 (2d Cir. 1998).

I'm not sure what another case would prove -- the appellate courts are loath to repeat themselves.

The (heartless) thing about it is that drugs are not too different from many other things in society that are used by rich and poor alike but harm the latter much more.

The rich are far more likely to own firearms than the poor and far less likely to shoot someone or be shot.
The rich buy far more alcohol than the poor but are far less likely to drive drunk or be alcoholics .
The rich do far more drugs than the poor but are far less likely to become non-functional addicts.
The rich are far more likely to waste their education on party schools than the poor but are less likely to suffer the career consequences.
The rich and the poor engage in about the same amount of premarital sex but the former are less likely to have kids out of wedlock.
The rich gamble more often than the poor but are far less likely to become chronic gamblers.

To my mind, this suggests that the ultimate cause of these problems isn't the particular vices, but rather the cultural and economic context around them that causes them to be destructive. We should work at fixing that context, along with providing opportunity and support for everyone to work towards their own success, rather than wasting our time on proximate causes.

The only thing you can cryptographically sign is a binary. The rest is inspection by hand which won't scale.

Hey, I can make all kinds of tasks faster by precomputing much of the work and then looking it up in a table. Congratulations, you've (re)discovered another instance of a Space/Time tradeoff.

Now, in particular what they've done is still wicked cool -- it's a great idea to perform may millions of simulations ahead of time so that at runtime (heh) you can quickly draw on that data to adapt. It would be perfectly good research even without the over-the-top claim that they've somehow made the work faster as opposed to cleverly pre-computing much of it.

But that's research -- you do something neat and then you make a ridiculous overstatement to generate buzz ...

No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.

It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.

tl;dr: it's much harder than just installing an identical version of clang and hitting make.

[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]

If the USA is the bastion of freedom, capitalism and independence, why are cab licenses limited by city bureaucrats? Why not let everyone who qualifies swim in the taxicab business leaving those who cannot stand the waters perish? I just don't get it!

Because historically taxis have engaged in a number of fraudulent and unsavory practices, outright racism in some cases and have generally made cities look bad. So there was a legitimate reason to regulate them in order to ensure that they didn't bilk (or take the long route) for gullible tourists, refuse rides to people of the wrong color, install fake meters, organize into a racket to overcharge customer or skip on carrying decent insurance.

Then, lo-and-behold, the well-meaning regulators were captured by the taxicabs (because they were smart) and turned around and instituted any number of illegitimate regulations designed to stifle competition. This is generally pretty easy in a democracy because when there's a small number of cabbies with a very large interest in certain policies, they can often get their way when there are a large number of citizens with contrary interests. It's the law of diffused costs versus concentrated benefits.

So now, instead of being predictably idiotic with our left/right pro/anti regulation, maybe we should think about stupid regulation versus smart regulation. Then we could distinguish a rule require cabbies to carry insurance for their passengers with one that limits the number of medallions to some artifical number. Or one that requires accurate metering of any form with one that requires a specific brand or type of metering. Or a law that requires cabbies to serve any part of the city with one that requires them to drive home from the airport empty instead of picking up a fare immediately after dropping one off (this one really I don't understand -- there is a line for cabs at the terminal!).

On the other hand, nah, let's just hurf about it....

Part of the problem is that it's easier to hire new folks than to reallocate existing ones without getting into political turf wars -- let alone shrinking some departments* that don't need the headcount. This means that the utility of a new employee is automatically greater than one that's been there forever, even if they are equal in skill, just because they can be put in the most useful position.

This is a facet of downwards-stickiness -- it's easy to tell an overstaffed* department that they don't get to hire new folks, it's nearly impossible to tell them to give up folks. But both of those are equivalent in terms of overall allocation of resources.

* Note: I don't mean to say that these folks are incompetent, only that demands change and a team that might be stretched thin one year because of a large project might have few demands the next. In fact, it's exactly the opposite -- the most talented teams end up overstaffed because they build things well and end up without much maintenance to do, rather than constantly chasing their tails duct-taping things up. We should be moving talent from those teams to where it's needed the most.