secure ftp - tls with ckermit client - Protocols

This is a discussion on secure ftp - tls with ckermit client - Protocols ; I gather that TLS is not compiled into the binaries available for download from Columbia. How do I tell whether a particular binary has TLS in it or not? Show ... something? With K95 as the client, I connect to ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: secure ftp - tls with ckermit client

  1. secure ftp - tls with ckermit client

    I gather that TLS is not compiled into the binaries available for download
    from Columbia.

    How do I tell whether a particular binary has TLS in it or not?
    Show ... something?

    With K95 as the client, I connect to either ftp or ftps by changing the
    port I use to connect. Will the same be true if I have the right ckermit?
    Does it try TSL before non-secure and fall back?

    I am on a CentOS 4.0 (kind of RedHat 4.0 ES) platform. When I try to make
    ckermit, it fails with an error that might be my lack of proper libraries,
    but I'm not sure.

    ~/source/kermit/ckver-8.0.211
    $ make redhat9 ends with
    ckuath.c:12208: warning: passing arg 4 of `DES_pcbc_encrypt' from incompatible pointer type
    ckuath.c:12208: warning: passing arg 5 of `DES_pcbc_encrypt' from incompatible pointer type
    make[2]: *** [ckuath.o] Error 1
    make[2]: Leaving directory `source/kermit/ckver-8.0.211'
    make[1]: *** [linux+krb5+krb4+openssl+zlib+shadow+pam] Error 2
    make[1]: Leaving directory `source/kermit/ckver-8.0.211'
    make: *** [redhat9] Error 2


    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  2. Re: secure ftp - tls with ckermit client

    On 2006-03-24, dold@XsecureXft.usenet.us.com wrote:
    : I gather that TLS is not compiled into the binaries available for download
    : from Columbia.
    :
    Right, we're not allowed to put binaries in public places that include
    strong encryption capabilities.

    : How do I tell whether a particular binary has TLS in it or not?
    : Show ... something?
    :
    SHOW FEATURES

    : With K95 as the client, I connect to either ftp or ftps by changing the
    : port I use to connect. Will the same be true if I have the right ckermit?
    :
    It's the same code.

    : I am on a CentOS 4.0 (kind of RedHat 4.0 ES) platform. When I try to make
    : ckermit, it fails with an error that might be my lack of proper libraries,
    : but I'm not sure.
    :
    : ~/source/kermit/ckver-8.0.211
    : $ make redhat9 ends with
    : ckuath.c:12208: warning: passing arg 4 of `DES_pcbc_encrypt' from
    : incompatible pointer type
    :
    Try the current development build:

    http://www.columbia.edu/kermit/ckdaily.html

    - Frank

  3. Re: secure ftp - tls with ckermit client

    Frank da Cruz wrote:
    > Try the current development build:


    > http://www.columbia.edu/kermit/ckdaily.html


    That was mean ;-(

    The x.zip is missing two files, compared to the x.tar.gz.

    No joy with the redhat9 build. I'm running through the other redhat builds
    to see if any of them like my CentOS 4.0 installation.

    make redhat9
    [...]
    ckcftp.c: At top level:
    ckcftp.c:13458: error: `ck_gss_mech_krb5' undeclared here (not in a
    function)
    [...]

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  4. Re: secure ftp - tls with ckermit client

    dold@xrexxsecur.usenet.us.com wrote:
    > No joy with the redhat9 build. I'm running through the other redhat builds
    > to see if any of them like my CentOS 4.0 installation.


    We have a winner.

    make redhat21+ssl is working for me.
    C-Kermit 8.0.212 Dev.16, 13 Mar 2006, for Linux

    I need to connect to the system on port 2121 for TLS, and there is no anon
    login.

    ftp open /tls www.thesite.com 2121 /user:me
    fails
    "ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
    routines:SSL3_GET_RECORD: wrong version number"


    set ftp authtype tls
    ftp open www.thesite.com 2121 /user:me

    works, but I get prompted (often) about self-signed certificates.
    "TLS accepted as authentication type
    Warning: Server has a self-signed certificate
    ...
    Continue? (Y/N)"
    "Warning: Hostname ("www.thesite.com") does not match server's
    certificate ("ftp.thesite.com")"

    What's wrong with /tls on the command line?
    How can I confirm that this is a TLS-protected connection?
    Is TLS only for authentication, and not the data?

    How can I ignore the problems with the self-signed certificate?
    Would that also ignore the naming problem ftp/www?

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  5. Re: secure ftp - tls with ckermit client

    dold@XReXXsecur.usenet.us.com wrote:
    > dold@xrexxsecur.usenet.us.com wrote:
    >> No joy with the redhat9 build. I'm running through the other redhat builds
    >> to see if any of them like my CentOS 4.0 installation.

    >
    > We have a winner.
    >
    > make redhat21+ssl is working for me.
    > C-Kermit 8.0.212 Dev.16, 13 Mar 2006, for Linux
    >
    > I need to connect to the system on port 2121 for TLS, and there is no anon
    > login.
    >
    > ftp open /tls www.thesite.com 2121 /user:me
    > fails
    > "ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
    > routines:SSL3_GET_RECORD: wrong version number"



    The server does not support FTP over TLS.

    > set ftp authtype tls
    > ftp open www.thesite.com 2121 /user:me
    >
    > works, but I get prompted (often) about self-signed certificates.


    The server supports FTP AUTH TLS

    > "TLS accepted as authentication type
    > Warning: Server has a self-signed certificate
    > ...
    > Continue? (Y/N)"
    > "Warning: Hostname ("www.thesite.com") does not match server's
    > certificate ("ftp.thesite.com")"


    And the server's name as specified by the certificate is
    "ftp.thesite.com" so you must connect to it with

    ftp open ftp.thesite.com 2121 /user:me

    and the server is using a self-signed certificate which means that
    you must obtain a copy of the certificate and store it into your
    certificate store.

    > What's wrong with /tls on the command line?


    see above

    > How can I confirm that this is a TLS-protected connection?


    kermit tells you

    > Is TLS only for authentication, and not the data?


    FTP AUTH TLS can be used for protecting by the command channel and the
    data channel provided that it is supported for both by the server.

    > How can I ignore the problems with the self-signed certificate?


    The server must either use a certificate issued by a trusted certificate
    authority or you must obtain a copy of the certificate out of band and
    install it into your certificate store.

    > Would that also ignore the naming problem ftp/www?


    Authentication is all about names. If the names don't match then you
    might as well assume you are communicating with an attacker who is about
    to pick your pocket.

    Jeffrey Altman

  6. Re: secure ftp - tls with ckermit client

    Jeffrey Altman wrote:
    > dold@XReXXsecur.usenet.us.com wrote:


    > > ftp open /tls www.thesite.com 2121 /user:me
    > > fails
    > > "ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
    > > routines:SSL3_GET_RECORD: wrong version number"


    > The server does not support FTP over TLS.


    > > set ftp authtype tls
    > > ftp open www.thesite.com 2121 /user:me


    > The server supports FTP AUTH TLS


    So TLS is only being used for the login authentication, and no protection
    is offered for the actual data?

    I do get
    Connected to www.thesite.com.
    TLS accepted as authentication type
    [TLS - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
    Compression: None
    FTP Command channel is Private (encrypted)
    FTP Data channel is Private (encrypted)

    After I'm connected, show ftp returns, in part
    Available security methods:

    ftp authtype: TLS
    ftp auto-encryption: on
    ftp credential-forwarding: off
    ftp command-protection-level: private
    ftp data-protection-level: private
    ftp secure proxy: (not set)


    > > "TLS accepted as authentication type
    > > Warning: Server has a self-signed certificate
    > > ...
    > > Continue? (Y/N)"
    > > "Warning: Hostname ("www.thesite.com") does not match server's
    > > certificate ("ftp.thesite.com")"


    > And the server's name as specified by the certificate is
    > "ftp.thesite.com" so you must connect to it with


    > ftp open ftp.thesite.com 2121 /user:me


    Administrative error that I'd like to get fixed. proftd is listening to
    the wrong IP address. Both are on the same machine.

    > and the server is using a self-signed certificate which means that
    > you must obtain a copy of the certificate and store it into your
    > certificate store.


    > > How can I confirm that this is a TLS-protected connection?


    > kermit tells you


    That's where I have ambiguity. It looks like TLS is there, except for the
    fact that I can't do /tls on the command line. How is kermit telling me?

    If I connect to the same server on the non-TLS port,
    I get messages
    TLS accepted as authentication type
    TLS authentication failed
    before the login prompt. After I log in
    show ftp
    Available security methods:

    ftp authtype: (none)
    ftp auto-encryption: on
    ftp credential-forwarding: off
    ftp command-protection-level: clear
    ftp data-protection-level: clear
    ftp secure proxy: (not set)

    > Authentication is all about names. If the names don't match then you
    > might as well assume you are communicating with an attacker who is about
    > to pick your pocket.


    Right. I know this server isn't configured correctly, so I can either hit
    "y" many times, "SET AUTHENTICATION TLS VERIFY OFF", or get the site admin
    to fix it. I'll take door #2 for now, and ask for the certificate problem
    to be corrected.

    If the ProFtpd configuration were correct, I think a TLS-client or a
    non-TLS client should be able to connect to the same name/IP and port
    number. I don't know why it is in this awkward state now, with both the
    wrong IP address and the special port number.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  7. Re: secure ftp - tls with ckermit client

    dold@XReXXsecur.usenet.us.com wrote:
    > Jeffrey Altman wrote:
    >> dold@XReXXsecur.usenet.us.com wrote:

    >
    >>> ftp open /tls www.thesite.com 2121 /user:me
    >>> fails
    >>> "ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
    >>> routines:SSL3_GET_RECORD: wrong version number"

    >
    >> The server does not support FTP over TLS.


    >>> set ftp authtype tls
    >>> ftp open www.thesite.com 2121 /user:me

    >
    >> The server supports FTP AUTH TLS

    >
    > So TLS is only being used for the login authentication, and no protection
    > is offered for the actual data?


    There is a protocol called FTP AUTH which allows an FTP client and
    server to negotiate the use of security mechanisms to provide a variety
    of service classes ranging from "clear" to "private". FTP AUTH TLS, as
    described in RFC 4217, specifies how to negotiate the use of TLS to
    provide private channels. A private channel is one that cannot be
    listened to or modified without the parties privy to the conversation
    being made aware.

    > I do get
    > Connected to www.thesite.com.
    > TLS accepted as authentication type
    > [TLS - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
    > Compression: None
    > FTP Command channel is Private (encrypted)
    > FTP Data channel is Private (encrypted)
    >
    > After I'm connected, show ftp returns, in part
    > Available security methods:
    >
    > ftp authtype: TLS
    > ftp auto-encryption: on
    > ftp credential-forwarding: off
    > ftp command-protection-level: private
    > ftp data-protection-level: private
    > ftp secure proxy: (not set)


    This tells you that the security mechanism used is TLS and that you have
    privacy for both the command and data channels ASSUMING THAT YOU HAVE
    PROPERLY VERIFIED THE HOST CERTIFICATE!!!!

    >>> "TLS accepted as authentication type
    >>> Warning: Server has a self-signed certificate
    >>> ...
    >>> Continue? (Y/N)"
    >>> "Warning: Hostname ("www.thesite.com") does not match server's
    >>> certificate ("ftp.thesite.com")"

    >
    >> And the server's name as specified by the certificate is
    >> "ftp.thesite.com" so you must connect to it with

    >
    >> ftp open ftp.thesite.com 2121 /user:me

    >
    > Administrative error that I'd like to get fixed. proftd is listening to
    > the wrong IP address. Both are on the same machine.


    Until you fix it you cannot verify the host and therefore you have no
    security at all.

    >> and the server is using a self-signed certificate which means that
    >> you must obtain a copy of the certificate and store it into your
    >> certificate store.

    >
    >>> How can I confirm that this is a TLS-protected connection?

    >
    >> kermit tells you

    >
    > That's where I have ambiguity. It looks like TLS is there, except for the
    > fact that I can't do /tls on the command line. How is kermit telling me?


    As I explained up top, FTP OPEN /TLS negotiates a different protocol
    that your server does not support.

    > If I connect to the same server on the non-TLS port,
    > I get messages
    > TLS accepted as authentication type
    > TLS authentication failed
    > before the login prompt. After I log in
    > show ftp
    > Available security methods:
    >
    > ftp authtype: (none)
    > ftp auto-encryption: on
    > ftp credential-forwarding: off
    > ftp command-protection-level: clear
    > ftp data-protection-level: clear
    > ftp secure proxy: (not set)


    The whole point of FTP AUTH is to allow FTP services to be offered on
    the standard port and be able to support clients that use security and
    those that do not.

    Now I am going to place a bet that you have IIS installed on the machine
    and that when you connect to the FTP port you are talking to the IIS FTP
    server and not PROFTPD. Turn off the IIS FTP and install PROFTPD on the
    FTP port.

    Jeffrey Altman
    Secure Endpoints Inc.

  8. Re: secure ftp - tls with ckermit client

    Jeffrey Altman wrote:
    > Now I am going to place a bet that you have IIS installed on the machine
    > and that when you connect to the FTP port you are talking to the IIS FTP
    > server and not PROFTPD. Turn off the IIS FTP and install PROFTPD on the
    > FTP port.


    This is a RedHAt ES 4.0 Linux box. No IIS. If I do the same connection to
    the non-TLS port, which I think is wu-ftpd, but I'm not sure, I get
    TLS accepted as authentication type
    TLS authentication failed
    before the login prompt. After I log in
    show ftp
    Available security methods:

    ftp authtype: (none)
    ftp auto-encryption: on
    ftp credential-forwarding: off
    ftp command-protection-level: clear
    ftp data-protection-level: clear
    ftp secure proxy: (not set)

    So, when I connect to the proftpd, I see both protection-level set to
    private, and when I connect to the other ftp, I see clear.

    If I accept the self-signed certificate, how is that a different level of
    data protection from having a proper certificate, as far as the protocol
    and encryption are concerned?

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  9. Re: secure ftp - tls with ckermit client

    dold@XReXXsecur.usenet.us.com wrote:
    > Jeffrey Altman wrote:
    > This is a RedHAt ES 4.0 Linux box. No IIS. If I do the same connection to
    > the non-TLS port, which I think is wu-ftpd, but I'm not sure, I get


    Why are you running two FTP daemons?

    > TLS accepted as authentication type
    > TLS authentication failed
    > before the login prompt. After I log in
    > show ftp
    > Available security methods:
    >
    > ftp authtype: (none)
    > ftp auto-encryption: on
    > ftp credential-forwarding: off
    > ftp command-protection-level: clear
    > ftp data-protection-level: clear
    > ftp secure proxy: (not set)


    wu-ftpd does not support secure FTP connections.

    > So, when I connect to the proftpd, I see both protection-level set to
    > private, and when I connect to the other ftp, I see clear.


    that's because proftpd supports security and wu-ftpd does not.

    > If I accept the self-signed certificate, how is that a different level of
    > data protection from having a proper certificate, as far as the protocol
    > and encryption are concerned?


    Here is the problem with the self-signed certificate. How can you
    distinguish the self-signed certificate produced by the person you trust
    from the self-signed certificate I just generated and installed on my
    server? They both say "ftp.thesite.com". So if I poison your DNS
    cache or get you to use my DNS server, then you connect to my server
    and I tell you that I am ftp.thesite.com. What's wrong with that?
    Well, you then send me your username and password and I can then
    connect to the real server and steal/modify your data.

    Security means nothing with authentication and self-signed certificates
    do not provide a method of authenticating a server UNLESS you have
    obtained a copy of the certificate via a trusted out of band mechanism
    and you have stored the certificate in your trusted certificate store.

    I can't stress this enough.

    Jeffrey Altman
    Secure Endpoints Inc.

  10. Re: secure ftp - tls with ckermit client

    Jeffrey Altman wrote:
    > Why are you running two FTP daemons?


    Not "I", "thesite". It isn't my site, although I will complain about the
    setup once I finish figuring out what I want to say.

    > wu-ftpd does not support secure FTP connections.


    I know that.

    > > So, when I connect to the proftpd, I see both protection-level set to
    > > private, and when I connect to the other ftp, I see clear.


    > that's because proftpd supports security and wu-ftpd does not.


    I know that. What I am trying to confirm is that the proftpd login is
    actually providing the encryption that it's supposed to provide(*). I said
    that it is, because I can see "private". You said it's not, because the
    /tls is not accepted on the ftp open command line. Kermit-95 connects to
    this site without a /tls on the command line, or in the script that it
    generates.

    I need to resolve encryption, "protection-level" and the command line /tls
    so I can finalize my complaint to the site.

    > Security means nothing with authentication and self-signed certificates
    > do not provide a method of authenticating a server UNLESS you have
    > obtained a copy of the certificate via a trusted out of band mechanism
    > and you have stored the certificate in your trusted certificate store.


    *The spoofing of a site certificate is an alternate, and separate, concern.
    If the certificate is spoofed, and the DNS is poisoned, or the IP address
    is somehow hijacked, and I connect to your site without realizing it, then
    you will also have access to my unencrypted data.

    > I can't stress this enough.


    Yes, you can stress this too much.
    I got the point about the security certificate. I got that before you
    mentioned it. A complaint has been registered with the site admin about
    the certificate. That is easy enough to point out to them. Merely going
    to https://www.thesite.com in a browser pops up a window about the
    certificate.

    I have customers that need to use this site, and they want secure ftp.

    To finish my part of this work, I can install proftp elsewhere and
    configure it properly, but I think the site that I need to use is almost
    there, I just need to provide a clue, since they seem to have none.

    I need to confirm that the site is currently providing encryption of login
    credentials and data, temporarily ignoring the certificate issue. If I
    have misunderstood the significance of accepting the self-signed
    certificate, that it really means there is no encryption, as opposed to
    encryption with the passcode written on the wall, then I apologize.

    I would also like to confirm that proftp can accept both secure and
    non-secure connections on port 21.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  11. Re: secure ftp - tls with ckermit client

    On 2006-03-24, dold@XReXXsecur.usenet.us.com wrote:
    : Frank da Cruz wrote:
    :> Try the current development build:
    :>
    :> http://www.columbia.edu/kermit/ckdaily.html
    :
    : That was mean ;-(
    :
    : The x.zip is missing two files, compared to the x.tar.gz.
    :
    Which ones?

    : No joy with the redhat9 build. I'm running through the other redhat builds
    : to see if any of them like my CentOS 4.0 installation.
    :
    : make redhat9
    : [...]
    : ckcftp.c: At top level:
    : ckcftp.c:13458: error: `ck_gss_mech_krb5' undeclared here (not in a
    : function)
    : [...]
    :
    Today I uploaded Dev.17, which has three new targets for Linux:

    linux+krb5+ssl
    linux+ssl
    linux+krb5

    These work, at least in Red Hat AS4.3. Hopefully other combinations can
    be modeled on these entries, which do it "right" -- they just set the bare
    minimum KFLAGS and LIBS items and then chain to the main Linux entry, which
    figures out all the rest.

    http://www.columbia.edu/kermit/ckdaily.html

    - Frank

  12. Re: secure ftp - tls with ckermit client

    Frank da Cruz wrote:
    > On 2006-03-24, dold@XReXXsecur.usenet.us.com wrote:
    > : Frank da Cruz wrote:
    > :> Try the current development build:
    > :>
    > :> http://www.columbia.edu/kermit/ckdaily.html
    > :
    > : That was mean ;-(
    > :
    > : The x.zip is missing two files, compared to the x.tar.gz.
    > :
    > Which ones?


    makefile was the one that caught my eye, and there was one other one.
    Today's build is even worse, 67 files verses 58.
    588$ diff x.zip-ls x.tar.gz-ls
    2a3
    > ck_des.c

    56,66d56
    < ckvcon.c
    < ckvcvt.c
    < ckvfio.c
    < ckvioc.c
    < ckvioc.h
    < ckvker.com
    < ckvker.mms
    < ckvold.c
    < ckvold.com
    < ckvtio.c
    < ckvvms.h
    67a58
    > makefile


    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  13. Re: secure ftp - tls with ckermit client

    Frank da Cruz wrote:
    > Today I uploaded Dev.17, which has three new targets for Linux:


    > linux+krb5+ssl
    > linux+ssl
    > linux+krb5


    > These work, at least in Red Hat AS4.3. Hopefully other combinations can
    > be modeled on these entries, which do it "right" -- they just set the bare
    > minimum KFLAGS and LIBS items and then chain to the main Linux entry, which
    > figures out all the rest.


    > http://www.columbia.edu/kermit/ckdaily.html


    These new ones and more all build on my CentOS platform.

    I haven't actually tested any of them.
    It would be helpful for the makefile to contain some history.

    If each makefile entry had a date alongside it, one could make some guesses
    about which had superceeded another. For instance, I think that on
    2006-03-27, linux+ssl is preferred to redhat21+ssl, and much preferred over
    linux+openssl, which is old.

    Lacking some chronological clue, I might think that the more items listed,
    the better, so linux+openssl+zlib+shadow+pam would look best for my current
    installation.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  14. Re: secure ftp - tls with ckermit client

    dold@XReXXsecur.usenet.us.com wrote:
    > Jeffrey Altman wrote:


    > I know that. What I am trying to confirm is that the proftpd login is
    > actually providing the encryption that it's supposed to provide(*). I said
    > that it is, because I can see "private". You said it's not, because the
    > /tls is not accepted on the ftp open command line. Kermit-95 connects to
    > this site without a /tls on the command line, or in the script that it
    > generates.


    That is not what I said at all.

    As I have pointed out several times now. You are confusing two
    different protocols both of combine FTP and TLS. There is "FTP over
    TLS" which is implemented in Kermit by "FTP OPEN /TLS " and
    "FTP AUTH TLS" which is implemented by negotiating the FTP AUTH command
    after an initial FTP session is established.

    "FTP over TLS" is not implemented by the server you are connecting to.

    "FTP AUTH TLS" is implemented by the server.

    Both are secure methods of performing FTP sessions when configured
    correctly. The server you are connecting to is not configured
    correctly and is therefore insecure.

    Jeffrey Altman

  15. Re: secure ftp - tls with ckermit client

    Jeffrey Altman wrote:
    > "FTP over TLS" is not implemented by the server you are connecting to.
    > "FTP AUTH TLS" is implemented by the server.


    > Both are secure methods of performing FTP sessions when configured
    > correctly.


    Thank you. I was not able to distinguish between those two.

    "FTP over TLS" is not implemeted, but not needed for proper security?
    Is this similar to sftp, or "FTP over SSH", which is another secure ftp,
    also not supported by this server?

    > The server you are connecting to is not configured correctly and is
    > therefore insecure.


    Is this a reference solely to the certificate?
    If that is true, I have asked to have that corrected.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  16. Re: secure ftp - tls with ckermit client

    On 2006-03-28, dold@XReXXsecur.usenet.us.com wrote:
    : ...
    : It would be helpful for the makefile to contain some history.
    :
    : If each makefile entry had a date alongside it, one could make some guesses
    : about which had superceeded another. For instance, I think that on
    : 2006-03-27, linux+ssl is preferred to redhat21+ssl, and much preferred over
    : linux+openssl, which is old.
    :
    It would be hard to do this retroactively but I'll try to do it from now on.

    : Lacking some chronological clue, I might think that the more items listed,
    : the better, so linux+openssl+zlib+shadow+pam would look best for my current
    : installation.
    :
    So far the Linux targets are only partially cleaned up.

    - Frank

  17. Re: secure ftp - tls with ckermit client

    On 2006-03-27, dold@XReXXsecur.usenet.us.com wrote:
    : Frank da Cruz wrote:
    :> On 2006-03-24, dold@XReXXsecur.usenet.us.com wrote:
    :> : ...
    :> : The x.zip is missing two files, compared to the x.tar.gz.
    :> :
    :> Which ones?
    :
    : makefile was the one that caught my eye, and there was one other one.
    : Today's build is even worse, 67 files verses 58.
    : 588$ diff x.zip-ls x.tar.gz-ls
    : 2a3
    :> ck_des.c
    : 56,66d56
    :< ckvcon.c
    :< ckvcvt.c
    :< ckvfio.c
    :< ckvioc.c
    :< ckvioc.h
    :< ckvker.com
    :< ckvker.mms
    :< ckvold.c
    :< ckvold.com
    :< ckvtio.c
    :< ckvvms.h
    : 67a58
    :> makefile
    :
    The Zip file adds the files needed for VMS. VMS is the whole reason we
    have a Zip file. The tar archives can't be used in VMS (as a rule). And
    the VMS files are generally not wanted in Unix. But in case you do want
    them on a Unix system, you can get the Zip file instead of the Tar one.

    So yes, the Zip archive should include the Unix makefile; I added this to
    the upload script just now, thanks.

    - Frank

  18. Re: secure ftp - tls with ckermit client

    Frank da Cruz wrote:
    > The Zip file adds the files needed for VMS. VMS is the whole reason we
    > have a Zip file. The tar archives can't be used in VMS (as a rule). And
    > the VMS files are generally not wanted in Unix. But in case you do want
    > them on a Unix system, you can get the Zip file instead of the Tar one.


    The zip was a subset of the tar, so the comment confuses me, but there is
    no indication that the three package styles are anything but three package
    styles. I assumed the content was identical.

    I'm just a zippy kind of guy ;-)
    Zip and kermit are available on all kinds of different platforms
    interchangeably.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8,-122.5

  19. Re: secure ftp - tls with ckermit client


    dold@XReXXsecur.usenet.us.com wrote:

    > Lacking some chronological clue, I might think that the more items listed,
    > the better, so linux+openssl+zlib+shadow+pam would look best for my current
    > installation.


    That's my current compilation target on Debian GNU/Linux, with the
    -DOPENSSL_097 define and the openssl include and library directories
    tweaked, and the MANDIR tweaked to match Debian conventions.

    Arthur.

+ Reply to Thread