[9fans] APE libsec

[Yaroslav]

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 signatures a9aa533a(/386/lib/ape/libap.a(freopen)) and aebfd74f(/386/lib/libc.a(calloc)) for open

ppanic: incompatible type signatures 4dcf09c4(/386/lib/ape/libap.a(_IO_putc)) and 55e8553c(/386/lib/libc.a(calloc)) for write

malloc: /386/lib/libc.a(calloc): redefinition: malloc

(1070) TEXT malloc+0(SB),$24

free: /386/lib/libc.a(calloc): redefinition: free

...

Could someone suggest a method for tracking down the library/object file which contains the loader instruction to load /386/lib/libc.a?

Thanks.

--
- Yaroslav

[Yaroslav]

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 mcs.8 mppc.8 orders.8 pstcache.8 rdesktop.8 rdp.8 rdp5.8 seamless.8 secure.8 tcp.8 snarf.8 xkeymap.8 xwin.8 

mpkaratsuba: undefined: mallocz

_PIPE: argv0: not defined

pcc: 8l: 8l 97689: error

The mp.h fix:

/n/sources/plan9/sys/include/ape/mp.h:5,12 - /sys/include/ape/mp.h:5,12

  #ifndef __LIBMP_H_

  #define __LIBMP_H_

  

- #pragma src "/sys/src/libmp"

- #pragma lib "libmp.a"

+ #pragma src "/sys/src/ape/lib/mp"

+ #pragma lib "/$M/lib/ape/libmp.a"

  

  typedef unsigned int mpdigit; /* from /$objtype/include/u.h */

  

2013/2/4 Yaroslav <yar...@gmail.com>

--
- Yaroslav

[lu...@proxima.alt.za]

> 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 work, in general I find it faster to fix these things
than to figure how to explain them (I can explain afterwards), if you
don't mind.

I have noted your next message, I think you chopped off more than was
required.

++L

[erik quanstrom]

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 need to recompile some modules so they are up to date.

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.

- erik

[lu...@proxima.alt.za]

> 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

[Jeff Sickel]

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

[Jens Staal]

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
"native" pthread implementation would be cool.

[yaroslav]

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,
ALG_sha1WithRSAEncryptionOiw,
ALG_md5,
+ ALG_sha256WithRSAEncryption,
+ ALG_shaWithRSASignatureOiw,
NUMALGS
};
typedef struct Ints7 {
/n/sources/plan9/sys/src/ape/lib/sec/port/x509-ape.c:1596,1601 - /sys/src/ape/lib/sec/port/x509-ape.c:1598,1605
static Ints7 oid_sha1WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 5 };
static Ints7 oid_sha1WithRSAEncryptionOiw ={6, 1, 3, 14, 3, 2, 29 };
static Ints7 oid_md5 ={6, 1, 2, 840, 113549, 2, 5, 0 };
+ static Ints7 oid_sha256WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 11 };
+ static Ints7 oid_shaWithRSASignatureOiw ={6, 1, 3, 14, 3, 2, 15 };
static Ints *alg_oid_tab[NUMALGS+1] = {
(Ints*)&oid_rsaEncryption,
(Ints*)&oid_md2WithRSAEncryption,
/n/sources/plan9/sys/src/ape/lib/sec/port/x509-ape.c:1604,1609 - /sys/src/ape/lib/sec/port/x509-ape.c:1608,1615
(Ints*)&oid_sha1WithRSAEncryption,
(Ints*)&oid_sha1WithRSAEncryptionOiw,
(Ints*)&oid_md5,
+ (Ints*)&oid_sha256WithRSAEncryption,
+ (Ints*)&oid_shaWithRSASignatureOiw,
nil
};
static DigestFun digestalg[NUMALGS+1] = { md5, md5, md5, md5, sha1, sha1, md5, nil };

[erik quanstrom]

we haven't investigated. you're welcome to try.

the immediate goal is to get hg and python working properly
on all arches we've currently got. we're desperately trying not
to drag anything else along.

- erik

