Re: Sets, subsets, syspkgs, and MK*

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

>   | Problem here is, I can't apply "YP code in libc" patch if I disable *_YP.
> 
> If you disable YP (and NetBSD has it enabled) then you don't want to
> apply binary patches from NetBSD - you're doing source builds already,
> and you want source patches.   Trying to impose binary patches onto
> source built systems would be lunacy,

I *have to* disable YP & build source because USE_YP changes libc.so's
signature.  If YP is only provided as syspkgs, I can be a happy binary
distribution user (== don't install YP syspkgs).

> I think you're thinking of those things as variables, that can change
> at random

No I don't!

> - they're not, they're constants (for a port/release combination).
> Once values are selected (as far as the standard distribution goes) they're
> fixed for all time for that release/port, and will never be changed (for
> TNF releases, the variables may as well all be deleted, and the code just
> selected, or deleted, as appropriate).   The MK* and USE* vars remain in

I pointed out this many times all around this thread.

> the sources for others who want to build different releases - but TNF
> binary patches are irrelevant to them, they make their own.

There's a big difference between:
- Who want to build different releases (e.g. different compiler optimisation)
- Who want to use partial functionality (no YP, no KERBEROS, ...)

> Only if their build was identical to TNF's build in the first place.   I
> know mine isn't - I deliberately want my binaries to be all just a little
> different from the TNF release versions (doing the exact same task, but
> with code at a different location, or order, or ...)   If this has no
> other advantages, it at least means that someone figuring out a binary patch
> attack needs to build one specific for my system, they can't experiment on
> their own (or someone else's) and then expect the hack to work without
> changes on my systems (this is a kind of pathetic "security by obscurity"
> but it is remarkably effective against mass system attacks - worms and such).

You're most paranoia. :)

I'm not familar with such security techniques.  I thought binary updates
(binary patches or partial binary updates == syspkgs) helped in security
context too.  Users can quickly apply patches without building their own, or
downloading big binary sets.

> Because of that exact reason, no binary patch from TNF (nor anything that
> is bit identical) can possibly be useful to me.   They also could not be
> useful to anyone who has changed any of the MK* or USE* config settings, for
> whatever reason.

In my YP example, I have to change config settings because it changes libc.so
signature.  If libc.so becomes common & YP is provided as syspkgs, I don't
need to build by myself.

> Sure, you're right, if you factor pieces of libc, and other things, into
> small tiny files, then binary patches can target exactly what is needed
> rather than just one big monolithic hunk, but I'm not sure that the MK*
> (or USE*) variables are in any particularly relevant way related to what
> would be good to move out to separate chunks - perhaps ideally every single
> source file that currently go to make up libc should be made into a
> separate shared lib, that is linked into the application only when needed.
> Or then again, perhaps not...

I think YP is worth being a module, because it's context is limited compared
to printf(3), malloc(3), ...

libc locale already uses dynamic modules.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635