Re: CVS commit: src/sys/uvm

2020-05-10 Thread Alistair Crooks
On Sat, 9 May 2020 at 14:50, Taylor R Campbell  wrote:

> Module Name:src
> Committed By:   riastradh
> Date:   Sat May  9 21:50:39 UTC 2020
>
> Modified Files:
> src/sys/uvm: uvm_swap.c
>
> Log Message:
> Implement swap encryption.
>
> Enabled by sysctl -w vm.swap_encrypt=1.  Key is generated lazily when
> we first need to swap a page.  Key is chosen independently for each
> swap device.  The ith swap page is encrypted with AES256-CBC using
> AES256_k(le32enc(i) || 0^96) as the initialization vector.  Can be
> changed at any time; no need for compatibility with on-disk formats.
> Costs one bit of memory per page in each swapdev, plus a few hundred
> bytes per swapdev to store the expanded AES key.
>
> Shoulda done this decades ago!  Plan to enable this by default;
> performance impact is unlikely to matter because it only happens when
> you're already swapping anyway.  Much easier to set up than cgd, so
> we can rip out all the documentation about carefully setting up
> random-keyed cgd at the right time.
>
> Thanks, this is great - looking forward to it being default!

Best,
Alistair


Re: CVS commit: src/lib/librumpuser

2020-05-06 Thread Alistair Crooks
On Tue, 5 May 2020 at 20:54, Kamil Rytarowski  wrote:

> Ping? We are blocked by this in GSoC now.
>
>
> I doubt that you are "blocked by this in GSoC", as the GSoC projects were
just announced yesterday.

You should be planning the milestones right now with your student


Re: CVS commit: src/sys/dev/ic

2019-07-02 Thread Alistair Crooks
Awesome, Jared - many thanks for this!

On Fri, 28 Jun 2019 at 08:08, Jared D. McNeill  wrote:

> Module Name:src
> Committed By:   jmcneill
> Date:   Fri Jun 28 15:08:47 UTC 2019
>
> Modified Files:
> src/sys/dev/ic: nvme.c nvmevar.h
>
> Log Message:
> Fix a performance issue where one busy queue can starve all other queues.
>
> In normal operations with multiple queues, the nvme driver will attempt
> to schedule I/O requests on the submitting CPU. This breaks down when any
> one of the queues becomes full; the driver returns EAGAIN to the disk
> layer, which causes the disk layer to stop submitting more requests until
> the blocked request is consumed. When space becomes available in the full
> queue, it pulls the next buffer from the bufq and fills the queue again,
> until finally hitting EAGAIN and preventing other queues from processing
> requests.
>
> Two changes here to fix the problem:
>
>  - When processing requests from the bufq, attempt to assign them to the
>queue associated with the CPU that originated the request.
>  - If that queue is busy, try to find another queue with available space
>before returning EAGAIN. This way, only when all queues are full will
>the disk layer stop submitting more requests.
>
> Now for some real numbers. On a Rockchip RK3399 board (6 CPUs), with 6
> concurrent readers:
>
> Old code:
> 4294967296 bytes transferred in 52.420 secs (81933752 bytes/sec)
> 4294967296 bytes transferred in 53.969 secs (79582117 bytes/sec)
> 4294967296 bytes transferred in 55.391 secs (77539082 bytes/sec)
> 4294967296 bytes transferred in 55.649 secs (77179595 bytes/sec)
> 4294967296 bytes transferred in 56.102 secs (76556402 bytes/sec)
> 4294967296 bytes transferred in 72.901 secs (58915066 bytes/sec)
>
> New code:
> 4294967296 bytes transferred in 37.171 secs (115546186 bytes/sec)
> 4294967296 bytes transferred in 37.611 secs (114194445 bytes/sec)
> 4294967296 bytes transferred in 37.655 secs (114061009 bytes/sec)
> 4294967296 bytes transferred in 38.247 secs (112295534 bytes/sec)
> 4294967296 bytes transferred in 38.496 secs (111569183 bytes/sec)
> 4294967296 bytes transferred in 38.595 secs (111282997 bytes/sec)
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.43 -r1.44 src/sys/dev/ic/nvme.c
> cvs rdiff -u -r1.19 -r1.20 src/sys/dev/ic/nvmevar.h
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>


Re: CVS commit: src/sys/arch/i386/stand

2018-02-21 Thread Alistair Crooks
Thanks, Christos.

This should also fix PR/53045 (qemu booting).

On 21 February 2018 at 17:37, Christos Zoulas  wrote:
> Module Name:src
> Committed By:   christos
> Date:   Thu Feb 22 01:37:04 UTC 2018
>
> Modified Files:
> src/sys/arch/i386/stand: Makefile.inc
>
> Log Message:
> gcc-6 needs -nosse
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.13 -r1.14 src/sys/arch/i386/stand/Makefile.inc
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/sys/arch/x86/x86

2017-10-21 Thread Alistair Crooks
Oh, nice! This is great :)

Thank you for all your work on this, pkboot, kaslr and the pmap.

Best,
Alistair

On 21 October 2017 at 01:27, Maxime Villard  wrote:
> Module Name:src
> Committed By:   maxv
> Date:   Sat Oct 21 08:27:19 UTC 2017
>
> Modified Files:
> src/sys/arch/x86/x86: sys_machdep.c
>
> Log Message:
> Forbid 64bit entries. That's it, now we support USER_LDT on amd64.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.42 -r1.43 src/sys/arch/x86/x86/sys_machdep.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src

2017-04-14 Thread Alistair Crooks
This is really neat - thanks!

Alistair

On 13 April 2017 at 19:43, Ryota Ozaki  wrote:
> Module Name:src
> Committed By:   ozaki-r
> Date:   Fri Apr 14 02:43:28 UTC 2017
>
> Modified Files:
> src/distrib/sets/lists/base: shl.mi
> src/distrib/sets/lists/comp: mi shl.mi
> src/distrib/sets/lists/debug: mi shl.mi
> src/sys/netinet: in_proto.c
> src/sys/netinet6: in6_proto.c
> src/sys/rump/librump/rumpnet: Makefile.rumpnet net_stub.c
> src/sys/rump/net: Makefile.rumpnetcomp
> src/sys/rump/net/lib/libnetinet: Makefile.inc
> src/sys/rump/net/lib/libnetinet6: Makefile.inc
> Added Files:
> src/sys/rump/net/lib/libnetipsec: Makefile Makefile.inc
> netipsec_component.c
>
> Log Message:
> Rumpify netipsec
>
> Note that we should modularize netipsec and reduce reverse symbol references
> (referencing symbols of netipsec from net, netinet and netinet6) though,
> the task needs lots of code changes. Prior to doing so, rumpifying it and
> having ATF tests should be useful.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.806 -r1.807 src/distrib/sets/lists/base/shl.mi
> cvs rdiff -u -r1.2119 -r1.2120 src/distrib/sets/lists/comp/mi
> cvs rdiff -u -r1.301 -r1.302 src/distrib/sets/lists/comp/shl.mi
> cvs rdiff -u -r1.204 -r1.205 src/distrib/sets/lists/debug/mi
> cvs rdiff -u -r1.164 -r1.165 src/distrib/sets/lists/debug/shl.mi
> cvs rdiff -u -r1.122 -r1.123 src/sys/netinet/in_proto.c
> cvs rdiff -u -r1.116 -r1.117 src/sys/netinet6/in6_proto.c
> cvs rdiff -u -r1.21 -r1.22 src/sys/rump/librump/rumpnet/Makefile.rumpnet
> cvs rdiff -u -r1.25 -r1.26 src/sys/rump/librump/rumpnet/net_stub.c
> cvs rdiff -u -r1.17 -r1.18 src/sys/rump/net/Makefile.rumpnetcomp
> cvs rdiff -u -r1.13 -r1.14 src/sys/rump/net/lib/libnetinet/Makefile.inc
> cvs rdiff -u -r1.3 -r1.4 src/sys/rump/net/lib/libnetinet6/Makefile.inc
> cvs rdiff -u -r0 -r1.1 src/sys/rump/net/lib/libnetipsec/Makefile \
> src/sys/rump/net/lib/libnetipsec/Makefile.inc \
> src/sys/rump/net/lib/libnetipsec/netipsec_component.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src

2017-02-19 Thread Alistair Crooks
Thanks, but I'd really like it if netpgp would work the same on all pkgsrc
platforms:

