| Summary: | VeraCrypt 1.0f-2 : compilation error | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Paul Brissaud <paul.brissaud> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | 5 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | VeraCrypt | CVE: | |
| Status comment: | |||
Apparently this because of a data type mismatch caused by UTF-8 being enabled in our wxgtk build. We just fixed a similar problem in Filezilla by getting a patch from upstream. Maybe you could ask upstream to fix VeraCrypt in the same way? Here is the VeraCryt team's answer to this proposal : "Unfortunately, the modification you have done changes the expected behavior since we need to access the internal characters of the password in order to erase them for security purpose. So, even if it compiles, it doesn't do what is supposed to do since we expect wxWidgets strings to use UTF-16 UNICODE (wchar_t) and not UTF-8 (char*). Until Mageia remove the utf8 switch from their build, the only solution is to build your own static wxWidgets library and link VeraCrypt against it: actually, this is how VeraCrypt is built and the official build scripts do just that." So "utf-8 being disabled in the wxgtk building" seems to be the best solution. I haven't looked at the code so I might be wrong, but this looks like a lazy answer. It's perfectly possible to build software that works both with utf-8 and utf-16. You just have to take care to not make wrong assumptions. There's probably a way to patch that properly, unless the code is too messy. I think Samuel's right, I see no obvious reason why VeraCrypt couldn't do the correct thing regardless of the character data type. However, when this question was raised in the past, I figured --enable-utf8 enabled UTF-8 in lieu of just using old fashioned 8-bit ASCII (with character encodings like iso8859-1), but it sounds like it's actually enabling UTF-8 in lieu of a default UTF-16. So it seems less likely to me that having this build option was correct and that we probably should remove it. Does anyone know of any potential problem with using UTF-16? Yes, Samuel is right. I made a quick patch in a hurry in order to get VeraCrypt working immediately. It doesn't suit to VeraCrypt for security reason. The real question deals with the use of '--enabled-utf8' within wxGTK. I can't answer David's question, not able to analyse the entire scope of the use of utf-16 instead of utf-8 within wxGTK. (for example, using playonlinux with utf-8 removed in wxGTK we can read : ImportError: /usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/_core_.so: symbol wxLocaleIsUtf8, version WXU_3.0 not defined in file libwx_baseu-3.0.so.0 with link time reference) Thanks for that information Paul. So it sounds like if this change is made, everything linked against wxgtk will need to be rebuilt. That would be: Source RPM : aegisub-3.2.2-1.mga5.src.rpm Source RPM : ariamaestosa-1.4.10-3.mga5.src.rpm Source RPM : filezilla-3.10.2-1.mga5.src.rpm Source RPM : freedink-dfarc-3.12-1.mga5.src.rpm Source RPM : freedv-0.97.0-1.mga5.src.rpm Source RPM : freefilesync-6.2-4.mga5.src.rpm Source RPM : golly-2.4-10.mga5.src.rpm Source RPM : hugin-2014.0.0-0.rc4.5.mga5.src.rpm Source RPM : megaglest-3.11.1-1.mga5.src.rpm Source RPM : mkvtoolnix-7.6.0-1.mga5.src.rpm Source RPM : openbabel-2.3.2-10.mga5.src.rpm Source RPM : plplot-5.10.0-10.mga5.src.rpm Source RPM : poedit-1.6.9-3.mga5.src.rpm Source RPM : springlobby-0.180-4.mga5.src.rpm Source RPM : tintii-2.9.0-5.mga5.src.rpm Source RPM : urbanlightscape-1.3.3-5.mga5.src.rpm Source RPM : wxhexeditor-0.22-5.mga5.src.rpm Source RPM : wxmaxima-14.12.1-1.mga5.src.rpm Source RPM : wxPython-3.0.1.1-1.mga5.src.rpm |
Hi, While trying to build veracrypt_1.0f-2 within Mageia 5 environment (gcc 4.9.2, libwxgtku3.0-devel 3.0.2) on a 32bits linux host, the following error occurs during compilation of TextUserInterface.cpp : Compiling TextUserInterface.cpp TextUserInterface.h: In member function âvirtual VeraCrypt::SharedPtr<VeraCrypt::VolumePassword> VeraCrypt::TextUserInterface::AskPassword(const wxString&, bool) constâ: TextUserInterface.h:174:49: erreur: invalid const_cast from type âconst wxScopedWCharBuffer {aka const wxScopedCharTypeBuffer<wchar_t>}â to type âwchar_t*â Let see file src/Main/TextUserInterface.cpp at line 119 : const_cast <wchar_t *> (passwordStr.wc_str())[i] = L'X'; My theory is that Mageia 5 refuses to compile an instruction containing two conversions in one. The line above tries to operate an explicit and a cv-qualification conversion. So, in order to get a working compilation, I tried to separate the two conversions like this : const wchar_t *temp = passwordStr.wc_str(); // explicite conversion const_cast <wchar_t *> (temp)[i] = L'X'; // cv-qualification conversion Then compilation works and it seems that VeraCrypt works fine too. I hope not to create a security gap. Best regards Paul Brissaud Reproducible: Steps to Reproduce: