jannic

> Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be.

How does this work? If TrustCor is no longer trusted, what keeps them from creating certificates which claim to be issued before December 1st, even after that date?

Just a guess: In priciple, yes, but it wouldn't be very practial. Because of noise sources on earth, one would need very big antennas pointing to the pulsars to get good s/n ratios. Additionally, as x-rays are blocked by the atmosphere, one would be limited to longer-wavelength pulsars, again increasing the size of the antennas. Given that, using GPS, we already have a positioning system much more accurate, I don't see why one would use pulsars for positioning on earth.

rustc will omit the frame pointer if you add "-C debuginfo=0".

  example::count:
        popcnt  eax, edi
        ret

My reaction when I wanted to searched for a file in a larger github repo, and the search bar was missing: I just cloned the repo and used `git grep` locally.

What's the next step? Cloning only allowed for logged-in users?

And thanks for writing acme-tiny!

It was really easy to setup automatic renewals, running as an ordinary user. sudo access for reloading apache is the only privileged operation necessary. Great job!

According to http://freifunk.net/en/how-to-join/find-your-nearest-communi... there are >15.000 access points, mainly in Germany.

Is there some international equivalent?

Please consider contributing to something like Freifunk, instead: http://freifunk.net/en/

Similar technology (OpenWRT based firmware), easier to use, less privacy issues as it's not necessary to track your network usage. And completely free.

No, you don't:

http://thejh.net/misc/website-terminal-copy-paste

Not loading the firewire driver is not an option, as the attack needs the driver.

I guess loading the driver with DMA disabled would be a good option, as I don't think the attack needs DMA on the host side. Not sure, though, after skimming over the documentation.

"Connect the attacker machine (host) and the victim (target) with a FireWire cable"

What keeps the target from starting an inception attack on the host?

I guess writing a new hard drive firmware from scratch, without inside knowledge, would be close to impossible.

But why start from scratch if you can just modify the existing firmware? And that seems to be perfectly possible: http://spritesmods.com/?art=hddhack

I'd say the most difficult and resource consuming part is to make versions which work on as many brands, models and revisions as possible, and make them all robust enough so they won't be detected because of random malfunctions.

But I don't know anything about hard disk firmwares: Perhaps they are not too diverse and once you know how to modify one drive, the others will follow easily?

The system may only store a hash of the correct password, and then try to brute force it with the entered (slightly wrong) password as a starting point.

This has several advantages: - Nearly as secure as only accepting the correct password (as an attacker could do the brute forcing as well, without help from the system) - Incentive for the user to remember and type the correct password, as logging in with an incorrect password takes longer - After successfully brute forcing the password, the system can remind the user of the correct one - without having to store it!

Of course, this is not without disadvantages: - Much more load on the server, which probably can't be offloaded to the client without leaking the hash. (But perhaps it can, by offloading parts of the calculation to the client, and only doing the final comparison on the server.) - Depends on efficiently generating a list of likely passwords given an imperfect starting point - one needs to develop a model of likely user errors.

Assuming 56 bit passwords, and 2^20 hashes per second, one could try all 4-bit-errors in 9s and all 5-bit-errors in 8min. But 'all possible n-bit errors' is not a realistic measure, as errors wouldn't be random.

56 bit would be about 10 random letters, and e.g. assuming that the only possible errors are omissions of letters, one could forget 3 letters and would still be able to login in about 1 minute. On the other hand, an attacker without any knowledge of the password would need ~2000 CPU years to brute force the password. (Of course the values should be tuned according to the intended security level.)

It seems more interesting to me that Rekdal doesn't cite this article:

http://www.bestthinking.com/articles/science/chemistry/bioch...

It's a 2012 followup by Mike Sutton to the two publications from 2010. It contains many new details, including a reference to Bunge (1892).

Perhaps, one should not only try to cite the original source, but also look for recent research on the same topic?

I guess the original publication which listed the high iron content of spinach was:

Bunge, G.. 'Weitere Untersuchungen über die Aufnahme des Eisens in den Organismus des Säuglings'. Zeitschrift für Physiologische Chemie, 16 (1892)

http://echo.mpiwg-berlin.mpg.de/ECHOdocuView?url=/permanent/...

If that's true, then indeed, it was not a misplaced decimal point. Instead, Bunge listed the iron contents of dried food.