The linux man page for getpass(3) (https://linux.die.net/man/3/getpass)
says:

The function *getpass*() returns a pointer to a static buffer containing
(the first *PASS_MAX* bytes of) the password without the trailing newline,
terminated by a null byte ('\0'). This buffer may be overwritten by a
following call. On error, the terminal state is restored, *errno* is set
appropriately, and NULL is returned.


On 19 February 2017 at 17:38, Pierre Pronchery  wrote:

> Module Name:src
> Committed By:   khorben
> Date:   Mon Feb 20 01:38:28 UTC 2017
>
> Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: netpgp.c
> src/crypto/external/bsd/netpgp/dist/src/librsa: rsastubs.c
>
> Log Message:
> Remove a useless loop around getpass()
>
> According to getpass(3), this library function cannot return NULL.
> Verified with a source code inspection.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.98 -r1.99 \
> src/crypto/external/bsd/netpgp/dist/src/lib/netpgp.c
> cvs rdiff -u -r1.2 -r1.3 \
> src/crypto/external/bsd/netpgp/dist/src/librsa/rsastubs.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>


Re: CVS commit: othersrc/external/bsd/set2pkg

2016-06-11 Thread Alistair Crooks
Thanks for the cleanups.

I'm not sure about the "sort options" one - in the Synopsis, and every
ascii(7) man page I've seen, 'V' precedes 'a'. Is there a rationale
for that being different in the "Options" section, with 'V' sorting
after 'a' and before 'v'?

Best,
Alistair

On 10 June 2016 at 23:17, Thomas Klausner  wrote:
> Module Name:othersrc
> Committed By:   wiz
> Date:   Sat Jun 11 06:17:43 UTC 2016
>
> Modified Files:
> othersrc/external/bsd/set2pkg: set2pkg.1
>
> Log Message:
> Sort options. Use Nx. Uppercase start of sentence.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.1 -r1.2 othersrc/external/bsd/set2pkg/set2pkg.1
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/sys/ufs/ffs

2016-05-07 Thread Alistair Crooks
pea

(Please Expand Acronyms)

Thx,
agc

On 7 May 2016 at 04:59, Maxime Villard  wrote:
> Module Name:src
> Committed By:   maxv
> Date:   Sat May  7 11:59:09 UTC 2016
>
> Modified Files:
> src/sys/ufs/ffs: ffs_subr.c
>
> Log Message:
> uaf
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.48 -r1.49 src/sys/ufs/ffs/ffs_subr.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS import: othersrc/external/mit/micropython

2016-01-16 Thread Alistair Crooks
Taken from othersrc/README:

"The "othersrc" collection consists of programs that are either "not
ready for the main tree" or "never going to be ready for the main
tree" but which are NOT appropriate to pkgsrc because they have no
external maintainer."

In this case, it's a case of not quite ready for the main tree - I've
been looking for a small, embeddable python for a long time (cpython
doesn't quite hit those checklist items), and micropython fits the
bill. I found that tinypy
(http://www.philhassey.com/blog/wp-content/uploads/2008/02/tinypy.tgz)
was too difficult to modify, and was fairly long in the tooth these
days. Micropython, OTOH, is a 3.4 clone, which works well for me. The
problem, as ever, is in libffi - then there is library function
support, and, after that, module support, but I think this is a step
in the right direction.

I talked briefly to christos about micropython, and he encouraged me
to take it to tech-misc, and I shall try to do that, but I'm behind on
so much mail right now, it's embarassing.

My goal is to have micropython be next to lua in the toolchain, not in
place of it (although I think there's going to come a time quite soon
where lua is going to have to justify its existence, and not just the
netpgp bindings I wrote, as I also did perl, python and tcl bindings
at the same time).

Definitely not aiming to be a fork - the external sources were
imported on a vendor branch, and local fixes for reachover
infrastructure and NetBSD packaging were added afterwards so that we
can incorporate future updates from upstream.

I have a pkgsrc entry made for it micropython-1.5.2, will try to add it RSN.

Best,
Alistair

On 16 January 2016 at 05:42, Kamil Rytarowski  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 14.01.2016 02:38, Alistair G. Crooks wrote:
>> Module Name:  othersrc Committed By:  agc Date:   Thu Jan 14 
>> 01:38:53
>> UTC 2016
>>
>> Update of /cvsroot/othersrc/external/mit/micropython In directory
>> ivanova.netbsd.org:/tmp/cvs-serv18307
>>
>> Log Message: Import micropython version 1.5.2 into othersrc.
>>
>> Micropython is a python3 implementation that has been optimised
>> for micro-controllers and small embedded systems.  It also has a
>> "unix" port. It has an MIT license.
>>
>
> Does it mean that it's prepared to be used as an extra set (located in
> othersrc/) of sources in the NetBSD base?
>
> Is it going to be evaluated for inclusion to base (next to Lua)?
>
> Is aimed to be a fork?
>
> Why not in pkgsrc?
>
> Thanks for making it clear.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWmkjbAAoJEEuzCOmwLnZsF3gP/RN9BpGOMNkTk7veDcEEXSxE
> D+KJFOtRmg+lyocuK8heDt3KbKO6UaLBc1n30DMKYZ/u1wcm6es2XEe6kmqTcQLf
> KZ3WH1QQwfpQpcuq/T9Lvo9ZZQwn0ui4ZGEERARadsJOPYL5IFOczVvJFJGgMlNT
> qWfSYxHYbKnxa9Ftn0oGsKHJPmsCUxvgKIpCKC3hUl8gbYw9H5wCyk8w0ZVWaor9
> fmqiNxbU6Mq4p3agNS3TLa/ISmetal8RqPFXsLIslUTA1dfDwP/xjxaZYBZEB54V
> Is9M1JxVnM7cOUAjmd5e/0fuxPMl3XA69lofBNkESdh/jYFGd+lEn59slfRSmlT/
> e8DKyWECS7dyjx2ne1XdUPrZ3tgwIGQmaYfAi7cqaabOQIaxh3e08Blo4LE+s1zU
> +3KZuojj5Z/jkYdK27E7XuROMslIuVIIYHWr8xjV08Pc1zoLbQXzm+VITtJltKWi
> 4c4VjjE2uTEfaP8N3MDG7JlyUBa8snAoJU1XDjdetoXW2cE3OOEpYJREGfjreT6i
> J+VlU+7Beu0VbJwnGBd7lkoZzdkC84Ph9nop190iMsuUKmXLvFMHgdkVsWhm9Hu6
> aGaTimrxBXGQYNosqxZgy4dOJU0aHFD/T/XCr623UsQY/pQ3TDfDe1V+6kBmm/7o
> woGjrYDz+QkVMe1HEvUp
> =lik+
> -END PGP SIGNATURE-
>


Re: CVS commit: src/external/cddl/osnet/sys/sys

2015-12-21 Thread Alistair Crooks
Nice catch!

Perhaps an entry in src/doc/HACKS would be appropriate?

Thanks,
Al

On 21 December 2015 at 05:28, Joerg Sonnenberger  wrote:
> Module Name:src
> Committed By:   joerg
> Date:   Mon Dec 21 13:28:39 UTC 2015
>
> Modified Files:
> src/external/cddl/osnet/sys/sys: time.h
>
> Log Message:
> Our time.h defines clock_gettime with assembler name after including
> sys/time.h. The Solaris compat code in sys/time.h wants to use it in an
> inline function, but misses a prototype (and the relabeling). As stopgap
> for getting consistent defines of clock_gettime duplicate the prototype
> here.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.4 -r1.5 src/external/cddl/osnet/sys/sys/time.h
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/libexec/httpd

2015-12-19 Thread Alistair Crooks
> (it seems that i let strdup(3) back in when i merged agc's library
> code, i should have caught that then.   oh well.)

My apologies about that, I wasn't careful enough.

Alistair


Re: CVS commit: src/sys/kern

2015-05-03 Thread Alistair Crooks
On Sun, May 03, 2015 at 09:48:43AM -0400, Tyler Retzlaff wrote:
 hey,
 
 On 5/2/2015 9:42 PM, Alistair Crooks wrote:
 Hi Tyler,
 
 On Sat, May 02, 2015 at 11:46:05PM +, Tyler R. Retzlaff wrote:
 Module Name:src
 Committed By:   rtr
 Date:   Sat May  2 23:46:04 UTC 2015
 
 Modified Files:
 src/sys/kern: uipc_socket.c
 
 Log Message:
 compare mbuf * pointer to NULL instead of 0
 @@ -941,7 +941,7 @@ sosend(struct socket *so, struct mbuf *a
 error = ENOTCONN;
 goto release;
 }
 -   } else if (addr == 0) {
 +   } else if (NULL == addr) {
 I really appreciate what you're doing with the mbuf conversion work.
 
 Having said that, I absolutely loathe the NULL == addr style of
 writing comparisons - it was introduced when compilers were stupid
 enough to think that a mistyped var = value could be misinterpreted
 as a conditional statement like var == value.
 
 i've committed a change to resolve this, thanks for raising it.

Thanks, Tyler, much appreciated!

Best,
Al


Re: CVS commit: src/sys/arch

2015-04-29 Thread Alistair Crooks
On Wed, Apr 29, 2015 at 08:32:01AM +, Hikaru Abe wrote:
 Module Name:  src
 Committed By: hikaru
 Date: Wed Apr 29 08:32:01 UTC 2015
 
 Modified Files:
   src/sys/arch/mips/conf: files.mips
   src/sys/arch/mips/include: cpuregs.h locore.h
   src/sys/arch/mips/mips: cache.c mips_machdep.c
 Added Files:
   src/sys/arch/evbmips/cavium: autoconf.c mach_intr.c machdep.c
   octeon_bootbus_machdep.c octeon_uboot.h
   src/sys/arch/evbmips/conf: ERLITE files.octeon
   src/sys/arch/mips/cavium: autoconf.h mainbus.c mainbus_octeon1p.c
   octeon1p_iobus.c octeon_bootbus.c octeon_dma.c octeon_intr.c
   octeon_iobus.c octeonvar.h
   src/sys/arch/mips/cavium/dev: if_cnmac.c if_cnmacvar.h octeon_asx.c
   octeon_asxreg.h octeon_asxvar.h octeon_bootbusreg.h octeon_ciu.c
   octeon_ciureg.h octeon_cop2reg.h octeon_cop2var.h octeon_corereg.h
   octeon_fau.c octeon_faureg.h octeon_fauvar.h octeon_fpa.c
   octeon_fpareg.h octeon_fpavar.h octeon_gmx.c octeon_gmxreg.h
   octeon_gmxvar.h octeon_gpioreg.h octeon_iobreg.h octeon_ipd.c
   octeon_ipdreg.h octeon_ipdvar.h octeon_l2creg.h octeon_mpi.c
   octeon_mpireg.h octeon_mpivar.h octeon_npireg.h octeon_pci.c
   octeon_pcmreg.h octeon_pip.c octeon_pipreg.h octeon_pipvar.h
   octeon_pko.c octeon_pkoreg.h octeon_pkovar.h octeon_pow.c
   octeon_powreg.h octeon_powvar.h octeon_rnm.c octeon_rnmreg.h
   octeon_smi.c octeon_smireg.h octeon_smivar.h octeon_tim.c
   octeon_timreg.h octeon_twsi.c octeon_twsireg.h octeon_uart.c
   octeon_uartreg.h octeon_usbc.c octeon_usbcreg.h octeon_usbcvar.h
   octeon_usbn.c octeon_usbnreg.h octeon_usbnvar.h
   src/sys/arch/mips/cavium/include: bootbusvar.h iobusvar.h mainbusvar.h
   src/sys/arch/mips/conf: files.octeon std.octeon
   src/sys/arch/mips/include: cache_octeon.h
   src/sys/arch/mips/mips: cache_octeon.c locore_octeon.S
 
 Log Message:
 Initial import of Cavium Octeon and Octeon Plus SoC and
 specifically Ubiquiti Networks EdgeRouter LITE support.
 Currently the ethernet and uart of are worked.
 This support was contributed by Internet Initiative Japan Inc.

Way cool - many thanks to you and IIJ!

Best,
Alistair


Re: CVS commit: src/sys

2015-01-23 Thread Alistair Crooks
On Fri, Jan 23, 2015 at 12:34:09PM +, Kenichi Hashimoto wrote:
 Module Name:  src
 Committed By: hkenken
 Date: Fri Jan 23 12:34:09 UTC 2015
 
 Modified Files:
   src/sys/arch/arm/conf: majors.arm32
   src/sys/arch/evbarm: Makefile
 Added Files:
   src/sys/arch/arm/zynq: files.zynq zynq7000_board.c zynq7000_intr.h
   zynq7000_reg.h zynq7000_sdhc.c zynq7000_uart.c zynq7000_usb.c
   zynq7000_var.h zynq_axi.c zynq_cemac.c zynq_dma.c zynq_slcr.c
   zynq_slcrreg.h zynq_slcrvar.h zynq_space.c zynq_uart.c
   zynq_uartreg.h zynq_uartvar.h zynq_usb.c zynq_usbreg.h
   zynq_usbvar.h
   src/sys/arch/evbarm/conf: PARALLELLA PARALLELLA_INSTALL ZEDBOARD
   ZEDBOARD_INSTALL files.parallella files.zedboard files.zynq mk.zynq
   std.zynq
   src/sys/arch/evbarm/zynq: genassym.cf platform.h zynq_machdep.c
   zynq_start.S
   src/sys/dev/cadence: cemacreg.h if_cemac.c if_cemacvar.h
 
 Log Message:
 Initial Zynq (Xilinx) support
 Add support for ZedBoard evaluation board and Parallella board.
 * cemac(4) Cadence EMAC/GEM(Gigabit) Ethernet Controller driver
   based on at91emac

Oh, neat, thanks!

Best,
Alistair


Re: CVS commit: src/libexec/httpd

2014-11-21 Thread Alistair Crooks
On Fri, Nov 21, 2014 at 08:54:12AM +, Mateusz Kocielski wrote:
 Module Name:  src
 Committed By: shm
 Date: Fri Nov 21 08:54:12 UTC 2014
 
 Modified Files:
   src/libexec/httpd: bozohttpd.c
 
 Log Message:
 Fixed off-by-one in virtualhost processing. Previous code was checking if
 Host header is a prefix of any existing vhost. This behaviour might be used to
 uncover existing vitual hosts from the remote.
 
 OK @mrg
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.57 -r1.58 src/libexec/httpd/bozohttpd.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 

 Modified files:
 
 Index: src/libexec/httpd/bozohttpd.c
 diff -u src/libexec/httpd/bozohttpd.c:1.57 src/libexec/httpd/bozohttpd.c:1.58
 --- src/libexec/httpd/bozohttpd.c:1.57Fri Oct 10 05:10:59 2014
 +++ src/libexec/httpd/bozohttpd.c Fri Nov 21 08:54:12 2014
 @@ -1,4 +1,4 @@
 -/*   $NetBSD: bozohttpd.c,v 1.57 2014/10/10 05:10:59 mrg Exp $   */
 +/*   $NetBSD: bozohttpd.c,v 1.58 2014/11/21 08:54:12 shm Exp $   */
  
  /*   $eterna: bozohttpd.c,v 1.178 2011/11/18 09:21:15 mrg Exp $  */
  
 @@ -1093,8 +1093,8 @@ check_virtual(bozo_httpreq_t *request)
   }
   debug((httpd, DEBUG_OBESE, looking at 
 dir``%s'',
  d-d_name));
 - if (strncasecmp(d-d_name, request-hr_host,
 - len) == 0) {
 + if (d-d_namlen == len  strcmp(d-d_name,
 + request-hr_host) == 0) {

I think we gained cASe-seNsItiVITy with this?

   /* found it, punch it */
   debug((httpd, DEBUG_OBESE, found it 
 punch it));
   request-hr_virthostname =
 



Re: CVS commit: othersrc/external/bsd/multigest

2014-10-28 Thread Alistair Crooks
On Tue, Oct 28, 2014 at 09:46:26AM -0400, Alan Barrett wrote:
 On Tue, 28 Oct 2014, Alistair G. Crooks wrote:
 Modified Files:
  othersrc/external/bsd/multigest/bin: Makefile
  othersrc/external/bsd/multigest/lib: Makefile
 +.ifndef PRINTOBJDIR
 +PRINTOBJDIR=${MAKE} -V .OBJDIR
 +.endif
 
 At least for NetBSD's make(1), you need ${MAKE} -V '${.OBJDIR}' to
 get the recursively-expanded value of .OBJDIR.  ${MAKE} -V .OBJDIR
 would print the unexpanded value.

Oh, you'd better fix it in NetBSD's bsd.own.mk then, which was where I took
the definition above from.

.if empty(.MAKEFLAGS:tW:M*-V .OBJDIR*)
.if defined(MAKEOBJDIRPREFIX) || defined(MAKEOBJDIR)
PRINTOBJDIR=${MAKE} -r -V .OBJDIR -f /dev/null xxx
.else
PRINTOBJDIR=${MAKE} -V .OBJDIR
.endif
.else
PRINTOBJDIR=echo /error/bsd.own.mk/PRINTOBJDIR # avoid infinite 
recursion
.endif

It also worked just fine on a FreeBSD 10.1-PRERELEASE machine (from Oct 24th):

 make -V .OBJDIR
/usr/home/agc/local/multigest/lib


Regards,
Alistair


Re: CVS commit: src/sys/fs/puffs

2014-10-05 Thread Alistair Crooks
On Sun, Oct 05, 2014 at 02:13:15PM +, Alan Barrett wrote:
  #ifdef PUFFSDEBUG
  extern int puffsdebug; /* puffs_subr.c */
 -#define DPRINTF(x) if (puffsdebug  0) printf x
 -#define DPRINTF_VERBOSE(x) if (puffsdebug  1) printf x
 +#define DPRINTF(x) do { \
 + if (puffsdebug  0) printf x; \
 + while (/*CONSTCOND*/0)

I think it'd be even more safe to close the block with a '}' before the
while.

 +#define DPRINTF_VERBOSE(x) do { \
 + if (puffsdebug  1) printf x; \
 + while (/*CONSTCOND*/0)

Here too.

  #else
 -#define DPRINTF(x)
 -#define DPRINTF_VERBOSE(x)
 +#define DPRINTF(x) ((void)0)
 +#define DPRINTF_VERBOSE(x) ((void)0)
  #endif
  
  #define MPTOPUFFSMP(mp) ((struct puffs_mount *)((mp)-mnt_data))

(I must admit, not compile-tested) 

Regards,
Alistair


Re: CVS commit: src/sys/sys

2013-10-16 Thread Alistair Crooks
On Wed, Oct 16, 2013 at 03:31:43PM -0400, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Wed Oct 16 19:31:43 UTC 2013
 
 Modified Files:
   src/sys/sys: cdefs.h
 
 Log Message:
 introduce __USE(variable) that uses a variable to squash unused variable
 warnings.
 [...]
  
 +#define __USE(a) ((void)(a))

I've long been using a macro like:

#define USE_ARG(x) /*LINTED*/(void)(x)

to get rid of unused arg warnings, after a conversation between dsl
and others (I think) on one of our lists.

Regards,
Al


Re: CVS commit: src/libexec/httpd

2013-10-12 Thread Alistair Crooks
On Sat, Oct 12, 2013 at 05:24:07PM +, Marc Balmer wrote:
 +#ifndef NO_LUA_SUPPORT
 +#include lua.h
 +#endif

Thanks for doing this, it's nice to get more lua support in-tree.

I really dislike the double negative in this one, though - it's much
easier for everyone if the definition was HAVE_LUA_SUPPORT and default
it to defined, or yes, or whatever.

Best,
Alistair


Re: CVS commit: [agc-symver] src/lib/libc

2013-03-31 Thread Alistair Crooks
On Sun, Mar 31, 2013 at 11:48:21AM +0900, Masao Uebayashi wrote:
 How do you generate Version.map?

With a script.
 
 Can you define symbols per-module (e.g., libc/gen, libc/stdio, ...)?

No, that makes no sense.  Symbols are per-library, and no-one wants to
manage multiple files for the symbols in one library.  What next? 
Multiple files for major, minor and teeny shlib_versions?

I'll commit some information regarding the symbol versioning methods RSN.

Regards,
Alistair
#! /bin/sh

# $NetBSD: genraidconf.sh,v 1.5 2011/05/19 00:24:22 agc Exp $

# Copyright (c) 2013 Alistair Crooks a...@netbsd.org
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#

# Usage: mkvermap c
#   makes symbol versioning info for /usr/lib/libc.so

major=0
minor=0
minimus=0
if [ -f shlib_version ]; then
. ./shlib_version
fi
os=$(uname -r)
output=Version.map
while [ $# -gt 0 ]; do
case $1 in
--major=*)  major=${1#--major=} ;;
--minor=*)  minor=${1#--minor=} ;;
--os=*) os=${1#--os=} ;;
--output=*) output=${1#--output=} ;;
-o) output=$2; shift ;;
-v) set -x ;;
*)  break ;;
esac
shift
done

