[zeromq-dev] Defaulting to tweetnacl?

[Roland Fehrenbacher]

>>>>> "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".
    >>
    >> Best,
    >>
    >> Roland
    >>
    >> ------- http://www.q-leap.com / http://qlustar.com
    >> --- HPC / Storage / Cloud Linux Cluster OS ---
    >> _______________________________________________ zeromq-dev
    >> mailing list zeromq-dev at lists.zeromq.org
    >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
    P> _______________________________________________ zeromq-dev
    P> mailing list zeromq-dev at lists.zeromq.org
    P> http://lists.zeromq.org/mailman/listinfo/zeromq-dev