I notice that there are several ANSI C implementations of crypto
routines contained in pycrypto if that is of any use.
https://github.com/dlitz/pycrypto/tree/master/src
Ian
On Feb 8, 2013, at 9:35 AM, Yaroslav wrote:
>
> 2013/2/5 erik quanstrom
> looks good, but i'd do libsec at the same time.
> unless you know of a compelling reason for these
> to support a different set of algorithms?
>
> Agree.
>
> /n/sources/patch/x509-oids
I really think the APE variant s
2013/2/5 erik quanstrom
> looks good, but i'd do libsec at the same time.
> unless you know of a compelling reason for these
> to support a different set of algorithms?
>
Agree.
/n/sources/patch/x509-oids
looks good, but i'd do libsec at the same time.
unless you know of a compelling reason for these
to support a different set of algorithms?
- erik
; diffy -c /sys/src/libsec/port/x509.c /sys/src/ape/lib/sec/port/x509-ape.c
diff -c /n/dump/2013/0205/sys/src/libsec/port/x509.c /sys/src/libsec/port/
On Tue Feb 5 03:42:51 EST 2013, staal1...@gmail.com wrote:
> Sorry if this may sound ignorant and clueless, but would a similar port of
> the
> Plan9 thread(2) to APE be possible - in particular in a form where stuff are
> exposed through the headers as a standard pthreads solution?
>
> Right
Sorry if this may sound ignorant and clueless, but would a similar port of the
Plan9 thread(2) to APE be possible - in particular in a form where stuff are
exposed through the headers as a standard pthreads solution?
Right now I have noticed that I use GNU Pth extensively under APE, but a more
Could you please include following changes to
/sys/src/ape/lib/sec/port/x509-ape.c: this is for X509toRSApub(2) to
accept some ms-generated certs:
/n/sources/plan9/sys/src/ape/lib/sec/port/x509-ape.c:1583,1588 -
/sys/src/ape/lib/sec/port/x509-ape.c:1583,1590
ALG_sha1WithRSAEncryption,
Whew, the libsec.h file was correct on the first push.
APE builds of libmp and libsec are being rolled in to support a new Python
2.7.3+
port. Like what you've started doing, the new Python port will not have OpenSSL
linked in and instead uses libsec.
-jas
On Feb 4, 2013, at 5:44 AM, Yaroslav
> it is exactly that you don't want libc references in ape!
> libc will drag in its own functions, and bring in the incorrect
> versions of things.
Oops, I forgot about libap.a!
Sorry, everyone.
++L
On Mon Feb 4 08:07:57 EST 2013, lu...@proxima.alt.za wrote:
> > Could someone suggest a method for tracking down the library/object file
> > which contains the loader instruction to load /386/lib/libc.a?
>
> It's not that you don't want libc references (what you would you have
> instead?), you ne
> Could someone suggest a method for tracking down the library/object file
> which contains the loader instruction to load /386/lib/libc.a?
It's not that you don't want libc references (what you would you have
instead?), you need to recompile some modules so they are up to date.
Point me to your
Aha! This ape/mp.h references the native lib not ape one. Applying the fix
below and recompiling ape/lib/mp and ape/lib/sec eliminates the reference
to /386/lib/libc.a, leaving just a few of unresolved references:
pcc -o 8.out bitmap.8 cache.8 channels.8 cliprdr.8 ewmhints.8 frpc.8 iso.8
licence.8
Hi,
I've noticed there are libsec/libmp became available for APE programs, and
dove into replacing OpenSSL calls with libsec equivalents. However, there
are still a reference to the native libc lurks somewhere in the ports as
the linker reports conflicts like these:
checkenv: incompatible type si
13 matches
Mail list logo