LIB=$1

nm /usr/lib/lib${LIB}.so |
awk '$2 ~ /^[BCDRTWV]$/ { print \t $3 ; }' |
sort -u |
awk -v LIB=${LIB} -v osver=${os} -v major=${major} -v minor=${minor} 
-v minimus=${minimus} '
BEGIN {
printf(LIB%s_%s.%s.%s.0 {\nglobal:\n, toupper(LIB), major, 
minor, minimus)
}
{ print }
END {
printf(};\n\n);
printf(NetBSD_%s.0 {\n} LIB%s_%s.%s.%s.0;\n\n, osver, 
toupper(LIB), major, minor, minimus);
printf(LIB%s_private_%s.%s.%s.0 {\nlocal:\n\t*;\n};\n\n, 
toupper(LIB), major, minor, minimus);
}'  ${output}

exit 0


Re: CVS commit: [agc-symver] src/lib/libisns

2013-03-28 Thread Alistair Crooks
On Thu, Mar 28, 2013 at 07:21:41PM +, Christos Zoulas wrote:
 In article 20130328151625.9236a17...@cvs.netbsd.org,
 Alistair G. Crooks source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:agc
 Date:Thu Mar 28 15:16:25 UTC 2013
 
 Added Files:
  src/lib/libisns [agc-symver]: Version.map
 
 
 Perhaps calling those version.map is better? Why the capitalization?