[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?

- 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/x509.c
/n/dump/2013/0205/sys/src/libsec/port/x509.c:1582,1587 - /sys/src/libsec/port/x509.c:1582,1589
ALG_md5WithRSAEncryption,
ALG_sha1WithRSAEncryption,
ALG_sha1WithRSAEncryptionOiw,
+ ALG_sha256WithRSAEncryption,
+ ALG_shaWithRSASignatureOiw,
ALG_md5,
NUMALGS
};
/n/dump/2013/0205/sys/src/libsec/port/x509.c:1595,1600 - /sys/src/libsec/port/x509.c:1597,1604
static Ints7 oid_md5WithRSAEncryption = {7, 1, 2, 840, 113549, 1, 1, 4 };

static Ints7 oid_sha1WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 5 };
static Ints7 oid_sha1WithRSAEncryptionOiw ={6, 1, 3, 14, 3, 2, 29 };

+ static Ints7 oid_sha256WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 11 };
+ static Ints7 oid_shaWithRSASignatureOiw ={6, 1, 3, 14, 3, 2, 15 };
static Ints7 oid_md5 ={6, 1, 2, 840, 113549, 2, 5, 0 };
static Ints *alg_oid_tab[NUMALGS+1] = {
(Ints*)&oid_rsaEncryption,

/n/dump/2013/0205/sys/src/libsec/port/x509.c:1603,1608 - /sys/src/libsec/port/x509.c:1607,1614
(Ints*)&oid_md5WithRSAEncryption,
(Ints*)&oid_sha1WithRSAEncryption,
(Ints*)&oid_sha1WithRSAEncryptionOiw,
+ (Ints*)&oid_sha256WithRSAEncryption,
+ (Ints*)&oid_shaWithRSASignatureOiw,
(Ints*)&oid_md5,
nil
};
diff -c /n/dump/2013/0205/sys/src/ape/lib/sec/port/x509-ape.c /sys/src/ape/lib/sec/port/x509-ape.c
/n/dump/2013/0205/sys/src/ape/lib/sec/port/x509-ape.c:1582,1587 - /sys/src/ape/lib/sec/port/x509-ape.c:1582,1589
ALG_md5WithRSAEncryption,
ALG_sha1WithRSAEncryption,
ALG_sha1WithRSAEncryptionOiw,
+ ALG_sha256WithRSAEncryption,
+ ALG_shaWithRSASignatureOiw,
ALG_md5,
NUMALGS
};
/n/dump/2013/0205/sys/src/ape/lib/sec/port/x509-ape.c:1595,1600 - /sys/src/ape/lib/sec/port/x509-ape.c:1597,1604
static Ints7 oid_md5WithRSAEncryption = {7, 1, 2, 840, 113549, 1, 1, 4 };

static Ints7 oid_sha1WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 5 };
static Ints7 oid_sha1WithRSAEncryptionOiw ={6, 1, 3, 14, 3, 2, 29 };

+ static Ints7 oid_sha256WithRSAEncryption ={7, 1, 2, 840, 113549, 1, 1, 11 };
+ static Ints7 oid_shaWithRSASignatureOiw ={6, 1, 3, 14, 3, 2, 15 };
static Ints7 oid_md5 ={6, 1, 2, 840, 113549, 2, 5, 0 };
static Ints *alg_oid_tab[NUMALGS+1] = {
(Ints*)&oid_rsaEncryption,

/n/dump/2013/0205/sys/src/ape/lib/sec/port/x509-ape.c:1603,1608 - /sys/src/ape/lib/sec/port/x509-ape.c:1607,1614
(Ints*)&oid_md5WithRSAEncryption,
(Ints*)&oid_sha1WithRSAEncryption,
(Ints*)&oid_sha1WithRSAEncryptionOiw,
+ (Ints*)&oid_sha256WithRSAEncryption,
+ (Ints*)&oid_shaWithRSASignatureOiw,
(Ints*)&oid_md5,
nil
};

[Yaroslav]

2013/2/5 erik quanstrom <quan...@quanstro.net>

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

[Jeff Sickel]

I really think the APE variant should be picked up as
a(n s)ed script in the mkfile. That way we can track
a single x509.c file.

[michaelian ennis]

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