xorbyte

Wallbleed, a buffer over-read vulnerability that existed in the DNS injection subsystem of the Great Firewall of China. Wallbleed caused certain nation-wide censorship middleboxes to reveal up to 125 bytes of their memory when censoring a crafted DNS query. It afforded a rare insight into one of the Great Firewall’s well-known network attacks, namely DNS injection, in terms of its internal architecture and the censor’s operational behaviors.

If he doesn't like your site, he may not allow you to use his service, which is something the TOS already cover.

Over time, such capricious terminations could lead to the Board seeking action against the CEO, depending on the impact to the business.

macOS and iOS don't support OpenVPN with the built-in client. You can use strongSwan-based VPNs (e.g., as would be deployed through Algo) or Cisco, but for OpenVPN you'll need a custom client which, unfortunately, very likely brings along its own .kext.

I think you may be confusing deterministic reproducible builds (that remove randomness and ensure binaries have the same content hash regardless of who builds them (so you can reproduce what the maintainers did and verify the source and binaries) to merely a repro'd environment where everything still works because deps are included, which seems to be all that Nix promises (and in fact there is at least one open issue to add full deterministic builds to Nix https://github.com/NixOS/nixpkgs/issues/9731 )

Not all tonic water is low cal, a 350 mL bottle can be 100 calories from the 30g of sugar added.

Any comparatively large corporation very likely has a release process for these sorts of things where a bunch of groups (like PR, maybe Legal etc) would take a look. Releasing company IP as open source outside of such a process would be a gross violation of any number of non-disclosure agreements between employer and employee.

Back issues are always included in the current issue, hence the zip. Keep recursing that way (or use binwalk)

There's nothing in the OPs post suggesting SSH was exposed to the public, or that the breach happened over SSH. So it's important to secure that, but it's also important to think holistically about the attack surface.

You assume the breach happened over SSH. This is valuable information to securing SSH, but it's entirely possible the original breach happened over some other service, and there were some other steps involved in the breach before the SSH screenshot was taken.

The article makes no mention of TLS anywhere, and the example endpoints are all HTTP. So, this is a thoroughly insecure implementation, relying on very weak security mechanisms, prone to straightforward interception and tampering, replay etc.

Wouldn't that just be regular Xen?

Not sure how you see progress and innovation otherwise. Much of what is good in Linux comes from experimentation and people/distros 'doing their own thing' which sometime improved the ecosystem, and sometimes resulted in abandoned projects. But things have not stagnated.

As for UNIX, perhaps you're familiar with Plan 9? Some of the principal UNIX designers were unhappy with the result, so they went and worked on improving it. Nothing is good enough the first time around.

Similarly echoed in the OpenWRT talk from 30C3 https://www.youtube.com/watch?v=Y-OlUxeS57E

No, I think this means PayPal recognizes tptacek's CCs and forces a log in. Even with a new card, perhaps they'll just base it on the name and refuse to process it without an account login.

OTR is only used in one-on-one communications in CC; group chat mechanisms are custom, and may now converge towards the mpOTR draft but that's still a pretty big risk.

Much of Jacob's presentation echoes many of the articles he (and others) had published in Der Spiegel earlier that day, going into a little more into the technical aspects (to the extent they are known and/or can be inferred.) While you may skip out the talk, at least look over the articles. While Jacob's style may rub you wrong, the issues are there regardless, and impatience is hardly a justifiable excuse.

On another note, if you are aware of Jacob misleading on any matter, it would be nice pointing that out directly. He is an activist that has done everything from helping with on-the-ground infrastructure deployments in war-torn areas, working on and advocating for Tor, speaking in front of the EU council… Casting doubt on his integrity without highlighting relevant facts is a way of distracting from the actual issues under discussion.

Look if anyone in your institution has created a dissertation template for LaTeX, or if you can use one [from elsewhere](https://github.com/briandealwis/ubcdiss). I personally found the formatting to be the hardest part, not the actual writing, especially since you can find helpers for various text editors, like LaTeXTools for Sublime etc.

As pointed out elsewhere in this thread, don't make your hammer solve all of the problems.

MultiMarkdown might be more suitable for large documents, as it allows the inclusion of files between documents, cross-references etc.

But ECB for media is particularly egregious, particularly since even the Wikipedia page on ECB shows how remarkably 'visible' large things encrypted with ECB are.

Would this legal around the world? AFAIK Canada and probably parts of the US don't allow wearing bulletproof vests, and while a suit might be harder to identify as such, I'm wondering if it's still problematic.

von Neumann is 'skirt chasing' but Curie is 'slutty'?

The previous hackathon was near Zurich https://whispersystems.org/blog/hackathon-zurich/, so it's certainly not out of the question it will be outside of the US again, some time in the future.

It seems to still do that, however I have not had any problems installing gpg2 via homebrew and overwriting the destination binary, e.g.,

    brew link gpg2 --overwrite

(use the above with `--dry-run` first; I only have one symlink that gets overwritten, but you may have more.)

Hushmail implements GPG, though perhaps it does not pass your definition of 'popular'.

Any current implementation of GPG by _web email_ is probably insecure as it would rely on JavaScript cryptography. Perhaps when the W3C passes the browser cryptography draft, and browsers start adding that in, we might see this. But the economics aren't aligned, because popular web email services want to see what you read and write, so they're not particularly motivated to give you strong encryption.

FWIW, someone on Crypto.SE reached out and received comments from DWave stating that it's not a problem in the foreseeable future.

http://crypto.stackexchange.com/a/439

This depends on intent. I don't want to confound exploration with activism, but there are many instances where damaging a company may be the ethical thing to do.

In the long run, avoiding damage is in the hacker's continued interest to be able to maintain a 'beachhead' through stealth; but where privacy and 'fairness' are concerned, avoiding damage isn't always desirable.

A CS degree has no bearing on one's ability to 'ship software', since that's not what a CS degree is meant for. I see a lot of disappointed second-years want to be taught how to better write software, but they're in a CS degree because it carries higher prestige than a diploma from a technical institute (at least here in Western Canada, and probably elsewhere, but not everywhere)

It would be great if more people understood how the two are different, it would save everyone a lot of headaches and ensure energy is spent where most valuable.