public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: aj@suse.de
Cc: libc-hacker@sourceware.cygnus.com
Subject: Re: Bind 8.2 Integration
Date: Fri, 26 Nov 1999 05:34:00 -0000	[thread overview]
Message-ID: <199911261334.OAA19027@landau.wins.uva.nl> (raw)
In-Reply-To: <u8yabliflf.fsf@gromit.rhein-neckar.de>

   From: Andreas Jaeger <aj@suse.de>
   Date: 26 Nov 1999 13:48:12 +0100

   Hi Zack, Mark and all others,

   About half a year ago Zack and Mark looked at the integration of the
   resolv code from bind 8.2 into glibc.  Since then nothing happened.
   Was it just a lack of time or interest or did you encounter any
   serious problems?

At the time there appeared to be some serious problems, since there is
some support for strong cryptography in the BIND 8.2 distrubution.  It
turns out that not all of the cryptography code is needed in the
resolver library.  The idea is that if you want to use secure DNS the
cryptography isn't done in the resolver stub itself, but by a trusted
named.  So it seems that we do not need to provide any strong
cryptography in glibc.

However, the new res_sendsigned/res_nsendsigned interfaces, do use the
HMAC_MD5 algorithm which is integrated in the same framework as the
strong cryptography code.  It is easy to compile the cryptography
code (which lives in `src/lib/dst' in the BIND distribution) such that
it only supports the HMAC_MD5 algorithm but there may be some
problems:

 * The code provides hooks that make it easy to add strong
   encryption.  According to some interpretations of US export laws
   this is just as bad as actually providing the code for strong
   encryption.

 * The MD5 code included in BIND is ripped from Eric Young's SSL
   implementation and the license might not be acceptable.  It should
   not be too difficult to use the MD5 code already present in glibc
   instead.

You'll probably want to have an "official" FSF statement on these
issues before doing any real work.

   I'm considering to do the integration myself soonish and would
   appreciate any help you can give me.

Just ask :)  I did some serious code browsing and even started writing
a free (in the GPL sense) implementation of the DSA algorithm, but
more or less dropped it when I found out that this was not needed for
glibc.

Mark

  reply	other threads:[~1999-11-26  5:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-26  4:50 Andreas Jaeger
1999-11-26  5:34 ` Mark Kettenis [this message]
1999-12-01  8:15   ` Andreas Jaeger
1999-12-01  8:25     ` Mark Kettenis
1999-12-03  6:55       ` Andreas Jaeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199911261334.OAA19027@landau.wins.uva.nl \
    --to=kettenis@wins.uva.nl \
    --cc=aj@suse.de \
    --cc=libc-hacker@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).