DSO missing from command line truecrypt

[stevepusser]

good info yea I'm working on handbrake for now I'm making progress with it. I wonder if there is a way to send it to the official repository for debian so other users will be able to have the newest handbrake available for jessie.That's a good idea about finding the bug fix and copying it to truecrypt source that's an option. And I've compiled debianized source before and your right it is way easier.

Debian packaging has a lot of policy requirements--one is to use the system libraries as far as possible, instead of building against the internal versions in the source. For example, this would mean building against the libav* -dev packages found in Debian instead of the internal libav supplied (downloaded by) in Handbrake. And I believe Debian also removes some code from the source because it violates the Debian free software guidelines or is unecessary.

Also, the handbrake source downloads some other source from the Net as part of the build process, which is against policy. Debian adds those files to the source tarball and disables the download, which is why the Debian upstream versions have "ds" added to the version.

[tomazzi]

...Also for those asking if i want to use veracrypt no thanks truecrypt's source is the only os crypto product that i know of thats been audited.

The status is: Truecrypt v7.1a sources are *NOT* compatible with Debian Jessie (but also most likely with other distributions)
Reason: To compile this version of truecrypt, the sources has to be modified in a way, which is reducing the reliability of the code: namely, f.e. in the file Common/SecurityToken.cpp the lines 660 and 661 have to be commented-out, but this is only a tip of the iceberg, as there are more problems:
AES encryption is broken: the author didn't take care of explicit initialization of some crucial variables, what results in tens of warnings regarding the AES code (not just false positives - they are really a threat).

The author knows crap about building executables for MAC OS/Linux - the makefile was most probably tested only on his own PC - it needs several modifications to work on "supposedly supported" target systems.

I've stopped my tries after satisfying the following dependancies:
libp11-kit-dev
libfuse-dev
nasm

After those packages are installed, only the internal bugs in truecrypt are preventing successful compilation...

Regards.

[lilDebbie]

do you think you could show me the log or logs of when you tried too compile truecrypt? I'm interested in seeing what your talking about and how the compile went for you

[stevepusser]

So...Veracrypt, which seems to have fixed those bugs, right? I don't know diddly about the actual coding, but would be interested if you gave the relevant parts of the veracrypt source a glance to see if they know what they're doing.

Oddly enough, I can build Veracypt on a wheezy plus wheezy-backports 32-bit virtual machine, too, but something in the same 64-bit VM setup causes the whole VM to lockup during a build. I'll see if the same thing happens on another 64-bit gcc machine--it may just be incompatible with the 64-bit gcc-4.7 in Wheezy:

Code: Select all

g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.

[lilDebbie]

good info yea I'm working on handbrake for now I'm making progress with it. I wonder if there is a way to send it to the official repository for debian so other users will be able to have the newest handbrake available for jessie.That's a good idea about finding the bug fix and copying it to truecrypt source that's an option. And I've compiled debianized source before and your right it is way easier.

Debian packaging has a lot of policy requirements--one is to use the system libraries as far as possible, instead of building against the internal versions in the source. For example, this would mean building against the ffmpeg -dev packages in jessie-backports instead of the internal ffmpeg supplied in Handbrake. And I believe Debian also removes some code from the source because it violates the Debian free software guidelines.

Also, the handbrake source downloads some other source from the Net as part of the build process, which is against policy. Debian adds those files to the source tarball and disables the download, which is why the Debian upstream versions have "ds" added to the version.

yea no wonder there's mostly older version's of stuff like handbrake and other software on there repos

[stevepusser]

OK, I managed to get Jessie Handbrake 10.3 packages that also meet Debian policy by reusing the 10.2 /debian folder, refreshing most of the patches in debian/patches so they applied to the changes in the source code, and yoinking a patch from the deb-multimedia /debian folder to address a code error that created an FTBFS (failure to build from source, learn that acronym, kids )

https://drive.google.com/file/d/0BxE7wb ... sp=sharing

If you want to install the packages as is, you'll also need to install libx265-59 from jessie-backports.

To build as is from the debianized source, you'll need libx265-dev from jessie-backports, the rest of the build-depends are found in the jessie main repository.

