Re: woody release task needs help: package priorities
On 05/15/2001 09:28:37 AM tfheen wrote:
>> You are assuming that talkd have buffer overflows, but you have no
>> proof of it. And talk is rwxr-xr-x, so what would you win by an
>> overflow on a local host? And I doubt that there are many bugs in a
>> daemon which is less than 10k big.
Perhaps it's poor form for me to pick on one specific type of security hole
on one specific binary.
When .debs include a file that has a formal proof of correctness for each
binary and any possible input parameters and data, then I'll completely
trust those debs. Maybe yet another lintian option (just kidding)
I'm thinking, your point of view is that if no current bugs are found, if
the source looks short, simple and OK, therefore no bugs will exist, but my
arguement is that if that were true, our BTS would only contain wishlists,
typos, and WNPP. Classic optimism vs pessimism argument.
Will a security related problem be found in every random binary someday?
Given enough time, yes.
>> Bugs != vulnerabilities. You are assuming that all programs are
>> exploitable, even if one can prove that they aren't. (Barring bugs in
>> the kernel or other places.)
One should provide me a formal proof of correctness for each line of source
code in Debian and how it interacts with each other line of source. Then I
guess one will be correct, one has proven they aren't (exploitable).
Again, my mistake for picking on one specific binary. If you do in fact
have a formal proof of correctness for talk and talkd, well then I guess it
truely has no security holes and is truely bug free, as long as all
interactions with other installed software and libraries are OK. If it
links to a buggy libc, then maybe the overall system would be exploitable.
>> Still, I don't think you are arguing that man-db should be made
>> priority optional or extra because of this? A stripped-down system
>> with the bare necessities doesn't have all the packages from standard
>> installed. Standard is more than the bare necessities.
You are correct, I am not argueing for that. I was using that as an
example of how I did not have a problem with software I purposefully did
not install. You can't have an open mail relay if you don't install any
mail software. You can't have skript kiddies compiling exploits if you
don't have a compiler. You can't have cgi-bin problems if you don't have a
webserver installed.
The question is how much more than bare necessities is standard? Would
installing everything be acceptable as a standard? True, installing
everything would be more than the bare necessities. I'm argueing for
moving the line toward installing less.
>> | Never install something unless you are willing to take the time to
support
>> | and debug it, AND then justify the time to your boss.
>>
>> If my boss were to decide whether I used two minutes for upgrading
>> some daemon or not, I'd change jobs, as I like to control my own
>> time.
It's a judgement call thing, not a time management thing. Why the heck
would someone have the poor judgement to install and maintain something the
users don't need, and then bill for it? Outside the computer world, it
might be popular to bill the client for playing cards or reading magazines,
but that doesn't make it ethical. It's not the dollar value of the wasted
time, its the lack of trust that they are not wasting time in other cases.
Besides, wouldn't you rather be playing quake rather than upgrading a
daemon that is not used?
Correct, for one box it's not much time, or if you have a hundred boxes its
also not much time because you write an expect script. Still, if you only
have a dozen or so boxes, thats half an hour of billable time if you do it
manually. All for nothing, if its not used. So why waste time/money/drive
space/electricity?
>> | Just because it's very easy to install MTAs and webservers and
>> | compilers doesn't mean it's a good idea to do so on every box, just
>> | because you can.
>>
>> So you think gcc and exim should be priority extra/optional as well?
Ah, no I don't want to start a flame war here. My production boxes are not
mail servers, I don't want to even screw around with email issues,
personally I purge all MTAs (which usually wipes out "at", which I also
don't need, etc). And I definately don't have gcc installed on the
production boxes, that's for sure. But for the average Debian user
(whatever that means) I suppose they are a standard, required, and often
used binary (?)
>> | If you have no use for talk or talkd, you should not install them.
Most
>> | people have no use for them, therefore most people should not install
them.
>>
>> If we are to remove each and every package from standard which
>> somebody might not need, I don't see the point of having standard at
>> all. Standard should be a slim but reasonable complete UNIX system.
>> Out of 1240 computers which submitted popcon results, talk got 167
>> votes. I think that shows that quite some people use it. And it's
>> small, and if it will listen on loopback by default, I see no problem
>> with it.
Playing games with the definition of "complete". If you want to play games
with numbers, then don't forget that 1073 of your 1240 popcon users act as
if a system without talk IS complete, or they would have installed and used
it.
How do you define "complete"? Able to boot? Able to run user
applications? Able to compile itself? Able to crosscompile a new
distribution on it?
I don't think my definition of complete matches your definition, and I'm
(mostly) OK with that, because at least Debian is highly customizable for
"power users". But we've made the decision as a group to decide for
newbies what a standard system means. So it's fair game to debate the
meaning of a very vague word, "standard". The thing I like about standards
is there are so many to choose from.
>> | Therefore talk and talkd should be removed from standard. The few
people
>> | that do have a use, also have the skill to type "apt-get install talk
>> | talkd".
>>
>> Not everybody has root on the systems they are using.
Root will set the system policies, including the use and installation of
talk and talkd. Not sure what you're getting at. If root doesn't want it
there, either become root by social engineering, use another box where you
are root, deal with it as a "management issue", or use/work at another
organization (?) I don't see any problem with root setting system policy,
and not having all users = root. If you truely need talk (why?), well then
that's a great arguement point to either get root, or get root to install
it for you. No problem. If you don't truely need talk, then it doesn't
matter if you can't install it. Also no problem. Thus not having root is
no problem, regardless of if you need talk or not.
Reply to: