Re: CVS commit: src/share/man/man7

[Alistair Crooks]

On Fri, Nov 24, 2023 at 18:09 Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:

> > Date: Sat, 25 Nov 2023 02:05:25 +
> > From: Taylor R Campbell 
> >
> > > Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> > > From: chris...@astron.com (Christos Zoulas)
> > >
> > > Yes, this is indeed a lot better. I prefer though:
> > >
> > > MAN+= \
> > > bar.7 \
> > > foo.7
> > >
> > > It is faster to parse, involves less typing, whitespace is cleaner.
> >
> > This one doesn't have the same pattern for every line, so it makes
> > merging and sorting harder -- do M-x sort-lines on the content lines,
> > and you'll come up with:
> >
> > MAN+= \
> > foo.7
> > bar.7 \
>
> err, obviously I meant this example the other way; if it had been
> written as:
>
> MAN+= \
> foo.7 \
> bar.7
>
> as the natural order of metasyntactic variables (foo, bar), then doing
> M-x sort-lines on the content lines would yield:
>
> MAN+= \
> bar.7
> foo.7 \


I find it better to have

MAN+= bar.7
MAN+= foo.7

Since a grep for 'MAN.*foo' will produce meaningful results

Sorting, and initial entry are once-only operations, searching happens
everywhere all the time.

>
>
>

Re: CVS commit: src

[Alistair Crooks]

On Mon, Jun 6, 2022 at 11:56 nia  wrote:

>
> And done.
>
> Thanks!

Best,
Al

Re: CVS commit: src

[Alistair Crooks]

On Sun, Jun 5, 2022 at 12:50 nia  wrote:

> On Sun, May 29, 2022 at 07:35:45PM +0200, J. Hannken-Illjes wrote:
> > Just a side note, how do we test a build system with say 20 knobs,
> > do we build all 2**20 configurations to be sure everything at
> > least builds?
> >
> > Isn't it better to always build everything and move this selection
> > into the set lists or whatever you use to get the final image?
>
> Just "for info" - everything knobified so far is what we'd call
> a "leaf package" in pkgsc. The knob only affects the build of
> that one program.


> And it is still the wrong way to do this, as was mentioned by Frank
previously in this thread.
Apologies, I obviously didn't make myself clear

If a bootable image is the endgoal, as mentioned above:

Everything needs to be built first

Then packages can be built - possibly using the sets you have just built,
and, depending on the packages needed, even cross built

Embedded systems providers would build their own software around about now

Then you can create a target file system, possibly by using some of the
in-tree tools

Then select binaries/libraries/utilities/configs/scripts/maybe even docs
can be installed onto your image

Or you could go wild and build a single crunchgenned binary, with a single
db file for /etc (the db file was lukem's idea at wasabi, and worked well)

Or, instead of building src/xsrc into sets, try the syspkg approach

Cutting single programs out of the initial build process is insufficient
and wrong

Re: CVS commit: src

[Alistair Crooks]

On Sun, May 29, 2022 at 17:39 nia  wrote:

>
> Hi, sorry I missed this email, please CC me next time.
>
> I talked about this a bit on ICB, but not on the lists yet.
>
> My end-game is to make it easier to make minimal embedded
> images of NetBSD.
>

A laudable endgoal.

But before starting to make piecemeal changes to the build system, maybe
some research into how others have accomplished this before with NetBSD?

I'd really like to avoid the plethora of (sometimes conflicting) switches
that make up the FreeBSD build system.

>
And I'd like to see discussion before any work is done (on a branch for
such intrusive changes) for this

Thanks,
Alistair

Re: CVS commit: src

[Alistair Crooks]

On Fri, 5 Nov 2021 at 16:45, Joerg Sonnenberger  wrote:

