Opened 7 years ago

Last modified 3 years ago

#15172 new enhancement

Windows: Schannel based SSL/TLS implementation

Reported by: mback2k Owned by:
Milestone: Component: libpurple
Version: Keywords: ssl tls win32
Cc:

Description

Hello everyone,

I am the original author of the new Schannel based SSL/TLS implementation for libcurl.

I would like to propose adding Schannel support to libpurple, too. And therefore I am opening this ticket in order to track the progress on such an implementation which could be picked up by everyone. I might have the time to do it myself, but just in case someone else wants to join in on this, I would welcome him or her.

But before any code is written, I would like to ask whether the pidgin/libpurple developers would actually like to see such an implementation or not. I would appreciate any feedback on this part.

Thanks in advance!

Best regards, Marc

Change History (9)

comment:1 Changed 7 years ago by datallah

Sure! If this can be used to eliminate a third party dependency, as long as it is functionally equivalent, this sounds like good thing.

comment:2 Changed 7 years ago by rekkanoryo

I would absolutely love to see a solution that uses Windows' native SSL/TLS facilities, especially if it lets us do all the same stuff we already do like validating the certificate chain and whatnot.

comment:3 Changed 7 years ago by mback2k

Great! Sorry, I haven't responded earlier since I didn't receive email notifications about your replies.

@datallah: Yes, the OpenSSL dependency could be eliminated on Windows. @rekkanoryo: Yes, using the Windows Schannel API allows Pidgin to directly validate against the Windows Certificate store. That basically just happens behind the scenes and it's also possible to optionally implement our own validation.

On the other hand Daniel Stenberg (curl project leader) and I were thinking that libpurple/Pidgin would also be a good candidate for a project which could use a generic SSL/TLS abstraction layer. Since libcurl already supports 9 different SSL/TLS implementations (state of the current development version), we would start of my separating the internal abstraction layer into it's own library. Then we would have to make sure that the design and architecture are not only fitting into the curl project, but are also fulfilling the requirements of other projects, like libpurple.

But this is a whole other topic. The question is: do we want to proceed on adding Schannel support using libpurple's abstraction layer or do you want to participate in the development of a generic abstraction library?

See the following Twitter conversation for more information. https://twitter.com/mback2k/status/217502425442029570

I would love to hear your opinions on this. Thanks in advance!

Best regards, Marc

comment:4 Changed 7 years ago by datallah

Pidgin actually can't use OpenSSL due to its licensing (except on BSDs where it is "part of the OS" similar to how schannel is on Windows) (pidgin is GPL, and openssl has a GPL-incompatible license).

That actually raises an interesting question - how would such a abstraction layer support handling that type of scenario?

comment:5 Changed 7 years ago by mback2k

Oh, sorry. I was under the impression that Pidgin was able to use OpenSSL. Then it's just GnuTLS and NSS, okay.

Yes, the licensing question is a very good one, but since I am really not into license stuff I can't help on this end. I don't know if an abstraction layer would need to use the most-restrictive license of all the supported libraries.

comment:6 follow-up: Changed 7 years ago by bagder

datallah: yes it can legally and license-wise be linked against OpenSSL. The licenses that collide (OpenSSL + GPL) only limits what is allowed to get distributed so usage and linking is not prohibited in any way, only distribution.

mback2k: a generic backend could of course easily be made to disable a specific library, but most likely it would simply mean that people who build binaries out of a GPL licensed program would simply not select to build a backend that involves a non-GPL compliance license.

comment:7 in reply to: ↑ 6 Changed 7 years ago by datallah

Replying to bagder:

datallah: yes it can legally and license-wise be linked against OpenSSL. The licenses that collide (OpenSSL + GPL) only limits what is allowed to get distributed so usage and linking is not prohibited in any way, only distribution.

Sure, if you're building from source you can do whatever you want, but that's not really a useful argument for the common use case (distro provided packages, windows binaries, etc.).

mback2k: a generic backend could of course easily be made to disable a specific library, but most likely it would simply mean that people who build binaries out of a GPL licensed program would simply not select to build a backend that involves a non-GPL compliance license.

It's not that simple - it wouldn't be a problem on e.g. Windows where we control the full stack of what is distributed. However, on other OSes, rresumably the abstraction layer would itself be installed as a shared package, and each of the SSL implementation modules would also be a package - it wouldn't necessarily be something that is statically linked into each program that uses it. If you connect the dots, you run into the situation described in this GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper

This isn't really the venue for a complicated licensing discussion.

comment:8 Changed 3 years ago by EionRobb

Ticket #16820 has been marked as a duplicate of this ticket.

comment:9 Changed 3 years ago by EionRobb

Should have probably mentioned when merging the other ticket to this one that I've been attempting to implement this over the xmas break. It's getting stuck on SSL connections, but I've done as much as I can and would appreciate if someone who knows the win32 api a little better than I can check it over to see if there's something obvious that I've done wrong.

I've put the code up on bitbucket rather than being silly and attaching it as a patch to that other ticket

https://bitbucket.org/EionRobb/pidgin/commits/9153cb4f5250787a15d955c8442bf04ac3f9de06

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!