[openssl.org #39] openssl-0.9.6d shared libs built on OSX *WITHOUT* .dylib extension ...
[levitte - Thu May 30 09:06:04 2002]: You're quite right, .dylib isn't added. The reason was two-fold: 1) darwin-ppc-cc, as well as a few other targets, had the shared_extensions field misaligned, which in effet disabled having any extension at all for shared libraries. 2) support for shared libraries with version numbers weren't properly done in Configure. One thing I'm unsure about, though: most Unix implementations have the version part of the soname last in the file name, like libcrypto.so.0.9.6. You're patch indicates that MacOS X has it in the middle, like libcrypto.0.9.6.dylib. Is that really so? I recalled having asked this question before and gotten the answer that this is the way to do things (or something like that). Anyhow, I've just commited the changes that correct the shared library support on Darwin. It will appear in the snapshots for 0.9.7 and 0.9.6e later tonight. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #43] Double Free Error
[[EMAIL PROTECTED] - Fri May 17 19:50:59 2002]: Installed openssl-0.9.6d source and built it locally. Built a PEM certificate for testing U of W IMAP with SSL. SSL didn't work, wouldn't accept the certificate. Discovered that code still has a double free bug that was reported back in 2000? :(( Unfortunately, we didn't have a ticket system until just recently, so some reports got lost. Very sorry about that... Fixed double free by hand by setting pointer to NULL after call to xxx_free in three locations. IMAP with SSL now appears to work. I just commited the suggested change. Thanks for the report. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
I'm not sure about the second question, but we found that the eracom engine submission was much more generic. When one of my co-workers tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway module there were many issues, as well as specific calls directly to PKCs#11 functions rather than through the function list. If I remember correctly the Eracom submission from last year was much more generic and we had to do nothing except point it to our shared library... No requirements for GKPCS11 headers, no direct function calls... Richard Levitte via RT wrote: I've just started looking at this, and I've got a couple of questions: 1. could this engine be considered a general PKCS#11 engine, or are there specific ties to Trustway. I'd prefer to see a general PKCS#11 engine. 2. Those extra functions in the RSA method, are they really needed? I understand that they provide a lot of automagic things, but then it should be added in the ENGINE framework as something that would be potentially available for any hardware (that supports that extra functionality). Also, when it comes to loading keys, the current modus operandi is to explicitely use the ENGINE key loading functions rather than having some implicit functionality going on. The reason is that we'd prefer not to surprise the users too much. -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:14:17PM +0200, Richard Levitte - VMS Whacker wrote: pod2man is a command line wrapper around Pod::Man these days, and depends on other Pod:: modules. Do you *really* want them to be included? If we can't update our copy of pod2man, we should at least keep the old one as a fallback if the system has no pod2man or it does not work properly. Otherwise expect tons of reports that 'make install' does not work. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #51] OpenSSL 0.9.7 -BUG - WIN32
Hi, That is also a working solution ! /raimo -Original Message- From: ext Richard Levitte via RT [mailto:[EMAIL PROTECTED]] Sent: 30 May, 2002 16:10 To: Vuonnala Raimo (NVO/Helsinki) Cc: [EMAIL PROTECTED] Subject: [openssl.org #51] OpenSSL 0.9.7 -BUG - WIN32 I think I should change e_os2.h so OPENSSL_SYS_MSDOS is only defined for OPENSSL_SYSNAME_WIN16 and OPENSSL_SYSNAME_WIN16. Does that seem to be a good solution, or is there something I've missed? [[EMAIL PROTECTED] - Thu May 23 14:20:17 2002]: Hi, There is a bug in 'e_os.h'. The effect is that Win32 multithreaded applications crash. The problem is that currently OPENSSL_SYS_MSDOS is defined also for Win32 platform, and MS_STATIC is defined as 'static' as follows: #if defined(OPENSSL_SYS_MSDOS) # define MS_STATIC static #else # define MS_STATIC #endif MS_STATIC is used here and there where there is a large auto variable used. In Win32 those are not a problem - instead the code is now not re-entrant. I would recommend to change that problematic definition as follows: #if defined(OPENSSL_SYS_MSDOS) !defined(OPENSSL_SYSNAME_WIN32) # define MS_STATIC static #else # define MS_STATIC #endif The bug seems to exist in all 0.9.7 snapshots. In 0.9.6 the definition is as follows : #if defined(WIN16) || defined(MSDOS) # define MS_STATIC static #else # define MS_STATIC #endif This works fine in all Windoze environments. Best regards Raimo Vuonnala Nokia Internet Communications Helsinki, Finland -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
In message [EMAIL PROTECTED] on Thu, 30 May 2002 15:27:44 +0200, Bodo Moeller [EMAIL PROTECTED] said: moeller Specifically, we'd have to test that multi-line NAME sections are moeller handled correctly; it appears this bug was fixed only recently in the moeller pod2man that comes with Perl. Hmm, I tested with doc/crypto/des.pod with the pod2man.pl we had before the small fix that supposedly fixed this (-r 1.1), and I can't see anything wrong with the output. If you could tell me what the difference is between a broken pod2man and a working one, I might be able to make an appropriate test... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:39:21PM +0200, Richard Levitte - VMS Whacker wrote: Specifically, we'd have to test that multi-line NAME sections are handled correctly; it appears this bug was fixed only recently in the pod2man that comes with Perl. Hmm, I tested with doc/crypto/des.pod with the pod2man.pl we had before the small fix that supposedly fixed this (-r 1.1), and I can't see anything wrong with the output. If you could tell me what the difference is between a broken pod2man and a working one, I might be able to make an appropriate test... The bug reported that led to the change was Christoph Martin [EMAIL PROTECTED]: Wichert Akkerman writes: Package: openssl Version: 0.9.6-1 Severity: normal The HISTORY section of RAND_add(3ssl) isn't formated correctly, its end looks like this: RAND_event() in OpenSSL 0.9.5a. entropy to the PRNG The .pod file is incorrect. Apparently you are not allowed to have more than one line in the NAME section. The following patch fixes this. A later comment was The pod2man which comes with perl 5.6 has the same problem. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
On Thu, May 30, 2002 at 03:43:34PM +0200, Bodo Moeller wrote: On Thu, May 30, 2002 at 03:39:21PM +0200, Richard Levitte - VMS Whacker wrote: Specifically, we'd have to test that multi-line NAME sections are handled correctly; it appears this bug was fixed only recently in the pod2man that comes with Perl. Hmm, I tested with doc/crypto/des.pod with the pod2man.pl we had before the small fix that supposedly fixed this (-r 1.1), and I can't see anything wrong with the output. If you could tell me what the difference is between a broken pod2man and a working one, I might be able to make an appropriate test... The bug reported that led to the change was Christoph Martin [EMAIL PROTECTED]: Wichert Akkerman writes: Package: openssl Version: 0.9.6-1 Severity: normal The HISTORY section of RAND_add(3ssl) isn't formated correctly, its end looks like this: RAND_event() in OpenSSL 0.9.5a. entropy to the PRNG The .pod file is incorrect. Apparently you are not allowed to have more than one line in the NAME section. The following patch fixes this. A later comment was The pod2man which comes with perl 5.6 has the same problem. I remember having had problems with multi line NAME sections. The solution for me was simple: I made sure that all manual pages I wrote only had a single line, even a long one, in the NAME section. We therefore do have another option for this problem. Falling back to a delivered pod2man.pl in case the system does not have however seems to be reasonable for me. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #56] Apparent bug in AES_ctr128_encrypt
[[EMAIL PROTECTED] - Sun May 26 11:34:49 2002]: The main loop from AES_ctr128_encrypt seems superficially incorrect. If any non-zero initial value is provided for *num, the first 16-*num bytes are not necessarily encrypted. You do know that AES_ctr128_encrypt() must be called with *num initially 0, right? *num is only there to provide the possibility to treat AES_ctr128_encrypt() as a stream cipher. Also, the value for *counter is never used as provided, but is always incremented before use. You're absolutely right. I just reread the NIST document on CTR mode, and it clearly shows that the initial counter value should be used as is. That was easily arranged by changing the order of the calls to AES_ctr128_inc() and AES_encrypt()... I'll commit my change promptly. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #12] Re: Revised DOS patch for openssl-0.9.7
On Thu, 30 May 2002, Richard Levitte via RT wrote: I'd like to know what state the DJGPP support is at right now. Since the large patch for DJGPP support that was sent to openssl-dev some time ago never made it into the ticket database, I'm a bit unsure about what to do with it. I suggest that the patch for DJGPP support gets resubmitted if nedded, so it can make it's way into our ticket database. This ticket will change state to resolved. I'll try to review the patch this weekend and resubmit. I presume you mean the patch for 0.9.7, or would you like the patch for 0.9.6 resubmitted also? Thanks. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #51] OpenSSL 0.9.7 -BUG - WIN32
On Thu, 30 May 2002, Richard Levitte via RT wrote: I think I should change e_os2.h so OPENSSL_SYS_MSDOS is only defined for OPENSSL_SYSNAME_WIN16 and OPENSSL_SYSNAME_WIN16. Does that seem to be a good solution, or is there something I've missed? I think you will need it for DJGPP also. Doug __ Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
Hi there, Slowly catching up on some of this ticket discussion ... On Thu, 30 May 2002, Lutz Jaenicke wrote: On Thu, May 30, 2002 at 03:43:34PM +0200, Bodo Moeller wrote: A later comment was The pod2man which comes with perl 5.6 has the same problem. I remember having had problems with multi line NAME sections. The solution for me was simple: I made sure that all manual pages I wrote only had a single line, even a long one, in the NAME section. We therefore do have another option for this problem. Falling back to a delivered pod2man.pl in case the system does not have however seems to be reasonable for me. We already assume an adequate version of perl, bc, etc when building and testing. I don't think it would hurt to assume the presence of an installed pod2man for those wanting to build docs (this is a similar problem to many other source packages). Those who don't have or want those extras installed shouldn't try building the documentation from source. OTOH: Why not compromise - let it fail if there's no pod2man installed (as it does now) but emit an error message that a bundled (though potentially out-of-date) script exists that can be used by setting an env-var? We could similarly emit some version information about the bundled version so the builder could then decide whether to use that or install the latest from CPAN or wherever. I don't think use of a bundled version should be automatic - we obviously can't hope to keep that up-to-date and using it automatically would imply otherwise. Cheers, Geoff -- Geoff Thorpe, geoff(at)openssl(dot)org The thirst for power is base. The desire to combat and conquer, more base still. Beware bassists writing foreign policy. Les Claypool for president?? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #12] Re: Revised DOS patch for openssl-0.9.7
In message [EMAIL PROTECTED] on Thu, 30 May 2002 07:54:17 -0700 (PDT), Doug Kaufman [EMAIL PROTECTED] said: dkaufman I'll try to review the patch this weekend and resubmit. I presume dkaufman you mean the patch for 0.9.7, or would you like the patch for 0.9.6 dkaufman resubmitted also? Thanks. 0.9.7. Sorry, but as I recall, the change is too big to safely be applied to 0.9.6. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
Richard Levitte via RT [EMAIL PROTECTED] writes: I've just started looking at this, and I've got a couple of questions: 1. could this engine be considered a general PKCS#11 engine, or are there specific ties to Trustway. I'd prefer to see a general PKCS#11 engine. This engine is a general PKCS#11 engine. I tested it first with the PKCS#11 library developped by Lutz Behnke (libgpkcs11.so) and its software token (libceay_tok.so). It is possible to make a general PKCS#11 engine and just put specific ties, if any, for multiple hardwares. In Trustway case, the only specific tie is the name of PKCS#11 library to load and some controls added when loading it. Our code depends on gpkcs11 include files (cryptoki.h, pkcs11.h, ...); it is possible to add them to our patch. 2. Those extra functions in the RSA method, are they really needed? I understand that they provide a lot of automagic things, but then it should be added in the ENGINE framework as something that would be potentially available for any hardware (that supports that extra functionality). Also, when it comes to loading keys, the current modus operandi is to explicitely use the ENGINE key loading functions rather than having some implicit functionality going on. The reason is that we'd prefer not to surprise the users too much. The Bull Trustway CC2000 isn't only a cryptographic accelerator card, it is a high level security hardware providing key generation and storage in secure memory. That's why we can't use ENGINE key loading functions. Yes those extra functions are really needed when using this kind of hardware. afchine __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
Richard Levitte via RT [EMAIL PROTECTED] writes: I've just started looking at this, and I've got a couple of questions: 1. could this engine be considered a general PKCS#11 engine, or are there specific ties to Trustway. I'd prefer to see a general PKCS#11 engine. This engine is a general PKCS#11 engine. I tested it first with the PKCS#11 library developped by Lutz Behnke (libgpkcs11.so) and its software token (libceay_tok.so). It is possible to make a general PKCS#11 engine and just put specific ties, if any, for multiple hardwares. In Trustway case, the only specific tie is the name of PKCS#11 library to load and some controls added when loading it. Our code depends on gpkcs11 include files (cryptoki.h, pkcs11.h, ...); it is possible to add them to our patch. 2. Those extra functions in the RSA method, are they really needed? I understand that they provide a lot of automagic things, but then it should be added in the ENGINE framework as something that would be potentially available for any hardware (that supports that extra functionality). Also, when it comes to loading keys, the current modus operandi is to explicitely use the ENGINE key loading functions rather than having some implicit functionality going on. The reason is that we'd prefer not to surprise the users too much. The Bull Trustway CC2000 isn't only a cryptographic accelerator card, it is a high level security hardware providing key generation and storage in secure memory. That's why we can't use ENGINE key loading functions. Yes those extra functions are really needed when using this kind of hardware. afchine __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #51] OpenSSL 0.9.7 -BUG - WIN32
[[EMAIL PROTECTED] - Thu May 30 16:22:22 2002]: Hi again, Sorry Richard, but your suggestion just don't work: OPENSSL_SYS_MSDOS is used all over the source and in principle these #ifdefs are correct. The only thing that must be fixed is that #define MS_STATIC static (set in e_os.h) cannot be used in Win32 environments (i.e only in 16-bit MS-DOS or Windows platforms - who uses these today any way...). My original proposal (below, file e_os.h) fixes this problem. #if defined(OPENSSL_SYS_MSDOS) !defined(OPENSSL_SYSNAME_WIN32) # define MS_STATICstatic #else # define MS_STATIC #endif OK, I've commited that change for now. I intend to review the definition of OPENSSL_SYS_MSDOS for 0.9.8, however. The current use is a bit confusing... -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
Steven Bade [EMAIL PROTECTED] writes: I'm not sure about the second question, but we found that the eracom engine submission was much more generic. When one of my co-workers tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway module there were many issues, as well as specific calls directly to PKCs#11 functions rather than through the function list. If I remember correctly the Eracom submission from last year was much more generic and we had to do nothing except point it to our shared library... No requirements for GKPCS11 headers, no direct function calls... I think that in the case of Eracom card, keys are generated by an external way. Trustway card generates and stores keys, it's the reason of changes in the RSA methods. If needed, I can add the include files in the patch, so it doesn't require to get gpkcs11 headers. afchine __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #43] Double Free Error
Hi, Just wanted you to know that I'm still having problems with DER format certificates. A more thorough inspection turned up additional double free errors in the same directory :( Best Rgds, -H- On Thu, 30 May 2002, Richard Levitte via RT wrote: [[EMAIL PROTECTED] - Fri May 17 19:50:59 2002]: Installed openssl-0.9.6d source and built it locally. Built a PEM certificate for testing U of W IMAP with SSL. SSL didn't work, wouldn't accept the certificate. Discovered that code still has a double free bug that was reported back in 2000? :(( Unfortunately, we didn't have a ticket system until just recently, so some reports got lost. Very sorry about that... Fixed double free by hand by setting pointer to NULL after call to xxx_free in three locations. IMAP with SSL now appears to work. I just committed the suggested change. Thanks for the report. -- Harvey M Wamboldt^ E-Mail: [EMAIL PROTECTED] MDA Inc 1000 Windmill Rd. Suite 60 ^ Fax:(902)468-2278 Dartmouth NS, B3B 1L7, Canada^ Phone: (902)481-3531 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #57] Solaris64 sparc-v9 GCC 3.1 patch for OpenSSL 0.9.6d Configure
The patch is now applied and committed. Thanks! [[EMAIL PROTECTED] - Tue May 28 20:00:46 2002]: Well, here it is... Works great for me, passed all tests. Creates a 64bit OpenSSL package for Solaris using the newly released GCC 3.1 -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #43] Double Free Error
[[EMAIL PROTECTED] - Thu May 30 19:28:13 2002]: Hi, Just wanted you to know that I'm still having problems with DER format certificates. A more thorough inspection turned up additional double free errors in the same directory :( Hmm, would you mind telling me which file it is, since you found it, or do you take pleasure in giving very little hintage? -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #52] Bug in crypto/cversion.c:84
This was much easier to fix than I thought. Committed and present in the next snapshot. [[EMAIL PROTECTED] - Thu May 23 16:27:27 2002]: Hi there, it seems that in line 84 in crypto/cversion.c there is a bug: eg. if you run Configure with -DDEVRANDOM=\/dev/random\ and therefore the compiler is invoked with gcc -DDEVRANDOM=\/dev/random\ you get an error of an unknown string dev. Maybe you could stringify the whole string within a define? Ciao Stephan -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl/util pod2man.pl
In message [EMAIL PROTECTED] on Thu, 30 May 2002
15:05:31 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller On Thu, May 30, 2002 at 12:18:15PM +0200, [EMAIL PROTECTED] wrote:
moeller
moellerLog:
moellerOur copy of pod2man.pl is old and comparatively broken, so lets remove it.
moeller
moeller If our pod2man.pl is too old, we should update it if necessary.
moeller Installations may have even older versions that don't contain all the
moeller bugfixes we need (are all of them obsoleted by the current official
moeller version of pod2man?), or pod2man may not be installed at all. For
moeller example, Solaris 8 comes with /usr/bin/perl, but pod2man is not in the
moeller standard PATH.
pod2man is a command line wrapper around Pod::Man these days, and
depends on other Pod:: modules. Do you *really* want them to be
included?
A solution I could see is to provide auxiliary packages with extra
files, like the whole pod2x packet. People would have to download
those separately and install them in some way. It's possible such a
package is already available on CPAN (which should check that out).
moeller Removing pod2man.pl creates more problems ('make install' will fail on
moeller many systems where it now works) than it solves (for the few people
moeller who actually look at the manpages and have a sufficiently new version
moeller of pod2man installed).
The more time goes, the more pod2man.pl will be deprecated and
broken. We got the first warnings now, let's not wait until it gets
out of hand, shall we? We're not mainly perl developers, after all,
and pod2x continues to develop.
--
Richard Levitte [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~levitte/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
