[zeromq-dev] Defaulting to tweetnacl?

Roland Fehrenbacher rf at q-leap.de
Tue Mar 1 11:01:17 CET 2016

>>>>> "P" == Pieter Hintjens <ph at imatix.com> writes:

    P> I can create the repo and the packaging for it, if you like.

That's fine, as long as you don't create a debian subdir in the master
branch. This would get in the way of the official Debian packaging. I'd
manage that in a debian/master branch.

    P> We have the technology (zproject) to make this simple. Would you
    P> like to contact the original authors wrt licensing?

If you're OK with the above, yes.

    P> I'd suggest using MPLv2 and hosting this repo in the zeromq
    P> organization (there are others we can use if that's not
    P> appropriate).

No objections. Just let me know the repo path when done.


http://www.q-leap.com / http://qlustar.com
          --- HPC / Storage / Cloud Linux Cluster OS ---

    P> On Mon, Feb 29, 2016 at 7:36 PM, Roland Fehrenbacher
    P> <rf at q-leap.de> wrote:
    >>>>>>> "P" == Pieter Hintjens <ph at imatix.com> writes:
    P> True, there is no source repo and no explicit license. The site
    P> https://tweetnacl.cr.yp.to/ states that the software is "public
    P> domain" which is a solid enough statement IMO to use the source
    P> code.
    P> I suspect the best solution is to create a proper repo for
    P> tweetnacl, with a license. We could then remove the packaged code
    P> from libzmq and make an external dependency.
    >> That's what I thought too. Do you want to create the repo? I'd
    >> create one for packaging on debian.org and clone it on our github
    >> page. If you're happy with that, I would provide write access to
    >> the latter, and we could use it as the main repo. Concerning the
    >> license: Might be a good idea, to choose one for this repo and
    >> then contact the original authors, to ask whether they're happy
    >> with it.
    P> As for timely updates, yes, of course.
    >> That's a statement. If we can get the original authors involved,
    >> it would make things easier.
    >> Roland
    >> ------- http://www.q-leap.com / http://qlustar.com
    >> --- HPC / Storage / Cloud Linux Cluster OS ---
    P> On Mon, Feb 29, 2016 at 6:46 PM, Roland Fehrenbacher
    P> <rf at q-leap.de> wrote:
    >> >>>>>>> "L" == Luca Boccassi <luca.boccassi at gmail.com> writes:
    >> >>
    >> >> Hi all,
    >> >>
    >> >> sorry for being a bit late to this discussion.
    >> >>
    L> On Feb 10, 2016 22:41, "Pieter Hintjens" <ph at imatix.com> wrote:
    >> >> >>
    >> >> >> Hi all,
    >> >> >>
    >> >> >> I'd like to start moving to tweetnacl as the default when
    >> >> >> building libzmq. This means, no separate install of
    >> >> >> libsodium, and encryption built in by default. We can still
    >> >> >> have a --with-libsodium and --without-curve at configure
    >> >> >> time.
    >> >> >>
    >> >> >> Does anyone have a problem with this? It will not change
    >> >> >> anything significant in terms of performance nor
    >> >> >> interoperability. Just easier builds.
    >> >>
    >> >> While bringing some convenience, I think it's bad practice to
    >> >> bundle external code in one's own project. Most strongly, this
    >> >> applies to heavily security related stuff like an encryption
    >> >> library, IMHO.  Will ZMQ provide timely security fixes for
    >> >> tweetnacl?
    >> >>
    L> As long as libsodium remains supported I don't think it is a
    L> problem. Bear in mind that distributions like Debian will most
    L> likely use libsodium, because even though it is allowed, it is
    L> strongly discouraged to ship statically linked binaries, and it
    L> makes the mainteiners life harder. See: https://
    L> wiki.debian.org/StaticLinking
    >> >>
    >> >> This is the second important point: While with the bundling of
    >> >> the C Code you won't have statically linked binaries, from the
    >> >> distribution point of view, Debian maintainers will have to
    >> >> strip out the bundled code and create a so called DFSG source
    >> >> package.
    >> >>
    >> >> On another note: A weird thing about tweetnacl is, that it
    >> >> doesn't even have a license, making it hard to include it into
    >> >> Debian e.g. I also can't find a public source repo.
    >> >>
    >> >> If the latter two points were resolved, I could create an
    >> >> official tweetnacl Debian package, bringing back some
    >> >> convenience from the "code bundling approach".

More information about the zeromq-dev mailing list