> On Thu, Nov 04, 2021 at 06:17:20PM -0700, Alistair Crooks wrote:
> > I think you're misreading the diff - it will only wrap if the minimum
> size
> > is 0x, which is...ummm...highly unlikely (it's defined to be 0
> > right now, the type is unsigned)
>
> I'm not so much worried about the constant, but the right hand size.
> Without looking at the types, I can't be sure that "context->pwdlen + 1"
> doesn't overflow or that "context->m_cost - 1" can't underflow. Much
> easier and safer to just use a type cast...
>

The author of the software made a conscious decision to make the variable
unsigned, since the length would never be less than zero.

The author then made a default definition for the lower bound of the
length, and made it 0.

I find it ironic that an overbearing, over-eager compiler takes these,
decides that the condition could never be true, and so a cast to an integer
type is now needed to shut up the overeager compiler, thereby negating the
(completely valid) thought process the author went through.

Nevertheless, I'll make the changes you suggest

Re: CVS commit: src

[Alistair Crooks]

I think you're misreading the diff - it will only wrap if the minimum size
is 0x, which is...ummm...highly unlikely (it's defined to be 0
right now, the type is unsigned)

On Thu, 4 Nov 2021 at 15:56, Joerg Sonnenberger  wrote:

> On Mon, Nov 01, 2021 at 03:09:59AM +, Alistair G. Crooks wrote:
> > Module Name:  src
> > Committed By: agc
> > Date: Mon Nov  1 03:09:59 UTC 2021
> >
> > Modified Files:
> >   src/external/apache2/argon2/dist/phc-winner-argon2/src: argon2.c
> core.c
> >   src/lib/libcrypt: Makefile
> >
> > Log Message:
> > Remove the
> >
> >   COPTS.*+=   -Wno-error=.*
> >
> > lines for building argon2 sources, by fixing the problems at source.
> >
> > Addresses Rin Okuyama's concerns on tech-userlevel/tech-crypto in
> >
> >   Message-ID: 
>
> The +1 part seems questionable to me as it can actually introduce a wrap
> around, can't it?
>
> Joerg
>
>

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

[Alistair Crooks]

Ugh, I fat-fingered the commit, and meant to commit the man page changes
under a separate commit.

The commit message from that was going to be:

"Feedback from uwe - document agcre_regfree and agcre_reg[an]sub - thanks!"

On Tue, 5 Oct 2021 at 15:17, Alistair G. Crooks  wrote:

> Module Name:othersrc
> Committed By:   agc
> Date:   Tue Oct  5 22:17:15 UTC 2021
>
> Modified Files:
> othersrc/external/bsd/agcre/dist: libagcre.3
> othersrc/external/bsd/agcre/lib: Makefile
>
> Log Message:
> add MLINKS for rev_regexec and reg[an]sub functions
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.4 -r1.5 othersrc/external/bsd/agcre/dist/libagcre.3
> cvs rdiff -u -r1.2 -r1.3 othersrc/external/bsd/agcre/lib/Makefile
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>

Re: CVS commit: src/sys/uvm

