TrueCrypt suggesting migration to BitLocker?

Re:TrueCrypt suggesting migration to BitLocker? by toyg on Wednesday May 28, 2014 @06:46PM (#7813453)

Interestingly, an Infoworld review of the recent TrueCrypt audit [1] says: "One major issue was how compiling TrueCrypt from source required the use of an older Windows build environment that's noticeably out of date [...] using a shockingly old version of Microsoft Visual C++ released in 1993."

Align this with what the TC website says now: "development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP."

Could it be that the original developer is somehow unable to update the build process to work on newer OSes, or unwilling to do so? Maybe they don't trust any VC++ released after 1993, and that version is probably not going to work on Windows 7 or 8.

[1] http://www.infoworld.com/t/encryption/sloppy-secure-open-sou...

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by Alupis on Wednesday May 28, 2014 @06:48PM (#7813468)

I would be absolutely shocked if there was some reason any VC++ lib would not install on any modern Windows OS.

Microsoft has many faults, but backwards compatibility is not one of them.

I doubt this would be the reason. (Also, TrueCrypt runs on OSX and Linux too, so a build environment dependent on Windows-only seems odd).

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by A_Non_eMouse on Wednesday May 28, 2014 @08:42PM (#7813945)

The version of MSVC needed is 1.52c, which was 16-bit, and was the last version able to create 16-bit binaries. It was likely needed for building the bootloader. (Why this couldn't be moved over to a FOSS compiler, I don't know.)

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by Canada on Wednesday May 28, 2014 @08:28PM (#7813905)

VC++ 1.52 is required to build the boot loader. You can still download it from MSDN. I can see why they would have an "if it ain't broke, don't fix it" attitude there.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by A_Non_eMouse on Wednesday May 28, 2014 @08:46PM (#7813955)

But, being a 16-bit program, it won't run on 64-bit windows. I'm not even sure it would install properly on anything newer than XP. I haven't tried installing it since the 9x days.

There are several things MS has released that don't install on newer systems very well. There are some where the installer depends on an old version of Internet Explorer being installed and which fail miserably on newer versions.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by jlawer on Wednesday May 28, 2014 @09:48PM (#7814192)

Its a boot loader, It runs while the system is in real mode (16bit), before windows itself has booted.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by taspeotis on Wednesday May 28, 2014 @10:49PM (#7814442)

The compiler is 16-bit [1]. It won't run on 64-bit Windows.

So if you have a Windows-based build server, it's probably running Windows Server 2008 or later. Which is 64-bit only.

You can run it on a recent 32-bit version of Windows, but client editions only.

And in the next year or two I imagine Windows 9 or 10 going exclusively x64/ARM.

[1] http://en.wikipedia.org/wiki/Visual_C%2B%2B

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by A_Non_eMouse on Wednesday May 28, 2014 @11:21PM (#7814516)

I meant MSVC 1.52c is 16-bit.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by Canada on Friday May 30, 2014 @04:22PM (#7823821)

I build my own TrueCrypt binaries on my 64bit Windows 7 box.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by Shorel on Thursday May 29, 2014 @08:56AM (#7815956)

Yesterday my Windows XP virtual machine killed itself after a Software Update related to Malware Protection Center.

I will try to reinstall it today, and have VS 2008 running inside.

[ Parent | on HN ]

Re:TrueCrypt suggesting migration to BitLocker? by rflig on Thursday May 29, 2014 @03:41AM (#7815177)

Nothing kept them from having an XP (VM) offline just for compilation. It was best practice for security related products (actually for any development) to develop and compile offline anyway.

[ Parent | on HN ]