* Package name    : libBabaSSL
  Version         : 8.3.1
  Upstream Author : Copyright (c) 2020-2022 Alibaba Digital Economy
* URL             : https://github.com/BabaSSL/BabaSSL
* License         : Apache 2.0
  Programming Lang: C
  Description     : BabaSSL is a base library for modern cryptography and communication security protocols.

- BabaSSL is a modern cryptographic and secure protocol library developed by the amazing people in Alibaba Digital Economy.
- BabaSSL provides the following major features:
-    Support RFC 8998, Chinese SM cipher suites in TLS 1.3 protocol
-    Support NTLS (formal GM dual-certificate protocol) handshake processing, according to GB/T 38636-2020 TLCP
-    QUIC API support
-    Support delegated credentials, according to draft-ietf-tls-subcerts-10

I plan to package and maintain BabaSSL myself.

Lance

Hi,

AFAIK this library is forked from OpenSSL with some extensive
modifications to support new crypto technologies, do you think we need
to involve the Security Team to review whether this package can be
supported during the next stable release cycle?

Also this project has a planned rename, and I'm a bit concerned this
could cause some maintenance burden if the rename is not well
coordinated at the time we accept it into Debian.

Regards,
Aron

What is the plan? Are there any current or new packages which will
depend on it?

Hello Aron,

Thank you for your email.

I think any reviews and oversight are a good thing. In making this ITP, I figured it would cause discussion as it's a "drop-in" replacement for OpenSSL and the libraries have the same name. I wasn't sure if this was directly permitted so the ITP is a good place to have the discussion.

The rename would help the name conflict issue, but you're also right about maintenance/path forward becoming more difficult. I welcome your input or guidance on how to proceed.

Lance Lin <lqi254@protonmail.com>
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

Hello Marco,

Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of my packages (Workflow) uses it but can also use OpenSSL.


I think this package will be beneficial to the Workflow users and downstream OS's.

Lance Lin <lqi254@protonmail.com>
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

Have you already designed how will this be packaged to work as a drop-in
replacement for libssl3? I see quite a lot of problems with that,
both Policy ones and technical ones.

Am Wed, Jun 22, 2022 at 02:28:36PM +0000 schrieb Lance Lin:

Then make it use OpenSSL. If there's anything exciting in BabaSSL, they
should submit it for inclusion in OpenSSL. We should aim for fewer
crypto libraries in our stable releases, not more.

Or if the goal is rather to experiment and expose BabaSSL to the many archs
we have in Debian, then keep it in unstable only by filing a bug to block
it from testing.

Cheers,
        Moritz

Hi,

Paul

Hello everyone,

Thank you for your input and guidance. I've only been in Debian for a year so

I still have many things to learn. I assumed there would be issues with library
name conflicts and wanted to get the group's opinion.

It sounds like it would be suitable for the community if I continue the packaging

work but restrict the package to experimental?


I'd like to continue working on it but also want to avoid any conflicts with Debian
policy, security, etc.

Any objections?

Thank you,

Lance Lin <lqi254@protonmail.com>
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

As a drop-in OpenSSL replacement or with different file names and SONAMEs?

Can you explain exactly what benefits these users have from using
BabaSSL instad of OpenSSL? And why only these users and not the users of
other current dependencies of OpenSSL?

As far as I understand it, the main point of BabaSSL is to add support
for Chinese developed ciphers and algorithms.

Long time ago in my student years, I was working with a German fork of
OpenSSL. The point was to add German elliptic curves (BSI and Deutsche
Telekom). They were eventually merged into OpenSSL.

Regards

Is supporting Chinese cryptography standards a goal for Debian?
If it is then they should be available to all packages, but if it is not
then I am not sure that having random (?) packages depend on an OpenSSL
alternative would be a good strategy.
Do you expect that support for the Chinese algorithms will be merged in
OpenSSL any time soon? Is there such a plan by the BabaSSL developers?

    Stephan> As far as I understand it, the main point of BabaSSL is to
    Stephan> add support for Chinese developed ciphers and algorithms.

It looked like there were two main points.
The first was in fact these ciphers.
I don't think that's a good reason for including in Debian because it
looks like OpenSSL is interested in adding these ciphers long-term, and
that appears a much better strategy for us as a ddistribution.

However there are some other features from the ITP:

-    Support NTLS (formal GM dual-certificate protocol) handshake processing, according to GB/T 38636-2020
TLCP
-    QUIC API support
-    Support delegated credentials, according to draft-ietf-tls-subcerts-10

I don't recognize NTLS
and presumably since draft-ietf-tls-subcerts is a working group draft it
will be possible to get into OpenSSL eventually.

Have been trying to reach you