[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

[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

[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

[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

[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

[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

[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

[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

[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 commit: src/sys

[Alistair Crooks]

On 9 February 2016 at 00:32, Ryota Ozaki  wrote:
> Module Name:src
> Committed By:   ozaki-r
> Date:   Tue Feb  9 08:32:12 UTC 2016
>
> Modified Files:
> src/sys/arch/acorn32/podulebus: if_ie.c
> [...]
> src/sys/rump/net/lib/libvirtif: if_virt.c
>
>
> Log Message:
> Introduce softint-based if_input
>
> This change intends to run the whole network stack in softint context
> (or normal LWP), not hardware interrupt context. Note that the work is
> still incomplete by this change; to that end, we also have to softint-ify
> if_link_state_change (and bpf) which can still run in hardware interrupt.

Way cool - thank you!

Best wishes,
Alistair

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

[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

[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

[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

[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/kern

[Alistair Crooks]

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".  That hasn't
been the case for a long while.  Semantically it's ass backwards, it
doesn't follow the conventions that the other comparisons in this file
make, and it's ugly, and I now have to parse the individual operation,
rather than reading the code as a whole :-(.

Anyway, please don't get me wrong, I really like the movement away
from mbufs in the networking code, it's good - just don't see the
point in using this unconventional way of expressing conditionals.

Best,
Alistair

Re: CVS commit: src/sys/arch

[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

[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

[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

[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

[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

[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

[Alistair Crooks]

On Sat, Oct 12, 2013 at 05:24:07PM +, Marc Balmer wrote:
> +#ifndef NO_LUA_SUPPORT
> +#include 
> +#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

[Alistair Crooks]

On Fri, Apr 05, 2013 at 01:50:41PM +0900, Masao Uebayashi wrote:
> I'm not sure if symbols like _citrus_* are meant to be exported as
> global.  Probably not.

Oh dear. That's a pity:

Taken from a 5.1_STABLE system...

[23:12:11] agc@morden ~ 3 > nm /usr/lib/libc.so | grep _citrus_
00200ab0 D _citrus_LC_CTYPE_desc
00200540 D _citrus_LC_MESSAGES_desc
00200920 D _citrus_LC_MONETARY_desc
002008c0 D _citrus_LC_NUMERIC_desc
002005c0 D _citrus_LC_TIME_desc
00207c20 D _citrus_NONE_ctype_ops
00207cc0 D _citrus_NONE_stdenc_ops
00207c10 D _citrus_NONE_stdenc_traits
000cba00 T _citrus_bcs_convert_to_lower
000cba80 T _citrus_bcs_convert_to_upper
000cbc60 T _citrus_bcs_skip_nonws
000cbb80 T _citrus_bcs_skip_nonws_len
000cb9b0 T _citrus_bcs_skip_ws
000cbbf0 T _citrus_bcs_skip_ws_len
000cba20 T _citrus_bcs_strcasecmp
000cbaa0 T _citrus_bcs_strncasecmp
000cd1d0 T _citrus_bcs_strtol
00060b10 T _citrus_bcs_strtoul
000cbb20 T _citrus_bcs_trunc_rws_len
000603a0 T _citrus_csmapper_open
000cd0e0 T _citrus_ctype_btowc_fallback
...

Regards,
Alistair

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

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

[Alistair Crooks]

On Thu, Mar 28, 2013 at 07:21:41PM +, Christos Zoulas wrote:
> In article <20130328151625.9236a17...@cvs.netbsd.org>,
> Alistair G. Crooks  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

[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

[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

[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

[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: othersrc/external/bsd/mat

[Alistair Crooks]

On Mon, Nov 26, 2012 at 04:23:47PM +0100, Marc Balmer wrote:
> memwrite() can return with the file still being mapped (successful
> mmap(), then a short write).  Is that intended?  No big problem if
> the calling program exits when memwrite() returns 0, but I did not
> check that.

Yeah, you're right; I have more changes to come with the error
handling part of this, so this will be addressed along with the
others.  Thanks for keeping me honest, much appreciated.
 
> Then different formats are uses to print the size, "%u" in one case,
> "%" PRlu64 "" in the second case.  Could be nicer if it was
> consistent, maybe.

Ah, yes. I will fix - thanks.
 
Best,
Alistair

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

[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

[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

[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: [agc-netpgp-standalone] src/crypto/external/bsd/netpgp/dist/src

[Alistair Crooks]

On Thu, Oct 25, 2012 at 12:40:28PM +, Christos Zoulas wrote:
> In article <20121025040317.3b16417...@cvs.netbsd.org>,
> Alistair G. Crooks  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: src/sys/arch/sparc64/sparc64

[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

[Alistair Crooks]

On Fri, Feb 17, 2012 at 02:18:00PM +, Christos Zoulas wrote:
> In article <20120217021118.ca61c17...@cvs.netbsd.org>,
> Alistair G. Crooks  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

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

Best,
Alistair

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

[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/external/public-domain/sqlite

[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

[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: othersrc/external/bsd/getopt2

[Alistair Crooks]

On Fri, Jul 15, 2011 at 07:41:03AM +0100, David Laight wrote:
> On Fri, Jul 15, 2011 at 05:30:48AM +, Alistair G. Crooks wrote:
> ...
> > Log Message:
> > Initial import of getopt2 into othersrc repository.
> ...
> > In addition, the optstring does the usual ':' for an option with an
> > argument, and uses ';' to denote an option that optionally takes an
> > argument.
> 
> Hmmm... optional arguments shouldn't really be allowed - they go against
> the standard command line syntax rules.

Well, no-one is forcing anyone to use them.  However, in some
circumstances, they are extremely useful, and one of the reasons that
I have used getopt_long in the past (see netpgp and netpgpkeys, for
example) is because of the optional argument support in that.

Anyway, the driver for this one was being able to parse quickly and
efficiently without global variables. The interface for getopt(3)
sucks hugely in this regard. And I know this isn't a generally useful
thing, which is why it's in othersrc.

> It isn't actually obvious to me how this is parsed, since the general
> recommendation is to have a space between any option and its argument.

The optional argument parsing follows the same rules as getopt(3) ':'
option string parsing - the next character in argv[n] is examined - if
it's 0x0, then look at argv[n + 1] - if it's a '-', then there's no
argument.  If it's another character, then assume argv[n + 1] is the
optional argument.  This works for normal arguments, as well as tar's
"cvf" style arguments too.

If you've finished arguments, and want to use an optional argument as
the last one, then invoke with "--" to end the arguments.

Regards,
Alistair

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

[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

[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

[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

[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/external/bsd/iscsi/dist/src/initiator

[Alistair Crooks]

On Tue, Feb 22, 2011 at 10:34:13AM +, Stephen Borrill wrote:
> Module Name:  src
> Committed By: sborrill
> Date: Tue Feb 22 10:34:13 UTC 2011
> 
> Modified Files:
>   src/external/bsd/iscsi/dist/src/initiator: iscsi-initiator.8
> 
> Log Message:
> Document -D option (discover LUNs).
> iscsi-initiator was NOT in NetBSD 5.0.

Thanks for updating this, Stephen.  The fuse-based initiator was in
NetBSD 5.0, but lived under src/share/examples/refuse/iscsi-initiator;
we didn't push the initiator part when 5 was branched and released
because of this, but it was certainly in there.

On a related theme - if anyone would like to help bringing the
kernel-based initiator (contributed by Wasabi Systems) forward to
-current, please just reply to this mail (privately, not to the list,
please).

Thanks,
Alistair

Re: CVS commit: src/share/mk

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

[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

[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

[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

[Alistair Crooks]

On Sun, Aug 15, 2010 at 05:16:47PM +, Christos Zoulas wrote:
> In article <20100815163624.8645d17...@cvs.netbsd.org>,
> Alistair G. Crooks  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

[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

[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 ])
> 
> ...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/crypto/external/bsd/netpgp/dist/src/lib

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

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

[Alistair Crooks]

On Fri, Jun 25, 2010 at 08:40:26PM +, Christos Zoulas wrote:
> In article <20100625183016.ac0be17...@cvs.netbsd.org>,
> Alistair G. Crooks  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 

San Diego Supercomputer Center <*> 

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/sys/rump/librump/rumpkern

[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

[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

[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: tn3270 removal (was: CVS commit: src)

[Alistair Crooks]

On Sun, Jan 17, 2010 at 02:18:29AM +, David Holland wrote:
> On Sat, Jan 16, 2010 at 11:57:13PM +0100, Bernd Ernesti wrote:
>  > > > Where was this discussed before?
>  > > 
>  > > on tech-userlevel
>  > 
>  > I found that thread which didn't make it obvious that this would happen
>  > without a WORKING replacement in pkgsrc.
> 
> I have added it to pkgsrc. Please let me know if it works, as I don't
> have an IBM mainframe in my back pocket for testing. :-/

Until then, there's always pkgsrc/emulators/hercules :-)

Regards,
Alistair

Re: CVS commit: src/sys

[Alistair Crooks]

On Thu, Dec 17, 2009 at 01:25:11AM +, Mindaugas Rasiukevicius wrote:
> Module Name:  src
> Committed By: rmind
> Date: Thu Dec 17 01:25:11 UTC 2009
> 
> Modified Files:
>   src/sys/ddb: db_lwp.c
>   src/sys/kern: init_main.c kern_lwp.c kern_proc.c subr_prof.c
>   sys_process.c
>   src/sys/uvm: uvm_fault.c uvm_glue.c
> 
> Log Message:
> Replace few USER_TO_UAREA/UAREA_TO_USER uses, reduce sys/user.h inclusions.

Maybe it's just me, but I do find the

-   return USER_TO_UAREA(l->l_addr);
+   return (vaddr_t)l->l_addr - UAREA_USER_OFFSET;
 }
 
 void
 uvm_lwp_setuarea(lwp_t *l, vaddr_t addr)
 {

-   l->l_addr = UAREA_TO_USER(addr);
+   l->l_addr = (void *)(addr + UAREA_USER_OFFSET);

USER_TO_UAREA/UAREA_TO_USER abstractions much more informative, especially
at a first glance. Would it be possible to keep them?

Regards,
Alistair

Re: CVS commit: src

[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

[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 
> > even though their  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

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

[Alistair Crooks]

On Mon, May 25, 2009 at 10:47:00PM +, Christos Zoulas wrote:
> In article <20090525160949.gr14...@nef.pbox.org>,
> Alistair Crooks   wrote:
> >Hi Arnaud, everyone,
> >
> >On Thu, May 21, 2009 at 10:59:04PM -0400, Arnaud Lacombe wrote:
> >> I've been seeing a lot of commit and activity in netpgp. Do you mind
> >> sending me a small paragraph [for the next CVS activity report] about
> >> what you're doing in it and what is already possible and what
> >> direction does it take ?
> > 
> >Yeah, there's no secret about what I'm doing with it, but just to clarify:
> >
> >netpgp is a high-level layer which sits on top of a heavily-modified
> >openpgpsdk, and provides a library interface defined in
> >/usr/include/netpgp.h - the main functions are:
> >
> >int netpgp_encrypt_file(netpgp_t *, char *, char *, char *, int);
> >int netpgp_decrypt_file(netpgp_t *, char *, char *, int);
> >int netpgp_sign_file(netpgp_t *, char *, char *, char *, int, int, int);
> >int netpgp_verify_file(netpgp_t *, char *, const char *, int);
> 
> Shouldn't most of those char *'s be const char *, and in the code
> the result of the __ops_functions should be checked, and appropriate
> errnos set?

Yes, I'll get onto it.

Thanks,
Alistair

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

[Alistair Crooks]

Hi Arnaud, everyone,

On Thu, May 21, 2009 at 10:59:04PM -0400, Arnaud Lacombe wrote:
> I've been seeing a lot of commit and activity in netpgp. Do you mind
> sending me a small paragraph [for the next CVS activity report] about
> what you're doing in it and what is already possible and what
> direction does it take ?
 
Yeah, there's no secret about what I'm doing with it, but just to clarify:

netpgp is a high-level layer which sits on top of a heavily-modified
openpgpsdk, and provides a library interface defined in
/usr/include/netpgp.h - the main functions are:

int netpgp_encrypt_file(netpgp_t *, char *, char *, char *, int);
int netpgp_decrypt_file(netpgp_t *, char *, char *, int);
int netpgp_sign_file(netpgp_t *, char *, char *, char *, int, int, int);
int netpgp_verify_file(netpgp_t *, char *, const char *, int);

There are also some key management functions which will be moving from
netpgp(1) to a separate key management program RSN.  All the
openpgpsdk functions have been hidden from userspace, and the only
structure and entry points are the libnetpgp(3) ones. There's now
one header file, rather than a number.

Netpgp(1) itself provides signing, verification, encryption and
decryption of RSA, DSA and Elgamal keys.  It can be used as a dropin
replacement for gpg in that respect - however, please be reassured
that the interface is completely different. There's one separate
command that I didn't find with gpg, which was the ability to verify
a file, and, if it was correct, to write the signed contents to a file
(which defaults to stdout). That's invoked as "netpgp --cat file.gpg"

Netpgp is built on top of openpgpsdk from Ben Laurie and Rachel Willmer,
with a few bugs fixed, like the ability to verify files > 8192 bytes,
to decrypt files > 8192 bytes.  It has also been updated to generate
keys with a default size of 2048 bits (even then, I'm thinking of
raising this to 4096) - key size can of course be specified via the
command line - and to use a default hash algorithm when signing of
SHA256 (instead of SHA1).  Netpgp also displays keys before prompting
for passphrases, displays the default key (as derived from the
.gnupg/gpg.conf file), and works with detached signatures (both
signing and verification).  The split from openpgpsdk wasn't just a
desire for NIH - the code is unusual in its structure in a lot of
respects, and I found I needed to run it through indent for my poor
little braincells to be able to cope with it, and I also found that I
don't like developing with vim in 120 column windows - so I did a lot
of gratuitous name changes - some of the names are huge, with > 50
chars in them - to the openpgpsdk such that Ben and Rachel would not
recognise it, and I suspect would disown it even if they did.  Their
copyright is still in all the files. openpgpsdk's goals are different
from mine, since they encourage the use of 3rd party verification
software written to their interface - my goals for netpgp are much
more mundane, in that I want a BSD-licensed library and userland
program which is efficient, and compatible/contemptible with GPG.

What can people do with it right now? It can be used as an embedded
library, such that files can be signed/verified, encrypted and decrypted.
This is completely compatible with gpg:

[8:32:53] agcro...@electricrace ~ 145 % netpgp --sign a
netpgp: default key set to "c0596823"
pub 2048/RSA (Encrypt or Sign) 1b68dcfcc0596823 2004-01-12
Key fingerprint: d415 9deb 336d e4cc cdfa 00cd 1b68 dcfc c059 6823 
uid  Alistair Crooks 
uid  Alistair Crooks 
uid  Alistair Crooks 
uid  Alistair Crooks 
netpgp passphrase: 
[8:33:21] agcro...@electricrace ~ 146 % gpg --verify a.gpg 
gpg: Signature made Mon 25 May 08:33:20 2009 PDT using RSA key ID C0596823
gpg: Good signature from "Alistair Crooks "
gpg:         aka "Alistair Crooks "
gpg: aka "Alistair Crooks "
gpg: aka "Alistair Crooks "
[8:33:30] agcro...@electricrace ~ 147 % netpgp --verify a.gpg
netpgp: default key set to "c0596823"
Good signature for a.gpg made Mon May 25 08:33:20 2009
using RSA (Encrypt or Sign) key 1b68dcfcc0596823
pub 2048/RSA (Encrypt or Sign) 1b68dcfcc0596823 2004-01-12
Key fingerprint: d415 9deb 336d e4cc cdfa 00cd 1b68 dcfc c059 6823 
uid  Alistair Crooks 
uid  Alistair Crooks 
uid  Alistair Crooks 
uid  Alistair Crooks 
[8:33:39] agcro...@electricrace ~ 148 %

It is similar on the encryption/decryption side:

[8:34:26] agcro...@electricrace ~ 149 % netpgp --encrypt a
netpgp: default key set to "c0596823"
[8:34:35] agcro...@electricrace ~ 150 % netpgp --decrypt a.gpg
netpgp: default key set to "c0596823"
pub 2048/RSA (Encrypt or Sign) 1b68dcfcc0596823 2004-01-12
Key fingerprint: d415 9deb 336

Re: Sun2 shared libraries

[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

Sun2 shared libraries

[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: CVS commit: src/crypto/external/bsd/netpgp/dist

[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

[Alistair Crooks]

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?

Thanks,
Al

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

[Alistair Crooks]

On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote:
> 
> "Alistair G. Crooks"  writes:
> 
> > Module Name:src
> > Committed By:   agc
> > Date:   Fri May  8 06:06:39 UTC 2009
> >
> > Modified Files:
> > src/crypto/external/bsd/netpgp/dist: TODO configure configure.ac
> > src/crypto/external/bsd/netpgp/dist/src/bin: netpgp.c
> > src/crypto/external/bsd/netpgp/dist/src/lib: config.h config.h.in
> > crypto.c misc.c netpgp.c openssl_crypto.c reader.c signature.c
> > signature.h version.h
> >
> > Log Message:
> [...]
> > + if setrlimit exists, set the core dump size to be 0
> >   (with thanks to mrg for the reference implementation)
> [...]
> 
> What's the threat model this is protecting against? Presumably, if a
> user can execute the program, and the program can read his keys, the
> uesr can already read his own keys, so having a core dump doesn't give
> the user information he didn't already have.

Heh, yeah, it's not really to do with keys, much more the passphrase,
which is dynamically allocated in a number of places in the library,
and I haven't finished auditing all of the places just yet.  I've
added code to zero out that memory after use when I can - some more
are still needed.

The threat that I'm protecting against here is that of information
disclosure coming from committing the passphrase to disk in a core
dump.  Having to remember to rm -P the core dump file is a pain, you
don't get a second chance at it, and after that there is still the
problem of any spared sectors.  I suspect you don't want a re-run of
the tls vs.  agc wars from a month ago.  Whilst most people will use
an encrypted block device of some description, others are prevented
from doing that for various reasons.  I'm especially sensitive about
passphrases here, since there's no way of changing a PGP passphrase
short of generating a new key.

I'd really recommend source-changes-full for reviewing the changes
that are made - the setrlimit(2) call is only made in the driver
program, not the library.

Regards,
Alistair

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

[Alistair Crooks]

On Thu, May 07, 2009 at 11:09:57PM -0400, Perry E. Metzger wrote:
> 
> Alistair Crooks  writes:
> > 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 , 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...
> 
> Often, when one is writing code like this, one assumes something like
> the idea that time_t is always, say, four bytes. Then, later, someone
> like Christos comes along and turns the value into an eight byte
> quantity and assumptions fail. It is nice to have the assumptions fail
> in a nice loud way at compile time. This is not the same as checking
> that pi has not changed.

The check was for time_t's being *at least 4 bytes* (openpgpsdk was
compiled on Solaris 10 update something which has 64bit time_t's) -
see the quoted text above.

We used to write

long time(); /* no C */

in the days before prototypes and  - this goes back to at
least the early 80s.  So, au contraire, the check had as much value as
one for pi changing.

Regards,
Alistair

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

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

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

[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

[Alistair Crooks]

On Tue, May 05, 2009 at 11:52:09AM -0400, Perry E. Metzger wrote:
> 
> "Alistair G. Crooks"  writes:
> > + get rid of some assertions in the code - this is a library - about 100 to 
> > go
> 
> Why does the fact that it is a library make assertions a bad thing,
> especially in security code?

It doesn't per se - but I personally have an aversion to libraries
that dump core in the middle of running well, especially when calling
code checks for bad return values and deals with them just fine.  I
was going to say that the fact that this is security code is neither
here nor there, but that's not exactly true.  I'd really prefer it if
a data section which could contain my PGP passphrase did not get sent
to a disk somewhere.

To illustrate this - I messed up one of the assertions when I was
converting it to an if() test, such that the condition was inverted. 
The regression test showed this up straight away, and presented me
with a "bad length" message along with the function name where it
happened.  Personally, I find that much more socially acceptable than
dumping core on me.

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.

We have too many of these core dumps and panics - we should only take
drastic action when the system as a whole cannot easily recover.  For
me, these assertions in netpgp are recoverable - return a false or
"error condition" value, and try to continue.

Regards,
Alistair

Re: CVS commit: src/sys

[Alistair Crooks]

On Sun, May 03, 2009 at 09:25:45PM +, Elad Efrat wrote:
> Module Name:  src
> Committed By: elad
> Date: Sun May  3 21:25:45 UTC 2009
> 
> Modified Files:
>   src/sys/conf: param.c
>   src/sys/kern: vfs_init.c
>   src/sys/secmodel/bsd44: secmodel_bsd44.c secmodel_bsd44_logic.c suser.h
> 
> Log Message:
> Move dovfsusermount to secmodel_bsd44, where it really belongs.
> 
> The secmodel code now creates the same knob in two places: both under the
> secmodel itself, as well as the widely known location.
> 
> Mailing list references:
> 
> http://mail-index.netbsd.org/source-changes/2009/05/02/msg220641.html
> http://mail-index.netbsd.org/tech-kern/2009/05/03/msg005015.html

What about other secmodels? They'll now have to duplicate the dovfsusermount
functionality.

Regards,
Alistair

PS. Please leave longer between proposing changes until committing them, as
others have asked you previously. You are not giving people enough time to
provide feedback, and so are causing yourself and others more work by doing
this.

Re: CVS commit: src/usr.bin/make

[Alistair Crooks]

On Sun, Mar 29, 2009 at 02:05:04PM -0400, Perry E. Metzger wrote:
> 
> Alistair Crooks  writes:
> > This is veering off topic, I fear, but a datapoint:
> >
> > We used a mmdd-based time value for version numbering of the
> > pkg_install tools, derived from embedded RCS Ids, for years (to check
> > tools had sufficient features for what they were going to be asked to
> > do).  This was across NetBSD and pkgsrc branches.
> 
> That's fine, but those are
> 
> a) essentially monotonic because of your management practices
> b) not based on build time (which is my main complaint about things like
>the old make(1) version stamp.
> 
> Also, the pkg tools are under quite active development and have
> substantial interface shifts with time, and you need to automatically
> decide when to rebuild them so you *need* a version.

If you want to check for features, then I suggest you add a -Q: argument
to make(1), to be used for querying for features. A non-existent -Q
argument would mean the feature wasn't available. Other uses would be:

% make -Q repeatable-builds
repeatable-builds supported
% echo $?
0
% make -Q me-a-crocodile-sandwich-and-make-it-snappy
me-a-crocodile-sanewich-and-make-it-snappy not supported
% echo $?
1

i.e. de-couple the feature from the date. The two are obviously not related
in this case.

Regards,
Alistair

Re: CVS commit: src/usr.bin/make

[Alistair Crooks]

On Fri, Mar 27, 2009 at 01:18:17AM +, David Holland wrote:
> On Tue, Mar 24, 2009 at 11:41:11AM -0400, Perry E. Metzger wrote:
>  > >  > Consider building NetBSD 0.9 today.  As it was, MAKE_VERSION would
>  > >  > seem quite modern, but the make would really be quite old.
>  > >
>  > > Using the last rcsid time would at least fix that...
>  > 
>  > Not really, because branches have non-linear temporal connections to
>  > each other.
> 
> It would fix NetBSD 5.0 vs. NetBSD 0.9, though, because those branches
> are strictly ordered.
>
>  > Again, I think that if one wanted to be serious about
>  > this, one would need to have manual management of version
>  > numbers.

This is veering off topic, I fear, but a datapoint:

We used a mmdd-based time value for version numbering of the
pkg_install tools, derived from embedded RCS Ids, for years (to check
tools had sufficient features for what they were going to be asked to
do).  This was across NetBSD and pkgsrc branches.

Much to my surprise, it worked well (and I was sceptical at the
start).
 
Regards,
Alistair