That's what FreeBSD used (although, admittedly, they also had
Symbol.map and Versions.def, which we do without).

And maybe, in the spirit of shlib_version, version_map, or
version_info or some other name is better?

Anyway, let me get them all added with the same name on the branch,
and I can change them all in one fell swoop before merging the branch.

Thanks,
Alistair


Re: CVS commit: [agc-symver] src

2013-03-26 Thread Alistair Crooks
On Tue, Mar 26, 2013 at 08:32:17AM +0100, Joerg Sonnenberger wrote:
 On Tue, Mar 26, 2013 at 01:59:13AM +, Alistair G. Crooks wrote:
  Also fix up the ZFS infrastructure where it tried to link with the
  wrong libz.so instance -- these problems showed up in testing with the
  versioned libz.so.
 
 Can you at least be consistent and also use it for libpthread?

Umm, yeah, I'll address libpthread when I do the symbol versioning for
libpthread.  As you can see, each lib is being done one at a time, and
builds performed after that to fix any fallout.

Regards,
Alistair


Re: CVS commit: src/external/bsd/mdocml/dist

2013-03-22 Thread Alistair Crooks
On Fri, Mar 22, 2013 at 08:31:25AM -0400, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Fri Mar 22 12:31:25 UTC 2013
 
 Modified Files:
   src/external/bsd/mdocml/dist: roff.c
 
 Log Message:
 avoid arraycount for toolz
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/external/bsd/mdocml/dist/roff.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 

 Modified files:
 
 Index: src/external/bsd/mdocml/dist/roff.c
 diff -u src/external/bsd/mdocml/dist/roff.c:1.9 
 src/external/bsd/mdocml/dist/roff.c:1.10
 --- src/external/bsd/mdocml/dist/roff.c:1.9   Thu Mar 21 21:24:46 2013
 +++ src/external/bsd/mdocml/dist/roff.c   Fri Mar 22 08:31:25 2013
 @@ -1267,7 +1267,7 @@ static struct roff_nr *
  hash_find(struct roff *r, const char *str, uint32_t *h)
  {
   struct roff_nr *e;
 - *h = hash_str(str) % __arraycount(r-nr);
 + *h = hash_str(str) % (sizeof(r-nr) / sizeof(r-nr[0]));
  
   for (e = r-nr[*h]; e; e = e-next)
   if (e-hash == *h  strcmp(e-str, str) == 0)
 

I usually find that a

#ifndef __arraycount
#define__arraycount(__x)   (sizeof(__x) / sizeof(__x[0]))
#endif

before the function, and then just use __arraycount(r-nr), is a bit more 
readable.

Best,
Alistair


Re: CVS commit: src/external/bsd/kyua-atf-compat/dist

2013-02-26 Thread Alistair Crooks
On Tue, Feb 26, 2013 at 03:23:19PM +, Julio Merino wrote:
 Module Name:  src
 Committed By: jmmv
 Date: Tue Feb 26 15:23:19 UTC 2013
 
 Modified Files:
   src/external/bsd/kyua-atf-compat/dist: atf-run.sh atf-run_test.sh
 
 Log Message:
 Cherry-pick upstream change 70aefdbe5b843d6b24b5a9b816e47f2fb026dde2:
 
 Properly handle tabs when parsing config files
 
 Backslashes within [] in a regexp don't have any meaning, so [ \t]
 did not have the intended effect of being evaluated to a space and
 a tab.  Fix this by writing an actual tab in the regexp.
 
 Problem found by Valeriy E. Ushakov.

It may be better to use the POSIX character class [[:space:]] rather
than embedded spaces and tabs (which may not cut and paste well), and
which make it more obvious what actually is wanted.

Best,
Alistair


Re: CVS commit: src/tests/usr.bin/netpgpverify

2012-12-04 Thread Alistair Crooks
On Tue, Nov 27, 2012 at 11:23:48AM +0100, Herbert J. Skuhra wrote:
 On 20.11.2012 08:55, Alistair G. Crooks wrote:
 Module Name: src
 Committed By:agc
 Date:Tue Nov 20 07:55:55 UTC 2012
 
 Added Files:
  src/tests/usr.bin/netpgpverify: Atffile Makefile t_netpgpverify.sh
 
 Log Message:
 Add tests for netpgpverify.
 
 After this commit the following command fails:
 
 % ./build.sh -O ../obj -T ../tools -U distribution
 [...]
 rm: Atffile: Permission denied
 Failed to remove the following files from
 /usr/src/tests/usr.bin/netpgpverify:
 Atffile
 [...]
 *** Error code 1
 
 Stop.
 nbmake: stopped in /usr/src
 
 ERROR: Failed to make distribution
 *** BUILD ABORTED ***

Should be fixed now.

Best,
Alistair


Re: CVS commit: [agc-netpgp-standalone] src/crypto/external/bsd/netpgp/dist/src

2012-10-26 Thread Alistair Crooks
On Fri, Oct 26, 2012 at 07:28:15AM +0100, David Laight wrote:
 On Fri, Oct 26, 2012 at 05:03:24AM +0200, Alistair Crooks wrote:
  
  /* set up the pubkey keyring */
  int
  pgpv_read_pubring(pgpv_t *pgp, const void *keyring, ssize_t size)
  {
  if (keyring) { 
  return (size  0) ?
  read_binary_memory(pgp, pubring, keyring, 
  (size_t)size) :
  read_binary_file(pgp, pubring, %s, keyring);
  }  
  return read_binary_file(pgp, pubring, %s/%s, getenv(HOME), 
  .gnupg/pubring.gpg);
  }
 
 What happens if $HOME is undefined ?

If $HOME is undefined, then the default public keyring will not be
found.  If the default public keyring is not found, then the
verification will fail.

 What happens if $HOME is very long ?

If $HOME is very long, then the snprintf will truncate the MAXPATHLEN
buffer further down the call tree.  If the buffer is truncated, the
correct default public keyring will not be found.  If the default
public keyring is not found, the verification will fail.
 
 Why did someone use ?: not if ?

Maybe because it's neater, it's someone's natural coding style, it's
much more obvious what's happening, it doesn't lead to staircases, and
I can't believe I'm even typing this.

Regards,
Alistair


Re: CVS commit: [agc-netpgp-standalone] src/crypto/external/bsd/netpgp/dist/src

2012-10-26 Thread Alistair Crooks
On Fri, Oct 26, 2012 at 07:45:14AM +0100, David Laight wrote:
 On Fri, Oct 26, 2012 at 08:47:39AM +0200, Alistair Crooks wrote:
   
   What happens if $HOME is undefined ?
  
  If $HOME is undefined, then the default public keyring will not be
  found.  If the default public keyring is not found, then the
  verification will fail.
 
 I thought the code would probably call
   snprintf(buf, sizeof buf, %s/%s, NULL, string);
 
 Which is allowed to core dump (and will on Solaris).

True, maybe a check should be added for those operating systems which
aren't as lenient as NetBSD.  And that will be done when I start
looking at porting it to other operating systems (the compression and
digest headers will be problematic when this happens, too), since openssl
is no longer in the mix.
 
   What happens if $HOME is very long ?
  
  If $HOME is very long, then the snprintf will truncate the MAXPATHLEN
  buffer further down the call tree.  If the buffer is truncated, the
  correct default public keyring will not be found.  If the default
  public keyring is not found, the verification will fail.
 
 Silent truncation seems a bad thing to do in security code.

Silent truncation of a filename that is  MAXPATHLEN is bad? I wonder
what else will fail when that happens.

And this is security code? Cool. No-one told me.

It has absolutely no crypto in there.  It has some digests, some large
MPIs and BIGNUMs it calculates and matches, and some public keys
(which are all available on the key servers).

Which security code are you talking about?

Regards,
Alistair


Re: CVS commit: [agc-netpgp-standalone] src/crypto/external/bsd/netpgp/dist/src

2012-10-25 Thread Alistair Crooks
On Thu, Oct 25, 2012 at 12:40:28PM +, Christos Zoulas wrote:
 In article 20121025040317.3b16417...@cvs.netbsd.org,
 Alistair G. Crooks source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:agc
 Date:Thu Oct 25 04:03:16 UTC 2012
 
 Modified Files:
  src/crypto/external/bsd/netpgp/dist/src/libverify 
  [agc-netpgp-standalone]:
  libnetpgpverify.3 libverify.c verify.h
  src/crypto/external/bsd/netpgp/dist/src/netpgpverify 
  [agc-netpgp-standalone]:
  main.c
 
 Log Message:
 change the signature (ha!) of the pgpv_read_pubring() function to allow a
 key to be specified as a string in memory, as well as in a file. as always,
 the pubring must precede the signature.
 
 That should be:
 
 .Ft ssize_t
 .Fo pgpv_read_pubring
 .Fa pgpv_t *pgp const void *keyring size_t size

Thanks.

But I'm not sure it should - the memory pointer or filename argument
is overloaded when it is passed in; the size parameter being negative
is used to signify that it's a filename, so ssize_t is the correct
type.

As for the return type, ssize_t would tend to indicate that it's an
amount of data being returned, with a negative amount signifying
failure. Again, that's not really the case here.

Best,
Alistair


Re: CVS commit: [agc-netpgp-standalone] src/crypto/external/bsd/netpgp/dist/src

2012-10-25 Thread Alistair Crooks
On Thu, Oct 25, 2012 at 04:09:12PM +, Christos Zoulas wrote:
 But I'm not sure it should - the memory pointer or filename argument
 is overloaded when it is passed in; the size parameter being negative
 is used to signify that it's a filename, so ssize_t is the correct
 type.
 
 Perhaps there should be two entry points for the function then:
 
 pgp_read_file_pubring
 pgp_read_memory_pubring
 
 and pgp_read_file_pubring should read/mmap the file and call
 pgp_read_memory_pubring.

Yes, this is what happens in pgpv_read_pubring():

/* set up the pubkey keyring */
int
pgpv_read_pubring(pgpv_t *pgp, const void *keyring, ssize_t size)
{
if (keyring) { 
return (size  0) ?
read_binary_memory(pgp, pubring, keyring, 
(size_t)size) :
read_binary_file(pgp, pubring, %s, keyring);
}  
return read_binary_file(pgp, pubring, %s/%s, getenv(HOME), 
.gnupg/pubring.gpg);
}

just without using two functions to do the same thing.

Regards,
Alistair


Re: CVS commit: src/sys/arch/sparc64/sparc64

2012-03-02 Thread Alistair Crooks
On Sat, Mar 03, 2012 at 03:17:32AM +, Takeshi Nakayama wrote:
 Module Name:  src
 Committed By: nakayama
 Date: Sat Mar  3 03:17:32 UTC 2012
 
 Modified Files:
   src/sys/arch/sparc64/sparc64: locore.s
 
 Log Message:
 Fix the root cause of the hack disable optimizations for uvm_bio.c
 on 32 bit kernels.
 
 gcc converts a division in the calculation of UBC_UMAP_ADDR macro
 to multiplication (smul or combination of add/sll), and the
 register of its result contains a garbage in upper 32 bits (the
 upper 32 bits of smul/add/sll's result isn't zero cleared).
 
 Then it passes to pseg_get{,_real} through pmap_extract without the
 zero clear of upper 32 bits in the optimization case.  So the
 result of pseg_get and pmap_extact sometimes gets screwed up.

Oh, good catch!

Thanks for fixing this one.

Best,
Al


Re: CVS commit: othersrc/crypto/external/bsd/ssss/dist/src/libssss

2012-02-17 Thread Alistair Crooks
On Fri, Feb 17, 2012 at 02:18:00PM +, Christos Zoulas wrote:
 In article 20120217021118.ca61c17...@cvs.netbsd.org,
 Alistair G. Crooks source-changes-d@NetBSD.org wrote:
 +{
 +if ((share-io.base = calloc(1, size)) == NULL) {
 +(void) fprintf(stderr, allocate: can't calloc %zu\n, size);
 
 warn() + __func__ instead?

Indeed, thanks - I'm about to change lib on a fairly large scale RSN,
so I'll do the warn() pass then.

Thanks once again,
Alistair


Re: CVS commit: src/lib/libperfuse

2011-12-28 Thread Alistair Crooks
On Thu, Dec 29, 2011 at 01:40:33AM +, Jeff Rizzo wrote:
 Module Name:  src
 Committed By: riz
 Date: Thu Dec 29 01:40:32 UTC 2011
 
 Modified Files:
   src/lib/libperfuse: debug.c
 
 Log Message:
 Cast time_t to intmax_t for printf purposes, and format with %j.  Fixes
 build on amd64 and probably i386 as well.

Thanks for fixing this one, Jeff.

Any reason we're not using the PRI* definitions in inttypes.h?

Best,
Alistair


Re: CVS commit: src/external/public-domain/sqlite

2011-10-16 Thread Alistair Crooks
On Sun, Oct 16, 2011 at 05:24:50PM +, Joerg Sonnenberger wrote:
 Module Name:  src
 Committed By: joerg
 Date: Sun Oct 16 17:24:50 UTC 2011
 
 Modified Files:
   src/external/public-domain/sqlite: Makefile.inc
 
 Log Message:
 Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS

pkgsrc sqlite3 also has an option for rtree - it would be nice to
build that into the version in src by default.  I'm not sure about the
pkgsrc icu option, but that would arguably be neat as well.

Best,
Alistair


Re: CVS commit: src/external/public-domain/sqlite

2011-10-16 Thread Alistair Crooks
On Sun, Oct 16, 2011 at 11:57:28PM +, David Holland wrote:
 On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote:
Log Message:
Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS
   
   pkgsrc sqlite3 also has an option for rtree - it would be nice to
   build that into the version in src by default.  I'm not sure about the
   pkgsrc icu option, but that would arguably be neat as well.
 
 icu is big. I don't think we want it in base unless we're really sure...

Yup, hence the arguably.  But rtrees are much lighterweight, involve
no external libraries, and would be nice to have.

Regards,
Alistair


Re: CVS commit: src/external/public-domain/sqlite

2011-10-16 Thread Alistair Crooks
On Mon, Oct 17, 2011 at 04:19:00AM +0200, Joerg Sonnenberger wrote:
 On Sun, Oct 16, 2011 at 07:31:51PM +0200, Alistair Crooks wrote:
  On Sun, Oct 16, 2011 at 05:24:50PM +, Joerg Sonnenberger wrote:
   Module Name:  src
   Committed By: joerg
   Date: Sun Oct 16 17:24:50 UTC 2011
   
   Modified Files:
 src/external/public-domain/sqlite: Makefile.inc
   
   Log Message:
   Build with -DSQLITE_ENABLE_FTS3_PARENTHESIS
  
  pkgsrc sqlite3 also has an option for rtree - it would be nice to
  build that into the version in src by default.  I'm not sure about the
  pkgsrc icu option, but that would arguably be neat as well.
 
 Feel free to add the option. ICU has external dependencies, but the
 default build does include support for loadable extensions, so it could
 still be provided via pkgsrc...

Well, if there's no cogent disagreement, I will, thanks.

And if you could make a builtin.mk for pkgsrc's sqlite3 entry, that
would also be great.

Thanks,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist

2011-06-28 Thread Alistair Crooks
On Tue, Jun 28, 2011 at 07:45:07AM +0300, Jukka Ruohonen wrote:
 On Tue, Jun 28, 2011 at 03:29:39AM +, Alistair G. Crooks wrote:
  Module Name:src
  Committed By:   agc
  Date:   Tue Jun 28 03:29:38 UTC 2011
  
  Modified Files:
  src/crypto/external/bsd/netpgp/dist: tst
  
  Log Message:
  re-do the tests so that it's much easier to see at a glance which tests
  passed and which failed.
 
 I wonder why these aren't part of tests(7)?

1.  afaict, they predate the atf tests, especially atf's latest
incarnation

2.  they are fairly user-dependent (i.e.  i think you'd need my
private key to make them all work)

3.  they are candidates for modifying to work under atf, I have yet to
get the time to do that

4. luke kindly made some gnu autotests for them a while ago

5.  i made some tests for my codecs stuff a while ago; the time i
spent doing that was wasted

now i'm very supportive about the testing framework, catching
regressions, and the great things that atf has done for netbsd.

and if someone was to offer to convert these tests to atf style, that
would be great, thanks.

best,
alistair


Re: CVS commit: othersrc/external/bsd/iscsi/sys

2011-06-07 Thread Alistair Crooks
On Tue, Jun 07, 2011 at 11:47:51PM +, Jeff Rizzo wrote:
 Module Name:  othersrc
 Committed By: riz
 Date: Tue Jun  7 23:47:51 UTC 2011
 
 Modified Files:
   othersrc/external/bsd/iscsi/sys/dev/iscsi: files.iscsi iscsi_globals.h
   iscsi_ioctl.c iscsi_main.c iscsi_send.c iscsi_text.c iscsi_utils.c
 Added Files:
   othersrc/external/bsd/iscsi/sys/modules/iscsi: Makefile
 Removed Files:
   othersrc/external/bsd/iscsi/sys/lkm/dev/iscsi: Makefile iscsi_lkm.c
   iscsi_post.sh
 
 Log Message:
 Update in-kernel initiator so it builds on -current as a module.
 
 XXX there is an spl bug which causes it to crash when DIAGNOSTIC which
 needs to be fixed, though on a non-DIAGNOSTIC kernel I can mount a
 volume from a local target and read files successfully under -current.
 
 Lots of code cleanup is needed before moving into src, but this is a step.

Way cool, Jeff, thanks!

One more small step towards 6.0...

Thanks once again,
Alistair


Re: CVS commit: src/distrib/sets/lists/comp

2011-05-09 Thread Alistair Crooks
On Mon, May 09, 2011 at 03:58:10PM +0200, Nicolas Joly wrote:
 On Mon, May 09, 2011 at 03:17:54PM +0200, Adam Hamsik wrote:
  
  I'm getting this error with sources updated couple of minutes ago 
  
  ===  24 extra files in DESTDIR  =
  Files in DESTDIR but missing from flist.
  File is obsolete or flist is out of date ?
  --
  ./usr/include/perfuse.h
  ./usr/lib/i386/libperfuse.a
  ./usr/lib/i386/libperfuse.so
  ./usr/lib/i386/libperfuse.so.0
  ./usr/lib/i386/libperfuse.so.0.0
  ./usr/lib/i386/libperfuse_p.a
  ./usr/lib/i386/libperfuse_pic.a
  ./usr/lib/libperfuse.a
  ./usr/lib/libperfuse.so
  ./usr/lib/libperfuse.so.0
  ./usr/lib/libperfuse.so.0.0
  ./usr/lib/libperfuse_p.a
  ./usr/lib/libperfuse_pic.a
  ./usr/libdata/debug/usr/lib/i386/libperfuse.so.0.0.debug
  ./usr/libdata/debug/usr/lib/libperfuse.so.0.0.debug
  ./usr/libdata/debug/usr/sbin/perfused.debug
  ./usr/libdata/lint/llib-lperfuse.ln
  ./usr/sbin/perfused
  ./usr/share/man/cat3/libperfuse.0
  ./usr/share/man/cat8/perfused.0
  ./usr/share/man/html3/libperfuse.html
  ./usr/share/man/html8/perfused.html
  ./usr/share/man/man3/libperfuse.3
  ./usr/share/man/man8/perfused.8
  =  end of 24 extra files  ===
 
 All these entries have the `perfuse' keyword, which means that they
 will be selected for MKPERFUSE=yes builds only. But MKPERFUSE variable
 is not defined anywhere ...
 
 Do we need to add another optional component here (Makefiles will then
 need some tweaks), or should the keywords need to be wiped out from
 lists ?

I think get rid of the perfuse guard keyword - it may be that I
misled people with my post to tech-userlevel, sorry, since the
examples I used had the guard in place; however none of the other
puffs-based entries use any guards so best to get rid of it.

Regards,
Alistair


Re: CVS commit: src/sys/dev/videomode

2011-04-10 Thread Alistair Crooks
hi christos,

On Sat, Apr 09, 2011 at 04:53:39PM -0400, Christos Zoulas wrote:
 - use struct copy instead of memcpy

i haven't looked into this specific instance, but won't gcc (at least)
produce the same code for memcpy as struct copy, and the memcpy call
has the (admittedly arguable) distinction of being more readable.

 - snprintf(%s) - strlcpy

i use snprintf(%s) since it's more portable, and avoids having to
indirect through autoconf HAVE_STRLCPY goo just to invoke
snprintf(%s) in a stub re-implementation of strlcpy(3). feel the
glibc luurrve.

regards,
al


Re: CVS commit: src/share/mk

2011-02-12 Thread Alistair Crooks
On Sat, Feb 12, 2011 at 07:42:46PM -0500, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Sun Feb 13 00:42:45 UTC 2011
 
 Modified Files:
   src/share/mk: bsd.prog.mk
 
 Log Message:
 add saslc

Thanks for looking after libsaslc, and the integration with postfix. 
This is neat stuff, and this mail is not meant to detract from all the
hard work that anon, mateusz and yourself have put in on this, and is
no criticism of saslc, but...

I've been left wondering about POLA, and why we're adding LIB*
definitions to bsd.prog.mk - it doesn't seem the right *.mk file for a
start, and it also puts knowledge of libraries into a file that should
be generic.

Is there a better way that we can accomplish this?

Regards,
Alistair


Re: liblua (CVS commit: src/distrib/sets/lists)

2010-10-31 Thread Alistair Crooks
On Sun, Oct 31, 2010 at 11:49:33AM -0700, Paul Goyette wrote:
 I notice that for libm, libmagic and others, base/md.amd64 contains only
 two entries
   lib/i386/libxxx.so.x
   lib/i386/libxxx.so.x.y
 
 while there are five entries in comp/md.amd64
   lib/i386/libxxx.a
   lib/i386/libxxx.so
   lib/i386/libxxx_p.a
   lib/i386/libxxx_pic.a
   lib/i386/libxxx_g.a
 
 Yet, this commit places lib/i386/liblua.so in base/md.amd64 list, and 
 there does not seem to be a lib/i386/liblua_g.a
 
 I'm not trying to complain about the current commit,but only trying to 
 determine if we should be consistent!  Is there a valid reason why 
 lib/i386/liblua.so belongs in base/md.amd64 while lib/i386/libm.so goes 
 in comp/md.amd64 ?

My gensetlist stuff (referenced on tech-userlevel, available here)

http://www.netbsd.org/~agc/gensetlist-20101031.tar.gz

puts the compat shared objects in base/md.amd64 (and
base/ad.mips64{eb,el}, and base/md.sparc64), and the rest of the
compat entries in

[src/distrib/sets/lists/comp/ad.mips64eb]
./usr/lib/64/libnetpgp.acomp-c-lib  compat,crypto
./usr/lib/64/libnetpgp.so   comp-sys-shlib  compat,crypto
./usr/lib/64/libnetpgp_g.a  comp-c-proflib  compat,debuglib,crypto
./usr/lib/64/libnetpgp_p.a  comp-c-proflib  compat,profile,crypto
./usr/lib/64/libnetpgp_pic.acomp-c-piclib   compat,pic,crypto
./usr/libdata/debug/usr/lib/64/libnetpgp.so.3.0 comp-compat-shlib   
compat,pic,debug,crypto

so we may well be missing the debug entry for the compat shlib?

Please note that this was done with a contrived example of a modified
netpgp Makefile, not lua, but I think the principles still apply.

Regards,
Alistair


Re: CVS commit: src/lib/libc/stdio

2010-09-28 Thread Alistair Crooks
On Tue, Sep 28, 2010 at 11:06:39AM +0900, Masao Uebayashi wrote:
  Index: src/lib/libc/stdio/fmemopen.c
  diff -u src/lib/libc/stdio/fmemopen.c:1.3 src/lib/libc/stdio/fmemopen.c:1.4
  --- src/lib/libc/stdio/fmemopen.c:1.3   Sat Sep 25 14:00:30 2010
  +++ src/lib/libc/stdio/fmemopen.c   Mon Sep 27 16:50:13 2010
  @@ -79,16 +79,18 @@
  if (p-cur = p-tail)
  return 0;
  s = p-cur;
  -   t = p-tail - 1;
  do {
  -   if (p-cur == t) {
  -   if (*buf == '\0')
  -   *p-cur++ = *buf++;
  +   if (p-cur == p-tail - 1) {
  +   if (*buf == '\0') {
  +   *p-cur++ = '\0';
  +   goto ok;
  +   }
  break;
  }
  *p-cur++ = *buf++;
  } while (--nbytes  0);
  *p-cur = '\0';
  +ok:
  if (p-cur  p-eob)
  p-eob = p-cur;
   
  
 
 Do we have any reason to NOT use more assertions in such a critical
 library code path?

I'm not sure how fmemopen(3) qualifies as a critical library code path,
but, whatever.

As for more and more assertions - if people remember the bind assertion
fun we had in July 2009, then I'm sure there would be people asking for
less assertions, not more, especially in library code.

By all means check and warn, but please do not cause execution to halt
unless it's absolutely essential.

Regards,
Alistair


Re: CVS commit: src

2010-09-24 Thread Alistair Crooks
On Fri, Sep 24, 2010 at 09:21:54AM +, Takehiko NOZAKI wrote:
 Module Name:  src
 Committed By: tnozaki
 Date: Fri Sep 24 09:21:53 UTC 2010
 
 Modified Files:
   src/include: stdio.h
   src/lib/libc: shlib_version
   src/lib/libc/stdio: Makefile.inc
 Added Files:
   src/lib/libc/stdio: fmemopen.c
   src/tests/lib/libc/stdio: Makefile t_fmemopen.c
 
 Log Message:
 add fmemopen(3) derrived from POSIX:2008.
 libc minor bump.

Awesome -- much appreciated!

Very appropriate to the tech-userlevel discussion :)

Thank you,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-08-15 Thread Alistair Crooks
On Sun, Aug 15, 2010 at 05:16:47PM +, Christos Zoulas wrote:
 In article 20100815163624.8645d17...@cvs.netbsd.org,
 Alistair G. Crooks source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:agc
 Date:Sun Aug 15 16:36:24 UTC 2010
 
 Modified Files:
  src/crypto/external/bsd/netpgp/dist/src/lib: misc.c packet-parse.c
  packet-show.c reader.c signature.c validate.c writer.c
 
 Log Message:
 get rid of more 64-bit lint
 
 some of this can be fixed in a better way, for example making cc ssize_t,
 len size_t etc. and avoiding casts.

Yes, it can, but I'm concerned about the portability of doing things
that way. Probably just me being overly conservative, but whatever.

I'm not particularly happy with the way this code looks now, but I
have it in a state that I can work with :-)

I'll re-address this when I get a chance, I wanted to get this in and
cleaned up now.

Best,
Al


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-07-26 Thread Alistair Crooks
On Mon, Jul 26, 2010 at 03:56:07AM -0700, Tom Spindler wrote:
  Modified Files:
  src/crypto/external/bsd/netpgp/dist/src/lib: keyring.h packet-print.c
  Added Files:
  src/crypto/external/bsd/netpgp/dist/src/lib: mj.c mj.h
  
  Log Message:
  add a minimalist JSON implementation, and add a new function to access the
  data, and serialise it using JSON.
 
 Alas, this fails to build on pretty much all 64-bit arches:
 
 /src/nbsrc/crypto/external/bsd/netpgp/lib/../dist/src/lib/mj.c: In function 
 'mj_parse':
 /src/nbsrc/crypto/external/bsd/netpgp/lib/../dist/src/lib/mj.c:278: warning: 
 cast from pointer to integer of different size

Fixed now, sorry about that.

Thanks,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-06-25 Thread Alistair Crooks
On Fri, Jun 25, 2010 at 08:40:26PM +, Christos Zoulas wrote:
 In article 20100625183016.ac0be17...@cvs.netbsd.org,
 Alistair G. Crooks source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:agc
 Date:Fri Jun 25 18:30:16 UTC 2010
 
 Modified Files:
  src/crypto/external/bsd/netpgp/dist/src/lib: misc.c
 
 Log Message:
 Fix build problems on LP64 platforms - thanks to Paul Goyette for the nudge.
 
 That should be %zu really; it is more readable.

%zu is more readble, but it's C99, and even some C99 implementations
don't define it (I have in my mind Microsoft from the time that I brought
up the iSCSI target on Windows, but I may be wrong there)

The following quote is apt:

C99 adds a 'z' modifier specifically for size_t:

printf(Total buffer size: %zu bytes\n, buffer_size);

but many printf implementations don't support it. (Even if your
compiler supports C99 and defines __STDC_VERSION__ appropriately,
that's not, practically speaking, a guarantee that the library also
conforms to C99.)

Even in C99, the %lu method will work unless size_t is bigger than
unsigned long *and* the value being printed exceeds ULONG_MAX, which
is unlikely to happen in practice.

--
Keith Thompson (The_Other_Keith) ks...@mib.org 
http://www.ghoti.net/~kst
San Diego Supercomputer Center * http://users.sdsc.edu/~kst

referenced in:


http://bytes.com/topic/c/answers/221867-portable-way-printf-size_t-instance

Oh, and yes, this is not a we need to conform to c89 as LCD post -
this is 2010 after all - it's an I want netpgp to be as portable as
possible post.

Regards,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-06-25 Thread Alistair Crooks
On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
 On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
  Even in C99, the %lu method will work unless size_t is bigger than
  unsigned long *and* the value being printed exceeds ULONG_MAX, which
  is unlikely to happen in practice.

Please get the attributions right - I was quoting that text.
 
 Actually, it doesn't. This method breaks as soon as size_t != u_long and
 might only work in a few edge cases like the size_t being the last
 argument and the byte order is Little Endian. This is worse because IIRC
 Microsoft decided to use IL32LLP64 or something similarly fancy.

Can you give us a reference to this, please?
 
 A more portable approach with autoconf can be found in pkg_install, look
 for MISSING_SIZE_T_SUPPORT and the corresponding AC_CHECK_SIZEOF calls
 in configure.ac.

Hmmm, I see this in configure.ac -

AC_CHECK_SIZEOF(int)  
AC_CHECK_SIZEOF(long)   
AC_CHECK_SIZEOF(long long)
AC_CHECK_SIZEOF(size_t, [#include stdlib.h])

and

case $host in
*-*-hpux*)
AC_DEFINE(MISSING_SIZE_T_SUPPORT)
AH_TEMPLATE([MISSING_SIZE_T_SUPPORT], [ 
Define to 1 if the `z' modifider for printf is missing.
])
;;
esac

and

#ifndef MISSING_SIZE_T_SUPPORT
#  define PRIzu zu
#elif SIZEOF_SIZE_T == SIZEOF_INT
#  define PRIzu u
#elif SIZEOF_SIZE_T == SIZEOF_LONG
#  define PRIzu lu
#elif SIZEOF_SIZE_T == SIZEOF_LONG_LONG
#  define PRIzu llu
#else
#  errror Unknown size_t size
#endif

Not quite what I'd been expecting, though, from the glowing description
above.

Am I missing a revision of that file or something? It took me ages to
find it, since I was looking under src/external first of all - and cvs
status does say it's up to date.

Thanks,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-06-25 Thread Alistair Crooks
On Sat, Jun 26, 2010 at 05:25:31AM +0200, Joerg Sonnenberger wrote:
 On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
  On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
   On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
Even in C99, the %lu method will work unless size_t is bigger 
than
unsigned long *and* the value being printed exceeds ULONG_MAX, 
which
is unlikely to happen in practice.
  
  Please get the attributions right - I was quoting that text.
   
   Actually, it doesn't. This method breaks as soon as size_t != u_long and
   might only work in a few edge cases like the size_t being the last
   argument and the byte order is Little Endian. This is worse because IIRC
   Microsoft decided to use IL32LLP64 or something similarly fancy.
  
  Can you give us a reference to this, please?
 
 E.g.
 http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
 and the MSDN reference inside.
 
   A more portable approach with autoconf can be found in pkg_install, look
   for MISSING_SIZE_T_SUPPORT and the corresponding AC_CHECK_SIZEOF calls
   in configure.ac.
  
  Hmmm, I see this in configure.ac -
  
  AC_CHECK_SIZEOF(int)  
  AC_CHECK_SIZEOF(long)   
  AC_CHECK_SIZEOF(long long)
  AC_CHECK_SIZEOF(size_t, [#include stdlib.h])
 
 ...compute the sizes to not depend on SIZE_MAX (which would simplify the
 logic a lot).
 
  and
  
  case $host in
  *-*-hpux*)
  AC_DEFINE(MISSING_SIZE_T_SUPPORT)
  AH_TEMPLATE([MISSING_SIZE_T_SUPPORT], [ 
  Define to 1 if the `z' modifider for printf is missing.
  ])
  ;;
  esac
 
 The only platform for pkgsrc purposes ATM which lacks the %z support.

It would be better to make this a check which is size_t dependent,
rather than platform-dependent.
 
  and
  
  #ifndef MISSING_SIZE_T_SUPPORT
  #  define PRIzu zu
  #elif SIZEOF_SIZE_T == SIZEOF_INT
  #  define PRIzu u
  #elif SIZEOF_SIZE_T == SIZEOF_LONG
  #  define PRIzu lu
  #elif SIZEOF_SIZE_T == SIZEOF_LONG_LONG
  #  define PRIzu llu
  #else
  #  errror Unknown size_t size
  #endif
  
  Not quite what I'd been expecting, though, from the glowing description
  above.
 
 It would be simpler if SIZE_MAX support can be assumed. In that case it
 would boil down to
 #if SIZE_MAX == INT_MAX
 #define PRIzu u
 #elif SIZE_MAX == LONG_MAX
 #define PRIzu lu
 #else SIZE_MAX == LLONG_MAX
 #define PRIzu llu
 #endif

That is even worse, though.

I still don't understand why autoconf is passing C pre-processor
directives down.

#if sizeof(size_t) == sizeof(int)
...
#elif sizeof(size_t) == sizeof(long)
...
#endif

directly in the code is much more readable.

Regards,
Alistair


Re: CVS commit: src/sys/rump/librump/rumpkern

2010-06-16 Thread Alistair Crooks
On Tue, Jun 15, 2010 at 04:40:24PM +1000, matthew green wrote:
 
  On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
On i386, that's true.  amd64 expands to '0', as does sun3.  This makes
the first one true.  The second one, i386 expands to '1', so the
second one would be false.
  
  Arguably we shouhld fix our gcc to only define __i386__, not i386,
  which conflicts with the user namespace...
 
 i agree.
 
 i was going to reply to an earlier message on this that it was the
 kernel Makefile's that define $MACHINE, but upon looking at them i
 noticed that only a few do, and that i486--netbsdelf-gcc defines
 i386 all the time so i didn't send any email.
 
 we should audit all of our gcc configs and kernel configs to deal.

Yes, I agree, too.

Quite some time ago, we stopped defining unix, which mainly
caused issues in pkgsrc and not in src, but nothing we couldn't
overcome given time and bulk builds.

Now's not the time, though, please leave it 2 weeks :-)

Best,
Alistair


Re: CVS commit: src/lib/libc/locale

2010-06-05 Thread Alistair Crooks
Hi Nozaki-san,

On Wed, Jun 02, 2010 at 04:04:52PM +, Takehiko NOZAKI wrote:
 Module Name:  src
 Committed By: tnozaki
 Date: Wed Jun  2 16:04:52 UTC 2010
 
 Modified Files:
   src/lib/libc/locale: bsdctype.c
 
 Log Message:
 uint8_t - unsigned char, int16_t - short.

As ever, thank you for looking after our locale code.

I was just wondering why this change was made? It seems to be a backwards
step to me?

Thanks,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/hkpd

2010-03-01 Thread Alistair Crooks
not really, i tried to shoehorn all of this into bozo, and it wasn't
willing to do it, and its cgi subsystem doesn't lend itself to this
kind of thing.  i'm fairly intimate with most of bozo's internals,
too.

the server itself is not that large.  if there's a common server-side
library that can be used, great, show me it, and i'll convert the hkpd
to use it.  libfetch certainly isn't up to the task.

regards,
alistair

On Mon, Mar 01, 2010 at 10:35:20PM +0100, Joerg Sonnenberger wrote:
 Why do we want to have another ad-hoc HTTP implementation? Wouldn't a
 small *CGI script be good enough?
 
 Joerg
 
 On Mon, Mar 01, 2010 at 07:41:57AM +, Alistair G. Crooks wrote:
  Module Name:src
  Committed By:   agc
  Date:   Mon Mar  1 07:41:57 UTC 2010
  
  Added Files:
  src/crypto/external/bsd/netpgp/dist/src/hkpd: Makefile hkpd.c hkpd.h
  main.c
  
  Log Message:
  add an embryonic httpd key server (hkpd) to netpgp. this is based on the
  discontinued draft for hkp servers, in lieu of any official rfc.
  
  the post method for adding keys to the server has not been implemented.
  not until i've gone through all of the implications, anyway.
  
  hkp servers serve up pgp public keys over http. the default port is 11371,
  but it can be any port, specifiable at run time. whilst this hkpd will
  return valid html to browsers, it is aimed at the ''machine readable''
  side, using the ''options=mr'' option to the http get string.
  
  this hkpd server will get hooked into the build at a later date.
  
  
  To generate a diff of this commit:
  cvs rdiff -u -r0 -r1.1 
  src/crypto/external/bsd/netpgp/dist/src/hkpd/Makefile \
  src/crypto/external/bsd/netpgp/dist/src/hkpd/hkpd.c \
  src/crypto/external/bsd/netpgp/dist/src/hkpd/hkpd.h \
  src/crypto/external/bsd/netpgp/dist/src/hkpd/main.c
  
  Please note that diffs are not public domain; they are subject to the
  copyright notices on the relevant files.


Re: CVS commit: src

2009-12-01 Thread Alistair Crooks
On Tue, Dec 01, 2009 at 09:24:50PM +0900, Masao Uebayashi wrote:
  Because the current PF sources (=version 4.2) is (still) in those  
  directories as far as I can tell. The only reason for this import is to  
  make upgrades easier, see my mail to current-users@ yesterday.
 
 I think doing repo-copy (from dist/ to external/) would help here?

We haven't done repo copies for a while now, and I'm not convinced
it's a good idea to get back into them - the git fanboys will hate you
for it :-), to name just one example.  The structure of dist and
external are different as well, so we should just bite the bullet and
do the move when it's feasible.

Best,
Alistair


Re: CVS commit: src/crypto/external/bsd/netpgp/dist

2009-05-27 Thread Alistair Crooks
On Tue, May 26, 2009 at 09:12:39AM +0200, Joerg Sonnenberger wrote:
 On Tue, May 26, 2009 at 05:40:03AM +, Luke Mewburn wrote:
  Log Message:
  Improve SHA256_CTX checks; OS/X provides it in CommonCrypto/CommonDigest.h
  even though their openssl/sha.h is too old.
 
 I think I will hit similiar issues with libarchive at some points, so do
 you have more details here?

Take a look at the source code - it's worked on Mac OS X with its weird
digest/openssl integration since January.

Regards,
Alistair


Sun2 shared libraries

2009-05-17 Thread Alistair Crooks
On Sun, May 17, 2009 at 11:38:43AM +, Havard Eidnes wrote:
 Module Name:  src
 Committed By: he
 Date: Sun May 17 11:38:43 UTC 2009
 
 Modified Files:
   src/crypto/external/bsd/netpgp/bin: Makefile
 
 Log Message:
 Add LDADD+= and DPADD+= settings so that this builds on sun2 as well,
 where we can't rely on shared libraries expressing the needs of the
 program.

[This isn't specific to netpgp, I had the same discussion over
one of the other libraries that we have - agc]

Once again, we come down to having to modify Makefiles for the sole
benefit of Sun2s. So I'll ask again - does anyone have one any more?

The last Sun2 I used must have been 1987, so I suspect most of its
use these days is from emulators. If not, can someone send me a
picture please - it's been a long, long time.

Yeah, I know it's a little thing, but it's the principle - since
bending over backwards to support slow and old platforms may impact
support for newer platforms, and the excellent performance figures
that Andrew showed with the release of 5.0.

http://blog.netbsd.org/tnf/entry/netbsd_5_0_an_overview
http://www.netbsd.org/~ad/50/

Wouldn't it be more advantageous to the project as a whole to bring
the support for Sun2s into line with every other port, or to just
retire the Sun2 port in general. Having to customise things for the
sake of a port which is more than 20 years old seems to me to be
getting our priorities wrong.

Regards,
Alistair


Re: Sun2 shared libraries

2009-05-17 Thread Alistair Crooks
On Mon, May 18, 2009 at 04:50:22AM +1000, matthew green wrote:
 
On Sun, May 17, 2009 at 11:38:43AM +, Havard Eidnes wrote:
 Module Name: src
 Committed By:he
 Date:Sun May 17 11:38:43 UTC 2009
 
 Modified Files:
  src/crypto/external/bsd/netpgp/bin: Makefile
 
 Log Message:
 Add LDADD+= and DPADD+= settings so that this builds on sun2 as well,
 where we can't rely on shared libraries expressing the needs of the
 program.

[This isn't specific to netpgp, I had the same discussion over
one of the other libraries that we have - agc]

Once again, we come down to having to modify Makefiles for the sole
benefit of Sun2s. So I'll ask again - does anyone have one any more?
 
 
 the benefit is for static userland.  it just happens that sun2
 only supports that, but the sun2 part is irrelevant.

OK, thanks for the explanation.  That leads to the question about
supporting NOPIC userland, but it's probably best that I shut up now.

Thanks,
Al


Re: CVS commit: src/crypto/external/bsd/netpgp/dist

2009-05-10 Thread Alistair Crooks
On Mon, May 11, 2009 at 12:11:03PM +1000, Daniel Carosone wrote:
 On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote:
  On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote:
   On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
   
[...] since there's no way of changing a PGP passphrase
short of generating a new key.
   
   Huh?  Sure, you have a need to deal with keyring copies from before
   the change, maybe with some more rm -P and its limtations, but
   otherwise, I don't understand this.  
  
  Sorry, I must be missing something then (perfectly possible, now I'm
  old and grey) - how do you change the passphrase on a PGP key?
 
 For gpg, the passwd sub-command under edit-key.  For other
 implementations, special sigils created by waving the magic
 wand^Wpointer.  
 
 If the corresponding feature is missing from this implementation,
 that's a deficiency, but not a limitation of the format.  Someone
 might implement the feature, or you might combine tools since the
 keyring format is standardised and (I hope) therefore the tools are
 interoperable.   

Cool, thanks, that's exactly the information I was looking for.

I'll look into providing that somehow (I've been of the opinion that
we need one binary for key management, and one binary for
signing/verification and encrypting/decrypting for a while now - it's
the way that the old nbpg SoC project was going too), and that
definitely gives me an incentive to do that kind of split.

Thanks once again,
Al


Re: CVS commit: src/crypto/external/bsd/netpgp/dist

2009-05-06 Thread Alistair Crooks
On Wed, May 06, 2009 at 12:57:06PM +0200, Klaus Klein wrote:
 On Tue, May 05, 2009 at 11:38:36PM +, David Holland wrote:
  On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote:
Imagine someone embedding this library in their (embedded) product.
Having the library dump core for what is an unusual ocurrence, admittedly
(such as an out of memory condition, perhaps) is suboptimal, since the
product may then have to be re-started to get a working system. This
is too intrusive. As someone with an LCD TV which sometimes does this,
it annoys me intensely. Names and models on request, in private.

This also brings us round to a pet peeve of mine - for development
work, dumping core is fine for exceptional conditions. Same as kernel
panics. It's not usually wanted in production code.
  
  Having things fail silently or go into a fugue state is not an
  improvement, particularly in security code. So I'd qualify all this by
  saying that end-to-end behavior should always be fail-stop.
  
  However, I'm inclined to agree that libraries should not in general
  abort on behalf of an application, and that it's the application's
  responsibility to be fail-stop.
 
 So, as far as the library is concerned, shouldn't these assertions
 be preserved, and face conversion to _DIAGASSERT(3)?

You're right, if you believe that the failure of a runtime check for
the length of time_t being greater than or equal to 4 bytes is
sufficient to abort an application.  There were also assertions about
previous values which had been hardcoded.  Some of the assertions had
code further on to check exactly the same error condition, and return
gracefully with an error value if triggered.

Anyway, on with the meta-discussion.

Regards,
Alistair



Re: CVS commit: src/crypto/external/bsd/netpgp/dist

2009-05-06 Thread Alistair Crooks
On Wed, May 06, 2009 at 06:47:37PM +0200, Joerg Sonnenberger wrote:
 On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
  You're right, if you believe that the failure of a runtime check for
  the length of time_t being greater than or equal to 4 bytes is
  sufficient to abort an application.
 
 ...which can and should be a compile-time assertion.

Absolutely - we can put it in sys/cdefs.h, right next to the check
for the value of pi changing, and the check for int32_t being able to
address 32 bits.

Having this kind of thing as compile-time checks would take a huge
weight off my mind.

Alistair

PS.  It has suddenly struck me that your suggestion might have been
serious. Oh well...