wasm-demo/demo/ermis-f/python_m/cur/0731

90 lines
3.9 KiB
Plaintext

From: mal at lemburg.com (M.-A. Lemburg)
Date: Tue, 06 Apr 1999 20:37:42 +0200
Subject: SNMPy update
References: <7e1hiq$a71$1@Starbase.NeoSoft.COM>
<7ear25$ksf$1@news-sj-3.cisco.com>
<14089.11820.416453.80124@bitdiddle.cnri.reston.va.us>
<3709C8BE.4257C9F1@lemburg.com> <14090.16807.950025.496495@bitdiddle.cnri.reston.va.us>
Message-ID: <370A5476.3AE3A7C1@lemburg.com>
Content-Length: 3483
X-UID: 731
Jeremy Hylton wrote:
>
> >>>>> "MAL" == M -A Lemburg <mal at lemburg.com> writes:
>
> MAL> Jeremy Hylton wrote:
> >> I'll second your sentiment! I did some work on an X.509 library
> >> written entirely in Python. Like you friend's SNMP code, it will
> >> probably never be released; I don't have time to finish it nor
> >> did I expect that I'd want to release it given the export control
> >> hassles.
>
> MAL> Just want to note that SSLeay/OpenSSL includes a pretty
> MAL> complete X.509 lib and also routines to do ASN.1 encoding an
> MAL> decoding. The main argument for using OpenSSL in this context
> MAL> is, of course, that no export control restrictions apply.
>
> Absolutely! There are a number of good reasons for using OpenSSL
> other than export control as well. OpenSSL buys you all of SSL as
> well as a lot of X.509 (and more of that every day). A Python
> application built on a SWIGed OpenSSL, however, has a *lot* of C code
> underneath it -- with all the problems a large C program has. A pure
> Python implementation of X.509 could be easier to understand, debug,
> and maintain.
Luckily, there's a whole team of people looking into this and
it is already pretty well debugged, so this may not be a
serious issue. The size is a problem though: you wouldn't want
OpenSSL sitting around in your memory on e.g. Windows CE :-)
> >> However, it seemed clear to me that an ASN.1 compiler could be
> >> written to generate the encode/decode routines. If someone is
> >> interested in that, I've got some design notes and rough code on
> >> how to do the encode/decode and on how to build a backend for
> >> SNACC. (A free-ish ASN.1 compiler; the only one?)
>
> MAL> Not sure what you mean with "ASN.1" compiler. If you want a
> MAL> compiler that does ASN.1 description -> Python function calling
> MAL> de/encoding routines kind of thing, then I guess the ASN.1
> MAL> stuff in OpenSSL could help you getting started quite fast.
>
> It seems awfully hard to separate the ASN.1 specific stuff out of
> OpenSSL. It uses it owns I/O abstractions and some moderately hair C
> data structures to manage the results. It's a lot simpler to just
> write the encode/decode routines in pure Python.
True. Using the struct module should get you the same results
on all supported platforms.
> MAL> Note that I have a project running with the intention to wrap
> MAL> OpenSSL in an OO manner called mxCrypto (see the link below).
>
> Looking forward to seeing it. When do you think you might have an
> alpha release ready?
I'm planning to wrap the ASN.1 stuff in the near future, since
it comes in handy when en/decoding keys used by the public key
algorithms.
Not sure when an alpha will be ready though. Right now I have
all the ciphers and hash functions wrapped, as well as RSA
and Diffie-Hellman. All takes a little longer, since I want to
do the wrapping in nice OO and not just simply tear out the
functions and use them on the raw data.
Maybe you could write the ASN.1 compiler stuff with an OO
structure in mind ?! That would make it possible to use it
for the stuff in mxCrypto too (with a speed gain I suppose).
--
Marc-Andre Lemburg Y2000: 269 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------