Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jul 1999 07:57:00 -0500 (CDT)
From:      Takeshi Morishima <morishim@cig.mot.com>
To:        obrien@freebsd.org
Cc:        morishim@cig.mot.com, freebsd-ports@freebsd.org
Subject:   Re: any recommendation for a port using encrypt
Message-ID:  <199907221257.HAA04607@timbre.cig.mot.com>
In-Reply-To: "David O'Brien"'s message of "Wed, 21 Jul 1999 22:45:41 -0700" <199907220549.AAA21806@timbre.cig.mot.com>
References:  <199907211628.LAA08209@timbre.cig.mot.com> <199907220549.AAA21806@timbre.cig.mot.com>

next in thread | previous in thread | raw e-mail | index | archive | help

In message "Re: any recommendation for a port using encrypt"
    on 99/07/21, "David O'Brien" <obrien@freebsd.org> writes:
> 
> >  o dynamic link to a crypto library assuming the user has DES package
> >    installed. (how to make dependency to DES package in the port
> >    system?) RESTRICTED=no
> 
> Can you dynamically link to libscript (ie, our MD5 password hashing)?
> And do things the same way?  Or are you sending the DES hash across the
> link to the other side?  OR, is there a DES lib/function you could add
> the list of distfiles?

One-way hash would not work in this case. The program sends raw login
and password through dynamically generated chat script (i.e.  they are
not encrypted when used.) Normally such information is statically
stored in a chat script file in /etc/ppp without any encryption and
its security is maintained by file permission and ownership. The sole
reason of using DES is to add additional security.  If I give up
storing login and password in an encrypted form, i.e.  skip the code
of encryption/decryption, raw login and password appears on the
startup file, and still the program works without DES.  (Although it
is not prefereable.)


>  Since you are already going to have to restrict this port, what's
> another restricted file?

Well, my understanding is that if the final executable uses
dynamically linked DES library routines, the program itself can be
non-restricted. (My problem is the UFC-crypt source, which is an
add-on package included in the distribution at users' convenience.)


> > BTW, the distribution tarball even includes UFC-crypt source for
> > SunOS. I assume this implicates the distribution cannot be placed
> > on cdrom/the freebsd.org ftp servers.
> 
> That would be correct.  You will have to make it
> RESTRICTED='contains DES code'

Assuming my understanding above is correct, is there anyway to work
around this? I can make the final executables DES independent, but I
do not like to make it restricted just because the UFC-crypt source is
included (while it is not really used). (If original author agrees
with separating the UFC-crypt part or me creating a subset 'no-crypt'
tarball from the original distribution, this is no longer a problem,
correct?)

Thanks,
Takeshi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907221257.HAA04607>