I have an implementation of SSL handshake from the client side, by using these functions:
SSL_CTX_load_verify_locations
SSL_CTX_use_certificate_chain_file
SSL_CTX_use_PrivateKey_file
All functions get char* type for the filename parameter.
How can I change it to support also unicode file locations?
Thanks!
On which platform? OpenSSL under Posix supports UTF-8 paths, but not on other platforms. Chances are, you will have to manually load the certificate files yourself using standard OS file I/O functions that support Unicode paths, and then parse the raw data and load it into OpenSSL, such as via PEM_read_bio_X509 with sk_X509_NAME_push, PEM_read_bio_PrivateKey/d2i_PrivateKey_bio with SSL_CTX_use_PrivateKey, d2i_X509_bio/PEM_read_bio_X509 with SSL_CTX_use_certificate, etc.
I want to reply to the above post instead of creating a new answer, however I was not able to reply it, so I create a new answer. Based on my testing for SSL_CTX_load_verify_locations and looking at openssl code, actually the openssl would use utf-8 for file path as well on Windows. At the function BIO_new_file to open a file, it would choose utf-8 for file path if both _WIN32 and CP_UTF8 are defined. Those are defined at windows. However openssl also has code to fall back to ANSI path if path is not a valid utf-8 characters. So with that, actually openssl will work with both utf-8 and ANSI path on Windows.
Related
I have some third party application that I have to use, it generates UTF16LE encoded json files.
When I put these manually on my server and try haxe generated php to parse these files, it refuses. It seems it can't detect and convert to the encoding haxe php accepts.
I don't know where to start. Converting it on the client is an impossibility, there are too many of such files and need too frequently be parsed. So I have to use php. It would be nice if haxe has a way to convert it to the encoding it accepts. I have tried RTFM, but I so far I havent found anything that says haxe can convert it. Before I start reinventing some second wheel, I rather make sure there isn't some obvious way to it with haxe.
I am using Haxe version 4.2.1+bf9ff69
What am I overlooking? Is haxe php able to solve this, or is going native php the only option?
== SOLVED ==
As these json files do not need any emoticon support or whatever characters for non-english language, my solution was to strip everything except basic printable ASCII characters.
import sys.io.File;
import php.Syntax;
// some function body
return Syntax.code('preg_replace( "/[^[:print:]]/", "",{0})',File.getContent(_path));
I couldn't share these file on the web, because of privacy concerns. Also I discovered these files had ... wait for it - double BOM's- hacked into it.The BOM detector I threw in reported the first BOM it found happening to be UTF16LE.
Enterprise spaghetti monster probably the reason. Thought I had seen it all, but with that, one probably can't never have seen it all. The wonders of human ingenuity.
Just a blunt strip instead of making my own ludicrous code to unfudge that stuff and justice served. Hurrah.
I would like to convert AES128 encrypted text into base64 encoding using boringssl in android. I am using functions like "BIO_new(BIO_f_base64());" to accomplish this. The compile process fails saying undefined reference to 'BIO_f_base64()'.
On further debugging I found out that while this works with openssl it wont work with boringssl since the function is deprecated.
Below is a piece of code showing base64 encoding (this works perfectly fine with openssl):
BIO *bio, *b64;
BUF_MEM *bufferPtr;
b64 = BIO_new(BIO_f_base64());
bio = BIO_new(BIO_s_mem());
bio = BIO_push(b64, bio);
BIO_set_flags(bio, BIO_FLAGS_BASE64_NO_NL);
BIO_write(bio, buffer, length);
BIO_flush(bio);
BIO_get_mem_ptr(bio, &bufferPtr);
BIO_set_close(bio, BIO_NOCLOSE);
BIO_free_all(bio);
*b64text=(*bufferPtr).data;
return (0); //success
BoringSSl contains a seperate directory for deprecated functions wherein 'BIO_f_base64()' is defined. How may I use this ?
For me it was enough to include src/decrepit/bio/base64_bio.c in the build.
Note: I won't vouch for the security of using anything other than the default BoringSSL build :)
I'm trying to get the file extension for the valid "audio/wav" mime type.
Using this code
MimeTypes mimeTypes = TikaConfig.getDefaultConfig().getMimeRepository();
String extension = mimeTypes.getDefaultMimeTypes().forName("audio/wav").getExtension();
The extension I get is the empty string.
However, using the "audio/x-wav" extension works.
Is this the expected behavior?
TL; DR
Yes, this is the expected behavior.
x- MIME subtypes are usually for formats which are not yet standardized. The MIME types corresponding to WAV format are audio/vnd.wave, audio/wav, audio/wave, audio/x-wav (see here). Some browsers accept more or less MIME types. Apache servers usually send WAV as x-wav, even though I don't know why.
The official MIME type is now audio/vnd.wave, so you might try it and see if it works.
Sources: here
This is a bug in older versions of Tika.
You need to use a newer version of Apache Tika to get the correct behaviour. (1.15.1 or 1.16 should do it). As taken from the tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java unit test:
assertType("audio/vnd.wave", "testWAV.wav");
(That unit test verifies that the official mime type is the one detected, other aliases like audio/wav will generally be transparently mapped onto the canonical one)
Alternately, if you're stuck on an old Tika version, you should largely be OK to swap out the tika-mimetypes.xml file for the latest version, though if you're swapping it out in an much older version of Tika it's best to re-run the unit tests to ensure you haven't broken anything in the process!
I have a few questions on zlib module, to be used with files under 40MB:
What kind of options should be used in zlib.gzipSync() for fastest zipping (compression level does not matter)?
Which default values is used, if options is not passed to the method?
Is this method returns Buffer?
What kind of extension and mime type should be used for final result?
Update: How to pass a file name? (So after unzipping file has name and extension)
Asked because reference is not expressive.
Yeah, not much to go on in that documentation.
I recommend that you look at the zlib manual (the zlib.h source file) for information on the noted parameters and operations.
The fastest compression would be level 1.
The default compression level is 6. Other defaults can be found in zlib.h.
There does not appear to be an interface to deflateSetHeader(), which would be required to insert a file name in a gzip header.
The docs describe the options object used for every zlib call. They also point you to the zlib manual which describes those options in great detail.
The fastest level is 0, which means no compression. However, this would be silly, since you may as well skip gzipping altogether. 1 means "some compression with best speed."
That said, don't use gzipSync. We don't do things synchronously in node. If you're looking to write the compressed data to a file, do:
var compressor = zlib.createGzip({level: 1});
compressor.pipe(fs.createWriteStream('output.gz'));
compressor.end(inputData);
I need the source code of the OpenSSL API functions for EVP encryption, like EVP_aes_256_cbc. After much searching, all I could find were the headers of the functions in openssl/evp.h, but no source code in a .c file.
Where can I find the source code?
You'll find the final CBC mode implementation in cbc128.c and AES itself in AES.c. Mind that the EVP are high level functions that could use an engine - for instance using a hardware module (HSM) - or AES-NI CPU instructions instead. Searching for a single source file is therefore bunk.
I need the source code of openssl api functions evp encription... "EVP_AES_256_CBC"...
There is no function EVP_AES_256_CBC:
$ cd openssl-1.0.1g
$ grep -R EVP_AES_256_CBC *
$
So searching for it should turn up no results.
where can I find the source code
As user3553031 pointed out, you can get the source code for OpenSSL at OpenSSL: Source, Tarballs.
What do you really want?