There's a way to disable the need for x265 if you do your own build, but it involves editing some files in /debian, so I leave that as an exercise for the interested.

yea no wonder there's mostly older version's of stuff like handbrake and other software on there repos

If you're talking about Debian stable, there won't be hardly any new versions of software in the main repo; those will only be found in jessie-backports (or other backporter's repositories )

Heh---if you want a real freaking headache, try and compile Pale Moon from their source code per the instructions they provide!

[lilDebbie]

I actually started looking into veracrypt and found this post
val (val) 2014-07-02 21:02:16 UTC #17

I question the effectiveness of VeraCrypt. The current linux install for it changes the user and group ownership of critical system directories, including /usr to "500" (the proper ownership for that directory is root:root and should not have been touched by the installer). Surely it is a bug, but such a glaring bug that seriously compromises the integrity of the filesystem is a clear indication that there's something wrong with quality control on that project.

val (val) 2014-07-03 01:36:25 UTC #19
It was not inherited from Truecrypt. The bug is unique to Veracrypt. By changing the owner and group ownership of various critical system directories, installing veracrypt on linux breaks a variety of unrelated software that are expecting sane ownership of those directories (virtualbox for example). Nothing should be changing permissions of your directories without letting you know. This is a fairly serious bug and reason enough not to trust that team. In this instance, Veracrypt surreptitiously changed the ownership and group ownership of system directories to something that doesn't make any sense; what else might it accidentally do without telling you in the future? This doesn't leave me with a good feeling about that project. Pushing out a product with some bugs is one thing, pushing out a product that breaks your system is quite another.
Go ahead and install veracrypt on a linux VM to see what I mean. I've only tested the 64 bit gui installer, so try that one first. Perhaps not all of the other installers are broken, but that one is.

The whole post and the response from mounir (Lead Dev) is at this link below
https://forum.truecrypt.ch/t/why-not-veracrypt/133



I don't know what there policy is for commits but ciphershed actually has a review team that thoroughly reviews code before any commits but are painfully slow at rolling things out because there taking there time and being thorough.. I think it's strange veracrypt project started just before the truecrypt team quit which is suspect to me maybe I'm paranoid idk. Veracrypt is located in france and there lead dev is very skilled if that's what your asking but idk how good there review policy is and that's what worry's me. Not only this but google researchers found these bugs in truecrypt's code CVE-2015-7358 and CVE-2015-7359 and it affected veracrypt as well but truecrypt just got a "professional audit and somehow missed this very serious bug. What else could they have missed? anyways i'm going to bed i'll look at the handbrake thing tomorrow

[tomazzi]

do you think you could show me the log or logs of when you tried too compile truecrypt? I'm interested in seeing what your talking about and how the compile went for you

I'm not keeping such things, especially that it was just a quick test.
However the logs are easily reproducible, so You can generate them on Your machine.

Besides installing the packages, one more thing needs to be changed:
/Common/SecurityToken.h.43: #include <p11-kit-1/p11-kit/pkcs11.h>

Regards.

[lilDebbie]

OK, I managed to get Jessie Handbrake 10.3 packages that also meet Debian policy by reusing the 10.2 /debian folder, refreshing most of the patches in debian/patches so they applied to the changes in the source code, and yoinking a patch from the deb-multimedia /debian folder to address a code error that created an FTBFS (failure to build from source, learn that acronym, kids )

https://drive.google.com/file/d/0BxE7wb ... sp=sharing

If you want to install the packages as is, you'll also need to install libx265-59 from jessie-backports.

To build as is from the debianized source, you'll need libx265-dev from jessie-backports, the rest of the build-depends are found in the jessie main repository.

There's a way to disable the need for x265 if you do your own build, but it involves editing some files in /debian, so I leave that as an exercise for the interested.

yea no wonder there's mostly older version's of stuff like handbrake and other software on there repos

If you're talking about Debian stable, there won't be hardly any new versions of software in the main repo; those will only be found in jessie-backports (or other backporter's repositories )

Heh---if you want a real freaking headache, try and compile Pale Moon from their source code per the instructions they provide!

Damn your good lol so if i build the default handbrake source as-is without adding any extra options by just doing ../configure in the build folder i create and then make it will include x265? I guess im wondering whether you have to include any options for it to compile with x265 or if HB does it by default. I went and downloaded the x265 libs from jessie-backport thanks to your advice I'm new to debian so that deff helps having that repo at my disposal. If you want to elaborate what options you used while compiling that version I'd like to know?

[stevepusser]

Well, if you follow my recipe for building the debianized source code, that's all handled automagically by the packaging process. Most of the time, the non-default configuration options are in the /debian/rules file, so in Handbrake's case, these lines in that rules file:

Code: Select all

LDFLAGS += -Wl,-z,defs -Wl,--as-needed

override_dh_auto_configure:
	./configure --prefix=/usr --build build --debug=std \
		--disable-fdk-aac \
		--enable-x265 \
		--disable-gtk-update-checks \
		CC="$(CC)" CXX="$(CXX)" \
		CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)"

would translate to this configure command line in the manual compile and install process:

Code: Select all

./configure --prefix=/usr --build build --debug=std --disable-fdk-aac --enable-x265 --disable-gtk-update-checks  LDFLAGS=-Wl,-z,defs -Wl,--as-needed

Though I strongly urge you to build proper deb packages via the recipe. I feel like a doctor asked for advice on how to treat a fever with bloodletting by someone who rejects modern, proven treatments, you know...Did you ever read this?

Re: wine

Did you know that the Wine folks at winehq.org maintain a repo with the latest wine-devel and wine-staging packages? The wine-staging folks also maintain their own Debian repo: https://github.com/wine-compholio/wine- ... stretchsid

Though when we rebuild wine-staging for the MX 15 repo, we add a couple small improvements.

[lilDebbie]

I feel like a doctor asked for advice on how to treat a fever with bloodletting by someone who rejects modern, proven treatments, you know...

HAHA! I'm sorry that was funny yea i honestly didn't know that building debian packages was that much of an advantage i bookmarked that link and will start doing that from now on so thank you for such sound advice thus far that was deff an interesting read you've convinced me. I'll also add the wine and mx-15 repo as well so thank you for all the great information. I'm going too download your version as well and try to replicate it just to learn more about the process, I just like experimenting with builds. You should give that handbrake build you did to the official repo team and see if they would take it you did great work on that.

[stevepusser]

Just a followup to Veracrypt; I noticed that an icon was not showing up in its menu entry, due to a packaging bug, so fixed that, along with modernizing the debian/rules file to fit the current trend. I have the source and packages here for a bit, until they get into the MX 15 test repo.

https://drive.google.com/file/d/0BxE7wb ... sp=sharing

[lilDebbie]

Thanks I actually just got done compiling veracrypt and they did fix whatever bug was in truecrypt because i was able to use wxwidgets3 with no errors so at least they fixed that I'm still gonna look into the differences between veracrypt and ciphershed tho I'm still undecided on which one is the better fork. I've looked into veracrypt and there lead dev is deff talented i wanna see what's up with ciphershed now. I honestly think they should be combining forces and sharing code and implementing things together it would be more effective. What do you think?

[stevepusser]

I wish a lot of projects would combine forces, but I guess people have their own visions and conflicts. The libav and ffmpeg split is a famous example, though ffmpeg does engulf all the libav work without shame.

Most of that veracrypt package is a PDF user guide, BTW.

Did you ever try Handbrake 10.3? I just want to make sure it does not blow up.

[lilDebbie]

yea i did i was missing some library that wasn't in the directions or maybe it was but had a diff name but yea it works flawlessly once i got it compiled and installed i can't remember the exaxt name of the lib but it was giving me a libmp3lame error while compiling. but i never got around to making it a deb package i was in a hurry to encode some movies so i could play them on the xbox one. but make install gave me no problems.

[stevepusser]

You were probably missing libmp3lame-dev. It's probably considered optional because almost nobody encodes video now with that codec for the audio track. I don't see it listed in the official online instructions: https://trac.handbrake.fr/wiki/CompileOnLinux