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

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 */

Post by 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
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

[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

Post by Yaroslav
/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 */

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

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]

Post by 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

[Jeff Sickel]

Post by 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 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

[l***@proxima.alt.za]

Post by Yaroslav
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]

Post by l***@proxima.alt.za

Post by Yaroslav
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

[l***@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

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

[erik quanstrom]

Post by 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.

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