On Wednesday 07 June 2017 14:06:42 Ted Unangst wrote: > Jonathan Gray wrote: > > when using a server.key with a passphrase, ie > > > > > > ) at /usr/src/lib/libc/stdio/fopen.c:54 > > #3 0x0000022b2d92d26f in open_console (ui=Variable "ui" is not available. > > ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304 > > > > #6 0x0000022b2d9dc018 in PEM_def_callback > > ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113 > > > > #10 0x0000022b6ef43b62 in tls_configure_ssl_keypair > > ugh, i think this is a bug in libtls. there should not be sneaky bullshit > console reading functions being called behind the scenes. this is, as > discovered, kind of surprising. and quite the layering violation, separation > of concerns, and all that.
Yes, it is a bug in libtls, however it is moreso a bug in libcrypto - that's what is trying to gain a passphrase via the console/stdin. We can hack around it and disable it in libtls. > a sane API would look something like this: > > tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how > to proceed, possibly asking for password, calls > tls_configure_keypair_this_time_with_password(). I'm not sure that I'd consider that sane. We already have tls_load_file() for this purpose, although admittedly the API there could probably be friendlier. Do we really want tls_configure_keypair() to become "maybe encrypted, maybe unencrypted"? I'm not convinced that we should really be making libtls expect to be dealing with encrypted keys at that point.
