Forgot your password?
typodupeerror

Comment: Re:"Anything more than a runtime and a language" (Score 1) 371

by snemarch (#47636199) Attached to: Oracle Hasn't Killed Java -- But There's Still Time

So now.. who wants to be a Java developer? Its akin to admitting to work for Walmart in the personal hygiene section.

Umm, have anybody (outside insane project like the Danish NemID) been doing applet programming for the last 10 years?

Serverside Java is still pretty strong, and I don't expect it will go away for a long time - and JVM-based stuff will last even longer, unless whOracle manage to screw up bigtime.

Comment: Re:Do we need HTML+Javascript at all? (Score 1) 104

by snemarch (#47386011) Attached to: Famo.us: Do We Really Need Another JavaScript Framework?

How would one go about running a video game on a dumb terminal? Cellular networks don't have enough throughput to support a lot of OnLive/Gaikai style streaming, and plenty of games are too twitch-sensitive for cellular Internet latency to keep the game enjoyable.

"Nobody wants to play those games". Like, nobody would want to play anything with an inferior non-DRM experience. Catch my drift?

Comment: Re:Not Ready Yet... (Score 1) 104

by snemarch (#47385977) Attached to: Famo.us: Do We Really Need Another JavaScript Framework?

Some systems (eg Direct2d) are built on top of 3d graphics stacks, you just have a flat projection and no depth co-ordinates to give the impression of a 2d graphics surface.

Do keep in mind that you're talking about one specific technology stack here.

So you see WebGL is significantly faster than HTML drawing, which is why it might be a good thing overall...

Really? I might be misunderstanding things, but the general browser engine is going to be C/C++ code, whereas all the famo.us stuff will be javascript. Sure thing, JS engines have become a lot more performant lately, but they still don't beat native code.

But sure, if you offer more limited layouting, you might be able to outperform the native browser engines with JS+WebGL. HTML+CSS is a pretty horribly bloated beast.

Comment: Re:Translation (Score 1) 250

by snemarch (#47276261) Attached to: TrueCrypt Author Claims That Forking Is Impossible

Dear sir,

I am interested in learning more about 'Forensic Analysis of Tamagotchi Devices'. Please subscribe me to your newsletter.

I would seriously love to know which value they extracted from grabbing his tamagotchis (and other devices). All in all, my impression is that the Norwegian police gained NOTHING from raiding him (except US-bitch creds), because everything relevant was in the open, anyway. It's been several years since I spoke with Jon, anyway, but he was doing well back then - he moved to the .us and attacked FairPlay. Before that, he had went under hiding to avoid the .no army... dunno how it is now, but back then, to avoid conscription, you had to claim you were homosexual (or at least that's what he told me).

I hope he's doing well nowadays, he was definitely a happy influx in our IRC channels back then :)

Comment: Re:What's hardest, the crypto or the OS integratio (Score 1) 250

by snemarch (#47275177) Attached to: TrueCrypt Author Claims That Forking Is Impossible

Mod parent up - I'm replying here, so can't use mod points :-)

Passing the decryption keys around in BIOS-style boot is somewhat dirty - haven't perused the TC source, so I don't know how they specifically do it, but it'd probably be along the lines of leaving the key at some fixed memory location, and let the Windows boot-time driver read it from there. UEFI drivers have a whole new way of booting the system, so you'd need to adapt to that. It's probably doable, and probably doesn't even need big voodoo - but if you've been working on a codebase for ~10 years, don't need UEFI support yourself, and probably have a family to look after now... it'd be a darn big task implementing. While UEFI stuff can be programmed in C rather than assembly and has SDK and documentation, it's quite a different world.

If we ignore (or postpone) encrypted boot volumes, however, I'm pretty sure that very large parts of the TrueCrypt codebase could be re-used - and at the same time, the really archaic build environment requirements could be dropped.

Comment: Re:Let me attempt to translate for you guys (Score 1) 250

by snemarch (#47275139) Attached to: TrueCrypt Author Claims That Forking Is Impossible

This sounds like over-the-top paranoia to me.

I'm a developer, and I used the phrase "impossible" quite often (though often softening it with "without spending way too much effort"). In the case of TC, I'd be far more inclined to believe that "impossible" either means due to license/copyright issues or because the build process requires really arcane versions of arcane tools rather than it's backdoored all the way to hell.

If anybody worth their salt forked (and audited) the code, they'd find the flaws that aren't deep-math problems in the core crypto code. And it'd probably still be easier to do fork-and-major-cleanup rather than rewrite-with-original-as-base - just look at what the OpenBSD guys are doing wrt. OpenSSL->LibReSSL - rewrite from scratch would likely introduce new security problems, and irregardless of whether you rewrite from scratch or "just" clean up the code, you need to go through every friggin' source file anyway.

Comment: Re:Pissing war (Score 1) 250

by snemarch (#47275025) Attached to: TrueCrypt Author Claims That Forking Is Impossible

The NSA can't force a backdoor without it being instantly obvious. There haven't been any code changes in a very long time and the source code is currently being audited. Any change would be heavily scrutinized.

You're missing the "it was already backdoored" vector, though. I don't personally believe this is the case, but it's a possible scenario - "OK, code audit is ongoing, they'll find it sooner or later, let's bail".

Given their lack of interest in the project it seems unlikely the developers spotted a vulnerability recently and discussed, privately, fixing it, with the NSA intercepting their discussion and demanding they not fix it.

Dunno about "lack of interest" - TrueCrypt is pretty feature-complete. Genuine question: are there any major bugs or lacking features in 7.1a?/

Comment: Re:Secret government pressure? (Score 1) 250

by snemarch (#47274949) Attached to: TrueCrypt Author Claims That Forking Is Impossible

The only thing I would add is that the cease and desist letter would be very illuminating. It would have to give a face to the anonymous developer group, and give New Guys a chance to sink their teeth into that face in court.

Assuming, of course, that the C&D letter comes from the original authors, and not shills set up (and funded by) whatever TLAs.

/me polishes the tin-foil hat :-)

Comment: Re:Translation (Score 0) 250

by snemarch (#47274873) Attached to: TrueCrypt Author Claims That Forking Is Impossible

Seriously, people, save yourself the time. You'll just also get a letter from the NSA and either have to include their backdoor or drop the project.

And I sure as hell don't want to be the one who did the right thing only to see it going to waste because someone else didn't.

Please provide evidence that the NSA had anything to do with TrueCrypt ending development.

Please provide evidence that they didn't :-)

Comment: Re:Translation (Score 1) 250

by snemarch (#47274861) Attached to: TrueCrypt Author Claims That Forking Is Impossible

First of all, there's a source code audit taking place. The source code audit has shown the binaries match the source, eliminating the possibility that the binaries were built with different source.

No, the audit didn't show that - the matching build was done by somebody else. A later goal of the audit project is to produce "repeatable, deterministic build", though.

Second, it's open-source. If a backdoor is put in the code, it would be in the commits.

The backdoors you have to worry about in Real Life isn't of the "if (nsa_are_connecting) { ... }" type - it's very subtle things that look like late-night coding errors, buffer overflows that allow remote code execution, or really obscure mathy stuff in crypto algorithms (like the wonky Dual_EC_DRBG stuff - that required hard math analysis, and wouldn't have been exposed during a code audit). In other words: you wouldn't discover backdoors from commit logs unless you were a world-class programmer and cryptographer, and you did hardcore analysis of all core-crypto related commits.

IMHO, any buffer-overflow or other "ability to run code on target machine" flaws aren't indicative of backdoors, merely human errors, and it's not critical to the security of TrueCrypt (or any other encryption software) - what we need 100% security against is cold attacks on encrypted volumes. Of course other flaws should be fixed, crypt-key material should be burned as soon as not needed, et cetera - but as long as you have an encrypted volume mounted, you are going to have the encryption key loaded in memory, and if anybody is able to execute code with root/admin/ring0/CallItWhatYouWill, they will be able to snatch your encrypion keys, and you're game over.

Comment: Re:Translation (Score 1) 250

by snemarch (#47274677) Attached to: TrueCrypt Author Claims That Forking Is Impossible

Unless the deveopment is done outside of US. Because in that case you can use the letter to wipe your, let's say tears of joy and carry on writing the project. Unless, ofcourse you are planning to visit US any time in the future.

For something as potentially annoying as an opensource, audited, cryptographically (and code-exploitability wise) secure system, do you really believe NSA wouldn't be able to affect people in other countries? Just look at what happened to Jon Lech Johansen when he published the DeCSS code - he was in Norway, did nothing that was illegal according to Norwegian law... yet the .us media industry flexxed their muscles, and his home was raided and all electronic gadgets (including cellphones and a tamagotchi) were raided.

Now, I'm (honestly!) not really sure who are most powerful, the NSA or the .us media industry. But I'd wager that the NSA are willing & capable to do some really nasty things against civilian not-very-well-publicly-known targets.

Comment: Re:wrong (Score 1) 250

by snemarch (#47274535) Attached to: TrueCrypt Author Claims That Forking Is Impossible

BitLocker? Nope, might as well be called BootLicker, given Microsoft's complicity with the federal surveillance apparatus.

I somehow kinda doubt that there's any blatant backdoors or crypto vulnerabilities in BitLocker - it would be very, very stupid of Microsoft to do something like that; there's a lot of eyes on MS, and a lot of people (including very skilled Reverse Engineers) who'd like to see MS burn.

On the other hand, given a Court/NSA order and a target, I'm also pretty sure that there's very easy ways for MS to retrieve crypto keys from a running system and handing them over - complying, but keeping the overall BitLocker integrity intact.

Cold attacks against a powered-down system? I'd actually be surprised. MS have done a lot of evil, but it's evil of a different kind.

Comment: Interesting! (Score 4, Interesting) 50

by snemarch (#47238063) Attached to: <em>OpenXcom</em> 1.0 Released

It's nice to see that there's still people interested in the *original* XCOM games - and not the utter junk that's been released since TFTD.

Some 13 years ago (wow, time flies), I was delighted to see a Windows re-release of the XCOM games (the "Collectors Edition"), since the DOS version was indeed pretty troublesome to get running under Windows - this was before the luxury of DOSBox. However, the fine developers who did the port didn't know the difference between "pitch" and "width", and thus it was unplayable (on a wide range of graphics cards, apparently). I was put down by this, but my friend who was visiting that evening said "well, you usually fix... bugs... in programs, so can't you fix this?".

One frantic night of reverse engineering and beer-drinking and reminiscing about chryssalids and tentaculats laters, I had a bugfix loader running. XCOM once again! The CE port in general wasn't perfect, the XCOM1 intro only had MIDI music but not the muton screams and other sound effects, there were stall-for-a-second issues when changing soundtrack on many soundcards, et cetera.

When XCOM1+2 were re-released on STEAM, they initially used my bugfix loaders (I'm told they use DOSBox nowadays - that's a more authentic experience). Didn't even contact me about it. When I reached out to the people in charge (took a while, the rights to the brand had been shifted around quite a bit), I was told that the source code no longer existed - apparently, at the end of days, it had existed on a single laptop that had been stolen or destroyed or whatever.

So, with the above in mind, it's nice to see that people are trying to re-create the legacy of one of the best games I've ever spent countless hours with.

There are running jobs. Why don't you go chase them?

Working...