I've never needed to get "by hand" the sources of crypt.

Abigail

I've always wondered this, but what exactly is the mathematical representation of gazillion? Maybe something like 10eGZ? And how does it compare to bazillion (or is that bizillion) or even just plain zillion? What about if you switch to a j prefix, as in jillion? A million kajillion?

Anyway, enough rambling. Now back to your regularly scheduled postings.

kelan

---

Perl6 Grammar Student

I think 'gazillion' means 'more than one'.

Abigail

no, you're all missing the point =P

bash$ pwd
/usr/local/nrg/src/perl-5.8.0
bash$ fgrep des_fcrypt README.*
README.win32:If you have either the source or a library that contains 
+des_fcrypt(),
README.win32:enable the appropriate option in the makefile.  des_fcryp
+t() is not
README.win32:name of the file that implements des_fcrypt().  Alternati
+vely, if
README.win32:you have built a library that contains des_fcrypt(), you 
+can set
README.win32:implementations of des_fcrypt().  Older versions have a s
+ingle,
README.win32:in des_fcrypt.patch.
README.win32:Perl will also build without des_fcrypt(), but the crypt(
+) builtin will
bash$
[download]

it's a win32ism which is why most of us who have built Perl a gazillion times have never seen it =P it's so standard on unix that it's always there. that's about all i can say.

But the OP was claiming everyone who build Perl runs in into this problem. I think that the vast majority of the people who build their own perls do this on Unix, Windows users lacking a C compiler delivered with their OS rather download a binary.

Had the OP not assumed there's nothing but crippled Mickeysoft OSses, people building a gazillion perls wouldn't have reacted.

Abigail

I wouldn't even pretend to understand the crypto laws without a good lawyer. There's a lot of detail at this site. My understanding (which may be wrong) is that DES is export controlled from the U.S. but that restriction was relaxed to allow 56-bit exports in 1998 or so. A lot of open source simply says, "I can't possibly get this right, so if you're outside the U.S. figure it out yourself." Unfortunate, but that may be the case here.

Yeah, this is an annoying aspect of the Win32 distribution of perl. Since the windows C/C++ API/libraries doesn't include fcrypt (from a shaky knowledge of what is there), presumably because it uses a different API for handling passwords (which is what crypt is for). So if you want it you need to download it from Sarathys (GSAR)'s site at ActiveState.¹.And it is valid as of the writing of this post. As a catch all, the link is hosted in Canada so theres no trouble with the US feds.

And theres the point. There is no restriction on the distribution of crypt these days from what I know, its everywhere already. Every distribution of linux has it somewhere doesn't it? I think the perl position is a hangover of when the US had much more restrictive laws on the export of encryption technology. So I dont think there is any reason not to distribute fcrypt.c in win32 directory. Who knows, if you pester the P5P mailing list they might check with a lwayer and put it back in (assuming I'm correct). But, unless harassed and helped to do so (ie, documentation updates, legal opinions, repeated mails to the right people, Hugo's consent, etc) they won't bother, as it is so freely available elsewhere. Especially as Abigail-II so amusingly put it, many Win32 users of Perl wont have a C compiler. Or they would build the cygwin version instead and not have to worry about it. But for those of us with VC++ or Borland, its a touch annoying having to do the extra download. Especially if you forget. :-)

Anyway, nowadays there are better techniques available than crypt. Its there to keep the unix people happy. For the rest of us, (and even for the unix people most times) you can forget it and use something stronger. There are lots of good encryption packages available from CPAN.

1. Strangely, (and for me surprisingly), the perlwin32 in AS 633 doesnt contain this link. The source to bleadperl that I have handy (a few months old) does contain it in REAME.win32 which I always thought was the source turned into perlwin32.html. Ive never built an AS patched version. Although I use their precompiles all the time.

I can't imagine actually using crypt(). If I want a hash then I turn to Digest::SHA1 (or the deprecated Digest::MD5). If I want to encrypt data then Crypt::CBC plus something like Crypt::Blowfish. But crypt()? Nah.

Seeking Green geeks in Minnesota

Do you know of a list/summary of different "digest"/checksum algorithms? Not just cryptographic one-way, but things like CRC-32 also.

No. I keep track of what I need - I guess if I wanted a crc then there's function for that under the unpack() function. But I've never wanted to do a plain crc32 - when I care about data integrity I use both md5 and sha1 (mostly just for redundancy). I wish I had better info for you.

I can't imagine actually using crypt()...

So? You completely missed the point.

If not, way not change this in the future and put the file needed for crypt(), since is a useful function for passwords, specially on web.

I can't imagine actually using crypt()...

So? You completely missed the point.

No I didn't. If the point is to work with crypted passwords then the digest functions I mentioned blow this out of the water. If the point is to work with a passwd file then there are modules for that (but never having actually written anything to muck with /etc/passwd or /etc/master.passwd I don't know their names). Or then there is Apache passwd file - but there's a module for that.

---

Seeking Green geeks in Minnesota