Re: Suggestion: A new variable for a few Makefiles: IS_BINARY
I'm sorry, you still haven't answered my questions: 1. What dangers are you trying to protect users from? 2. Why do you feel that existing safeguards for what goes into the ports tree are not adequate? Responding indirectly to your last post, the ports infrastructure is already VERY complex. Complex systems by their very nature are fragile. Adding more complexity (and therefore more fragility) without a very good reason is a very bad idea. You are asserting that a change is necessary. Therefore it's on you to prove that the benefits of the proposed change outweigh the costs. Some of the costs that come immediately to mind: 1. Someone has to write the patch 2. Someone has to test it 3. Someone has to identify all existing ports that install binaries. 3. Someone has to add flags to all existing ports that install binaries 4. Someone has to verify that new ports that are added to the tree either do or do not have binaries, and that flags are set accordingly 5. Someone has to maintain the code once it's in the tree Your assertion from your previous message seems to be that "it should be done because it will help some people, and won't hurt anyone who doesn't use it." I disagree with your analysis. I see significant "costs" in terms of person-hours to do the things that are in that list above, and I'm sure there are other costs that I'm not thinking of. So what I'm asking you to do is outline in detail what benefits your proposed change will bring to the community that will justify the cost of making the change. Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Suggestion: A new variable for a few Makefiles: IS_BINARY
Hi, Reference: > From: Gary Jennejohn > Reply-to: gary.jennej...@freenet.de > Date: Thu, 21 Jan 2010 17:01:46 +0100 > Message-id: <20100121170146.672ac...@ernst.jennejohn.org> Gary Jennejohn wrote: > On Thu, 21 Jan 2010 07:34:02 -0800 > Doug Barton wrote: > > > On 1/20/2010 6:47 PM, Julian H. Stacey wrote: > > > Some may not don't mind > > > installing binaries from elsewhere, but FreeSBD could protect more, > > > > What is it that you're trying to protect people from? In other words, > > what bad thing do you think is going to happen if someone installs a > > binary, and why do you think that we would allow something dangerous > > into the ports collection in the first place? > > > > I know Julian very well and he's, umm, very cautious. > > I assume he wants a knob he can turn on to avoid installing binaries while > doing unattended installations, i.e. with BATCH set to yes. Thanks, Yes, sort of, Mechanism would be similar to implemenation methoid of BATCH, (Except we could improve on it by not having different strings eg Makefile: IS_INTERACTIVE=YES Mk/*: BATCH= but perhaps Makefile: IS_BINARY=YES Mk/*: SKIP_BINARY_INSTALL=YES # (or NO) ) It could be use with BATCH (but doesnt have to be), eg personally I do a multi pass build on my ports, cd /usr/ports ; make BERKLIX_CLIENTS=YES BATCH=YES # overnight cd /usr/ports ; make BERKLIX_CLIENTS=YES # later build of interactives next day Usage of SKIP_BINARY_INSTALL would be personaly choosable I'd specify SKIP_BINARY_INSTALL=YES (if not default in Mk/*.mk) but others could equally choose Not to assert it. Example: I just did an upgrade (to 8.0) & compiled & installed 694 ports (inc. dependencies), from my set of */Makefile.local Manually scanning Makefiles each remake (inc changing dependencies), looking for binary rogue software sneaking through, is pointless, when binaries without source could so easily be marked in Makefiles. The mechanism would help people & companies that have a policy: Install No software without matching sources. Others could ignore occasional declarative markers in a few ports like www/opera/Makefile IS_BINARY=YES One could debate whether default make install behaviour from Mk/ should be to continue to install (as now), or exit 1, on the few ports needing IS_BINARY=YES; Default would be over-ridable by an env var to make command. There is a spectrum of usage, no one preference fits all, No point trying to convince each other 1 policy is best for all :-) Some run binaries ie BLOBs, drivers, opera, mega ports (openoffice), & flash binaries under linux emulators etc, & maybe havent source, enthusiasm, time, space or interest to build their own. Some (by temperament, employer, or market sector, eg security companies, firewall manufacturers, military development support, government security etc), may want to No software tools installed without matching sources. Not everyone needs the hook, but that's no reason not implement it; it is simple, helps some, & will not harm others who can ignore it. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Suggestion: A new variable for a few Makefiles: IS_BINARY
On Thu, 21 Jan 2010 07:34:02 -0800 Doug Barton wrote: > On 1/20/2010 6:47 PM, Julian H. Stacey wrote: > > Some may not don't mind > > installing binaries from elsewhere, but FreeSBD could protect more, > > What is it that you're trying to protect people from? In other words, > what bad thing do you think is going to happen if someone installs a > binary, and why do you think that we would allow something dangerous > into the ports collection in the first place? > I know Julian very well and he's, umm, very cautious. I assume he wants a knob he can turn on to avoid installing binaries while doing unattended installations, i.e. with BATCH set to yes. --- Gary Jennejohn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Suggestion: A new variable for a few Makefiles: IS_BINARY
On 1/20/2010 6:47 PM, Julian H. Stacey wrote: Some may not don't mind installing binaries from elsewhere, but FreeSBD could protect more, What is it that you're trying to protect people from? In other words, what bad thing do you think is going to happen if someone installs a binary, and why do you think that we would allow something dangerous into the ports collection in the first place? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Suggestion: A new variable for a few Makefiles: IS_BINARY
Hi ports@ people, Suggestion: A new variable for a few ports Makefiles, eg /usr/ports/www/opera/Makefile BINARY="To install binaries lacking sources, use RISK_BINARIES=YES" to over-ride it one would use eg cd /usr/ports ; make RISK_BINARIES=YES install It could work similarly to IS_INTERACTIVE=YES in Makefiles that make BATCH=YES detects (to avoid unattended builds hanging on input). ports/Mk. has NO_BUILD, thats not the same thingm but good for a first quick hints where to add BINARY= in a few Makefile. One can see untrusted binaries with make extract ; find . -type f | sort | xargs file Look for eg: ELF 64-bit LSB shared object, ... It's too easy to install BLOBs without realising, eg if one has a hierarchy of ports/*/Makefile.local. The only warning at present is a few ports eg opera make too fast. Some may not don't mind installing binaries from elsewhere, but FreeSBD could protect more, not just allow MickeySoft style blind installs of unsourced binaries. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
