<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_18_2039229</id>
	<title>Fedora 12 Lets Users Install Signed Packages, Sans Root Privileges</title>
	<author>timothy</author>
	<datestamp>1258536600000</datestamp>
	<htmltext>eqisow writes <i>"The new default policy for Fedora 12 <a href="https://bugzilla.redhat.com/show\_bug.cgi?id=534047">allows local, unprivileged users to install signed packages</a> without root access. This change apparently went mostly unnoticed until after the <a href="//linux.slashdot.org/story/09/11/17/1810256/Fedora-12-Released">Fedora 12 GA release</a>, at which point it sparked a <a href="https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00926.html">mailing list thread</a> that is, as of this writing, over 100 posts long."</i></htmltext>
<tokenext>eqisow writes " The new default policy for Fedora 12 allows local , unprivileged users to install signed packages without root access .
This change apparently went mostly unnoticed until after the Fedora 12 GA release , at which point it sparked a mailing list thread that is , as of this writing , over 100 posts long .
"</tokentext>
<sentencetext>eqisow writes "The new default policy for Fedora 12 allows local, unprivileged users to install signed packages without root access.
This change apparently went mostly unnoticed until after the Fedora 12 GA release, at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149338</id>
	<title>Require Password Instructions</title>
	<author>BountyX</author>
	<datestamp>1257073380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Browsed through the list. Here are instructions to <a href="http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/" title="wordpress.com">require a password for signed repo</a> [wordpress.com]. I agree with many of the mailing list users, this is a very bad default and there seems to be an assumption of targeting the desktop, or single user environments...</htmltext>
<tokenext>Browsed through the list .
Here are instructions to require a password for signed repo [ wordpress.com ] .
I agree with many of the mailing list users , this is a very bad default and there seems to be an assumption of targeting the desktop , or single user environments.. .</tokentext>
<sentencetext>Browsed through the list.
Here are instructions to require a password for signed repo [wordpress.com].
I agree with many of the mailing list users, this is a very bad default and there seems to be an assumption of targeting the desktop, or single user environments...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238</id>
	<title>I fail to see the problem</title>
	<author>afed125</author>
	<datestamp>1257072840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This change only applies to Fedora's desktop oriented spins, not the server versions, and it makes sense from an usability point of view.  No user should be able to gain root access just by installing a signed package from a signed repository.  It might be possible, but since Fedora controls all of those packages it should be easy to prevent that possibility.  Overall, I think the increase in usability outweighs the security concern and definitely outweighs the argument of "expected unix behavior".  This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.</htmltext>
<tokenext>This change only applies to Fedora 's desktop oriented spins , not the server versions , and it makes sense from an usability point of view .
No user should be able to gain root access just by installing a signed package from a signed repository .
It might be possible , but since Fedora controls all of those packages it should be easy to prevent that possibility .
Overall , I think the increase in usability outweighs the security concern and definitely outweighs the argument of " expected unix behavior " .
This is someone 's workstation or netbook , not a Vax in 1985 with 120 users on it .</tokentext>
<sentencetext>This change only applies to Fedora's desktop oriented spins, not the server versions, and it makes sense from an usability point of view.
No user should be able to gain root access just by installing a signed package from a signed repository.
It might be possible, but since Fedora controls all of those packages it should be easy to prevent that possibility.
Overall, I think the increase in usability outweighs the security concern and definitely outweighs the argument of "expected unix behavior".
This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30168374</id>
	<title>Important: policy will be changed</title>
	<author>AdamWill</author>
	<datestamp>1258654980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see <a href="https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012.html" title="redhat.com">the official announcement</a> [redhat.com] and <a href="https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html" title="redhat.com">the more extensive fedora-devel-list post</a> [redhat.com] for more details.

Thanks.</htmltext>
<tokenext>Important note : the policy in question will be changed , likely with an update to be issued tomorrow .
The new policy will be more restrictive than that in Fedora 11 ( it will require root authentication for each package installation operation ) .
Please see the official announcement [ redhat.com ] and the more extensive fedora-devel-list post [ redhat.com ] for more details .
Thanks .</tokentext>
<sentencetext>Important note: the policy in question will be changed, likely with an update to be issued tomorrow.
The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation).
Please see the official announcement [redhat.com] and the more extensive fedora-devel-list post [redhat.com] for more details.
Thanks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150122</id>
	<title>Denial of service attack?</title>
	<author>seandiggity</author>
	<datestamp>1257076440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Besides the obvious problems with this that I've already seen posted here...

Couldn't a user install everything from an approved repo and crash the machine by filling up all the disk space?  Seems like an attack vector for denial of service attacks.</htmltext>
<tokenext>Besides the obvious problems with this that I 've already seen posted here.. . Could n't a user install everything from an approved repo and crash the machine by filling up all the disk space ?
Seems like an attack vector for denial of service attacks .</tokentext>
<sentencetext>Besides the obvious problems with this that I've already seen posted here...

Couldn't a user install everything from an approved repo and crash the machine by filling up all the disk space?
Seems like an attack vector for denial of service attacks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</id>
	<title>Re:It's obvious</title>
	<author>644bd346996</author>
	<datestamp>1257072720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>This isn't necessarily insecure. Sure, it's not something you'd want enabled on your servers, but for a desktop the only big problems I see are with disk space. (If, on the other hand, this allows the user to install and start a network-accessible service without root privileges, then it's a problem.) For home users, this feature is a definite convenience, and nothing to worry about. For corporate desktops, it's more of a wash: employees can install productivity apps without pestering IT, but now IT has to disable repos that contain counter-productivity apps.</p><p>The reason unix has always required root access in order to install software isn't because that's the way things <i>should</i> be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.</p></htmltext>
<tokenext>This is n't necessarily insecure .
Sure , it 's not something you 'd want enabled on your servers , but for a desktop the only big problems I see are with disk space .
( If , on the other hand , this allows the user to install and start a network-accessible service without root privileges , then it 's a problem .
) For home users , this feature is a definite convenience , and nothing to worry about .
For corporate desktops , it 's more of a wash : employees can install productivity apps without pestering IT , but now IT has to disable repos that contain counter-productivity apps.The reason unix has always required root access in order to install software is n't because that 's the way things should be , it 's because there has n't been another way to make it secure .
Now , if you trust the distro 's repos , you can safely let users install those signed packages .
This is similar to ( but more secure than ) Mac OS X 's policy of letting users install and uninstall but not modify app bundles .</tokentext>
<sentencetext>This isn't necessarily insecure.
Sure, it's not something you'd want enabled on your servers, but for a desktop the only big problems I see are with disk space.
(If, on the other hand, this allows the user to install and start a network-accessible service without root privileges, then it's a problem.
) For home users, this feature is a definite convenience, and nothing to worry about.
For corporate desktops, it's more of a wash: employees can install productivity apps without pestering IT, but now IT has to disable repos that contain counter-productivity apps.The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure.
Now, if you trust the distro's repos, you can safely let users install those signed packages.
This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155870</id>
	<title>Re:It's obvious</title>
	<author>Martin Blank</author>
	<datestamp>1258644480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.</p></div></blockquote><p>As I mention in another post, there is a wide variety of packages that could be installed which make me uncomfortable.  It's good that they can't install daemons, but what about dev environments?  IM programs?  Games?  Workplace policies may prohibit the latter two, and dev environments bring about their own issues that I probably don't need to go into.</p></div>
	</htmltext>
<tokenext>It turns out that daemons packaged by Fedora are disabled by default , and require someone with root access to enable them .
A package wo n't pass review if that 's not the case.As I mention in another post , there is a wide variety of packages that could be installed which make me uncomfortable .
It 's good that they ca n't install daemons , but what about dev environments ?
IM programs ?
Games ? Workplace policies may prohibit the latter two , and dev environments bring about their own issues that I probably do n't need to go into .</tokentext>
<sentencetext>It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them.
A package won't pass review if that's not the case.As I mention in another post, there is a wide variety of packages that could be installed which make me uncomfortable.
It's good that they can't install daemons, but what about dev environments?
IM programs?
Games?  Workplace policies may prohibit the latter two, and dev environments bring about their own issues that I probably don't need to go into.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153512</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149664</id>
	<title>100 posts is nothing!</title>
	<author>kimvette</author>
	<datestamp>1257074820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."</p><p>Pfft. 100 posts is nothing. Consider your audience; this is slashdot!</p></htmltext>
<tokenext>" at which point it sparked a mailing list thread that is , as of this writing , over 100 posts long. " Pfft .
100 posts is nothing .
Consider your audience ; this is slashdot !</tokentext>
<sentencetext>"at which point it sparked a mailing list thread that is, as of this writing, over 100 posts long."Pfft.
100 posts is nothing.
Consider your audience; this is slashdot!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155412</id>
	<title>Whew</title>
	<author>kernelpannik</author>
	<datestamp>1258642200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm just glad Fedora got this mistake out of the way already. If this is truly a default setting in upstream PackageKit then the next LTS of Ubuntu might have suffered the same mistake. With all this stink, however, I imagine it will not be duplicated in other distros.</htmltext>
<tokenext>I 'm just glad Fedora got this mistake out of the way already .
If this is truly a default setting in upstream PackageKit then the next LTS of Ubuntu might have suffered the same mistake .
With all this stink , however , I imagine it will not be duplicated in other distros .</tokentext>
<sentencetext>I'm just glad Fedora got this mistake out of the way already.
If this is truly a default setting in upstream PackageKit then the next LTS of Ubuntu might have suffered the same mistake.
With all this stink, however, I imagine it will not be duplicated in other distros.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30159866</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258657080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I believe the closest thing to that is GoboLinux.</p></htmltext>
<tokenext>I believe the closest thing to that is GoboLinux .</tokentext>
<sentencetext>I believe the closest thing to that is GoboLinux.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149492</id>
	<title>Re:Developers vs. Sysadmins</title>
	<author>HangingChad</author>
	<datestamp>1257074100000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p> <i>After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).</i>

</p><p>We did okay in our office.  We let the dev's admin their own machines and an actual sysadmin, like yourself, run the production environment.  For the desktops users put in an install request and we installed the software for them.  It wasn't that hard, we didn't get a lot of requests.

</p><p>I don't see the conflict myself.  Just by running CentOS dev machines and Ubuntu for commodity desktops, we were light years ahead on security without even doing a lot.  As long as no one is staying logged in as root, there are much easier targets.  It's kind of like the bear joke.  We don't have to have bear proof security, just better security than the company next door.</p></htmltext>
<tokenext>After working as a sysadmin for 10 + years for several groups of Linux software devs , I realized that devs do n't make good sysadmins , and vice-versa ( in general ) .
We did okay in our office .
We let the dev 's admin their own machines and an actual sysadmin , like yourself , run the production environment .
For the desktops users put in an install request and we installed the software for them .
It was n't that hard , we did n't get a lot of requests .
I do n't see the conflict myself .
Just by running CentOS dev machines and Ubuntu for commodity desktops , we were light years ahead on security without even doing a lot .
As long as no one is staying logged in as root , there are much easier targets .
It 's kind of like the bear joke .
We do n't have to have bear proof security , just better security than the company next door .</tokentext>
<sentencetext> After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).
We did okay in our office.
We let the dev's admin their own machines and an actual sysadmin, like yourself, run the production environment.
For the desktops users put in an install request and we installed the software for them.
It wasn't that hard, we didn't get a lot of requests.
I don't see the conflict myself.
Just by running CentOS dev machines and Ubuntu for commodity desktops, we were light years ahead on security without even doing a lot.
As long as no one is staying logged in as root, there are much easier targets.
It's kind of like the bear joke.
We don't have to have bear proof security, just better security than the company next door.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153408</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257102000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>take a look at zeroinstall.  never used it, but it seems to have a few very innovative ideas.</p></htmltext>
<tokenext>take a look at zeroinstall .
never used it , but it seems to have a few very innovative ideas .</tokentext>
<sentencetext>take a look at zeroinstall.
never used it, but it seems to have a few very innovative ideas.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154424</id>
	<title>Re:PackageKit at fault, not Fedora</title>
	<author>Homburg</author>
	<datestamp>1258630860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>PackageKit is developed by Richard Hughes, a RedHat employee. It's not like this is some totally separate upstream that has nothing to do with Fedora.</p></htmltext>
<tokenext>PackageKit is developed by Richard Hughes , a RedHat employee .
It 's not like this is some totally separate upstream that has nothing to do with Fedora .</tokentext>
<sentencetext>PackageKit is developed by Richard Hughes, a RedHat employee.
It's not like this is some totally separate upstream that has nothing to do with Fedora.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150316</id>
	<title>How to disable it...</title>
	<author>sten ben</author>
	<datestamp>1257077340000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Here's a blog post on how to disable it: <a href="http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/" title="wordpress.com" rel="nofollow">polkit and package kit and changing settings</a> [wordpress.com] </p><p>I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo?</p></htmltext>
<tokenext>Here 's a blog post on how to disable it : polkit and package kit and changing settings [ wordpress.com ] I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo ?</tokentext>
<sentencetext>Here's a blog post on how to disable it: polkit and package kit and changing settings [wordpress.com] I might be getting a bit conservative in my old age but what of what is explained in that post is better than visudo?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150050</id>
	<title>Re:This makes sense</title>
	<author>XSpud</author>
	<datestamp>1257076260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The contest might be trusted, but not wanted by the administrator of the machine.</p></div><p>I agree - this separation is the norm in just about any corporate environment I've come across. There may be good reasons for staggering the roll-out of trusted software within an organization including: user training issues, ensuring compatibility with other software, making sure hardware is up to scratch etc. </p><p>This policy change removes the ability of admins to manage the roll-out of software to multiple users.</p></div>
	</htmltext>
<tokenext>The contest might be trusted , but not wanted by the administrator of the machine.I agree - this separation is the norm in just about any corporate environment I 've come across .
There may be good reasons for staggering the roll-out of trusted software within an organization including : user training issues , ensuring compatibility with other software , making sure hardware is up to scratch etc .
This policy change removes the ability of admins to manage the roll-out of software to multiple users .</tokentext>
<sentencetext>The contest might be trusted, but not wanted by the administrator of the machine.I agree - this separation is the norm in just about any corporate environment I've come across.
There may be good reasons for staggering the roll-out of trusted software within an organization including: user training issues, ensuring compatibility with other software, making sure hardware is up to scratch etc.
This policy change removes the ability of admins to manage the roll-out of software to multiple users.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150088</id>
	<title>shameful</title>
	<author>Anonymous</author>
	<datestamp>1257076380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>After reading the list discussion I can only say...</p><p>Thank fucking christ for Debian.  The illogical "security" ideas of some involved with Fedora is shameful.</p></htmltext>
<tokenext>After reading the list discussion I can only say...Thank fucking christ for Debian .
The illogical " security " ideas of some involved with Fedora is shameful .</tokentext>
<sentencetext>After reading the list discussion I can only say...Thank fucking christ for Debian.
The illogical "security" ideas of some involved with Fedora is shameful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151882</id>
	<title>Re:It's obvious</title>
	<author>Homburg</author>
	<datestamp>1257086460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Why should the average user have a web or FTP server running on the desktop?</p></div><p>They shouldn't, but PackageKit doesn't allow them to do so - they can install a web server, but they can't run it, or open the ports to allow it to listen on the network.</p></div>
	</htmltext>
<tokenext>Why should the average user have a web or FTP server running on the desktop ? They should n't , but PackageKit does n't allow them to do so - they can install a web server , but they ca n't run it , or open the ports to allow it to listen on the network .</tokentext>
<sentencetext>Why should the average user have a web or FTP server running on the desktop?They shouldn't, but PackageKit doesn't allow them to do so - they can install a web server, but they can't run it, or open the ports to allow it to listen on the network.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772</id>
	<title>Interesting comment on Bugzilla...</title>
	<author>bheer</author>
	<datestamp>1257075180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Interesting and <a href="https://bugzilla.redhat.com/show\_bug.cgi?id=534047#c14" title="redhat.com">wrong</a> [redhat.com], I should say:</p><blockquote><div><p>There's nothing to discuss here. Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system.</p></div></blockquote><p>There's a superficial kind of sense in what he's saying. After all, if someone has console access, he could already pwn the machine, right? Well, the keyword here is <b>defense-in-depth</b>. There are lots of reasons non-root, non-trusted users might want to run from the console. Linux on random net-cafe machines is one example, where all kinds of people use the console. A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.</p><p>Sure, it's trivial to fix this with pklocalauthority, but should users have to? It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it."</p><p>It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot. Cf another gem of a comment on Bugzilla: <a href="https://bugzilla.redhat.com/show\_bug.cgi?id=534047#c9" title="redhat.com">I don't particularly care how UNIX has always worked.</a> [redhat.com] Sigh.</p></div>
	</htmltext>
<tokenext>Interesting and wrong [ redhat.com ] , I should say : There 's nothing to discuss here .
Your problem is that pretending asking for root authentication for * local * users in * active * sessions... when installing * trusted * software adds security is... well.. only a sign of dogma , snakeoil and ignorance when it comes to providing a secure system.There 's a superficial kind of sense in what he 's saying .
After all , if someone has console access , he could already pwn the machine , right ?
Well , the keyword here is defense-in-depth .
There are lots of reasons non-root , non-trusted users might want to run from the console .
Linux on random net-cafe machines is one example , where all kinds of people use the console .
A family PC running Linux ( hey , not as farfetched as it sounds ) might have different user accounts for each family member.Sure , it 's trivial to fix this with pklocalauthority , but should users have to ?
It 's about as lame as telling folk , " hey , you can just switch off IIS if you do n't need it .
" It 's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration , Red Hat seems to be losing the plot .
Cf another gem of a comment on Bugzilla : I do n't particularly care how UNIX has always worked .
[ redhat.com ] Sigh .</tokentext>
<sentencetext>Interesting and wrong [redhat.com], I should say:There's nothing to discuss here.
Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system.There's a superficial kind of sense in what he's saying.
After all, if someone has console access, he could already pwn the machine, right?
Well, the keyword here is defense-in-depth.
There are lots of reasons non-root, non-trusted users might want to run from the console.
Linux on random net-cafe machines is one example, where all kinds of people use the console.
A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.Sure, it's trivial to fix this with pklocalauthority, but should users have to?
It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it.
"It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot.
Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked.
[redhat.com] Sigh.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000</id>
	<title>It's obvious</title>
	<author>Hognoxious</author>
	<datestamp>1257071700000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext>They're just trying to make it more like Windows.</htmltext>
<tokenext>They 're just trying to make it more like Windows .</tokentext>
<sentencetext>They're just trying to make it more like Windows.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150098</id>
	<title>Hang on? This isn't all that new</title>
	<author>Anonymous</author>
	<datestamp>1257076440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've been using Fedora for years now. This has been available at least for the release cycle of F11 (possibly F10). The main difference is the implication that this is the default. Since Fedora 10, you only needed to authenticate as root once. After this, that user is able to install anything without having to re-authenticate.</p><p>For those with gnome, try the command polkit-gnome-authorization. From this the default required authorisation requirement can be set. For F11, the default is Active Console: Admin Authentication (keep indefinitely). Presumably this has been set to Authentication (ie, user auth) or Yes in Fedora 12. Change this as appropriate.</p><p>I will agree though, if this is the default, then this is a frankly bad decision. If the computer is single user, that user would have the root password and, as said earlier, would have already authenticated.</p></htmltext>
<tokenext>I 've been using Fedora for years now .
This has been available at least for the release cycle of F11 ( possibly F10 ) .
The main difference is the implication that this is the default .
Since Fedora 10 , you only needed to authenticate as root once .
After this , that user is able to install anything without having to re-authenticate.For those with gnome , try the command polkit-gnome-authorization .
From this the default required authorisation requirement can be set .
For F11 , the default is Active Console : Admin Authentication ( keep indefinitely ) .
Presumably this has been set to Authentication ( ie , user auth ) or Yes in Fedora 12 .
Change this as appropriate.I will agree though , if this is the default , then this is a frankly bad decision .
If the computer is single user , that user would have the root password and , as said earlier , would have already authenticated .</tokentext>
<sentencetext>I've been using Fedora for years now.
This has been available at least for the release cycle of F11 (possibly F10).
The main difference is the implication that this is the default.
Since Fedora 10, you only needed to authenticate as root once.
After this, that user is able to install anything without having to re-authenticate.For those with gnome, try the command polkit-gnome-authorization.
From this the default required authorisation requirement can be set.
For F11, the default is Active Console: Admin Authentication (keep indefinitely).
Presumably this has been set to Authentication (ie, user auth) or Yes in Fedora 12.
Change this as appropriate.I will agree though, if this is the default, then this is a frankly bad decision.
If the computer is single user, that user would have the root password and, as said earlier, would have already authenticated.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151508</id>
	<title>Re:Developers vs. Sysadmins</title>
	<author>Anonymous</author>
	<datestamp>1257083940000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Thank goodness for virtualization. I can keep the host system locked down and fairly pristine, yet inside the virtual environment I am a wild man with wild thoughts, eating my oatmeal without a spoon, cutting off mattress tags, and installing beta code wherever I see fit.</p></htmltext>
<tokenext>Thank goodness for virtualization .
I can keep the host system locked down and fairly pristine , yet inside the virtual environment I am a wild man with wild thoughts , eating my oatmeal without a spoon , cutting off mattress tags , and installing beta code wherever I see fit .</tokentext>
<sentencetext>Thank goodness for virtualization.
I can keep the host system locked down and fairly pristine, yet inside the virtual environment I am a wild man with wild thoughts, eating my oatmeal without a spoon, cutting off mattress tags, and installing beta code wherever I see fit.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</id>
	<title>User-level package manager</title>
	<author>EvanED</author>
	<datestamp>1257072240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?</p></htmltext>
<tokenext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix = $ HOME/whatever &amp;&amp; make install ' but without the complete bitchness of dependency hell -- without any root privileges at all .
Anyone know of one ?</tokentext>
<sentencetext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all.
Anyone know of one?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012</id>
	<title>Re:It's obvious</title>
	<author>Martin Blank</author>
	<datestamp>1257076080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Trusting the repos has nothing to do with it.  If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about.  Why should the average user have a web or FTP server running on the desktop?  Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.</p><p>While the Fedora devs seem to think that Package-Kit should be removed from servers, this is, as one poster mentioned, a case where "should" has nothing to do with it.  I have an expectation that I have to either use sudo or provide a root password to install even the smallest package.  Changes like this render that expectation void without doing a proper job of notifying me, and there are a lot of relatively unsophisticated Linux admins out there.  There's only a certain level of coddling that should be done to avoid oversimplifying things, but this breaks a fundamental premise of the Linux world, and I don't recall seeing anything in the installer saying that Package-Kit's installer would work differently.</p></htmltext>
<tokenext>Trusting the repos has nothing to do with it .
If I 've got my users on Fedora as their desktops , I do n't want them installing packages that I do n't know about .
Why should the average user have a web or FTP server running on the desktop ?
Default configurations have frequently been the location for vulnerabilities , and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.While the Fedora devs seem to think that Package-Kit should be removed from servers , this is , as one poster mentioned , a case where " should " has nothing to do with it .
I have an expectation that I have to either use sudo or provide a root password to install even the smallest package .
Changes like this render that expectation void without doing a proper job of notifying me , and there are a lot of relatively unsophisticated Linux admins out there .
There 's only a certain level of coddling that should be done to avoid oversimplifying things , but this breaks a fundamental premise of the Linux world , and I do n't recall seeing anything in the installer saying that Package-Kit 's installer would work differently .</tokentext>
<sentencetext>Trusting the repos has nothing to do with it.
If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about.
Why should the average user have a web or FTP server running on the desktop?
Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.While the Fedora devs seem to think that Package-Kit should be removed from servers, this is, as one poster mentioned, a case where "should" has nothing to do with it.
I have an expectation that I have to either use sudo or provide a root password to install even the smallest package.
Changes like this render that expectation void without doing a proper job of notifying me, and there are a lot of relatively unsophisticated Linux admins out there.
There's only a certain level of coddling that should be done to avoid oversimplifying things, but this breaks a fundamental premise of the Linux world, and I don't recall seeing anything in the installer saying that Package-Kit's installer would work differently.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150358</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>HiThere</author>
	<datestamp>1257077520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Letting users us sudo to install software is only acceptable because the right to use sudo is restrictable at the account level.  Even so I'm a bit dubious.  I'd really prefer if software could be installed to only run in a particular group, and that the installation itself be done with privileges to only the group directories.  I *do* understand that this would make the file system more complex, as one would need<nobr> <wbr></nobr>/\_group\_/etc,<nobr> <wbr></nobr>/\_group\_/bin, etc., but I feel it would be slightly more secure.  (Also this would mean that a particular group could have a super-user, who wouldn't necessarily have ANY rights outside the group.)</p><p>The odd thing is, I keep thinking that the first UNIX I ever used worked that way.  Perhaps it was decided that the extra complexity wasn't worth it.</p><p>P.S.:  Sorry about the \_group\_ markup, but<nobr> <wbr></nobr>/. doesn't support underscore markup, and the italic is frequently too understated in a small area.  (And bold definitely isn't what I wanted, and emphasis didn't emphasize noticeably.)</p></htmltext>
<tokenext>Letting users us sudo to install software is only acceptable because the right to use sudo is restrictable at the account level .
Even so I 'm a bit dubious .
I 'd really prefer if software could be installed to only run in a particular group , and that the installation itself be done with privileges to only the group directories .
I * do * understand that this would make the file system more complex , as one would need / \ _group \ _/etc , / \ _group \ _/bin , etc. , but I feel it would be slightly more secure .
( Also this would mean that a particular group could have a super-user , who would n't necessarily have ANY rights outside the group .
) The odd thing is , I keep thinking that the first UNIX I ever used worked that way .
Perhaps it was decided that the extra complexity was n't worth it.P.S .
: Sorry about the \ _group \ _ markup , but / .
does n't support underscore markup , and the italic is frequently too understated in a small area .
( And bold definitely is n't what I wanted , and emphasis did n't emphasize noticeably .
)</tokentext>
<sentencetext>Letting users us sudo to install software is only acceptable because the right to use sudo is restrictable at the account level.
Even so I'm a bit dubious.
I'd really prefer if software could be installed to only run in a particular group, and that the installation itself be done with privileges to only the group directories.
I *do* understand that this would make the file system more complex, as one would need /\_group\_/etc, /\_group\_/bin, etc., but I feel it would be slightly more secure.
(Also this would mean that a particular group could have a super-user, who wouldn't necessarily have ANY rights outside the group.
)The odd thing is, I keep thinking that the first UNIX I ever used worked that way.
Perhaps it was decided that the extra complexity wasn't worth it.P.S.
:  Sorry about the \_group\_ markup, but /.
doesn't support underscore markup, and the italic is frequently too understated in a small area.
(And bold definitely isn't what I wanted, and emphasis didn't emphasize noticeably.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152638</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>Belial6</author>
	<datestamp>1257092880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Oh how I wish that were true...</htmltext>
<tokenext>Oh how I wish that were true.. .</tokentext>
<sentencetext>Oh how I wish that were true...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154986</id>
	<title>Re:It's obvious</title>
	<author>KGBear</author>
	<datestamp>1258639440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Precisely. For some reason though I've been seeing what almost looks like a campaign from users for the right to install software "on their own machines" (never mind these machines belong to the company, not them). This is being billed to management as an absolute necessity in order for people to be able to get work done. Windows is being used as an example by Linux users, who want something akin to the "power user" group Windows offers. I've spent hours this week explaining to managers why giving users full sudo is exactly the same thing as giving them the root password. The fact that Fedora comes up with this new "feature" precisely now raises flags all over my paranoid brain. I'm absolutely certain before the week is over some manager will suggest replacing all our Ubuntu workstations with Fedora as a way to solve the "problem" of users not being able to install software. This looks suspiciously similar to the way Windows took over the corporate desktop in the early-to-mid nineties.<br> <br>
On a related note, what happens in settings like computer labs, where users can be students in a school or patrons in a library, etc.?</htmltext>
<tokenext>Precisely .
For some reason though I 've been seeing what almost looks like a campaign from users for the right to install software " on their own machines " ( never mind these machines belong to the company , not them ) .
This is being billed to management as an absolute necessity in order for people to be able to get work done .
Windows is being used as an example by Linux users , who want something akin to the " power user " group Windows offers .
I 've spent hours this week explaining to managers why giving users full sudo is exactly the same thing as giving them the root password .
The fact that Fedora comes up with this new " feature " precisely now raises flags all over my paranoid brain .
I 'm absolutely certain before the week is over some manager will suggest replacing all our Ubuntu workstations with Fedora as a way to solve the " problem " of users not being able to install software .
This looks suspiciously similar to the way Windows took over the corporate desktop in the early-to-mid nineties .
On a related note , what happens in settings like computer labs , where users can be students in a school or patrons in a library , etc .
?</tokentext>
<sentencetext>Precisely.
For some reason though I've been seeing what almost looks like a campaign from users for the right to install software "on their own machines" (never mind these machines belong to the company, not them).
This is being billed to management as an absolute necessity in order for people to be able to get work done.
Windows is being used as an example by Linux users, who want something akin to the "power user" group Windows offers.
I've spent hours this week explaining to managers why giving users full sudo is exactly the same thing as giving them the root password.
The fact that Fedora comes up with this new "feature" precisely now raises flags all over my paranoid brain.
I'm absolutely certain before the week is over some manager will suggest replacing all our Ubuntu workstations with Fedora as a way to solve the "problem" of users not being able to install software.
This looks suspiciously similar to the way Windows took over the corporate desktop in the early-to-mid nineties.
On a related note, what happens in settings like computer labs, where users can be students in a school or patrons in a library, etc.
?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149540</id>
	<title>Re:I fail to see the problem</title>
	<author>sheph</author>
	<datestamp>1257074340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well that would be fine if it were an option durring the install, but to make it default behavior seems like a bad idea.  I think it's great to give users that choice, but it shouldn't be by default and there should be a flashing warning surrounding the option.  We already have enough infected systems on the net, why make it easier?</htmltext>
<tokenext>Well that would be fine if it were an option durring the install , but to make it default behavior seems like a bad idea .
I think it 's great to give users that choice , but it should n't be by default and there should be a flashing warning surrounding the option .
We already have enough infected systems on the net , why make it easier ?</tokentext>
<sentencetext>Well that would be fine if it were an option durring the install, but to make it default behavior seems like a bad idea.
I think it's great to give users that choice, but it shouldn't be by default and there should be a flashing warning surrounding the option.
We already have enough infected systems on the net, why make it easier?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150808</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>Kjella</author>
	<datestamp>1257079860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Wouldn't it be trivial for a remote user to alter stuff in the user's home dir to install it next time someone logs on with a local user? I think this defense only works if the user never logs on locally, which is very unlikely for a home machine.</p></htmltext>
<tokenext>Would n't it be trivial for a remote user to alter stuff in the user 's home dir to install it next time someone logs on with a local user ?
I think this defense only works if the user never logs on locally , which is very unlikely for a home machine .</tokentext>
<sentencetext>Wouldn't it be trivial for a remote user to alter stuff in the user's home dir to install it next time someone logs on with a local user?
I think this defense only works if the user never logs on locally, which is very unlikely for a home machine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151698</id>
	<title>You dont' need root or sudo to install software</title>
	<author>Dr. Evil</author>
	<datestamp>1257085080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was doing it for years on Slackware and it was one of my biggest gripes with package management.

</p><p>I used to do stuff like download an xmodem protocol app, compile it and run it as a binary from my home directory.  There's no reason I shouldn't be able to install OpenOffice in ~/bin/Openoffice instead of<nobr> <wbr></nobr>/usr/bin/... except that package managers don't work for non-root users.</p></htmltext>
<tokenext>I was doing it for years on Slackware and it was one of my biggest gripes with package management .
I used to do stuff like download an xmodem protocol app , compile it and run it as a binary from my home directory .
There 's no reason I should n't be able to install OpenOffice in ~ /bin/Openoffice instead of /usr/bin/... except that package managers do n't work for non-root users .</tokentext>
<sentencetext>I was doing it for years on Slackware and it was one of my biggest gripes with package management.
I used to do stuff like download an xmodem protocol app, compile it and run it as a binary from my home directory.
There's no reason I shouldn't be able to install OpenOffice in ~/bin/Openoffice instead of /usr/bin/... except that package managers don't work for non-root users.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153570</id>
	<title>someone tell me this another political prank</title>
	<author>Anonymous</author>
	<datestamp>1257104760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><nobr> <wbr></nobr>... and that it will be rolled back after much hue and cry about security and signed packages and signed repos.<br>These "freedom" goons always do things like these for devious political intents and poor young adolescents fall for the "freedom" thing and get infected...</p><p>I cannot believe the Fedora team has actually made such a big change and one of the first instinctive explanations is</p><p><div class="quote"><p>I <strong>don't particularly care how UNIX has always worked</strong>. Looking at the use-cases and the things people are trying to do this seemed the best default. Admins can trivially change the default on machines if they wish.</p></div><p>Don't you guys have enough work fixing bugs and security vulnerabilities in the core packages?<br>Don't those guys at security firms all over the world get income from testing open source programs and publishing vulnerabilities?<br>What happens to them if all signed packages were secure by default?<br>Is that a wise assumption?<br><strong>What's wrong with "remember authentication"?</strong></p><p>Politics. That's the only explanation I can think of. <strong>Distro</strong> Level Trolling !</p></div>
	</htmltext>
<tokenext>... and that it will be rolled back after much hue and cry about security and signed packages and signed repos.These " freedom " goons always do things like these for devious political intents and poor young adolescents fall for the " freedom " thing and get infected...I can not believe the Fedora team has actually made such a big change and one of the first instinctive explanations isI do n't particularly care how UNIX has always worked .
Looking at the use-cases and the things people are trying to do this seemed the best default .
Admins can trivially change the default on machines if they wish.Do n't you guys have enough work fixing bugs and security vulnerabilities in the core packages ? Do n't those guys at security firms all over the world get income from testing open source programs and publishing vulnerabilities ? What happens to them if all signed packages were secure by default ? Is that a wise assumption ? What 's wrong with " remember authentication " ? Politics .
That 's the only explanation I can think of .
Distro Level Trolling !</tokentext>
<sentencetext> ... and that it will be rolled back after much hue and cry about security and signed packages and signed repos.These "freedom" goons always do things like these for devious political intents and poor young adolescents fall for the "freedom" thing and get infected...I cannot believe the Fedora team has actually made such a big change and one of the first instinctive explanations isI don't particularly care how UNIX has always worked.
Looking at the use-cases and the things people are trying to do this seemed the best default.
Admins can trivially change the default on machines if they wish.Don't you guys have enough work fixing bugs and security vulnerabilities in the core packages?Don't those guys at security firms all over the world get income from testing open source programs and publishing vulnerabilities?What happens to them if all signed packages were secure by default?Is that a wise assumption?What's wrong with "remember authentication"?Politics.
That's the only explanation I can think of.
Distro Level Trolling !
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158188</id>
	<title>Re:PackageKit at fault, not Fedora</title>
	<author>Professional Slacker</author>
	<datestamp>1258651920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p> I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g.<nobr> <wbr></nobr>/usr/bin etc.)</p></div><p>No, that's exactly what people are upset about, that any random account logged in to the physical machine can write to<nobr> <wbr></nobr>/usr/bin, the things that they can write are limited to the contents of signed packages, but that's still a whole lot more than the absolutely nothing they could write under F11. Also all the comments I've seen are about adding packages, but does this also allow removing packages?</p></div>
	</htmltext>
<tokenext>I 'm assuming that PackageKit still requires root to modify shared system areas where the owner is root ( e.g .
/usr/bin etc .
) No , that 's exactly what people are upset about , that any random account logged in to the physical machine can write to /usr/bin , the things that they can write are limited to the contents of signed packages , but that 's still a whole lot more than the absolutely nothing they could write under F11 .
Also all the comments I 've seen are about adding packages , but does this also allow removing packages ?</tokentext>
<sentencetext> I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g.
/usr/bin etc.
)No, that's exactly what people are upset about, that any random account logged in to the physical machine can write to /usr/bin, the things that they can write are limited to the contents of signed packages, but that's still a whole lot more than the absolutely nothing they could write under F11.
Also all the comments I've seen are about adding packages, but does this also allow removing packages?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150818</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>BitZtream</author>
	<datestamp>1257079920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I've got a box sitting right here, I'd love to see you boot from a LiveCD.  Not real sure how you're going to do it considering the CD isn't part of the boot sequence and the BIOS is locked with a password.</p><p>You could try to move the drive to a new machine if you'd like, but since thats going to require you digging it out from behind a table, with several large items sitting on top of it, I'm probably going to notice you doing it.  Did I mention the case also has a lock on it?</p><p>I let plenty of random people use it, its a shared workstation in a hotel for guests to use.</p><p>Now, with that in mind, how safe does it sound now?</p><p>This is a retarded policy choice no matter how you look at it by a couple of douce bag milkshakes who shouldn't be allowed to commit to any repository on the planet, even their on personal one.</p></htmltext>
<tokenext>I 've got a box sitting right here , I 'd love to see you boot from a LiveCD .
Not real sure how you 're going to do it considering the CD is n't part of the boot sequence and the BIOS is locked with a password.You could try to move the drive to a new machine if you 'd like , but since thats going to require you digging it out from behind a table , with several large items sitting on top of it , I 'm probably going to notice you doing it .
Did I mention the case also has a lock on it ? I let plenty of random people use it , its a shared workstation in a hotel for guests to use.Now , with that in mind , how safe does it sound now ? This is a retarded policy choice no matter how you look at it by a couple of douce bag milkshakes who should n't be allowed to commit to any repository on the planet , even their on personal one .</tokentext>
<sentencetext>I've got a box sitting right here, I'd love to see you boot from a LiveCD.
Not real sure how you're going to do it considering the CD isn't part of the boot sequence and the BIOS is locked with a password.You could try to move the drive to a new machine if you'd like, but since thats going to require you digging it out from behind a table, with several large items sitting on top of it, I'm probably going to notice you doing it.
Did I mention the case also has a lock on it?I let plenty of random people use it, its a shared workstation in a hotel for guests to use.Now, with that in mind, how safe does it sound now?This is a retarded policy choice no matter how you look at it by a couple of douce bag milkshakes who shouldn't be allowed to commit to any repository on the planet, even their on personal one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150194</id>
	<title>Re:This makes sense</title>
	<author>Wrath0fb0b</author>
	<datestamp>1257076740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.</p> </div><p> Presumably, the now-vulnerable-package will have its signature revoked as soon as the exploit is known. That is, if the implementers were smart enough to have the updater check the latest package list before installing a library -- e.g. if LibFoo v0.81 has the bug, when it checked the list it should see that LibFoo v0.81.1 supersedes that version and refuse to install the older version.</p><p>As I understand things (e.g. poorly), this would not be hard to implement. You could own a machine that's not connected to the net, if those exist anymore, by manually moving the file over there, but I believe that is a corner case.</p></div>
	</htmltext>
<tokenext>Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed , but also in packages you chose not to install .
Presumably , the now-vulnerable-package will have its signature revoked as soon as the exploit is known .
That is , if the implementers were smart enough to have the updater check the latest package list before installing a library -- e.g .
if LibFoo v0.81 has the bug , when it checked the list it should see that LibFoo v0.81.1 supersedes that version and refuse to install the older version.As I understand things ( e.g .
poorly ) , this would not be hard to implement .
You could own a machine that 's not connected to the net , if those exist anymore , by manually moving the file over there , but I believe that is a corner case .</tokentext>
<sentencetext> Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.
Presumably, the now-vulnerable-package will have its signature revoked as soon as the exploit is known.
That is, if the implementers were smart enough to have the updater check the latest package list before installing a library -- e.g.
if LibFoo v0.81 has the bug, when it checked the list it should see that LibFoo v0.81.1 supersedes that version and refuse to install the older version.As I understand things (e.g.
poorly), this would not be hard to implement.
You could own a machine that's not connected to the net, if those exist anymore, by manually moving the file over there, but I believe that is a corner case.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150760</id>
	<title>Re:What does this solve?</title>
	<author>Anonymous</author>
	<datestamp>1257079620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.</p></div><p>The first thing I do on my desktop ubuntu install is<br><tt>\%admin ALL=(ALL) NOPASSWD: ALL</tt></p><p>Fedora is a desktop distro, and I guess that the user is almost always the admin andyway. And even if that is not the case, becoming root and install stuff on a machine you have physiscal access to is trivial.</p><p><div class="quote"><p>Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.</p></div><p>Why? Personally I don't understand all this paranoia.</p></div>
	</htmltext>
<tokenext>I really do n't understand the basis for this move .
From a desktop usability perspective , having the gui password prompt for an elevated privilege such as a package install works fine.The first thing I do on my desktop ubuntu install is \ % admin ALL = ( ALL ) NOPASSWD : ALLFedora is a desktop distro , and I guess that the user is almost always the admin andyway .
And even if that is not the case , becoming root and install stuff on a machine you have physiscal access to is trivial.Its seemless in Linux and OSX .
Not prompting for authentication for signed package installs is insanely insecure and borderline insane.Why ?
Personally I do n't understand all this paranoia .</tokentext>
<sentencetext>I really don't understand the basis for this move.
From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.The first thing I do on my desktop ubuntu install is\%admin ALL=(ALL) NOPASSWD: ALLFedora is a desktop distro, and I guess that the user is almost always the admin andyway.
And even if that is not the case, becoming root and install stuff on a machine you have physiscal access to is trivial.Its seemless in Linux and OSX.
Not prompting for authentication for signed package installs is insanely insecure and borderline insane.Why?
Personally I don't understand all this paranoia.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150190</id>
	<title>Separation of root binaries/local binaries?</title>
	<author>vosester</author>
	<datestamp>1257076740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Isn't this just a separation of root binaries/local binaries, I mean if the packages are signed and placed in a users dir and the user can not install unsigned apps. Then I seen don&rsquo;t really see a problem with this. It might increase the attack vector a little bit.</p><p>But I could see this helping in a corporate environment. Admin could deploy a standard set of apps, and the different department would deploy there own, Then the user could use his own personal email and browser that best fits with there workflow.</p><p>I will properly stick with the Debian/Ubuntu way, but I an not blankly ruling this out as a deployment method until I know more about the pros and cons.</p><p>I think the reaction is a bit over the top</p><p>OMG!!!! my box will get pwned</p><p>I will give the Fedora devs a chance and run this in a virtual machine for testing.</p><p>Its the same with all operating systems what are the default policies for the systems?<br>Why do you think there is 1001 flavours of linux no one distro, Will fit all ways of administration.</p></htmltext>
<tokenext>Is n't this just a separation of root binaries/local binaries , I mean if the packages are signed and placed in a users dir and the user can not install unsigned apps .
Then I seen don    t really see a problem with this .
It might increase the attack vector a little bit.But I could see this helping in a corporate environment .
Admin could deploy a standard set of apps , and the different department would deploy there own , Then the user could use his own personal email and browser that best fits with there workflow.I will properly stick with the Debian/Ubuntu way , but I an not blankly ruling this out as a deployment method until I know more about the pros and cons.I think the reaction is a bit over the topOMG ! ! ! !
my box will get pwnedI will give the Fedora devs a chance and run this in a virtual machine for testing.Its the same with all operating systems what are the default policies for the systems ? Why do you think there is 1001 flavours of linux no one distro , Will fit all ways of administration .</tokentext>
<sentencetext>Isn't this just a separation of root binaries/local binaries, I mean if the packages are signed and placed in a users dir and the user can not install unsigned apps.
Then I seen don’t really see a problem with this.
It might increase the attack vector a little bit.But I could see this helping in a corporate environment.
Admin could deploy a standard set of apps, and the different department would deploy there own, Then the user could use his own personal email and browser that best fits with there workflow.I will properly stick with the Debian/Ubuntu way, but I an not blankly ruling this out as a deployment method until I know more about the pros and cons.I think the reaction is a bit over the topOMG!!!!
my box will get pwnedI will give the Fedora devs a chance and run this in a virtual machine for testing.Its the same with all operating systems what are the default policies for the systems?Why do you think there is 1001 flavours of linux no one distro, Will fit all ways of administration.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30282192</id>
	<title>Re:User-level package manager</title>
	<author>Wanon</author>
	<datestamp>1259677620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>rpm2cpio blah.rpm | cpio -vid</p><p>cpio is an archive format. cpio -vid will extract this archive to the current directory.</p><p>Suddenly you have the contents of the entire rpm in your home dir. Hooray!</p></htmltext>
<tokenext>rpm2cpio blah.rpm | cpio -vidcpio is an archive format .
cpio -vid will extract this archive to the current directory.Suddenly you have the contents of the entire rpm in your home dir .
Hooray !</tokentext>
<sentencetext>rpm2cpio blah.rpm | cpio -vidcpio is an archive format.
cpio -vid will extract this archive to the current directory.Suddenly you have the contents of the entire rpm in your home dir.
Hooray!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152542</id>
	<title>Self Signed?</title>
	<author>Anonymous</author>
	<datestamp>1257091800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I can self sign a package myself in a minute, does that count?</p></htmltext>
<tokenext>I can self sign a package myself in a minute , does that count ?</tokentext>
<sentencetext>I can self sign a package myself in a minute, does that count?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150440</id>
	<title>Re:User-level package manager</title>
	<author>agrif</author>
	<datestamp>1257077940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most programs I know of will let you install packages to any root directory you want, to facilitate hand-installation of the operating system and whatnot. You could do that, but it'd also install <em>all</em> the dependencies, too, which is clearly not what you want.</p><p>The problem with installing the packages, individually, to different directories, is that sometimes (a lot of the time) installed files have hard-coded paths. I know that, technically, hard-coded paths are bad style, but I can see how sometimes they just can't be avoided. Besides, usually any path changes can be taken care of at configure/compile time.</p><p>When you do the compilation by hand, the package knows exactly where you want to put it, and it works. However, when you install a binary package (say from apt) it expects to be in the root, and could (and usually does) fail if it isn't. Package managers don't support this for <em>exactly this reason</em>.</p><p>I bet Gentoo's portage has an option, though, seeing as it compiles everything from scratch anyways. If it doesn't, I'm sure it wouldn't be hard to hack into it, being Gentoo and all. Of course, you'd also have to put up with Gentoo...</p></htmltext>
<tokenext>Most programs I know of will let you install packages to any root directory you want , to facilitate hand-installation of the operating system and whatnot .
You could do that , but it 'd also install all the dependencies , too , which is clearly not what you want.The problem with installing the packages , individually , to different directories , is that sometimes ( a lot of the time ) installed files have hard-coded paths .
I know that , technically , hard-coded paths are bad style , but I can see how sometimes they just ca n't be avoided .
Besides , usually any path changes can be taken care of at configure/compile time.When you do the compilation by hand , the package knows exactly where you want to put it , and it works .
However , when you install a binary package ( say from apt ) it expects to be in the root , and could ( and usually does ) fail if it is n't .
Package managers do n't support this for exactly this reason.I bet Gentoo 's portage has an option , though , seeing as it compiles everything from scratch anyways .
If it does n't , I 'm sure it would n't be hard to hack into it , being Gentoo and all .
Of course , you 'd also have to put up with Gentoo.. .</tokentext>
<sentencetext>Most programs I know of will let you install packages to any root directory you want, to facilitate hand-installation of the operating system and whatnot.
You could do that, but it'd also install all the dependencies, too, which is clearly not what you want.The problem with installing the packages, individually, to different directories, is that sometimes (a lot of the time) installed files have hard-coded paths.
I know that, technically, hard-coded paths are bad style, but I can see how sometimes they just can't be avoided.
Besides, usually any path changes can be taken care of at configure/compile time.When you do the compilation by hand, the package knows exactly where you want to put it, and it works.
However, when you install a binary package (say from apt) it expects to be in the root, and could (and usually does) fail if it isn't.
Package managers don't support this for exactly this reason.I bet Gentoo's portage has an option, though, seeing as it compiles everything from scratch anyways.
If it doesn't, I'm sure it wouldn't be hard to hack into it, being Gentoo and all.
Of course, you'd also have to put up with Gentoo...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149754</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>blueg3</author>
	<datestamp>1257075120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Yes, only the console user can install packages.</p><p>Or, any software the console user is running?<br>Or, perhaps, a web page that the console user is viewing through a web browser with a security vulnerability that enables remote code execution?<br>Or, perhaps, an ad embedded in a web page that...</p></htmltext>
<tokenext>Yes , only the console user can install packages.Or , any software the console user is running ? Or , perhaps , a web page that the console user is viewing through a web browser with a security vulnerability that enables remote code execution ? Or , perhaps , an ad embedded in a web page that.. .</tokentext>
<sentencetext>Yes, only the console user can install packages.Or, any software the console user is running?Or, perhaps, a web page that the console user is viewing through a web browser with a security vulnerability that enables remote code execution?Or, perhaps, an ad embedded in a web page that...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152258</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257089040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Have you seen Gobo Linux?</p></htmltext>
<tokenext>Have you seen Gobo Linux ?</tokentext>
<sentencetext>Have you seen Gobo Linux?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149810</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>RAMMS+EIN</author>
	<datestamp>1257075360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.</p><p>However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?</p><p>And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?</p><p>In either of those cases, you would have a secure-by-default design. Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.</p><p>Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.</p><p>The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the <strong>new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it</strong>.</p></htmltext>
<tokenext>You are right that the idea is that this only applies to the scenario where there is , essentially , a single user who owns , operates , and physically sits at the PC , and that a lot of people seem to be missing that.However , if you own , operate , and physically sit at your PC , how onerous would it be to have to enter your password , or even the root password , when you want to do something as disruptive and uncommon as use the package manager to make system wide changes ? And if that is indeed too onerous , how bad would it be to have to change the configuration to allow you to do same without having to enter a password ? In either of those cases , you would have a secure-by-default design .
Deviating from that just opens a huge can of worms ( no pun intended ) , as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion , and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off , and probably with the default being off.The mind boggling WTF here is n't that somebody thought letting users install packages without having to enter a password is a good idea , but rather that the new , disruptive , less secure setting has been made the default without the world , the users , or even the developers knowing about it .</tokentext>
<sentencetext>You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?In either of those cases, you would have a secure-by-default design.
Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234</id>
	<title>YAY!!!!</title>
	<author>Anonymous</author>
	<datestamp>1257072840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Fedora, Now With The Power Of Windows!!!!</p><p>Tired of those pesky admin privileges.  Tired of using superuser.  Want everyone on your system to install what they like, even from websites  that say "Install Me!", why Fedora 12 is here!  Come on, don't be afraid.  Flush forty years of basic security principles down the toilet!</p></htmltext>
<tokenext>Fedora , Now With The Power Of Windows ! ! !
! Tired of those pesky admin privileges .
Tired of using superuser .
Want everyone on your system to install what they like , even from websites that say " Install Me !
" , why Fedora 12 is here !
Come on , do n't be afraid .
Flush forty years of basic security principles down the toilet !</tokentext>
<sentencetext>Fedora, Now With The Power Of Windows!!!
!Tired of those pesky admin privileges.
Tired of using superuser.
Want everyone on your system to install what they like, even from websites  that say "Install Me!
", why Fedora 12 is here!
Come on, don't be afraid.
Flush forty years of basic security principles down the toilet!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154014</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258624140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><a href="http://0install.net/" title="0install.net" rel="nofollow">http://0install.net</a> [0install.net]</p></htmltext>
<tokenext>http : //0install.net [ 0install.net ]</tokentext>
<sentencetext>http://0install.net [0install.net]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153170</id>
	<title>Re:It's obvious</title>
	<author>cppmonkey</author>
	<datestamp>1257098940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Huh What? OS X let's standard users install software? Sorry but looking at my 10.4 and 10.5 machines that would be a no. Having worked on a few 10.6 machines today I am confident that they are the same but I don't have one here to test. Standard (non admin users) can not "install" software except in their own home directory just like Linux (though installing to one's home directory is not for the faint of heart). Standard users can not add launch deamons or otherwise modify<nobr> <wbr></nobr>/Library or<nobr> <wbr></nobr>/Applications. This is actually how it should be. Users can do anything they want in their space so long as it does not affect other users or the system. That's actually security not this we will control what you can and can not do in infinitely fine detail. The big problem is that Linux and Windows require you to modify the SYSTEM in order to do practically anything. Want to run new/updated software then you need to drop some libraries in<nobr> <wbr></nobr>/usr/lib some resources in<nobr> <wbr></nobr>/usr/share etc. One of the ways OS X makes management so much easier is to let applications bundle their libraries inside those application bundles. Those same bundles that end users who happen to be the owner in terms of file permissions can indeed modify (unless they are a "managed" user) This enables drag and drop installs and the ability to have ~/Applications/Nifty*.app. So every user can have their own web browser and their own productivity software and it just works.</p></htmltext>
<tokenext>Huh What ?
OS X let 's standard users install software ?
Sorry but looking at my 10.4 and 10.5 machines that would be a no .
Having worked on a few 10.6 machines today I am confident that they are the same but I do n't have one here to test .
Standard ( non admin users ) can not " install " software except in their own home directory just like Linux ( though installing to one 's home directory is not for the faint of heart ) .
Standard users can not add launch deamons or otherwise modify /Library or /Applications .
This is actually how it should be .
Users can do anything they want in their space so long as it does not affect other users or the system .
That 's actually security not this we will control what you can and can not do in infinitely fine detail .
The big problem is that Linux and Windows require you to modify the SYSTEM in order to do practically anything .
Want to run new/updated software then you need to drop some libraries in /usr/lib some resources in /usr/share etc .
One of the ways OS X makes management so much easier is to let applications bundle their libraries inside those application bundles .
Those same bundles that end users who happen to be the owner in terms of file permissions can indeed modify ( unless they are a " managed " user ) This enables drag and drop installs and the ability to have ~ /Applications/Nifty * .app .
So every user can have their own web browser and their own productivity software and it just works .</tokentext>
<sentencetext>Huh What?
OS X let's standard users install software?
Sorry but looking at my 10.4 and 10.5 machines that would be a no.
Having worked on a few 10.6 machines today I am confident that they are the same but I don't have one here to test.
Standard (non admin users) can not "install" software except in their own home directory just like Linux (though installing to one's home directory is not for the faint of heart).
Standard users can not add launch deamons or otherwise modify /Library or /Applications.
This is actually how it should be.
Users can do anything they want in their space so long as it does not affect other users or the system.
That's actually security not this we will control what you can and can not do in infinitely fine detail.
The big problem is that Linux and Windows require you to modify the SYSTEM in order to do practically anything.
Want to run new/updated software then you need to drop some libraries in /usr/lib some resources in /usr/share etc.
One of the ways OS X makes management so much easier is to let applications bundle their libraries inside those application bundles.
Those same bundles that end users who happen to be the owner in terms of file permissions can indeed modify (unless they are a "managed" user) This enables drag and drop installs and the ability to have ~/Applications/Nifty*.app.
So every user can have their own web browser and their own productivity software and it just works.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30189728</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258812120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?</p></div><p>With 'stow' you are relieved of the problems of conflicting versions and cruft, so you can focus on 'the complete bitchness of dependency hell'.</p></div>
	</htmltext>
<tokenext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix = $ HOME/whatever &amp;&amp; make install ' but without the complete bitchness of dependency hell -- without any root privileges at all .
Anyone know of one ? With 'stow ' you are relieved of the problems of conflicting versions and cruft , so you can focus on 'the complete bitchness of dependency hell' .</tokentext>
<sentencetext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all.
Anyone know of one?With 'stow' you are relieved of the problems of conflicting versions and cruft, so you can focus on 'the complete bitchness of dependency hell'.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149778</id>
	<title>How about signed non-suid non-services?</title>
	<author>Captain Segfault</author>
	<datestamp>1257075240000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>The big <i>security</i> issues are with services and suid/sgid binaries. As long as installing the package doesn't cause any other users to run that code it shouldn't be any more of a problem than letting the user run their own code. Those probably should require root to install.</p><p>This isn't 100\% watertight but would drastically reduce the scope for local root exploits.</p><p>It'd be stupid to have this policy on a server, obviously, but it doesn't seem to be that absurd at all for desktops/workstations.</p></htmltext>
<tokenext>The big security issues are with services and suid/sgid binaries .
As long as installing the package does n't cause any other users to run that code it should n't be any more of a problem than letting the user run their own code .
Those probably should require root to install.This is n't 100 \ % watertight but would drastically reduce the scope for local root exploits.It 'd be stupid to have this policy on a server , obviously , but it does n't seem to be that absurd at all for desktops/workstations .</tokentext>
<sentencetext>The big security issues are with services and suid/sgid binaries.
As long as installing the package doesn't cause any other users to run that code it shouldn't be any more of a problem than letting the user run their own code.
Those probably should require root to install.This isn't 100\% watertight but would drastically reduce the scope for local root exploits.It'd be stupid to have this policy on a server, obviously, but it doesn't seem to be that absurd at all for desktops/workstations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149436</id>
	<title>It sounds scary...</title>
	<author>Anonymous</author>
	<datestamp>1257073860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>but I don't know if it is.  It makes sense for my computers when I am the admin and my three other users are friends and family.  It does not make sense for computers where I have worked. Of course they used CENTOS or RHEL.  Which I would have blithely updated before admins had a clue to say don't do that. It would have made reversion a nightmare.  It might have fixed some problems but I don't know how many new problems it would have introduced.  This does seem to be headed towards the Windows model of security which maybe a great strength for Windows but it is also its greatest weakness.</p></htmltext>
<tokenext>but I do n't know if it is .
It makes sense for my computers when I am the admin and my three other users are friends and family .
It does not make sense for computers where I have worked .
Of course they used CENTOS or RHEL .
Which I would have blithely updated before admins had a clue to say do n't do that .
It would have made reversion a nightmare .
It might have fixed some problems but I do n't know how many new problems it would have introduced .
This does seem to be headed towards the Windows model of security which maybe a great strength for Windows but it is also its greatest weakness .</tokentext>
<sentencetext>but I don't know if it is.
It makes sense for my computers when I am the admin and my three other users are friends and family.
It does not make sense for computers where I have worked.
Of course they used CENTOS or RHEL.
Which I would have blithely updated before admins had a clue to say don't do that.
It would have made reversion a nightmare.
It might have fixed some problems but I don't know how many new problems it would have introduced.
This does seem to be headed towards the Windows model of security which maybe a great strength for Windows but it is also its greatest weakness.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152666</id>
	<title>Re:It's obvious</title>
	<author>Anonymous</author>
	<datestamp>1257093180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>And this customer-hostile attitude in the Linux world is why Windows has market share and Linux doesn't. It is also why we will always have insecure crap infesting the net.</htmltext>
<tokenext>And this customer-hostile attitude in the Linux world is why Windows has market share and Linux does n't .
It is also why we will always have insecure crap infesting the net .</tokentext>
<sentencetext>And this customer-hostile attitude in the Linux world is why Windows has market share and Linux doesn't.
It is also why we will always have insecure crap infesting the net.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149342</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152774</id>
	<title>Re:This makes sense</title>
	<author>Anonymous</author>
	<datestamp>1257094140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And what if you didn't install compilers, or network monitoring software just so your users can't have the ability to compile up exploit code or monitor and probe the network. Now they can install them themselves and have all the tools they need to carry out directed attacks against your or other systems.</p><p>This is bad. It removes the ability to configure a machine to least privilige to where it serves only limited purposes. If it has other users, it can now do pretty much anything.</p><p>This needs to come out. Hopefully there will be an easy way to block this "feature".</p></htmltext>
<tokenext>And what if you did n't install compilers , or network monitoring software just so your users ca n't have the ability to compile up exploit code or monitor and probe the network .
Now they can install them themselves and have all the tools they need to carry out directed attacks against your or other systems.This is bad .
It removes the ability to configure a machine to least privilige to where it serves only limited purposes .
If it has other users , it can now do pretty much anything.This needs to come out .
Hopefully there will be an easy way to block this " feature " .</tokentext>
<sentencetext>And what if you didn't install compilers, or network monitoring software just so your users can't have the ability to compile up exploit code or monitor and probe the network.
Now they can install them themselves and have all the tools they need to carry out directed attacks against your or other systems.This is bad.
It removes the ability to configure a machine to least privilige to where it serves only limited purposes.
If it has other users, it can now do pretty much anything.This needs to come out.
Hopefully there will be an easy way to block this "feature".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</id>
	<title>Developers vs. Sysadmins</title>
	<author>Anonymous</author>
	<datestamp>1257072420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Ah yes, the age-old struggle between developers and sysadmins bears yet more sour fruit.</p><p>After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).</p><p>Developer workstations are usually a mess of tweaks, customizations, hacks, extraneous libraries that they were "testing" three months ago, odd daemons, and all kinds of other crap. They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.</p><p>Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing. This is great when we're talking the company webservers, but when it comes to developer workstations, well... the devs weren't too happy about being locked down.</p><p>I guarantee you that this feature was requested/suggested by one or more developers on the team, who thought it'd make their lives easier. And I also guarantee you that most of the people against it are system administrators.</p><p>God, I'm glad I went back into Science.</p></htmltext>
<tokenext>Ah yes , the age-old struggle between developers and sysadmins bears yet more sour fruit.After working as a sysadmin for 10 + years for several groups of Linux software devs , I realized that devs do n't make good sysadmins , and vice-versa ( in general ) .Developer workstations are usually a mess of tweaks , customizations , hacks , extraneous libraries that they were " testing " three months ago , odd daemons , and all kinds of other crap .
They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing .
This is great when we 're talking the company webservers , but when it comes to developer workstations , well... the devs were n't too happy about being locked down.I guarantee you that this feature was requested/suggested by one or more developers on the team , who thought it 'd make their lives easier .
And I also guarantee you that most of the people against it are system administrators.God , I 'm glad I went back into Science .</tokentext>
<sentencetext>Ah yes, the age-old struggle between developers and sysadmins bears yet more sour fruit.After working as a sysadmin for 10+ years for several groups of Linux software devs, I realized that devs don't make good sysadmins, and vice-versa (in general).Developer workstations are usually a mess of tweaks, customizations, hacks, extraneous libraries that they were "testing" three months ago, odd daemons, and all kinds of other crap.
They would install new packages hourly - so all the better if they could do it without requiring root access to the servers.Sysadmins on the other hand tend to be uptight control freaks who micro-manage every little thing.
This is great when we're talking the company webservers, but when it comes to developer workstations, well... the devs weren't too happy about being locked down.I guarantee you that this feature was requested/suggested by one or more developers on the team, who thought it'd make their lives easier.
And I also guarantee you that most of the people against it are system administrators.God, I'm glad I went back into Science.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150</id>
	<title>What does this solve?</title>
	<author>asv108</author>
	<datestamp>1257072480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX. Not prompting for authentication for signed package installs is insanely insecure and borderline insane.</htmltext>
<tokenext>I really do n't understand the basis for this move .
From a desktop usability perspective , having the gui password prompt for an elevated privilege such as a package install works fine .
Its seemless in Linux and OSX .
Not prompting for authentication for signed package installs is insanely insecure and borderline insane .</tokentext>
<sentencetext>I really don't understand the basis for this move.
From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.
Its seemless in Linux and OSX.
Not prompting for authentication for signed package installs is insanely insecure and borderline insane.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149264</id>
	<title>Re:User-level package manager</title>
	<author>Nimey</author>
	<datestamp>1257073020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Stow isn't quite what you want, but it's pretty close.  I've used it for just about ten years for locally-compiled stuff.</p><p>Generally what I do is<nobr> <wbr></nobr>./configure --prefix=/usr/local/stow/[PACKAGENAME-VERSION] &amp;&amp; make &amp;&amp; sudo make install, then cd<nobr> <wbr></nobr>/usr/local/stow and type "sudo stow [PACKAGENAME-VERSION].  Removal is a simple cd<nobr> <wbr></nobr>/usr/local/stow &amp;&amp; sudo stow -D [PACKAGENAME-VERSION].  It doesn't worry about dependencies at all, and really all it does is make symlinks in<nobr> <wbr></nobr>/usr/local/bin,<nobr> <wbr></nobr>/usr/local/share, and so on.</p><p>It would be trivial to set up a ~/stow directory and use that instead of<nobr> <wbr></nobr>/usr/local/stow.</p><p>[PACKAGENAME-VERSION], such as nano-2.0.9.</p></htmltext>
<tokenext>Stow is n't quite what you want , but it 's pretty close .
I 've used it for just about ten years for locally-compiled stuff.Generally what I do is ./configure --prefix = /usr/local/stow/ [ PACKAGENAME-VERSION ] &amp;&amp; make &amp;&amp; sudo make install , then cd /usr/local/stow and type " sudo stow [ PACKAGENAME-VERSION ] .
Removal is a simple cd /usr/local/stow &amp;&amp; sudo stow -D [ PACKAGENAME-VERSION ] .
It does n't worry about dependencies at all , and really all it does is make symlinks in /usr/local/bin , /usr/local/share , and so on.It would be trivial to set up a ~ /stow directory and use that instead of /usr/local/stow .
[ PACKAGENAME-VERSION ] , such as nano-2.0.9 .</tokentext>
<sentencetext>Stow isn't quite what you want, but it's pretty close.
I've used it for just about ten years for locally-compiled stuff.Generally what I do is ./configure --prefix=/usr/local/stow/[PACKAGENAME-VERSION] &amp;&amp; make &amp;&amp; sudo make install, then cd /usr/local/stow and type "sudo stow [PACKAGENAME-VERSION].
Removal is a simple cd /usr/local/stow &amp;&amp; sudo stow -D [PACKAGENAME-VERSION].
It doesn't worry about dependencies at all, and really all it does is make symlinks in /usr/local/bin, /usr/local/share, and so on.It would be trivial to set up a ~/stow directory and use that instead of /usr/local/stow.
[PACKAGENAME-VERSION], such as nano-2.0.9.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150322</id>
	<title>Re:It's obvious</title>
	<author>Penguinisto</author>
	<datestamp>1257077340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>If you're doing it corporate-style, you should already have a local repo (for bandwidth and security reasons), them lock yum.conf to only recognize your local repo.</p><p>Doesn't solve all permutations (e.g. discreet downloaded packages, some idiot installing apt-get, etc), but it solves enough of them to make things sane again.</p></htmltext>
<tokenext>If you 're doing it corporate-style , you should already have a local repo ( for bandwidth and security reasons ) , them lock yum.conf to only recognize your local repo.Does n't solve all permutations ( e.g .
discreet downloaded packages , some idiot installing apt-get , etc ) , but it solves enough of them to make things sane again .</tokentext>
<sentencetext>If you're doing it corporate-style, you should already have a local repo (for bandwidth and security reasons), them lock yum.conf to only recognize your local repo.Doesn't solve all permutations (e.g.
discreet downloaded packages, some idiot installing apt-get, etc), but it solves enough of them to make things sane again.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149250</id>
	<title>Re:Of course there isn't a problem</title>
	<author>Anonymous</author>
	<datestamp>1257072900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Worse than that, consider your same scenario where Package X suffers a critical vulnerability, but the sysadmin is on top of it so checks the system to make sure package X is not installed.  Then the next day, random user or malicious user, installs package X without the sysadmin knowing.</p></htmltext>
<tokenext>Worse than that , consider your same scenario where Package X suffers a critical vulnerability , but the sysadmin is on top of it so checks the system to make sure package X is not installed .
Then the next day , random user or malicious user , installs package X without the sysadmin knowing .</tokentext>
<sentencetext>Worse than that, consider your same scenario where Package X suffers a critical vulnerability, but the sysadmin is on top of it so checks the system to make sure package X is not installed.
Then the next day, random user or malicious user, installs package X without the sysadmin knowing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150084</id>
	<title>Forget vulnerabilities, think telnetd</title>
	<author>Xtifr</author>
	<datestamp>1257076380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Unless there simply <em>isn't</em>, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems.  Many packages are not the sort of thing you would really want to have on, say, a publicly accessible machine, but might be willing to have on a system on your LAN (Samba springs to mind).  Beyond vulnerabilities, there's the simple issue of exposure.</p><p>If the admin can't define who is allowed to do such basic administration tasks as <em>installing packages</em>, something is seriously wrong!</p></htmltext>
<tokenext>Unless there simply is n't , e.g. , a signed telnetd package , you do n't need undiscovered vulnerabilities for this to be a potential for major problems .
Many packages are not the sort of thing you would really want to have on , say , a publicly accessible machine , but might be willing to have on a system on your LAN ( Samba springs to mind ) .
Beyond vulnerabilities , there 's the simple issue of exposure.If the admin ca n't define who is allowed to do such basic administration tasks as installing packages , something is seriously wrong !</tokentext>
<sentencetext>Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems.
Many packages are not the sort of thing you would really want to have on, say, a publicly accessible machine, but might be willing to have on a system on your LAN (Samba springs to mind).
Beyond vulnerabilities, there's the simple issue of exposure.If the admin can't define who is allowed to do such basic administration tasks as installing packages, something is seriously wrong!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992</id>
	<title>Wow</title>
	<author>Anonymous</author>
	<datestamp>1257071640000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Sounds like I need to upgrade to Windows 7 for some real security...</p></htmltext>
<tokenext>Sounds like I need to upgrade to Windows 7 for some real security.. .</tokentext>
<sentencetext>Sounds like I need to upgrade to Windows 7 for some real security...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038</id>
	<title>Re:It's obvious</title>
	<author>Anonymous</author>
	<datestamp>1257071820000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>I agree.. reading the thread, one of the people who implemented this said (paraphrasing) "I don't care about the way *nix has "always worked" - users want it this way."</p><p>That sounds pretty much like the Windows approach to me. "Screw security, this will be easier!"</p></htmltext>
<tokenext>I agree.. reading the thread , one of the people who implemented this said ( paraphrasing ) " I do n't care about the way * nix has " always worked " - users want it this way .
" That sounds pretty much like the Windows approach to me .
" Screw security , this will be easier !
"</tokentext>
<sentencetext>I agree.. reading the thread, one of the people who implemented this said (paraphrasing) "I don't care about the way *nix has "always worked" - users want it this way.
"That sounds pretty much like the Windows approach to me.
"Screw security, this will be easier!
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151892</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257086580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes. <a href="http://www.gentoo.org/proj/en/gentoo-alt/prefix/" title="gentoo.org" rel="nofollow">Gentoo Prefix</a> [gentoo.org].</p><p>It has all of the functionality of Gentoo's package manager, Portage, but can be run by an unprivileged user.</p></htmltext>
<tokenext>Yes .
Gentoo Prefix [ gentoo.org ] .It has all of the functionality of Gentoo 's package manager , Portage , but can be run by an unprivileged user .</tokentext>
<sentencetext>Yes.
Gentoo Prefix [gentoo.org].It has all of the functionality of Gentoo's package manager, Portage, but can be run by an unprivileged user.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154066</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258625160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Try http://0install.net/</p></htmltext>
<tokenext>Try http : //0install.net/</tokentext>
<sentencetext>Try http://0install.net/</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155808</id>
	<title>Pourquoi sans English</title>
	<author>Benson Arizona</author>
	<datestamp>1258644240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Has anyone else noticed French words such as <em>sans</em> gradually creeping into English in place of perfectly good words such as <em>without</em>? I believe that this is not coincidental but rather the work of a dedicated group of French extremists who, by gradually increasing the proportion of French words in circulation, hope to replace the English language entirely within just a few decades. Par recognizer this behaviour, we can arret it before it gets out of main. Mai, si nous do not faites attention then pendant just a few ans, we could find qui French is the nouvel Anglais. Dit "non" maintenant a English avec Francais!
<br> <br>
Diese Anmerkung ist auch auf Deutsch vorhanden.
<br> <br>
Well it's lunch time and all the blinkenlights are working...</htmltext>
<tokenext>Has anyone else noticed French words such as sans gradually creeping into English in place of perfectly good words such as without ?
I believe that this is not coincidental but rather the work of a dedicated group of French extremists who , by gradually increasing the proportion of French words in circulation , hope to replace the English language entirely within just a few decades .
Par recognizer this behaviour , we can arret it before it gets out of main .
Mai , si nous do not faites attention then pendant just a few ans , we could find qui French is the nouvel Anglais .
Dit " non " maintenant a English avec Francais !
Diese Anmerkung ist auch auf Deutsch vorhanden .
Well it 's lunch time and all the blinkenlights are working.. .</tokentext>
<sentencetext>Has anyone else noticed French words such as sans gradually creeping into English in place of perfectly good words such as without?
I believe that this is not coincidental but rather the work of a dedicated group of French extremists who, by gradually increasing the proportion of French words in circulation, hope to replace the English language entirely within just a few decades.
Par recognizer this behaviour, we can arret it before it gets out of main.
Mai, si nous do not faites attention then pendant just a few ans, we could find qui French is the nouvel Anglais.
Dit "non" maintenant a English avec Francais!
Diese Anmerkung ist auch auf Deutsch vorhanden.
Well it's lunch time and all the blinkenlights are working...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152696</id>
	<title>Re:It's obvious</title>
	<author>plasticsquirrel</author>
	<datestamp>1257093480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>The reason unix has always required root access in order to install software isn't because that's the way things <i>should</i> be, it's because there hasn't been another way to make it secure. Now, if you trust the distro's repos, you can safely let users install those signed packages. This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.</p></div><p>The reason was simply because a user didn't have the privileges to change anything (by default) outside his/her own home directory and the system temporary directory. That is the way it should be -- only changing files that you have permission to change. Allowing users to add or remove software packages in / and<nobr> <wbr></nobr>/usr is beyond ridiculous. This is why users who want to install software packages themselves, can only install them to their own home directories, so they don't interfere with other users. The only sensible approach is one such as this, where users can only install software where they have permission to do so.<br> <br>If the Fedora people really want to fix things, they could work on making their packages easy to install into the users' home folders, so users don't have to use the "configure prefix" to change things around, and then compile from source. That sort of user software installation is perfectly reasonable, and completely in line with the overarching concepts of Unix security.</p></div>
	</htmltext>
<tokenext>The reason unix has always required root access in order to install software is n't because that 's the way things should be , it 's because there has n't been another way to make it secure .
Now , if you trust the distro 's repos , you can safely let users install those signed packages .
This is similar to ( but more secure than ) Mac OS X 's policy of letting users install and uninstall but not modify app bundles.The reason was simply because a user did n't have the privileges to change anything ( by default ) outside his/her own home directory and the system temporary directory .
That is the way it should be -- only changing files that you have permission to change .
Allowing users to add or remove software packages in / and /usr is beyond ridiculous .
This is why users who want to install software packages themselves , can only install them to their own home directories , so they do n't interfere with other users .
The only sensible approach is one such as this , where users can only install software where they have permission to do so .
If the Fedora people really want to fix things , they could work on making their packages easy to install into the users ' home folders , so users do n't have to use the " configure prefix " to change things around , and then compile from source .
That sort of user software installation is perfectly reasonable , and completely in line with the overarching concepts of Unix security .</tokentext>
<sentencetext>The reason unix has always required root access in order to install software isn't because that's the way things should be, it's because there hasn't been another way to make it secure.
Now, if you trust the distro's repos, you can safely let users install those signed packages.
This is similar to (but more secure than) Mac OS X's policy of letting users install and uninstall but not modify app bundles.The reason was simply because a user didn't have the privileges to change anything (by default) outside his/her own home directory and the system temporary directory.
That is the way it should be -- only changing files that you have permission to change.
Allowing users to add or remove software packages in / and /usr is beyond ridiculous.
This is why users who want to install software packages themselves, can only install them to their own home directories, so they don't interfere with other users.
The only sensible approach is one such as this, where users can only install software where they have permission to do so.
If the Fedora people really want to fix things, they could work on making their packages easy to install into the users' home folders, so users don't have to use the "configure prefix" to change things around, and then compile from source.
That sort of user software installation is perfectly reasonable, and completely in line with the overarching concepts of Unix security.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152834</id>
	<title>Re:It's obvious</title>
	<author>NeverVotedBush</author>
	<datestamp>1257094800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Do you really want your users installing and running things like Wireshark and nmap?<br> <br>

Or, maybe compilers so they can turn exploit code into executables all that much easier?<br> <br>

The problem goes way beyond disk space.</htmltext>
<tokenext>Do you really want your users installing and running things like Wireshark and nmap ?
Or , maybe compilers so they can turn exploit code into executables all that much easier ?
The problem goes way beyond disk space .</tokentext>
<sentencetext>Do you really want your users installing and running things like Wireshark and nmap?
Or, maybe compilers so they can turn exploit code into executables all that much easier?
The problem goes way beyond disk space.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149326</id>
	<title>I don't get it...</title>
	<author>Junta</author>
	<datestamp>1257073320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If it *is* a desktop scenario, then controlling it via sudo shouldn't be a problem.  If you don't have sudo access, I don't see why you should get to install packages...</p><p>Second, a vulnerability is found in an apache package in fedora 12, and the repo is fixed, but vulnerable versions from release may be had by crackers.  A fedora server with multiple users that doesn't happen to have apache installed is vulnerable to having the vulnerable package injected by an untrusted user.</p></htmltext>
<tokenext>If it * is * a desktop scenario , then controlling it via sudo should n't be a problem .
If you do n't have sudo access , I do n't see why you should get to install packages...Second , a vulnerability is found in an apache package in fedora 12 , and the repo is fixed , but vulnerable versions from release may be had by crackers .
A fedora server with multiple users that does n't happen to have apache installed is vulnerable to having the vulnerable package injected by an untrusted user .</tokentext>
<sentencetext>If it *is* a desktop scenario, then controlling it via sudo shouldn't be a problem.
If you don't have sudo access, I don't see why you should get to install packages...Second, a vulnerability is found in an apache package in fedora 12, and the repo is fixed, but vulnerable versions from release may be had by crackers.
A fedora server with multiple users that doesn't happen to have apache installed is vulnerable to having the vulnerable package injected by an untrusted user.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152982</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>raylu</author>
	<datestamp>1257096660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So you disallow ping without root, too?</p></htmltext>
<tokenext>So you disallow ping without root , too ?</tokentext>
<sentencetext>So you disallow ping without root, too?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151740</id>
	<title>It is an irony...</title>
	<author>drolli</author>
	<datestamp>1257085380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>that many posters here see this as a security bug "because it enables you to install any exploit found in any package". That is true and untrue at the same time. A good idea would be that no user may create a setuid root binary. But all escalations based on system call implementation errors can be provoked by the user himself by picking out the right code from the source of the packages and compiling it himself using the gcc which is most likely available on many systems.</p><p>An even better idea view would be an per-user-view of the computer.</p></htmltext>
<tokenext>that many posters here see this as a security bug " because it enables you to install any exploit found in any package " .
That is true and untrue at the same time .
A good idea would be that no user may create a setuid root binary .
But all escalations based on system call implementation errors can be provoked by the user himself by picking out the right code from the source of the packages and compiling it himself using the gcc which is most likely available on many systems.An even better idea view would be an per-user-view of the computer .</tokentext>
<sentencetext>that many posters here see this as a security bug "because it enables you to install any exploit found in any package".
That is true and untrue at the same time.
A good idea would be that no user may create a setuid root binary.
But all escalations based on system call implementation errors can be provoked by the user himself by picking out the right code from the source of the packages and compiling it himself using the gcc which is most likely available on many systems.An even better idea view would be an per-user-view of the computer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151510</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>Xtifr</author>
	<datestamp>1257083940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yeah?  And my <b>NINE-YEAR-OLD NIECE</b> regularly sits at my computer!  <b>PHYSICALLY!!</b>  And no, I <b>DON'T WANT HER TO INSTALL RANDOM STUFF!</b>  And no, I'm <b>NOT WORRIED ABOUT HER ROOTING THE MACHINE</b>.  But I <b>STILL DON'T WANT HER INSTALLING RANDOM STUFF</b>!  I trust her, but only so far, and she might start to wonder what this telnetd package is....  She's nine!</p><p>Does my <b>SHOUTING IN BOLD-FACED CAPS</b> help get the message across, or is it as annoying and pointless as it was in your post?<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Yeah ?
And my NINE-YEAR-OLD NIECE regularly sits at my computer !
PHYSICALLY ! ! And no , I DO N'T WANT HER TO INSTALL RANDOM STUFF !
And no , I 'm NOT WORRIED ABOUT HER ROOTING THE MACHINE .
But I STILL DO N'T WANT HER INSTALLING RANDOM STUFF !
I trust her , but only so far , and she might start to wonder what this telnetd package is.... She 's nine ! Does my SHOUTING IN BOLD-FACED CAPS help get the message across , or is it as annoying and pointless as it was in your post ?
: )</tokentext>
<sentencetext>Yeah?
And my NINE-YEAR-OLD NIECE regularly sits at my computer!
PHYSICALLY!!  And no, I DON'T WANT HER TO INSTALL RANDOM STUFF!
And no, I'm NOT WORRIED ABOUT HER ROOTING THE MACHINE.
But I STILL DON'T WANT HER INSTALLING RANDOM STUFF!
I trust her, but only so far, and she might start to wonder what this telnetd package is....  She's nine!Does my SHOUTING IN BOLD-FACED CAPS help get the message across, or is it as annoying and pointless as it was in your post?
:)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154890</id>
	<title>Re:User-level package manager</title>
	<author>TP2k</author>
	<datestamp>1258638600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Take a peek at <a href="http://www.gentoo.org/proj/en/gentoo-alt/prefix/" title="gentoo.org" rel="nofollow">Gentoo Prefix</a> [gentoo.org].
It still requires you to build from source, but it will provide you with dependency resolution.
I know people who have run it in $HOME on CentOS boxes.</htmltext>
<tokenext>Take a peek at Gentoo Prefix [ gentoo.org ] .
It still requires you to build from source , but it will provide you with dependency resolution .
I know people who have run it in $ HOME on CentOS boxes .</tokentext>
<sentencetext>Take a peek at Gentoo Prefix [gentoo.org].
It still requires you to build from source, but it will provide you with dependency resolution.
I know people who have run it in $HOME on CentOS boxes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150612</id>
	<title>Re:Developers vs. Sysadmins</title>
	<author>BitZtream</author>
	<datestamp>1257078840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A good sys admin acting as a developer is fine.</p><p>What you describe is a shitty developer.</p><p>A good developer will develop as a normal user, no development environment I'm aware of actually requires elevated privs for standard development, including Visual Studio using IIS for web apps if you invest the 30 seconds it takes to google for the solution in older versions, newer versions run their own webserver as needed to avoid that problem as well.</p><p>A good developer will test on clean machines/fresh installs regularly.</p><p>A good developer will test on locked down machines regularly.</p><p>A good developer will write an application that doesn't require any specific additional privileges unless they are truly needed, and they'll document what those privileges are and why they are needed.</p><p>A good developer has no problem dealing with Nazi admins, the developer will know how to explain EXACTLY why elevated privileges are needed to the admin and what safety precautions are in place or should be observed to limit potential breeches due to those privs.</p><p>This problem is a result of cluelessness on the part of the devs who created it, I classify it as a dangerous/critical bug.</p><p>Even MS doesn't allow this sort of thing by default.  You can trust a particular publisher, which is commonly used in large corps to trust internally developed and signed software, but out of the box, being signed doesn't help you.</p><p>Admins act like they do because users with too many privs have a tendency to make their lives hell, so they lock things down to prevent some ignorant user from breaking their system and requiring the admin to do more work, there is nothing wrong with this, especially for company PCs.  The biggest problem here is that too many people have this sense of entitlement and seem to think they should be allowed to do whatever they want on their work PC which is simply wrong.</p><p>A good developer creates software that a good admin will be happy to run.  The only time there is conflict is when one or both of the parties are unskilled and/or ignorant.</p><p>I've done both jobs, and currently function as a developer.  I started out as a developer, got thrown in the sys admin position working with some very talented people who I learned a great deal from.  Now, being back in the developer seat again I can write software that makes admins happy.  Which I do,  and its used by a few very large and very locked down companies, without any major issues.</p><p>Admins that no nothing about software development are a problem.</p><p>Developers that no nothing about administration are a problem.</p><p>If you've got either one of the above you have a bad situation, but these is no struggle between the two groups, only struggles with ignorant/incompetent versions of either or both.</p><p>If, out of the box, this setup allows a user to install a package 'signed' by 'anyone' then the admins have every right to be upset, its unlikely thats the way its supposed to function.  Very few admins would take issue with having the ability to allow certain signers to install without elevated privileges, those that do take issue with it are probably more concerned with the fact that these developers have already screwed it up more than the actual feature.</p><p>I doubt any dev would want it so ANY package with a valid signature could be installed, theres no real reason for it.  I can believe that would like some ability to have installation of certain signers as well though, so again, this is probably a bug.</p><p>If by some chance that the intended functionality is that out of the box any package with a valid signature (or for that matter if there is a preset list of accepted valid signers out of the box) then everyone that has written the code, reviewed the code or approved of the idea should not be allowed to write code.</p><p>I accept bugs, shit happens, if this is intended as I understand it, everyone involved in this 'feature' that approved of it needs not be allowed to participate in any software development again.  Ignor</p></htmltext>
<tokenext>A good sys admin acting as a developer is fine.What you describe is a shitty developer.A good developer will develop as a normal user , no development environment I 'm aware of actually requires elevated privs for standard development , including Visual Studio using IIS for web apps if you invest the 30 seconds it takes to google for the solution in older versions , newer versions run their own webserver as needed to avoid that problem as well.A good developer will test on clean machines/fresh installs regularly.A good developer will test on locked down machines regularly.A good developer will write an application that does n't require any specific additional privileges unless they are truly needed , and they 'll document what those privileges are and why they are needed.A good developer has no problem dealing with Nazi admins , the developer will know how to explain EXACTLY why elevated privileges are needed to the admin and what safety precautions are in place or should be observed to limit potential breeches due to those privs.This problem is a result of cluelessness on the part of the devs who created it , I classify it as a dangerous/critical bug.Even MS does n't allow this sort of thing by default .
You can trust a particular publisher , which is commonly used in large corps to trust internally developed and signed software , but out of the box , being signed does n't help you.Admins act like they do because users with too many privs have a tendency to make their lives hell , so they lock things down to prevent some ignorant user from breaking their system and requiring the admin to do more work , there is nothing wrong with this , especially for company PCs .
The biggest problem here is that too many people have this sense of entitlement and seem to think they should be allowed to do whatever they want on their work PC which is simply wrong.A good developer creates software that a good admin will be happy to run .
The only time there is conflict is when one or both of the parties are unskilled and/or ignorant.I 've done both jobs , and currently function as a developer .
I started out as a developer , got thrown in the sys admin position working with some very talented people who I learned a great deal from .
Now , being back in the developer seat again I can write software that makes admins happy .
Which I do , and its used by a few very large and very locked down companies , without any major issues.Admins that no nothing about software development are a problem.Developers that no nothing about administration are a problem.If you 've got either one of the above you have a bad situation , but these is no struggle between the two groups , only struggles with ignorant/incompetent versions of either or both.If , out of the box , this setup allows a user to install a package 'signed ' by 'anyone ' then the admins have every right to be upset , its unlikely thats the way its supposed to function .
Very few admins would take issue with having the ability to allow certain signers to install without elevated privileges , those that do take issue with it are probably more concerned with the fact that these developers have already screwed it up more than the actual feature.I doubt any dev would want it so ANY package with a valid signature could be installed , theres no real reason for it .
I can believe that would like some ability to have installation of certain signers as well though , so again , this is probably a bug.If by some chance that the intended functionality is that out of the box any package with a valid signature ( or for that matter if there is a preset list of accepted valid signers out of the box ) then everyone that has written the code , reviewed the code or approved of the idea should not be allowed to write code.I accept bugs , shit happens , if this is intended as I understand it , everyone involved in this 'feature ' that approved of it needs not be allowed to participate in any software development again .
Ignor</tokentext>
<sentencetext>A good sys admin acting as a developer is fine.What you describe is a shitty developer.A good developer will develop as a normal user, no development environment I'm aware of actually requires elevated privs for standard development, including Visual Studio using IIS for web apps if you invest the 30 seconds it takes to google for the solution in older versions, newer versions run their own webserver as needed to avoid that problem as well.A good developer will test on clean machines/fresh installs regularly.A good developer will test on locked down machines regularly.A good developer will write an application that doesn't require any specific additional privileges unless they are truly needed, and they'll document what those privileges are and why they are needed.A good developer has no problem dealing with Nazi admins, the developer will know how to explain EXACTLY why elevated privileges are needed to the admin and what safety precautions are in place or should be observed to limit potential breeches due to those privs.This problem is a result of cluelessness on the part of the devs who created it, I classify it as a dangerous/critical bug.Even MS doesn't allow this sort of thing by default.
You can trust a particular publisher, which is commonly used in large corps to trust internally developed and signed software, but out of the box, being signed doesn't help you.Admins act like they do because users with too many privs have a tendency to make their lives hell, so they lock things down to prevent some ignorant user from breaking their system and requiring the admin to do more work, there is nothing wrong with this, especially for company PCs.
The biggest problem here is that too many people have this sense of entitlement and seem to think they should be allowed to do whatever they want on their work PC which is simply wrong.A good developer creates software that a good admin will be happy to run.
The only time there is conflict is when one or both of the parties are unskilled and/or ignorant.I've done both jobs, and currently function as a developer.
I started out as a developer, got thrown in the sys admin position working with some very talented people who I learned a great deal from.
Now, being back in the developer seat again I can write software that makes admins happy.
Which I do,  and its used by a few very large and very locked down companies, without any major issues.Admins that no nothing about software development are a problem.Developers that no nothing about administration are a problem.If you've got either one of the above you have a bad situation, but these is no struggle between the two groups, only struggles with ignorant/incompetent versions of either or both.If, out of the box, this setup allows a user to install a package 'signed' by 'anyone' then the admins have every right to be upset, its unlikely thats the way its supposed to function.
Very few admins would take issue with having the ability to allow certain signers to install without elevated privileges, those that do take issue with it are probably more concerned with the fact that these developers have already screwed it up more than the actual feature.I doubt any dev would want it so ANY package with a valid signature could be installed, theres no real reason for it.
I can believe that would like some ability to have installation of certain signers as well though, so again, this is probably a bug.If by some chance that the intended functionality is that out of the box any package with a valid signature (or for that matter if there is a preset list of accepted valid signers out of the box) then everyone that has written the code, reviewed the code or approved of the idea should not be allowed to write code.I accept bugs, shit happens, if this is intended as I understand it, everyone involved in this 'feature' that approved of it needs not be allowed to participate in any software development again.
Ignor</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151142</id>
	<title>Re:Wow</title>
	<author>JohnBailey</author>
	<datestamp>1257081780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Sounds like I need to upgrade to Windows 7 for some real security...</p></div><p>Of the blanket type.. With pink bunny rabbits.</p></div>
	</htmltext>
<tokenext>Sounds like I need to upgrade to Windows 7 for some real security...Of the blanket type.. With pink bunny rabbits .</tokentext>
<sentencetext>Sounds like I need to upgrade to Windows 7 for some real security...Of the blanket type.. With pink bunny rabbits.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149608</id>
	<title>Let's see who can speak more about this issue...</title>
	<author>icepick72</author>
	<datestamp>1257074580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>.. the<nobr> <wbr></nobr>./ community, or on the mailing list thread. Bets anyone?</htmltext>
<tokenext>.. the ./ community , or on the mailing list thread .
Bets anyone ?</tokentext>
<sentencetext>.. the ./ community, or on the mailing list thread.
Bets anyone?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149584</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257074520000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Nix (http://nixos.org/). You have to have your own glibc, though. As a bonus you can have a few of them without conflicts.</p><p>By the way, we allow non-root users to install software - any software. Now, the semantics is such that it doesn't really give user something he couldn't achieve by manually writing a binary: setuid wrappers and upstart jobs are enabled/disabled by root by a process similar to installing packages, but distinct enough. Yes, you can install sshd - you could download a statically compiled version with the same success.</p></htmltext>
<tokenext>Nix ( http : //nixos.org/ ) .
You have to have your own glibc , though .
As a bonus you can have a few of them without conflicts.By the way , we allow non-root users to install software - any software .
Now , the semantics is such that it does n't really give user something he could n't achieve by manually writing a binary : setuid wrappers and upstart jobs are enabled/disabled by root by a process similar to installing packages , but distinct enough .
Yes , you can install sshd - you could download a statically compiled version with the same success .</tokentext>
<sentencetext>Nix (http://nixos.org/).
You have to have your own glibc, though.
As a bonus you can have a few of them without conflicts.By the way, we allow non-root users to install software - any software.
Now, the semantics is such that it doesn't really give user something he couldn't achieve by manually writing a binary: setuid wrappers and upstart jobs are enabled/disabled by root by a process similar to installing packages, but distinct enough.
Yes, you can install sshd - you could download a statically compiled version with the same success.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149358</id>
	<title>Mandriva's rurpmi</title>
	<author>Zombie Ryushu</author>
	<datestamp>1257073440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Mandriva had a function like this called rurpmi. (r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages. I'm not sure if this is exactly the same thing.</p></htmltext>
<tokenext>Mandriva had a function like this called rurpmi .
( r as in " restricted " ) that would allow sudoers allowed only rurpmi to install ( Signed ) packages .
I 'm not sure if this is exactly the same thing .</tokentext>
<sentencetext>Mandriva had a function like this called rurpmi.
(r as in "restricted") that would allow sudoers allowed only rurpmi to install (Signed) packages.
I'm not sure if this is exactly the same thing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150632</id>
	<title>Re:This makes sense</title>
	<author>Anonymous</author>
	<datestamp>1257078900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>In most installations (<i>especially</i> Fedora installations) the user is the administrator, so this just removes one redundant step.</htmltext>
<tokenext>In most installations ( especially Fedora installations ) the user is the administrator , so this just removes one redundant step .</tokentext>
<sentencetext>In most installations (especially Fedora installations) the user is the administrator, so this just removes one redundant step.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148974</id>
	<title>Umm...</title>
	<author>SaidinUnleashed</author>
	<datestamp>1257071580000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>0</modscore>
	<htmltext>Oopsie?</htmltext>
<tokenext>Oopsie ?</tokentext>
<sentencetext>Oopsie?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149618</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257074640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Gobo rootless might be of interest?</p><p><a href="http://www.gobolinux.org/?page=rootless" title="gobolinux.org" rel="nofollow">http://www.gobolinux.org/?page=rootless</a> [gobolinux.org]</p></htmltext>
<tokenext>Gobo rootless might be of interest ? http : //www.gobolinux.org/ ? page = rootless [ gobolinux.org ]</tokentext>
<sentencetext>Gobo rootless might be of interest?http://www.gobolinux.org/?page=rootless [gobolinux.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153888</id>
	<title>Should you trust signed software?</title>
	<author>Loki\_666</author>
	<datestamp>1258622040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>My beef with this is a little different i think.  While i general i dont like the idea, it goes further than that.  I do not trust signed software or web-site certificates.  So, just because company X uses a Verisign signature for their security of the website, or in this case signatures are given to software, i still wont trust it just because it has a signature.</p><p>This is not paranoia (i hope).  Its simply because even security systems are possible to be broken.</p><p>Therefore i still would like my security blanket of having to su/sudo to do something that can affect the whole system.  A kind of "stop!  are you sure?".  UAC made a lot of people unhappy, but it was a bold move by MS.  I always hated it when applications even back in the days of Win95 would start writing to \Windows\ or \Program Files\</p><p>Still, my biggest grief with Windows is the Registry.  One file gets corrupt and thats it... bye bye boot up, bye bye many of your licence keys, bye bye everything.  Still, this is off-topic, but its a personal peeve of mine, and the day someone proposes something similar for Linux is the day i would switch to BSD.</p></htmltext>
<tokenext>My beef with this is a little different i think .
While i general i dont like the idea , it goes further than that .
I do not trust signed software or web-site certificates .
So , just because company X uses a Verisign signature for their security of the website , or in this case signatures are given to software , i still wont trust it just because it has a signature.This is not paranoia ( i hope ) .
Its simply because even security systems are possible to be broken.Therefore i still would like my security blanket of having to su/sudo to do something that can affect the whole system .
A kind of " stop !
are you sure ? " .
UAC made a lot of people unhappy , but it was a bold move by MS. I always hated it when applications even back in the days of Win95 would start writing to \ Windows \ or \ Program Files \ Still , my biggest grief with Windows is the Registry .
One file gets corrupt and thats it... bye bye boot up , bye bye many of your licence keys , bye bye everything .
Still , this is off-topic , but its a personal peeve of mine , and the day someone proposes something similar for Linux is the day i would switch to BSD .</tokentext>
<sentencetext>My beef with this is a little different i think.
While i general i dont like the idea, it goes further than that.
I do not trust signed software or web-site certificates.
So, just because company X uses a Verisign signature for their security of the website, or in this case signatures are given to software, i still wont trust it just because it has a signature.This is not paranoia (i hope).
Its simply because even security systems are possible to be broken.Therefore i still would like my security blanket of having to su/sudo to do something that can affect the whole system.
A kind of "stop!
are you sure?".
UAC made a lot of people unhappy, but it was a bold move by MS.  I always hated it when applications even back in the days of Win95 would start writing to \Windows\ or \Program Files\Still, my biggest grief with Windows is the Registry.
One file gets corrupt and thats it... bye bye boot up, bye bye many of your licence keys, bye bye everything.
Still, this is off-topic, but its a personal peeve of mine, and the day someone proposes something similar for Linux is the day i would switch to BSD.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151176</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>Celeste R</author>
	<datestamp>1257081960000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>RH didn't give any go ahead, it was the PackageKit upstream that did it without any communication.</p><p>Also:<br>NO documentation about this 'feature'.<br>Terrible configuration system.<br>Also, the entire mailing list had to do their own homework about this policy.</p></htmltext>
<tokenext>RH did n't give any go ahead , it was the PackageKit upstream that did it without any communication.Also : NO documentation about this 'feature'.Terrible configuration system.Also , the entire mailing list had to do their own homework about this policy .</tokentext>
<sentencetext>RH didn't give any go ahead, it was the PackageKit upstream that did it without any communication.Also:NO documentation about this 'feature'.Terrible configuration system.Also, the entire mailing list had to do their own homework about this policy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149708</id>
	<title>Re:YAY!!!!</title>
	<author>Anonymous</author>
	<datestamp>1257075000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can't really compare it to Windows as there is no way to install a bit of software without being an Administrator/Power User. That just happens to be the default (or used to be) for most boxes. This is different.</p><p>It's also a bit unfair on RH, you can't just grab any bit of software off the web and install it. I'm not sure how they plan to protect their keys though - will the installing software have to phone home to ensure they're not using a lifted key?</p><p>I imagine this is more of a money making venture anyway, for 2000$ you can allow users to install your software without root access.</p></htmltext>
<tokenext>You ca n't really compare it to Windows as there is no way to install a bit of software without being an Administrator/Power User .
That just happens to be the default ( or used to be ) for most boxes .
This is different.It 's also a bit unfair on RH , you ca n't just grab any bit of software off the web and install it .
I 'm not sure how they plan to protect their keys though - will the installing software have to phone home to ensure they 're not using a lifted key ? I imagine this is more of a money making venture anyway , for 2000 $ you can allow users to install your software without root access .</tokentext>
<sentencetext>You can't really compare it to Windows as there is no way to install a bit of software without being an Administrator/Power User.
That just happens to be the default (or used to be) for most boxes.
This is different.It's also a bit unfair on RH, you can't just grab any bit of software off the web and install it.
I'm not sure how they plan to protect their keys though - will the installing software have to phone home to ensure they're not using a lifted key?I imagine this is more of a money making venture anyway, for 2000$ you can allow users to install your software without root access.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154196</id>
	<title>Executive Summary...</title>
	<author>ifknot</author>
	<datestamp>1258627140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Summary
1/ It's a good idea, really good actually &amp; very useful - YAY
2/ It comes switched on by default which might not be ideal in all situations - BOO
3/ But don't worry, it doesn't leave your machines wide open in any way - YAY
4/ It's one line to switch it off: - DOUBLE YAY
pkalalockdown --lockdown org.freedesktop.pakagekit.package-install

Conclusion: 4:1 YAY:BOO ratio</htmltext>
<tokenext>Summary 1/ It 's a good idea , really good actually &amp; very useful - YAY 2/ It comes switched on by default which might not be ideal in all situations - BOO 3/ But do n't worry , it does n't leave your machines wide open in any way - YAY 4/ It 's one line to switch it off : - DOUBLE YAY pkalalockdown --lockdown org.freedesktop.pakagekit.package-install Conclusion : 4 : 1 YAY : BOO ratio</tokentext>
<sentencetext>Summary
1/ It's a good idea, really good actually &amp; very useful - YAY
2/ It comes switched on by default which might not be ideal in all situations - BOO
3/ But don't worry, it doesn't leave your machines wide open in any way - YAY
4/ It's one line to switch it off: - DOUBLE YAY
pkalalockdown --lockdown org.freedesktop.pakagekit.package-install

Conclusion: 4:1 YAY:BOO ratio</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30157740</id>
	<title>We can have this!</title>
	<author>ClosedSource</author>
	<datestamp>1258650600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If they allow Linux users to install packages easily, the next thing you know everybody will be using Linux.</p></htmltext>
<tokenext>If they allow Linux users to install packages easily , the next thing you know everybody will be using Linux .</tokentext>
<sentencetext>If they allow Linux users to install packages easily, the next thing you know everybody will be using Linux.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154102</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258625640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><a href="http://0install.net/" title="0install.net" rel="nofollow">Zero Install</a> [0install.net] will do what you want.</p></htmltext>
<tokenext>Zero Install [ 0install.net ] will do what you want .</tokentext>
<sentencetext>Zero Install [0install.net] will do what you want.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152954</id>
	<title>Re:Wow</title>
	<author>ethan0</author>
	<datestamp>1257096180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm seeing lots of comments on the security of this, but I'm not seeing how it is insecure. Users can currently install any software they want into their home directory - how is this any different? it goes into a system directory, sure, but that doesn't give the user any more privileges with regard to it.</p><p>An possible exception is if the package is setuid root, is runnable by any user, and has some exploit to get the user root. Does this happen? I can't think of what could have this, and it doesn't seem like the package manager should install such things (regardless of known exploitability - bugs do happen) Perhaps if this functionality is applied only to software that does not escalate privileges at all? I would consider that a sensible default, but don't know if that is the case here.</p></htmltext>
<tokenext>I 'm seeing lots of comments on the security of this , but I 'm not seeing how it is insecure .
Users can currently install any software they want into their home directory - how is this any different ?
it goes into a system directory , sure , but that does n't give the user any more privileges with regard to it.An possible exception is if the package is setuid root , is runnable by any user , and has some exploit to get the user root .
Does this happen ?
I ca n't think of what could have this , and it does n't seem like the package manager should install such things ( regardless of known exploitability - bugs do happen ) Perhaps if this functionality is applied only to software that does not escalate privileges at all ?
I would consider that a sensible default , but do n't know if that is the case here .</tokentext>
<sentencetext>I'm seeing lots of comments on the security of this, but I'm not seeing how it is insecure.
Users can currently install any software they want into their home directory - how is this any different?
it goes into a system directory, sure, but that doesn't give the user any more privileges with regard to it.An possible exception is if the package is setuid root, is runnable by any user, and has some exploit to get the user root.
Does this happen?
I can't think of what could have this, and it doesn't seem like the package manager should install such things (regardless of known exploitability - bugs do happen) Perhaps if this functionality is applied only to software that does not escalate privileges at all?
I would consider that a sensible default, but don't know if that is the case here.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149774</id>
	<title>In some cases it could be ok...</title>
	<author>atmurray</author>
	<datestamp>1257075180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As long as the program never runs with privileges different than the user installing it then it's not really a concern. In fact, it's not really any different to the user running whatever software they want in their home directory.

However, as pointed out by many before, if the program runs with elevated privileges or under a different username or even worse, as root, than it becomes far too dangerous to allow.

Hopefully a sane compromise can be achieved like only requiring root privileges to install programs that run elevated.</htmltext>
<tokenext>As long as the program never runs with privileges different than the user installing it then it 's not really a concern .
In fact , it 's not really any different to the user running whatever software they want in their home directory .
However , as pointed out by many before , if the program runs with elevated privileges or under a different username or even worse , as root , than it becomes far too dangerous to allow .
Hopefully a sane compromise can be achieved like only requiring root privileges to install programs that run elevated .</tokentext>
<sentencetext>As long as the program never runs with privileges different than the user installing it then it's not really a concern.
In fact, it's not really any different to the user running whatever software they want in their home directory.
However, as pointed out by many before, if the program runs with elevated privileges or under a different username or even worse, as root, than it becomes far too dangerous to allow.
Hopefully a sane compromise can be achieved like only requiring root privileges to install programs that run elevated.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153474</id>
	<title>sudo</title>
	<author>whm</author>
	<datestamp>1257103380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How does something like this differ practically from using sudo, which in many distros grants the user root privileges without any further authentication necessary?</p></htmltext>
<tokenext>How does something like this differ practically from using sudo , which in many distros grants the user root privileges without any further authentication necessary ?</tokentext>
<sentencetext>How does something like this differ practically from using sudo, which in many distros grants the user root privileges without any further authentication necessary?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154684</id>
	<title>Re:It's obvious</title>
	<author>MrMr</author>
	<datestamp>1258635180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Interesting how everybody who remarks that the Windows default behaviour is copied by this change is moderated troll. Must be a slow day in Redmond.</htmltext>
<tokenext>Interesting how everybody who remarks that the Windows default behaviour is copied by this change is moderated troll .
Must be a slow day in Redmond .</tokentext>
<sentencetext>Interesting how everybody who remarks that the Windows default behaviour is copied by this change is moderated troll.
Must be a slow day in Redmond.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149784</id>
	<title>Re:User-level package manager</title>
	<author>miknix</author>
	<datestamp>1257075240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all. Anyone know of one?</p></div><p>ROOT=/home/meLikesStuffAtHomeAndCamelToesAlso emerge something</p><p>You can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.</p></div>
	</htmltext>
<tokenext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix = $ HOME/whatever &amp;&amp; make install ' but without the complete bitchness of dependency hell -- without any root privileges at all .
Anyone know of one ? ROOT = /home/meLikesStuffAtHomeAndCamelToesAlso emerge somethingYou can make emerge to install stuff anywhere , do n't forget to add yourself to the portage group .</tokentext>
<sentencetext>What I want is a package manager that will do installation to my own home directory -- basically the same as downloading the source and running './configure --prefix=$HOME/whatever &amp;&amp; make install' but without the complete bitchness of dependency hell -- without any root privileges at all.
Anyone know of one?ROOT=/home/meLikesStuffAtHomeAndCamelToesAlso emerge somethingYou can make emerge to install stuff anywhere, don't forget to add yourself to the portage group.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155088</id>
	<title>Re:It's obvious</title>
	<author>nathanh</author>
	<datestamp>1258640160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p> <i>
This isn't necessarily insecure.
</i></p></div> </blockquote><p>Yes, it is most definitely insecure. This change in Fedora 12 allows an <b>unprivileged user</b> to:

</p><ul>
<li>Start and stop network services</li>
<li>Install setuid binaries</li>
<li>Remove and install files owned by root</li>
<li>Modify system configurations</li>
<li>Change user and group databases</li>
</ul><p>On any normal system, the unprivileged users can do some of these things only through a *very* small subset of programs (e.g. passwd) that have been heavily vetted, and even then they still have an occasional exploit.

</p><p>Now Fedora is saying "hey, all 15000 of our programs can do all of these things, and any unprivileged user can install any of the 15000 programs". Fedora has increased the number of potential exploits by several orders of magnitude.

</p><p>That's insecure.</p></div>
	</htmltext>
<tokenext>This is n't necessarily insecure .
Yes , it is most definitely insecure .
This change in Fedora 12 allows an unprivileged user to : Start and stop network services Install setuid binaries Remove and install files owned by root Modify system configurations Change user and group databases On any normal system , the unprivileged users can do some of these things only through a * very * small subset of programs ( e.g .
passwd ) that have been heavily vetted , and even then they still have an occasional exploit .
Now Fedora is saying " hey , all 15000 of our programs can do all of these things , and any unprivileged user can install any of the 15000 programs " .
Fedora has increased the number of potential exploits by several orders of magnitude .
That 's insecure .</tokentext>
<sentencetext> 
This isn't necessarily insecure.
Yes, it is most definitely insecure.
This change in Fedora 12 allows an unprivileged user to:


Start and stop network services
Install setuid binaries
Remove and install files owned by root
Modify system configurations
Change user and group databases
On any normal system, the unprivileged users can do some of these things only through a *very* small subset of programs (e.g.
passwd) that have been heavily vetted, and even then they still have an occasional exploit.
Now Fedora is saying "hey, all 15000 of our programs can do all of these things, and any unprivileged user can install any of the 15000 programs".
Fedora has increased the number of potential exploits by several orders of magnitude.
That's insecure.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153984</id>
	<title>already possible in every distro</title>
	<author>Anonymous</author>
	<datestamp>1258623480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There are some differences, but many of this is already possible. You just have to download source, compile it and install it a place where you have write access.<br>So for people wanting to exploit bugs, this is a non issue.</p><p>Of course, i'd like packages running with root permissions to be excluded from this.</p></htmltext>
<tokenext>There are some differences , but many of this is already possible .
You just have to download source , compile it and install it a place where you have write access.So for people wanting to exploit bugs , this is a non issue.Of course , i 'd like packages running with root permissions to be excluded from this .</tokentext>
<sentencetext>There are some differences, but many of this is already possible.
You just have to download source, compile it and install it a place where you have write access.So for people wanting to exploit bugs, this is a non issue.Of course, i'd like packages running with root permissions to be excluded from this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30157566</id>
	<title>Want to see a fun security fail in Linux?</title>
	<author>drinkypoo</author>
	<datestamp>1258650120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Step 1: Install Ubuntu Karmic<br>Step 2: Log in as admin<br>Step 3: Create an unprivileged user<br>Step 4: Use user switching and log in the unprivileged user<br>Step 5: Log out this user and enjoy being switched back to your admin user's desktop automatically.</p><p>Now, to be fair, this is an upgrade from Jaunty, which I think may have even been intrepid before that. So perhaps this wouldn't happen in a fresh install. I currently have the problem though.</p></htmltext>
<tokenext>Step 1 : Install Ubuntu KarmicStep 2 : Log in as adminStep 3 : Create an unprivileged userStep 4 : Use user switching and log in the unprivileged userStep 5 : Log out this user and enjoy being switched back to your admin user 's desktop automatically.Now , to be fair , this is an upgrade from Jaunty , which I think may have even been intrepid before that .
So perhaps this would n't happen in a fresh install .
I currently have the problem though .</tokentext>
<sentencetext>Step 1: Install Ubuntu KarmicStep 2: Log in as adminStep 3: Create an unprivileged userStep 4: Use user switching and log in the unprivileged userStep 5: Log out this user and enjoy being switched back to your admin user's desktop automatically.Now, to be fair, this is an upgrade from Jaunty, which I think may have even been intrepid before that.
So perhaps this wouldn't happen in a fresh install.
I currently have the problem though.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149488</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257074040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Have you tried pkgsrc (http://www.netbsd.org/docs/software/packages.html)?  It's the NetBSD package manager, but works on many operating systems.  I use it for my Mac because I've had difficulties with fink in the past, and like that I can install to my home directory.</p></htmltext>
<tokenext>Have you tried pkgsrc ( http : //www.netbsd.org/docs/software/packages.html ) ?
It 's the NetBSD package manager , but works on many operating systems .
I use it for my Mac because I 've had difficulties with fink in the past , and like that I can install to my home directory .</tokentext>
<sentencetext>Have you tried pkgsrc (http://www.netbsd.org/docs/software/packages.html)?
It's the NetBSD package manager, but works on many operating systems.
I use it for my Mac because I've had difficulties with fink in the past, and like that I can install to my home directory.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150796</id>
	<title>Re:It's obvious</title>
	<author>644bd346996</author>
	<datestamp>1257079800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In other words, it allows a remote-exploitable user level flaw to be combined with a local privilege escalation into a remote root exploit. That part isn't particularly new. What is new is that such an attack would take quite some time (to download, install, and start the new software), and would be fully logged along the way. A very small hole indeed. It can be closed by using a private repo that excludes packages with known exploits. Or by not allowing users to install packages containing suid executables. Or by requiring the user to type in their password sudo-style before packages get installed. There are probably several other relatively simple ways to mitigate the small risk.</p><p>And none of this changes the fact that if security is this big of a problem to you, you shouldn't be using a distro like Fedora in the first place.</p></htmltext>
<tokenext>In other words , it allows a remote-exploitable user level flaw to be combined with a local privilege escalation into a remote root exploit .
That part is n't particularly new .
What is new is that such an attack would take quite some time ( to download , install , and start the new software ) , and would be fully logged along the way .
A very small hole indeed .
It can be closed by using a private repo that excludes packages with known exploits .
Or by not allowing users to install packages containing suid executables .
Or by requiring the user to type in their password sudo-style before packages get installed .
There are probably several other relatively simple ways to mitigate the small risk.And none of this changes the fact that if security is this big of a problem to you , you should n't be using a distro like Fedora in the first place .</tokentext>
<sentencetext>In other words, it allows a remote-exploitable user level flaw to be combined with a local privilege escalation into a remote root exploit.
That part isn't particularly new.
What is new is that such an attack would take quite some time (to download, install, and start the new software), and would be fully logged along the way.
A very small hole indeed.
It can be closed by using a private repo that excludes packages with known exploits.
Or by not allowing users to install packages containing suid executables.
Or by requiring the user to type in their password sudo-style before packages get installed.
There are probably several other relatively simple ways to mitigate the small risk.And none of this changes the fact that if security is this big of a problem to you, you shouldn't be using a distro like Fedora in the first place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150520</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149472</id>
	<title>Stinks</title>
	<author>Anonymous</author>
	<datestamp>1257073980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This smells like a back door.</p></htmltext>
<tokenext>This smells like a back door .</tokentext>
<sentencetext>This smells like a back door.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30164682</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258629060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You'd probably enjoy Zero Install http://0install.net/</p><p>I'm confident it's precisely what you want.</p></htmltext>
<tokenext>You 'd probably enjoy Zero Install http : //0install.net/I 'm confident it 's precisely what you want .</tokentext>
<sentencetext>You'd probably enjoy Zero Install http://0install.net/I'm confident it's precisely what you want.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</id>
	<title>LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>QuoteMstr</author>
	<datestamp>1257074100000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>There's something really, critically important here that everyone is missing:</p><p><b>ONLY LOCAL USERS CAN INSTALL PACKAGES</b></p><p>In other words:</p><p><b>IT ONLY MAKES A DIFFERENCE FOR USERS <i>PHYSICALLY SITTING</i> AT A MACHINE</b></p><p>That means that a random user can't ssh into your server and install packages. He has to <i>actually be at the machine</i>. And if he has physical access to the machine, he can just boot from a LiveCD.</p><p><b>Installing signed packages is a very low-risk operation.</b> Yes, there are theoretical vulnerabilities, but in order for them to make much of a difference, you need the perfect alignment of coincidences that's really unlikely in practice.</p><p>This change allows users who can <b>already</b> compromise the machine given enough time do something <b>very safe</b> painlessly.</p></htmltext>
<tokenext>There 's something really , critically important here that everyone is missing : ONLY LOCAL USERS CAN INSTALL PACKAGESIn other words : IT ONLY MAKES A DIFFERENCE FOR USERS PHYSICALLY SITTING AT A MACHINEThat means that a random user ca n't ssh into your server and install packages .
He has to actually be at the machine .
And if he has physical access to the machine , he can just boot from a LiveCD.Installing signed packages is a very low-risk operation .
Yes , there are theoretical vulnerabilities , but in order for them to make much of a difference , you need the perfect alignment of coincidences that 's really unlikely in practice.This change allows users who can already compromise the machine given enough time do something very safe painlessly .</tokentext>
<sentencetext>There's something really, critically important here that everyone is missing:ONLY LOCAL USERS CAN INSTALL PACKAGESIn other words:IT ONLY MAKES A DIFFERENCE FOR USERS PHYSICALLY SITTING AT A MACHINEThat means that a random user can't ssh into your server and install packages.
He has to actually be at the machine.
And if he has physical access to the machine, he can just boot from a LiveCD.Installing signed packages is a very low-risk operation.
Yes, there are theoretical vulnerabilities, but in order for them to make much of a difference, you need the perfect alignment of coincidences that's really unlikely in practice.This change allows users who can already compromise the machine given enough time do something very safe painlessly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150520</id>
	<title>Re:It's obvious</title>
	<author>cookie23</author>
	<datestamp>1257078240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext>It is necessarily insecure: At any point in time there can exist signed software in the repo which the user can install and which has known exploitable vulnerabilities. Therefore it follows that malicious code running as the user can, without root privileges, install said software and then exploit the vulnerability automatically and without the users knowledge. Its just a matter of effort to create a virus/worm that quarries for current unlatched packages and exploits them or runs in the user context again until such time as it can. Once root the policy is exploited once the policy can be used again by adding a malicious, but now trusted repo so the user code can keep getting root and reinfecting in the future as needed. This is a path to turn a malicious unprivileged user exploit into a system exploit, not unlike the many IE cross-zone security problems of the past.</htmltext>
<tokenext>It is necessarily insecure : At any point in time there can exist signed software in the repo which the user can install and which has known exploitable vulnerabilities .
Therefore it follows that malicious code running as the user can , without root privileges , install said software and then exploit the vulnerability automatically and without the users knowledge .
Its just a matter of effort to create a virus/worm that quarries for current unlatched packages and exploits them or runs in the user context again until such time as it can .
Once root the policy is exploited once the policy can be used again by adding a malicious , but now trusted repo so the user code can keep getting root and reinfecting in the future as needed .
This is a path to turn a malicious unprivileged user exploit into a system exploit , not unlike the many IE cross-zone security problems of the past .</tokentext>
<sentencetext>It is necessarily insecure: At any point in time there can exist signed software in the repo which the user can install and which has known exploitable vulnerabilities.
Therefore it follows that malicious code running as the user can, without root privileges, install said software and then exploit the vulnerability automatically and without the users knowledge.
Its just a matter of effort to create a virus/worm that quarries for current unlatched packages and exploits them or runs in the user context again until such time as it can.
Once root the policy is exploited once the policy can be used again by adding a malicious, but now trusted repo so the user code can keep getting root and reinfecting in the future as needed.
This is a path to turn a malicious unprivileged user exploit into a system exploit, not unlike the many IE cross-zone security problems of the past.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149428</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>natehoy</author>
	<datestamp>1257073800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In a corporate environment, this does make sense.</p><p>As a default, it doesn't, because if you're a corporation wanting to extend this authority you'll almost certainly want to spend some time configuring the trusted authority list so you can host "approved" applications on an internal server.</p><p>Fortunately, this is a policy setting and not a code change.  RedHat should change the default back to "requires root", though, because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control (or not) the applications that can be installed.</p></htmltext>
<tokenext>In a corporate environment , this does make sense.As a default , it does n't , because if you 're a corporation wanting to extend this authority you 'll almost certainly want to spend some time configuring the trusted authority list so you can host " approved " applications on an internal server.Fortunately , this is a policy setting and not a code change .
RedHat should change the default back to " requires root " , though , because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control ( or not ) the applications that can be installed .</tokentext>
<sentencetext>In a corporate environment, this does make sense.As a default, it doesn't, because if you're a corporation wanting to extend this authority you'll almost certainly want to spend some time configuring the trusted authority list so you can host "approved" applications on an internal server.Fortunately, this is a policy setting and not a code change.
RedHat should change the default back to "requires root", though, because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control (or not) the applications that can be installed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144</id>
	<title>Re:This makes sense</title>
	<author>MatanZ</author>
	<datestamp>1257072420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>The contest might be trusted, but not wanted by the administrator of the machine.</p><p>Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.</p></htmltext>
<tokenext>The contest might be trusted , but not wanted by the administrator of the machine.Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed , but also in packages you chose not to install .</tokentext>
<sentencetext>The contest might be trusted, but not wanted by the administrator of the machine.Another way to think about it - you are now vulnerable to local root exploits not only in packages you installed, but also in packages you chose not to install.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149236</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257072840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>I know of one for Mac OS:<br>
<a href="http://github.com/mxcl/homebrew/" title="github.com">http://github.com/mxcl/homebrew/</a> [github.com]
<br>
It would probably not be much of a challenge to make that work on a Linux machine. That and a Linux tool for this probably already exists.</htmltext>
<tokenext>I know of one for Mac OS : http : //github.com/mxcl/homebrew/ [ github.com ] It would probably not be much of a challenge to make that work on a Linux machine .
That and a Linux tool for this probably already exists .</tokentext>
<sentencetext>I know of one for Mac OS:
http://github.com/mxcl/homebrew/ [github.com]

It would probably not be much of a challenge to make that work on a Linux machine.
That and a Linux tool for this probably already exists.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149390</id>
	<title>Re:User-level package manager</title>
	<author>FooBarWidget</author>
	<datestamp>1257073620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Autopackage.</p><p>But it's not just the package manager. Applications have to be modified to specifically support $HOME installation (or, to be more exact, installation to arbitrary locations), and most Unix apps right now don't support this without hardcoding paths during compilation time. This is something which Autopackage tries to take care of too, by providing documentation and code for developers for writing relocatable apps.</p></htmltext>
<tokenext>Autopackage.But it 's not just the package manager .
Applications have to be modified to specifically support $ HOME installation ( or , to be more exact , installation to arbitrary locations ) , and most Unix apps right now do n't support this without hardcoding paths during compilation time .
This is something which Autopackage tries to take care of too , by providing documentation and code for developers for writing relocatable apps .</tokentext>
<sentencetext>Autopackage.But it's not just the package manager.
Applications have to be modified to specifically support $HOME installation (or, to be more exact, installation to arbitrary locations), and most Unix apps right now don't support this without hardcoding paths during compilation time.
This is something which Autopackage tries to take care of too, by providing documentation and code for developers for writing relocatable apps.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</id>
	<title>Users should not get to be root. PERIOD</title>
	<author>Anonymous</author>
	<datestamp>1257072360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>That is just silly. Users are users for a reason, and admins are admins for a reason. If users want to install software, they can use sudo.</p><p>Whoever approved that in the Fedora team needs a refresher in security.</p></htmltext>
<tokenext>That is just silly .
Users are users for a reason , and admins are admins for a reason .
If users want to install software , they can use sudo.Whoever approved that in the Fedora team needs a refresher in security .</tokentext>
<sentencetext>That is just silly.
Users are users for a reason, and admins are admins for a reason.
If users want to install software, they can use sudo.Whoever approved that in the Fedora team needs a refresher in security.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150134</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257076500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I know one, i tend to use it when package managers get on my way: http://www.gobolinux.org/?page=rootless</p></htmltext>
<tokenext>I know one , i tend to use it when package managers get on my way : http : //www.gobolinux.org/ ? page = rootless</tokentext>
<sentencetext>I know one, i tend to use it when package managers get on my way: http://www.gobolinux.org/?page=rootless</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151268</id>
	<title>Maybe ... maybe ...</title>
	<author>Anonymous</author>
	<datestamp>1257082440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Maybe if this policy allowed non-system software to be installed chrooted to the user it would be useful. Maybe. But here, Red Hat is fixing something that simply isn't broken.</p></htmltext>
<tokenext>Maybe if this policy allowed non-system software to be installed chrooted to the user it would be useful .
Maybe. But here , Red Hat is fixing something that simply is n't broken .</tokentext>
<sentencetext>Maybe if this policy allowed non-system software to be installed chrooted to the user it would be useful.
Maybe. But here, Red Hat is fixing something that simply isn't broken.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151376</id>
	<title>Let's regain touch with reality</title>
	<author>Anonymous</author>
	<datestamp>1257083160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This discussion has lost touch with reality. People are panicking and, with limbs flailing wildly, denouncing RedHat and exclaiming that poor, innocent sysadmins will be unarmed against RedHat's monstrous, security-jeopardizing onslaught. RedHat's decision is moronic as any reasonable person should agree. But let's regain some reality here: every competent sysadmin will simply change the PolicyKit settings:<br>polkit-action --set-defaults-any org.freedesktop.packagekit.package-install auth\_admin\_one\_shot<br>Notice how many commands that requires? One. This changed default will affect few users' systems and certainly won't affect mine.<br>(Fedora and Ubuntu also provide a GUI to change PolicyKit settings.)</p></htmltext>
<tokenext>This discussion has lost touch with reality .
People are panicking and , with limbs flailing wildly , denouncing RedHat and exclaiming that poor , innocent sysadmins will be unarmed against RedHat 's monstrous , security-jeopardizing onslaught .
RedHat 's decision is moronic as any reasonable person should agree .
But let 's regain some reality here : every competent sysadmin will simply change the PolicyKit settings : polkit-action --set-defaults-any org.freedesktop.packagekit.package-install auth \ _admin \ _one \ _shotNotice how many commands that requires ?
One. This changed default will affect few users ' systems and certainly wo n't affect mine .
( Fedora and Ubuntu also provide a GUI to change PolicyKit settings .
)</tokentext>
<sentencetext>This discussion has lost touch with reality.
People are panicking and, with limbs flailing wildly, denouncing RedHat and exclaiming that poor, innocent sysadmins will be unarmed against RedHat's monstrous, security-jeopardizing onslaught.
RedHat's decision is moronic as any reasonable person should agree.
But let's regain some reality here: every competent sysadmin will simply change the PolicyKit settings:polkit-action --set-defaults-any org.freedesktop.packagekit.package-install auth\_admin\_one\_shotNotice how many commands that requires?
One. This changed default will affect few users' systems and certainly won't affect mine.
(Fedora and Ubuntu also provide a GUI to change PolicyKit settings.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154322</id>
	<title>Re:User-level package manager</title>
	<author>ynef</author>
	<datestamp>1258629060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Absolutely. You could try Zero Install[1]. The list of software[2] is pathetically small (it does, however, provide useful apps such as Firefox, Inkscape, and Xara Xtreme), but there are ways of generating your own package. So, you could just generate your favorite packages and either publish them on the web or carry them with you on a USB stick or something. I don't think this will be the future package management system to rule them all, but it is nice to be able to install an app you need without spending ages compiling it (and its dependencies!) or by requesting that your systems administrator approves a request, which could take a long time, particularly if your request is uncommon. </p><p>
[1] <a href="http://0install.net/" title="0install.net" rel="nofollow">http://0install.net/</a> [0install.net] <br>
[2] <a href="http://0install.net/injector-feeds.html" title="0install.net" rel="nofollow">http://0install.net/injector-feeds.html</a> [0install.net]
</p></htmltext>
<tokenext>Absolutely .
You could try Zero Install [ 1 ] .
The list of software [ 2 ] is pathetically small ( it does , however , provide useful apps such as Firefox , Inkscape , and Xara Xtreme ) , but there are ways of generating your own package .
So , you could just generate your favorite packages and either publish them on the web or carry them with you on a USB stick or something .
I do n't think this will be the future package management system to rule them all , but it is nice to be able to install an app you need without spending ages compiling it ( and its dependencies !
) or by requesting that your systems administrator approves a request , which could take a long time , particularly if your request is uncommon .
[ 1 ] http : //0install.net/ [ 0install.net ] [ 2 ] http : //0install.net/injector-feeds.html [ 0install.net ]</tokentext>
<sentencetext>Absolutely.
You could try Zero Install[1].
The list of software[2] is pathetically small (it does, however, provide useful apps such as Firefox, Inkscape, and Xara Xtreme), but there are ways of generating your own package.
So, you could just generate your favorite packages and either publish them on the web or carry them with you on a USB stick or something.
I don't think this will be the future package management system to rule them all, but it is nice to be able to install an app you need without spending ages compiling it (and its dependencies!
) or by requesting that your systems administrator approves a request, which could take a long time, particularly if your request is uncommon.
[1] http://0install.net/ [0install.net] 
[2] http://0install.net/injector-feeds.html [0install.net]
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149926</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>Lemming Mark</author>
	<datestamp>1257075840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Worth noting the corollary - (only) console users are susceptible to any malware they happen to get (ab)using the package system.  Assuming an absence of malware running under a user account, it makes a good deal of sense to let users with physical access install new packages, in fact it sounds very useful indeed.  Thanks for pointing this out as it does make a huge difference that the feature is restricted by default to local users!</p></htmltext>
<tokenext>Worth noting the corollary - ( only ) console users are susceptible to any malware they happen to get ( ab ) using the package system .
Assuming an absence of malware running under a user account , it makes a good deal of sense to let users with physical access install new packages , in fact it sounds very useful indeed .
Thanks for pointing this out as it does make a huge difference that the feature is restricted by default to local users !</tokentext>
<sentencetext>Worth noting the corollary - (only) console users are susceptible to any malware they happen to get (ab)using the package system.
Assuming an absence of malware running under a user account, it makes a good deal of sense to let users with physical access install new packages, in fact it sounds very useful indeed.
Thanks for pointing this out as it does make a huge difference that the feature is restricted by default to local users!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155344</id>
	<title>Re:Developers vs. Sysadmins</title>
	<author>vegiVamp</author>
	<datestamp>1258641960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is why you have<br>
&nbsp; a) The development environment on the dev's local PCs, where they can fuck about as much as they want,<br>
&nbsp; b) The development SERVER, where you are willing to install stuff from time to time to get their committed code to run and get real testing,<br>
&nbsp; c) The staging server, which is kept as close as possible to your production environment, and where code is tested in production-like circumstances,<br>
&nbsp; d) The production server, surrounded with plenty of slow, painful deathtraps for developers.</htmltext>
<tokenext>This is why you have   a ) The development environment on the dev 's local PCs , where they can fuck about as much as they want ,   b ) The development SERVER , where you are willing to install stuff from time to time to get their committed code to run and get real testing ,   c ) The staging server , which is kept as close as possible to your production environment , and where code is tested in production-like circumstances ,   d ) The production server , surrounded with plenty of slow , painful deathtraps for developers .</tokentext>
<sentencetext>This is why you have
  a) The development environment on the dev's local PCs, where they can fuck about as much as they want,
  b) The development SERVER, where you are willing to install stuff from time to time to get their committed code to run and get real testing,
  c) The staging server, which is kept as close as possible to your production environment, and where code is tested in production-like circumstances,
  d) The production server, surrounded with plenty of slow, painful deathtraps for developers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161624</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>StuartHankins</author>
	<datestamp>1258662660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The vulnerability is extended to anyone who VNC's into a system. There may be other attack vectors as well.</htmltext>
<tokenext>The vulnerability is extended to anyone who VNC 's into a system .
There may be other attack vectors as well .</tokentext>
<sentencetext>The vulnerability is extended to anyone who VNC's into a system.
There may be other attack vectors as well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149354</id>
	<title>Hmm...</title>
	<author>fuzzyfuzzyfungus</author>
	<datestamp>1257073440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>I'm not sure that this is a good default setting(though I would say that it is much more defensible for a desktop oriented distro, with the ability to turn it off; while it would be unsuitable for a server/corporate lockdown box setup). However, aside from the on by default/off by default question, I don't really understand what the big deal is.<br> <br>

Some people are freaking out, as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good(tm). That seems frankly nonsensical.For example, good old Sudo does exactly that. If you are on the sudoers list, you can do some or all things as a different user(usually root) with just your own credentials. This is wildly useful, and is a routine part of a great many UNIX systems. In desktopish contexts, we've also had things like automounters for external storage, doing a limited amount of trusted stuff as root, for some years now. Not necessarily the thing for servers; but usually good for desktops.<br> <br>

I don't know whether this is a good default or not, and I'd certainly want to see it mentioned in the docs(assuming it isn't already, haven't checked). However, limited privilege escalation mechanisms, for performing a set of trusted actions, have been part of UNIX for years. Anybody who is merely blowing up about that, rather than about the defaults question, is being reactionary in a way that isn't even accurate.</htmltext>
<tokenext>I 'm not sure that this is a good default setting ( though I would say that it is much more defensible for a desktop oriented distro , with the ability to turn it off ; while it would be unsuitable for a server/corporate lockdown box setup ) .
However , aside from the on by default/off by default question , I do n't really understand what the big deal is .
Some people are freaking out , as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good ( tm ) .
That seems frankly nonsensical.For example , good old Sudo does exactly that .
If you are on the sudoers list , you can do some or all things as a different user ( usually root ) with just your own credentials .
This is wildly useful , and is a routine part of a great many UNIX systems .
In desktopish contexts , we 've also had things like automounters for external storage , doing a limited amount of trusted stuff as root , for some years now .
Not necessarily the thing for servers ; but usually good for desktops .
I do n't know whether this is a good default or not , and I 'd certainly want to see it mentioned in the docs ( assuming it is n't already , have n't checked ) .
However , limited privilege escalation mechanisms , for performing a set of trusted actions , have been part of UNIX for years .
Anybody who is merely blowing up about that , rather than about the defaults question , is being reactionary in a way that is n't even accurate .</tokentext>
<sentencetext>I'm not sure that this is a good default setting(though I would say that it is much more defensible for a desktop oriented distro, with the ability to turn it off; while it would be unsuitable for a server/corporate lockdown box setup).
However, aside from the on by default/off by default question, I don't really understand what the big deal is.
Some people are freaking out, as though context-sensitive privilege escalation is some sort of ghastly betrayal of all that is UNIX and Good(tm).
That seems frankly nonsensical.For example, good old Sudo does exactly that.
If you are on the sudoers list, you can do some or all things as a different user(usually root) with just your own credentials.
This is wildly useful, and is a routine part of a great many UNIX systems.
In desktopish contexts, we've also had things like automounters for external storage, doing a limited amount of trusted stuff as root, for some years now.
Not necessarily the thing for servers; but usually good for desktops.
I don't know whether this is a good default or not, and I'd certainly want to see it mentioned in the docs(assuming it isn't already, haven't checked).
However, limited privilege escalation mechanisms, for performing a set of trusted actions, have been part of UNIX for years.
Anybody who is merely blowing up about that, rather than about the defaults question, is being reactionary in a way that isn't even accurate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154716</id>
	<title>It's Official...</title>
	<author>nathanh</author>
	<datestamp>1258635720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>... Red Hat is now hiring idiot developers who don't know the first thing about UNIX.

</p><p>The Linux admins at one of the sites I regularly work were in a furor over this change to Fedora. Within the space of a minute they had concocted a half dozen ways this "feature" could be exploited. This wasn't even taking into account the management and maintenance nightmare of machines where users could install software; they were simply considering the security implications. One of the admins was so furious that he suggested in all seriousness that the site drops Red Hat Enterprise Linux immediately and use SUSE Enterprise. His justification being that if Red Hat can allow this kind of stupidity into their community build, imagine what sort of crap is filtering through into Enterprise Linux. He no longer has any confidence that Red Hat has the faintest clue what constitutes a secure system. I didn't think he was overreacting; this is the dumbest thing I've seen any Linux distribution do, ever.

</p><p>That the Fedora developers are trying to defend this stupidity is just the icing on the cake. Red Hat should sack every last one of them for incompetence.</p></htmltext>
<tokenext>... Red Hat is now hiring idiot developers who do n't know the first thing about UNIX .
The Linux admins at one of the sites I regularly work were in a furor over this change to Fedora .
Within the space of a minute they had concocted a half dozen ways this " feature " could be exploited .
This was n't even taking into account the management and maintenance nightmare of machines where users could install software ; they were simply considering the security implications .
One of the admins was so furious that he suggested in all seriousness that the site drops Red Hat Enterprise Linux immediately and use SUSE Enterprise .
His justification being that if Red Hat can allow this kind of stupidity into their community build , imagine what sort of crap is filtering through into Enterprise Linux .
He no longer has any confidence that Red Hat has the faintest clue what constitutes a secure system .
I did n't think he was overreacting ; this is the dumbest thing I 've seen any Linux distribution do , ever .
That the Fedora developers are trying to defend this stupidity is just the icing on the cake .
Red Hat should sack every last one of them for incompetence .</tokentext>
<sentencetext>... Red Hat is now hiring idiot developers who don't know the first thing about UNIX.
The Linux admins at one of the sites I regularly work were in a furor over this change to Fedora.
Within the space of a minute they had concocted a half dozen ways this "feature" could be exploited.
This wasn't even taking into account the management and maintenance nightmare of machines where users could install software; they were simply considering the security implications.
One of the admins was so furious that he suggested in all seriousness that the site drops Red Hat Enterprise Linux immediately and use SUSE Enterprise.
His justification being that if Red Hat can allow this kind of stupidity into their community build, imagine what sort of crap is filtering through into Enterprise Linux.
He no longer has any confidence that Red Hat has the faintest clue what constitutes a secure system.
I didn't think he was overreacting; this is the dumbest thing I've seen any Linux distribution do, ever.
That the Fedora developers are trying to defend this stupidity is just the icing on the cake.
Red Hat should sack every last one of them for incompetence.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150268</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>RiotingPacifist</author>
	<datestamp>1257077100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You don't have to use it, however users can already install and run programs in their<nobr> <wbr></nobr>/home (noexec can only help so much), making this easier and safer for them (installing trusted packages instead of random ones) is a good idea.</p></htmltext>
<tokenext>You do n't have to use it , however users can already install and run programs in their /home ( noexec can only help so much ) , making this easier and safer for them ( installing trusted packages instead of random ones ) is a good idea .</tokentext>
<sentencetext>You don't have to use it, however users can already install and run programs in their /home (noexec can only help so much), making this easier and safer for them (installing trusted packages instead of random ones) is a good idea.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154044</id>
	<title>package conflicts?</title>
	<author>Anonymous</author>
	<datestamp>1258624860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't like this one bit.<br>What about package conflicts? If 2 packages conflict with each other, a regular user can remove the conflicting package? Doesn't look like a sensible thing to do....<br>not only can some idiot install random packages from the repo, but also remove certain 'needed' packages.<br>This is disturbing indeed.</p></htmltext>
<tokenext>I do n't like this one bit.What about package conflicts ?
If 2 packages conflict with each other , a regular user can remove the conflicting package ?
Does n't look like a sensible thing to do....not only can some idiot install random packages from the repo , but also remove certain 'needed ' packages.This is disturbing indeed .</tokentext>
<sentencetext>I don't like this one bit.What about package conflicts?
If 2 packages conflict with each other, a regular user can remove the conflicting package?
Doesn't look like a sensible thing to do....not only can some idiot install random packages from the repo, but also remove certain 'needed' packages.This is disturbing indeed.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151338</id>
	<title>can only end badly...</title>
	<author>smash</author>
	<datestamp>1257082860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>consider that I find an exploitable hole in Package X to get me root.
<p>
I can then go to any fedora 12 desktop (say, an entire college lab), and install that package to exploit, to get root.
</p><p>
That is brain damage.</p></htmltext>
<tokenext>consider that I find an exploitable hole in Package X to get me root .
I can then go to any fedora 12 desktop ( say , an entire college lab ) , and install that package to exploit , to get root .
That is brain damage .</tokentext>
<sentencetext>consider that I find an exploitable hole in Package X to get me root.
I can then go to any fedora 12 desktop (say, an entire college lab), and install that package to exploit, to get root.
That is brain damage.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149592</id>
	<title>One way to root a Fedora install</title>
	<author>mukund</author>
	<datestamp>1257074520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Fedora accepts all kinds of packages. You could create a simple utility, like some netmask computation code, make it a trojan (add code which does what it's not intended to do as setuid root).. package it for Fedora. This can go completely unnoticed. As an upstream maintainer, I am pretty sure Fedora or any other distro does not review my project code more than a cursory glance to fix any compilation/integration issues.</p><p>User gets to be root user. It may not even be a user.. it may be a program of some kind that has access to your user account after exploiting a vulnerability in an app such as your web browser.</p><p>There are other ways to get root too, such as exploit other setuid binaries in any of the thousands of packages that Fedora ships in the Everything repo.</p><p>Letting users install packages (signed or not) on a system administered by root is a stupid decision.</p></htmltext>
<tokenext>Fedora accepts all kinds of packages .
You could create a simple utility , like some netmask computation code , make it a trojan ( add code which does what it 's not intended to do as setuid root ) .. package it for Fedora .
This can go completely unnoticed .
As an upstream maintainer , I am pretty sure Fedora or any other distro does not review my project code more than a cursory glance to fix any compilation/integration issues.User gets to be root user .
It may not even be a user.. it may be a program of some kind that has access to your user account after exploiting a vulnerability in an app such as your web browser.There are other ways to get root too , such as exploit other setuid binaries in any of the thousands of packages that Fedora ships in the Everything repo.Letting users install packages ( signed or not ) on a system administered by root is a stupid decision .</tokentext>
<sentencetext>Fedora accepts all kinds of packages.
You could create a simple utility, like some netmask computation code, make it a trojan (add code which does what it's not intended to do as setuid root).. package it for Fedora.
This can go completely unnoticed.
As an upstream maintainer, I am pretty sure Fedora or any other distro does not review my project code more than a cursory glance to fix any compilation/integration issues.User gets to be root user.
It may not even be a user.. it may be a program of some kind that has access to your user account after exploiting a vulnerability in an app such as your web browser.There are other ways to get root too, such as exploit other setuid binaries in any of the thousands of packages that Fedora ships in the Everything repo.Letting users install packages (signed or not) on a system administered by root is a stupid decision.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151802</id>
	<title>This seems ok</title>
	<author>anexkahn</author>
	<datestamp>1257085860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As long as it is an option, and turned off by default.....and who has to sign these packages?</htmltext>
<tokenext>As long as it is an option , and turned off by default.....and who has to sign these packages ?</tokentext>
<sentencetext>As long as it is an option, and turned off by default.....and who has to sign these packages?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161644</id>
	<title>Re:Interesting comment on Bugzilla...</title>
	<author>StuartHankins</author>
	<datestamp>1258662780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Mod parent up. Finally, someone "gets" it.</htmltext>
<tokenext>Mod parent up .
Finally , someone " gets " it .</tokentext>
<sentencetext>Mod parent up.
Finally, someone "gets" it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149638</id>
	<title>Re:What does this solve?</title>
	<author>natehoy</author>
	<datestamp>1257074760000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>It depends on your environment.  For an individual user, you'd want sudo or su and you'd want to be prompted for each install.  And that's a good thing.</p><p>But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs").  I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository.  But installs of things not on the "approved" list and therefore in the repository require root access.</p><p>However, this configuration setting was still a Bad Move on RedHat's part.  If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use.  So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).</p></htmltext>
<tokenext>It depends on your environment .
For an individual user , you 'd want sudo or su and you 'd want to be prompted for each install .
And that 's a good thing.But in a large corporate environment , I might want to make a bank of internal applications available ( similar to Microsoft 's " Run Advertised Programs " ) .
I could configure all of my corporate desktops to only recognize the signing authority of a repository I own , then any of my users can install anything they want off that repository .
But installs of things not on the " approved " list and therefore in the repository require root access.However , this configuration setting was still a Bad Move on RedHat 's part .
If a corporation wants to allow this , they 'll probably also want to think about the list of signing authorities they want to use .
So this should be OFF by default and if an administrator wants to turn it ON they 'd need to take action ( and would presumably know what they are doing and why ) .</tokentext>
<sentencetext>It depends on your environment.
For an individual user, you'd want sudo or su and you'd want to be prompted for each install.
And that's a good thing.But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs").
I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository.
But installs of things not on the "approved" list and therefore in the repository require root access.However, this configuration setting was still a Bad Move on RedHat's part.
If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use.
So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154068</id>
	<title>New filesystems</title>
	<author>bytesex</author>
	<datestamp>1258625160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What you need is a complete filesystem lay-over for the specific user.  Then it doesn't matter that a user has installed a certain package.  It's just that the other users won't be able to see it.</p></htmltext>
<tokenext>What you need is a complete filesystem lay-over for the specific user .
Then it does n't matter that a user has installed a certain package .
It 's just that the other users wo n't be able to see it .</tokentext>
<sentencetext>What you need is a complete filesystem lay-over for the specific user.
Then it doesn't matter that a user has installed a certain package.
It's just that the other users won't be able to see it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151380</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>Spit</author>
	<datestamp>1257083160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are too many assumptions: the implementation is flawless, that the input is indeed on the console and not from hijacked controls or remote desktop, that the user hasn't been engineered into adding a bad repo key. This is just poor.</p></htmltext>
<tokenext>There are too many assumptions : the implementation is flawless , that the input is indeed on the console and not from hijacked controls or remote desktop , that the user has n't been engineered into adding a bad repo key .
This is just poor .</tokentext>
<sentencetext>There are too many assumptions: the implementation is flawless, that the input is indeed on the console and not from hijacked controls or remote desktop, that the user hasn't been engineered into adding a bad repo key.
This is just poor.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149738</id>
	<title>Of course!</title>
	<author>RoboRay</author>
	<datestamp>1257075060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>They had to do this in response to Microsoft patenting SUDO.</p></htmltext>
<tokenext>They had to do this in response to Microsoft patenting SUDO .</tokentext>
<sentencetext>They had to do this in response to Microsoft patenting SUDO.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149090</id>
	<title>Re:It's obvious</title>
	<author>Anonymous</author>
	<datestamp>1257072180000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>On Windows, only admins can install. Otherwise, nice try, moron.</p></htmltext>
<tokenext>On Windows , only admins can install .
Otherwise , nice try , moron .</tokentext>
<sentencetext>On Windows, only admins can install.
Otherwise, nice try, moron.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526</id>
	<title>PackageKit at fault, not Fedora</title>
	<author>Azureflare</author>
	<datestamp>1257084120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Lots of posters flying off the handle that obviously didn't read the actual thread.  PackageKit added this as a "feature" without notifying the Fedora team.  yum still behaves as expected. I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g.<nobr> <wbr></nobr>/usr/bin etc.), but users can install their own local packages using PackageKit.
<br> <br>
In fact, this is exactly what Mac OS X does by default.  I'm not entirely sure if this is really a problem or not. In Linux, users are already able to install local apps into their home directories, this appears to just make it integrate with the UI much easier than before.  I remember I had to manage my own user apps in my home directory and it was a real pain, since I had to add that bin directory to my path, and none of those apps appeared in menus anywhere.</htmltext>
<tokenext>Lots of posters flying off the handle that obviously did n't read the actual thread .
PackageKit added this as a " feature " without notifying the Fedora team .
yum still behaves as expected .
I 'm assuming that PackageKit still requires root to modify shared system areas where the owner is root ( e.g .
/usr/bin etc .
) , but users can install their own local packages using PackageKit .
In fact , this is exactly what Mac OS X does by default .
I 'm not entirely sure if this is really a problem or not .
In Linux , users are already able to install local apps into their home directories , this appears to just make it integrate with the UI much easier than before .
I remember I had to manage my own user apps in my home directory and it was a real pain , since I had to add that bin directory to my path , and none of those apps appeared in menus anywhere .</tokentext>
<sentencetext>Lots of posters flying off the handle that obviously didn't read the actual thread.
PackageKit added this as a "feature" without notifying the Fedora team.
yum still behaves as expected.
I'm assuming that PackageKit still requires root to modify shared system areas where the owner is root (e.g.
/usr/bin etc.
), but users can install their own local packages using PackageKit.
In fact, this is exactly what Mac OS X does by default.
I'm not entirely sure if this is really a problem or not.
In Linux, users are already able to install local apps into their home directories, this appears to just make it integrate with the UI much easier than before.
I remember I had to manage my own user apps in my home directory and it was a real pain, since I had to add that bin directory to my path, and none of those apps appeared in menus anywhere.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149032</id>
	<title>whatcouldpossiblygowrong?</title>
	<author>rrohbeck</author>
	<datestamp>1257071760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just hope that your appliance manufacturer has disabled this.</p></htmltext>
<tokenext>Just hope that your appliance manufacturer has disabled this .</tokentext>
<sentencetext>Just hope that your appliance manufacturer has disabled this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153256</id>
	<title>Packet sniffers, hacking tools...</title>
	<author>marciot</author>
	<datestamp>1257099960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A lot of people here have pointed out the vulnerability of allowing someone to choose to install a package with a known exploit, but even if no such buggy code existed, there are other vulnerabilities to consider. For example, if regular users install a signed package of wireshark and/or metasploit they can now use such tools to attempt to compromise network security.</p></htmltext>
<tokenext>A lot of people here have pointed out the vulnerability of allowing someone to choose to install a package with a known exploit , but even if no such buggy code existed , there are other vulnerabilities to consider .
For example , if regular users install a signed package of wireshark and/or metasploit they can now use such tools to attempt to compromise network security .</tokentext>
<sentencetext>A lot of people here have pointed out the vulnerability of allowing someone to choose to install a package with a known exploit, but even if no such buggy code existed, there are other vulnerabilities to consider.
For example, if regular users install a signed package of wireshark and/or metasploit they can now use such tools to attempt to compromise network security.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153512</id>
	<title>Re:It's obvious</title>
	<author>PeterBrett</author>
	<datestamp>1257104100000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Trusting the repos has nothing to do with it. If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about. Why should the average user have a web or FTP server running on the desktop? Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.</p></div><p>I agreed with you about this, so I investigated. It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them. A package won't pass review if that's not the case.</p><p>The issue suddenly became much less of a big deal to me.  In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.</p></div>
	</htmltext>
<tokenext>Trusting the repos has nothing to do with it .
If I 've got my users on Fedora as their desktops , I do n't want them installing packages that I do n't know about .
Why should the average user have a web or FTP server running on the desktop ?
Default configurations have frequently been the location for vulnerabilities , and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.I agreed with you about this , so I investigated .
It turns out that daemons packaged by Fedora are disabled by default , and require someone with root access to enable them .
A package wo n't pass review if that 's not the case.The issue suddenly became much less of a big deal to me .
In the end , it comes down to whether you trust the quality of Fedora packages and the security of their signing key .
Either you do , in which case this is n't a problem , or you do n't , in which case you should n't be using Fedora .</tokentext>
<sentencetext>Trusting the repos has nothing to do with it.
If I've got my users on Fedora as their desktops, I don't want them installing packages that I don't know about.
Why should the average user have a web or FTP server running on the desktop?
Default configurations have frequently been the location for vulnerabilities, and many users could install a service and then not be able to secure it properly because most of those configuration files require root or sudo access.I agreed with you about this, so I investigated.
It turns out that daemons packaged by Fedora are disabled by default, and require someone with root access to enable them.
A package won't pass review if that's not the case.The issue suddenly became much less of a big deal to me.
In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key.
Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151696</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257085080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>zeroinstall</p></htmltext>
<tokenext>zeroinstall</tokentext>
<sentencetext>zeroinstall</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30163970</id>
	<title>Dependencies</title>
	<author>unixguy43</author>
	<datestamp>1258626900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Like many of the posters so far, I don't like users having the ability to install packages either.  While there's exceptions, "users" are generally people who don't have the skills to do the administrative tasks on the system.  If they have the skills, then they should have root (or sudo) access, plain and simple. Why?  Dependencies.

Virtually anything that someone would want to install has dependencies.  Admins know about dependencies, and understand the risks associated with making changes to them.  So Joe User grabs the latest and greatest music app and wants it installed, so he installs it- along with it's 3 dependencies, one of which complains that library ld.so.1 will be replaced and is needed by some other installed program.  Joe User just wants his music player, so he overrides the install and forces it to overwrite the library and redirect the related links to the new library.  One or more apps are now cratered because of a failed dependency.

The admin now has to go through and rectify a library that was there at one point, but is now gone because of a user.  Anything that has potential to change the functionality of the system should not be in the hands of a non-privileged user.</htmltext>
<tokenext>Like many of the posters so far , I do n't like users having the ability to install packages either .
While there 's exceptions , " users " are generally people who do n't have the skills to do the administrative tasks on the system .
If they have the skills , then they should have root ( or sudo ) access , plain and simple .
Why ? Dependencies .
Virtually anything that someone would want to install has dependencies .
Admins know about dependencies , and understand the risks associated with making changes to them .
So Joe User grabs the latest and greatest music app and wants it installed , so he installs it- along with it 's 3 dependencies , one of which complains that library ld.so.1 will be replaced and is needed by some other installed program .
Joe User just wants his music player , so he overrides the install and forces it to overwrite the library and redirect the related links to the new library .
One or more apps are now cratered because of a failed dependency .
The admin now has to go through and rectify a library that was there at one point , but is now gone because of a user .
Anything that has potential to change the functionality of the system should not be in the hands of a non-privileged user .</tokentext>
<sentencetext>Like many of the posters so far, I don't like users having the ability to install packages either.
While there's exceptions, "users" are generally people who don't have the skills to do the administrative tasks on the system.
If they have the skills, then they should have root (or sudo) access, plain and simple.
Why?  Dependencies.
Virtually anything that someone would want to install has dependencies.
Admins know about dependencies, and understand the risks associated with making changes to them.
So Joe User grabs the latest and greatest music app and wants it installed, so he installs it- along with it's 3 dependencies, one of which complains that library ld.so.1 will be replaced and is needed by some other installed program.
Joe User just wants his music player, so he overrides the install and forces it to overwrite the library and redirect the related links to the new library.
One or more apps are now cratered because of a failed dependency.
The admin now has to go through and rectify a library that was there at one point, but is now gone because of a user.
Anything that has potential to change the functionality of the system should not be in the hands of a non-privileged user.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152478</id>
	<title>Re:What does this solve?</title>
	<author>99BottlesOfBeerInMyF</author>
	<datestamp>1257091080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine. Its seemless in Linux and OSX.</p></div><p>Usability and security are complementary in this case. Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.</p><p><div class="quote"><p>Not prompting for authentication for signed package installs is insanely insecure and borderline insane.</p></div><p>While I don't like this implementation, as a concept I think that for signed software the sysadmin has already verified as a trusted source, not asking for the user to enter a password is a very good thing. If only we could get more packages reviewed properly for security and signed. Think of the iPhone App store. Is it insane that they don't ask users to type in a password when installing an app?</p></div>
	</htmltext>
<tokenext>From a desktop usability perspective , having the gui password prompt for an elevated privilege such as a package install works fine .
Its seemless in Linux and OSX.Usability and security are complementary in this case .
Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.Not prompting for authentication for signed package installs is insanely insecure and borderline insane.While I do n't like this implementation , as a concept I think that for signed software the sysadmin has already verified as a trusted source , not asking for the user to enter a password is a very good thing .
If only we could get more packages reviewed properly for security and signed .
Think of the iPhone App store .
Is it insane that they do n't ask users to type in a password when installing an app ?</tokentext>
<sentencetext> From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.
Its seemless in Linux and OSX.Usability and security are complementary in this case.
Training users to type in their password whenever they need to install software is a usability problem that leads to a security problem of users typing in their password in order to install a trojan with elevated permissions.Not prompting for authentication for signed package installs is insanely insecure and borderline insane.While I don't like this implementation, as a concept I think that for signed software the sysadmin has already verified as a trusted source, not asking for the user to enter a password is a very good thing.
If only we could get more packages reviewed properly for security and signed.
Think of the iPhone App store.
Is it insane that they don't ask users to type in a password when installing an app?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148966</id>
	<title>what could possibly go wrong</title>
	<author>Anonymous</author>
	<datestamp>1257071580000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><p>no really</p></htmltext>
<tokenext>no really</tokentext>
<sentencetext>no really</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066</id>
	<title>This makes sense</title>
	<author>Anonymous</author>
	<datestamp>1257071940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers). I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages. I don't want my guest users installing every signed package and filling my HDD.</p></htmltext>
<tokenext>If the content is trusted then requiring the user to get root privileges is just a security risk ( key-loggers ) .
I do hope , however , that they had to foresight to require specific permissions to allow users to install signed packages .
I do n't want my guest users installing every signed package and filling my HDD .</tokentext>
<sentencetext>If the content is trusted then requiring the user to get root privileges is just a security risk (key-loggers).
I do hope, however, that they had to foresight to require specific permissions to allow users to install signed packages.
I don't want my guest users installing every signed package and filling my HDD.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30156620</id>
	<title>RTFA</title>
	<author>fulldecent</author>
	<datestamp>1258647300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Read the first link. There's about 1000 people basically arguing that "if any one Fedora-signed package is compromised, then all default-install systems can be compromised by unprivileged users."</p><p>Then read comments by Richard Hughes.</p><p>It's like having an argument with someone who believes in god.</p></htmltext>
<tokenext>Read the first link .
There 's about 1000 people basically arguing that " if any one Fedora-signed package is compromised , then all default-install systems can be compromised by unprivileged users .
" Then read comments by Richard Hughes.It 's like having an argument with someone who believes in god .</tokentext>
<sentencetext>Read the first link.
There's about 1000 people basically arguing that "if any one Fedora-signed package is compromised, then all default-install systems can be compromised by unprivileged users.
"Then read comments by Richard Hughes.It's like having an argument with someone who believes in god.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152074</id>
	<title>Re:What does this solve?</title>
	<author>Homburg</author>
	<datestamp>1257087720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I really don't understand the basis for this move. From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.</p></div><p>It makes sense if you have other users on the machine who should be able to install trusted software, but not perform other administrative tasks - perhaps your child wants to install some games, or your spouse needs some additional graphics application, or something. You don't want to give them full admin access, or even unrestricted access to the package manager (which would allow them to uninstall important stuff).</p><p>Now, whether this should be the default is more questionable; it probably makes more sense to have something that can be turned on on a user-by-user basis. But letting at least some users install signed packages without elevated privileges could be quite useful on a home system.</p></div>
	</htmltext>
<tokenext>I really do n't understand the basis for this move .
From a desktop usability perspective , having the gui password prompt for an elevated privilege such as a package install works fine.It makes sense if you have other users on the machine who should be able to install trusted software , but not perform other administrative tasks - perhaps your child wants to install some games , or your spouse needs some additional graphics application , or something .
You do n't want to give them full admin access , or even unrestricted access to the package manager ( which would allow them to uninstall important stuff ) .Now , whether this should be the default is more questionable ; it probably makes more sense to have something that can be turned on on a user-by-user basis .
But letting at least some users install signed packages without elevated privileges could be quite useful on a home system .</tokentext>
<sentencetext>I really don't understand the basis for this move.
From a desktop usability perspective, having the gui password prompt for an elevated privilege such as a package install works fine.It makes sense if you have other users on the machine who should be able to install trusted software, but not perform other administrative tasks - perhaps your child wants to install some games, or your spouse needs some additional graphics application, or something.
You don't want to give them full admin access, or even unrestricted access to the package manager (which would allow them to uninstall important stuff).Now, whether this should be the default is more questionable; it probably makes more sense to have something that can be turned on on a user-by-user basis.
But letting at least some users install signed packages without elevated privileges could be quite useful on a home system.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151544</id>
	<title>Time to leave Fedora...</title>
	<author>Improv</author>
	<datestamp>1257084240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I've been using redhat/fedora since at least RedHat5, having previously used Slackware. I thought SELinux was pretty sketchy, but this change is utterly ridiculous. I'm still on FC11, but until and unless they develop some sanity by FC13, I'm going to need to find a new distro (CentOS? Debian? I'm not sure yet)</p></htmltext>
<tokenext>I 've been using redhat/fedora since at least RedHat5 , having previously used Slackware .
I thought SELinux was pretty sketchy , but this change is utterly ridiculous .
I 'm still on FC11 , but until and unless they develop some sanity by FC13 , I 'm going to need to find a new distro ( CentOS ?
Debian ? I 'm not sure yet )</tokentext>
<sentencetext>I've been using redhat/fedora since at least RedHat5, having previously used Slackware.
I thought SELinux was pretty sketchy, but this change is utterly ridiculous.
I'm still on FC11, but until and unless they develop some sanity by FC13, I'm going to need to find a new distro (CentOS?
Debian? I'm not sure yet)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149892</id>
	<title>Re:Wow</title>
	<author>Anonymous</author>
	<datestamp>1257075660000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>I'm not even sure who to <i>ROOT</i> for anymore.</p><p>Haha, that was so terrible, please don't mod me funny.</p></htmltext>
<tokenext>I 'm not even sure who to ROOT for anymore.Haha , that was so terrible , please do n't mod me funny .</tokentext>
<sentencetext>I'm not even sure who to ROOT for anymore.Haha, that was so terrible, please don't mod me funny.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30156918</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>sgtrock</author>
	<datestamp>1258648260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My kids have had direct, physical access to the desktop on a shared machine since they were old enough to see the keyboard and move the mouse.  My now 15 year old daughter started that way when she was 3.  Do you really think it's a good idea to allow a <b>THREE YEAR OLD GIRL</b> the ability to <b>INSTALL ANY SOFTWARE WHATSOEVER????</b></p><p>Whoever thought that setting this as the default was a good idea should be shot before they contribute to the gene pool.  Anyone who thinks this is a good idea for any distribution deserves the rooting that they're about to get.</p></htmltext>
<tokenext>My kids have had direct , physical access to the desktop on a shared machine since they were old enough to see the keyboard and move the mouse .
My now 15 year old daughter started that way when she was 3 .
Do you really think it 's a good idea to allow a THREE YEAR OLD GIRL the ability to INSTALL ANY SOFTWARE WHATSOEVER ? ? ?
? Whoever thought that setting this as the default was a good idea should be shot before they contribute to the gene pool .
Anyone who thinks this is a good idea for any distribution deserves the rooting that they 're about to get .</tokentext>
<sentencetext>My kids have had direct, physical access to the desktop on a shared machine since they were old enough to see the keyboard and move the mouse.
My now 15 year old daughter started that way when she was 3.
Do you really think it's a good idea to allow a THREE YEAR OLD GIRL the ability to INSTALL ANY SOFTWARE WHATSOEVER???
?Whoever thought that setting this as the default was a good idea should be shot before they contribute to the gene pool.
Anyone who thinks this is a good idea for any distribution deserves the rooting that they're about to get.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158362</id>
	<title>Re:Interesting comment on Bugzilla...</title>
	<author>alien\_life\_form</author>
	<datestamp>1258652460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Greetings.</p><p>The two comments you quote have been posted by the developer that appears to have made the change in the first place. In his blog, he also explains how that is part of the "philosophy" of the application, and somesuch.</p><p>It is also of interest that other developers on the same thread appear to be on a similar short fuse (see comment #144). There is a very annoying tendency (on the bug coments and the ML) to simply tell people who argue against this behavior to either add more justifications (as if they were actaully needed) until they are blue in the face or to shut up (or, sometimes, just the latest).</p><p>It has basically turned into an ideological war, and it's ugly to behold.</p><p>Cheers,<br>alf</p></div>
	</htmltext>
<tokenext>Greetings.The two comments you quote have been posted by the developer that appears to have made the change in the first place .
In his blog , he also explains how that is part of the " philosophy " of the application , and somesuch.It is also of interest that other developers on the same thread appear to be on a similar short fuse ( see comment # 144 ) .
There is a very annoying tendency ( on the bug coments and the ML ) to simply tell people who argue against this behavior to either add more justifications ( as if they were actaully needed ) until they are blue in the face or to shut up ( or , sometimes , just the latest ) .It has basically turned into an ideological war , and it 's ugly to behold.Cheers,alf</tokentext>
<sentencetext>Greetings.The two comments you quote have been posted by the developer that appears to have made the change in the first place.
In his blog, he also explains how that is part of the "philosophy" of the application, and somesuch.It is also of interest that other developers on the same thread appear to be on a similar short fuse (see comment #144).
There is a very annoying tendency (on the bug coments and the ML) to simply tell people who argue against this behavior to either add more justifications (as if they were actaully needed) until they are blue in the face or to shut up (or, sometimes, just the latest).It has basically turned into an ideological war, and it's ugly to behold.Cheers,alf
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151476</id>
	<title>Err I thought this was handled through ConsoleKit</title>
	<author>Nicolas MONNET</author>
	<datestamp>1257083760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I could be mistaken but I reinstalled F12beta after a major disk crash, and I had to auth once to ConsoleKit, which memorized my authorization for my current user. You don't have to memorize the auth, in which case you have to type the root password each time<nobr> <wbr></nobr>... or did I miss something?<br>I can understand not wanting this for new packages, but for updates to packages already installed, this strikes me as better than the Ubuntu way.<br>There is one security advantage for the average user, it limits the number of times you have to type the damn password, therefore avoiding the numbing down and making trojan type attacks more noticeable. IE if a fake popup asks your for your root password you might not pay attention if you've been asked a thousand times already for something as mundane as updating.</p></htmltext>
<tokenext>I could be mistaken but I reinstalled F12beta after a major disk crash , and I had to auth once to ConsoleKit , which memorized my authorization for my current user .
You do n't have to memorize the auth , in which case you have to type the root password each time ... or did I miss something ? I can understand not wanting this for new packages , but for updates to packages already installed , this strikes me as better than the Ubuntu way.There is one security advantage for the average user , it limits the number of times you have to type the damn password , therefore avoiding the numbing down and making trojan type attacks more noticeable .
IE if a fake popup asks your for your root password you might not pay attention if you 've been asked a thousand times already for something as mundane as updating .</tokentext>
<sentencetext>I could be mistaken but I reinstalled F12beta after a major disk crash, and I had to auth once to ConsoleKit, which memorized my authorization for my current user.
You don't have to memorize the auth, in which case you have to type the root password each time ... or did I miss something?I can understand not wanting this for new packages, but for updates to packages already installed, this strikes me as better than the Ubuntu way.There is one security advantage for the average user, it limits the number of times you have to type the damn password, therefore avoiding the numbing down and making trojan type attacks more noticeable.
IE if a fake popup asks your for your root password you might not pay attention if you've been asked a thousand times already for something as mundane as updating.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108</id>
	<title>Of course there isn't a problem</title>
	<author>TSHTF</author>
	<datestamp>1257072300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>Certainly there can't be a problem here, says the Fedora team.

According to the <a href="http://fedoraproject.org/wiki/Fedora\_12\_one\_page\_release\_notes" title="fedoraproject.org" rel="nofollow">release notes</a> [fedoraproject.org], there are 15,000 packages which can be installed by these unprivileged users. That's a lot of fscking code -- surely some of it is poorly written. Consider this scenario:

Package X suffers a critical {local, remote} root vulnerability. If the vulnerability isn't public, any local user (and maybe remote ones too!) has root. If the vulnerability is public,  there is often a long window between downstream fixes and Fedora fixes. In either case, this is a security issue.

The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.</htmltext>
<tokenext>Certainly there ca n't be a problem here , says the Fedora team .
According to the release notes [ fedoraproject.org ] , there are 15,000 packages which can be installed by these unprivileged users .
That 's a lot of fscking code -- surely some of it is poorly written .
Consider this scenario : Package X suffers a critical { local , remote } root vulnerability .
If the vulnerability is n't public , any local user ( and maybe remote ones too !
) has root .
If the vulnerability is public , there is often a long window between downstream fixes and Fedora fixes .
In either case , this is a security issue .
The Fedora team really should have put this in the release notes and reconsider this implementation in the first place .</tokentext>
<sentencetext>Certainly there can't be a problem here, says the Fedora team.
According to the release notes [fedoraproject.org], there are 15,000 packages which can be installed by these unprivileged users.
That's a lot of fscking code -- surely some of it is poorly written.
Consider this scenario:

Package X suffers a critical {local, remote} root vulnerability.
If the vulnerability isn't public, any local user (and maybe remote ones too!
) has root.
If the vulnerability is public,  there is often a long window between downstream fixes and Fedora fixes.
In either case, this is a security issue.
The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149342</id>
	<title>Re:It's obvious</title>
	<author>Anonymous</author>
	<datestamp>1257073380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>The best rant against the Windows way of doing things from Tom Christiansen:</p><p><a href="http://slashdot.org/comments.pl?sid=3291&amp;cid=1395315" title="slashdot.org">http://slashdot.org/comments.pl?sid=3291&amp;cid=1395315</a> [slashdot.org] </p><blockquote><div><p>No, I don't care that a customer asked for it. Customers are idiots, just like any other user. So what if they pay you? They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses. The customer is not always right. In fact, they're very often wrong. A physician or a lawyer doesn't do whatever the customer requests, and neither do you. They, meaning the customers or users, simply don't have the background and training;</p></div></blockquote><p>Truer words were never spoken.</p><p>--<br>BMO</p></div>
	</htmltext>
<tokenext>The best rant against the Windows way of doing things from Tom Christiansen : http : //slashdot.org/comments.pl ? sid = 3291&amp;cid = 1395315 [ slashdot.org ] No , I do n't care that a customer asked for it .
Customers are idiots , just like any other user .
So what if they pay you ?
They 're still idiots , and it 's your professional responsibility to act responsibly , to refuse to go along with their madnesses .
The customer is not always right .
In fact , they 're very often wrong .
A physician or a lawyer does n't do whatever the customer requests , and neither do you .
They , meaning the customers or users , simply do n't have the background and training ; Truer words were never spoken.--BMO</tokentext>
<sentencetext>The best rant against the Windows way of doing things from Tom Christiansen:http://slashdot.org/comments.pl?sid=3291&amp;cid=1395315 [slashdot.org] No, I don't care that a customer asked for it.
Customers are idiots, just like any other user.
So what if they pay you?
They're still idiots, and it's your professional responsibility to act responsibly, to refuse to go along with their madnesses.
The customer is not always right.
In fact, they're very often wrong.
A physician or a lawyer doesn't do whatever the customer requests, and neither do you.
They, meaning the customers or users, simply don't have the background and training;Truer words were never spoken.--BMO
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150416</id>
	<title>Re:LOCAL USER ONLY, AND SIGNED PACKAGE ONLY</title>
	<author>Anonymous</author>
	<datestamp>1257077820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Imagine this for a second:</p><p>In a college or university, studens will install a bunch of packages...  This is so simple, so user friendly.</p><p>You says: we can break a server with a LiveCD.  Well, haven't you heard about BIOS password ?</p></htmltext>
<tokenext>Imagine this for a second : In a college or university , studens will install a bunch of packages... This is so simple , so user friendly.You says : we can break a server with a LiveCD .
Well , have n't you heard about BIOS password ?</tokentext>
<sentencetext>Imagine this for a second:In a college or university, studens will install a bunch of packages...  This is so simple, so user friendly.You says: we can break a server with a LiveCD.
Well, haven't you heard about BIOS password ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149330</id>
	<title>Re:YAY!!!!</title>
	<author>Anonymous</author>
	<datestamp>1257073320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually, no. It only allows to install packages that have been signed - so things in the fedora repositories.</p><p>And if any of them is insecure, then the "correct" fix is to fix the package to fix the insecurity.</p><p>Saying that, I can understand why someone may not want others to randomly install even signed packages, so maybe they should have limited this feature to updates only?</p></htmltext>
<tokenext>Actually , no .
It only allows to install packages that have been signed - so things in the fedora repositories.And if any of them is insecure , then the " correct " fix is to fix the package to fix the insecurity.Saying that , I can understand why someone may not want others to randomly install even signed packages , so maybe they should have limited this feature to updates only ?</tokentext>
<sentencetext>Actually, no.
It only allows to install packages that have been signed - so things in the fedora repositories.And if any of them is insecure, then the "correct" fix is to fix the package to fix the insecurity.Saying that, I can understand why someone may not want others to randomly install even signed packages, so maybe they should have limited this feature to updates only?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151714</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1257085140000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>zero install: http://0install.net<br>You run an app through it (using its URL, eg: 0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer ), and it will install it to a path under your home directory if it isn't already there, and then run it. Not much third-party software available via it yet, but there's an effort in place to change that.</p></htmltext>
<tokenext>zero install : http : //0install.netYou run an app through it ( using its URL , eg : 0launch http : //rox.sourceforge.net/2005/interfaces/ROX-Filer ) , and it will install it to a path under your home directory if it is n't already there , and then run it .
Not much third-party software available via it yet , but there 's an effort in place to change that .</tokentext>
<sentencetext>zero install: http://0install.netYou run an app through it (using its URL, eg: 0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer ), and it will install it to a path under your home directory if it isn't already there, and then run it.
Not much third-party software available via it yet, but there's an effort in place to change that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154090</id>
	<title>Goals to have</title>
	<author>Anonymous</author>
	<datestamp>1258625460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Get several packages blessed, sanctified, anointed and kissed by David the inbred developer with every flaw, buffer overflow, gimme-root command, system-wipe command I can just to show I care.</p><p>I'll wrap at least one into a turkey punching game as a nod to the zombie apocalypse.</p></htmltext>
<tokenext>Get several packages blessed , sanctified , anointed and kissed by David the inbred developer with every flaw , buffer overflow , gim me-root command , system-wipe command I can just to show I care.I 'll wrap at least one into a turkey punching game as a nod to the zombie apocalypse .</tokentext>
<sentencetext>Get several packages blessed, sanctified, anointed and kissed by David the inbred developer with every flaw, buffer overflow, gimme-root command, system-wipe command I can just to show I care.I'll wrap at least one into a turkey punching game as a nod to the zombie apocalypse.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149012</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151300</id>
	<title>packagekit</title>
	<author>Anonymous</author>
	<datestamp>1257082620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Those in the know about packagekit just uninstall it as one of the first tasks after installing fedora.<br>Most fedora people prefer good old yum instead.<br>It has been said time and time again by more than just the fedora community that packagekit is crapware and that fedora should drop it.<br>The message just doesn't seem to be getting through.</p><p>It comes as absolutely no surprise what so ever that the problem stems from packagekit.</p><p>Knowing how many really bad bugs there are in fedora 12 having tested it since alpha, it might be a good idea for potential adopters to wait for the fedora 13 released spring next year, instead.</p></htmltext>
<tokenext>Those in the know about packagekit just uninstall it as one of the first tasks after installing fedora.Most fedora people prefer good old yum instead.It has been said time and time again by more than just the fedora community that packagekit is crapware and that fedora should drop it.The message just does n't seem to be getting through.It comes as absolutely no surprise what so ever that the problem stems from packagekit.Knowing how many really bad bugs there are in fedora 12 having tested it since alpha , it might be a good idea for potential adopters to wait for the fedora 13 released spring next year , instead .</tokentext>
<sentencetext>Those in the know about packagekit just uninstall it as one of the first tasks after installing fedora.Most fedora people prefer good old yum instead.It has been said time and time again by more than just the fedora community that packagekit is crapware and that fedora should drop it.The message just doesn't seem to be getting through.It comes as absolutely no surprise what so ever that the problem stems from packagekit.Knowing how many really bad bugs there are in fedora 12 having tested it since alpha, it might be a good idea for potential adopters to wait for the fedora 13 released spring next year, instead.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151738</id>
	<title>Re:User-level package manager</title>
	<author>Shin-LaC</author>
	<datestamp>1257085380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That sounded interesting until I read: "Dependency resolution and updates are basic or not working yet."<br> <br>It's not really a package manager if it doesn't do that.</htmltext>
<tokenext>That sounded interesting until I read : " Dependency resolution and updates are basic or not working yet .
" It 's not really a package manager if it does n't do that .</tokentext>
<sentencetext>That sounded interesting until I read: "Dependency resolution and updates are basic or not working yet.
" It's not really a package manager if it doesn't do that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149236</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151734</id>
	<title>Re:Users should not get to be root. PERIOD</title>
	<author>Anonymous</author>
	<datestamp>1257085380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>su buddy!</p></htmltext>
<tokenext>su buddy !</tokentext>
<sentencetext>su buddy!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30157284</id>
	<title>Re:Developers vs. Sysadmins</title>
	<author>Culture20</author>
	<datestamp>1258649280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Your developers don't appear to know what --prefix=~/ means for<nobr> <wbr></nobr>./configure scripts.</htmltext>
<tokenext>Your developers do n't appear to know what --prefix = ~ / means for ./configure scripts .</tokentext>
<sentencetext>Your developers don't appear to know what --prefix=~/ means for ./configure scripts.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149012</id>
	<title>Glad to see...</title>
	<author>Anonymous</author>
	<datestamp>1257071700000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>...all those laid off Microsoft employees already found work.</htmltext>
<tokenext>...all those laid off Microsoft employees already found work .</tokentext>
<sentencetext>...all those laid off Microsoft employees already found work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150250</id>
	<title>Re:I fail to see the problem</title>
	<author>XSpud</author>
	<datestamp>1257076980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.</p></div><p>
But that workstation or netbook might be behind a corporate firewall on a network with 120 other users.
</p></div>
	</htmltext>
<tokenext>This is someone 's workstation or netbook , not a Vax in 1985 with 120 users on it .
But that workstation or netbook might be behind a corporate firewall on a network with 120 other users .</tokentext>
<sentencetext>This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.
But that workstation or netbook might be behind a corporate firewall on a network with 120 other users.

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150082</id>
	<title>Re:I fail to see the problem</title>
	<author>bmo</author>
	<datestamp>1257076380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.</i></p><p>What about computers that are shared among a family?  While working in a computer and electronics repair shop, I can't tell you the number of times someone said "Can you figure out what my son did?"</p><p>To quote Tom Christiansen again:</p><p>"My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe."</p><p>Installing software is a root function.  There's a reason why it's been that way for decades.  Allowing ordinary users without some sort of gateway (password in sudo) to install even signed packages is madness.  Ignoring the fact that computers are used by more than one person is ignoring reality.</p><p>There is a point where "user friendliness" becomes harmful in the long run.  This is one of those cases.</p><p>--<br>BMO</p></div>
	</htmltext>
<tokenext>This is someone 's workstation or netbook , not a Vax in 1985 with 120 users on it.What about computers that are shared among a family ?
While working in a computer and electronics repair shop , I ca n't tell you the number of times someone said " Can you figure out what my son did ?
" To quote Tom Christiansen again : " My hunch , and it 's only a hunch , is that this is happening because Microsoft and their moronic minions simply can not for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe .
" Installing software is a root function .
There 's a reason why it 's been that way for decades .
Allowing ordinary users without some sort of gateway ( password in sudo ) to install even signed packages is madness .
Ignoring the fact that computers are used by more than one person is ignoring reality.There is a point where " user friendliness " becomes harmful in the long run .
This is one of those cases.--BMO</tokentext>
<sentencetext>This is someone's workstation or netbook, not a Vax in 1985 with 120 users on it.What about computers that are shared among a family?
While working in a computer and electronics repair shop, I can't tell you the number of times someone said "Can you figure out what my son did?
"To quote Tom Christiansen again:"My hunch, and it's only a hunch, is that this is happening because Microsoft and their moronic minions simply cannot for the all the tea in China ever manage to think outside of their quaint but completely fictional little single-user universe.
"Installing software is a root function.
There's a reason why it's been that way for decades.
Allowing ordinary users without some sort of gateway (password in sudo) to install even signed packages is madness.
Ignoring the fact that computers are used by more than one person is ignoring reality.There is a point where "user friendliness" becomes harmful in the long run.
This is one of those cases.--BMO
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151136</id>
	<title>Line crossed..</title>
	<author>Junta</author>
	<datestamp>1257081780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>I undestood locality to console as an 'authentication' scheme for reboot/shutdown -h now.  That is a transient state change with, in theory, no lasting effects on the underlying platform.  The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.</p><p>I understand the use for removable media, where the owner of auto-plugged media is assigned to the 'console' user.  Persistent state change is possible, but restricted in scope to a removable device that someone at a 'console' controlled physically anyway.</p><p>However, this is a mechanism that allows a user to make persistent state changes to the 'root' owned content.  This is simply not acceptable.  The act of installing software is rare enough so the password shouldn't be considered horrible, and no worse alternatives are likely if a user cannot install the software conveniently.</p></htmltext>
<tokenext>I undestood locality to console as an 'authentication ' scheme for reboot/shutdown -h now .
That is a transient state change with , in theory , no lasting effects on the underlying platform .
The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.I understand the use for removable media , where the owner of auto-plugged media is assigned to the 'console ' user .
Persistent state change is possible , but restricted in scope to a removable device that someone at a 'console ' controlled physically anyway.However , this is a mechanism that allows a user to make persistent state changes to the 'root ' owned content .
This is simply not acceptable .
The act of installing software is rare enough so the password should n't be considered horrible , and no worse alternatives are likely if a user can not install the software conveniently .</tokentext>
<sentencetext>I undestood locality to console as an 'authentication' scheme for reboot/shutdown -h now.
That is a transient state change with, in theory, no lasting effects on the underlying platform.
The slight risk of temporary DoS is taken understanding that the user would otherwise resort to ungraceful use of the power button.I understand the use for removable media, where the owner of auto-plugged media is assigned to the 'console' user.
Persistent state change is possible, but restricted in scope to a removable device that someone at a 'console' controlled physically anyway.However, this is a mechanism that allows a user to make persistent state changes to the 'root' owned content.
This is simply not acceptable.
The act of installing software is rare enough so the password shouldn't be considered horrible, and no worse alternatives are likely if a user cannot install the software conveniently.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151044</id>
	<title>Re:User-level package manager</title>
	<author>eldepeche</author>
	<datestamp>1257081120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I bet you can configure gentoo to do this on top of another distro. I used to have a gentoo tree built in my OS X home directory.</p></htmltext>
<tokenext>I bet you can configure gentoo to do this on top of another distro .
I used to have a gentoo tree built in my OS X home directory .</tokentext>
<sentencetext>I bet you can configure gentoo to do this on top of another distro.
I used to have a gentoo tree built in my OS X home directory.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149850</id>
	<title>Re:User-level package manager</title>
	<author>jmorris42</author>
	<datestamp>1257075480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; What I want is a package manager that will do installation to my own home directory.</p><p>Both rpm and deb can almost do that.  It requires some minor things to change to make it usable.</p><p>1.  An effort to raise the issue, push the advantages to it, etc.</p><p>2.  You create a mini tree in your home directory, with a bin, lib, etc.  Then you init an rpmdb (or the deb equiv) in that tree.  And get the magic right in your login to point the environment variables at it.  Then you can install packages into that tree so long as they don't do things only root can do.</p><p>3.  As things stand now, to install the smallest package into that tree will require installing darned near a full distro which will have packages only root can install.  So the one key feature is rpm (and dpkg) need a new switch that allows it to merge two package sets so the user tree doesn't need any package already installed on the main system.</p><p>4.  Packages which are good candidates for this sort of ad-hoc install need to be checked for any root only activity that could be seperated out into a sub-package for system wide install.</p><p>5. To complete the system the update tool would need to monitor your local packages and be able to notify you of updates and then actually do the updates automagically even if you have local repos installed.</p><p>5.  The graphical front ends would need to be modified to make it all just work.  You would run packagekit and click on a package.  If you were a mortal user it would just install it into your home directory if it could or tell you to ask an admin if it needed root.  Ad icon in the package list would show eligible packages or perhaps grey out package the user lacked rights to install.  A power user/admin would get prompted whether to install system-wide or locally.</p><p>6.  One last touch would be some sort of system to fix duplicate installs.  If a user added a package to their private set and the admin later added it the system would need to be smart enough to remove the local version to prevent two different versions from being visible at the same time.  It would also help recover disk space.</p></htmltext>
<tokenext>&gt; What I want is a package manager that will do installation to my own home directory.Both rpm and deb can almost do that .
It requires some minor things to change to make it usable.1 .
An effort to raise the issue , push the advantages to it , etc.2 .
You create a mini tree in your home directory , with a bin , lib , etc .
Then you init an rpmdb ( or the deb equiv ) in that tree .
And get the magic right in your login to point the environment variables at it .
Then you can install packages into that tree so long as they do n't do things only root can do.3 .
As things stand now , to install the smallest package into that tree will require installing darned near a full distro which will have packages only root can install .
So the one key feature is rpm ( and dpkg ) need a new switch that allows it to merge two package sets so the user tree does n't need any package already installed on the main system.4 .
Packages which are good candidates for this sort of ad-hoc install need to be checked for any root only activity that could be seperated out into a sub-package for system wide install.5 .
To complete the system the update tool would need to monitor your local packages and be able to notify you of updates and then actually do the updates automagically even if you have local repos installed.5 .
The graphical front ends would need to be modified to make it all just work .
You would run packagekit and click on a package .
If you were a mortal user it would just install it into your home directory if it could or tell you to ask an admin if it needed root .
Ad icon in the package list would show eligible packages or perhaps grey out package the user lacked rights to install .
A power user/admin would get prompted whether to install system-wide or locally.6 .
One last touch would be some sort of system to fix duplicate installs .
If a user added a package to their private set and the admin later added it the system would need to be smart enough to remove the local version to prevent two different versions from being visible at the same time .
It would also help recover disk space .</tokentext>
<sentencetext>&gt; What I want is a package manager that will do installation to my own home directory.Both rpm and deb can almost do that.
It requires some minor things to change to make it usable.1.
An effort to raise the issue, push the advantages to it, etc.2.
You create a mini tree in your home directory, with a bin, lib, etc.
Then you init an rpmdb (or the deb equiv) in that tree.
And get the magic right in your login to point the environment variables at it.
Then you can install packages into that tree so long as they don't do things only root can do.3.
As things stand now, to install the smallest package into that tree will require installing darned near a full distro which will have packages only root can install.
So the one key feature is rpm (and dpkg) need a new switch that allows it to merge two package sets so the user tree doesn't need any package already installed on the main system.4.
Packages which are good candidates for this sort of ad-hoc install need to be checked for any root only activity that could be seperated out into a sub-package for system wide install.5.
To complete the system the update tool would need to monitor your local packages and be able to notify you of updates and then actually do the updates automagically even if you have local repos installed.5.
The graphical front ends would need to be modified to make it all just work.
You would run packagekit and click on a package.
If you were a mortal user it would just install it into your home directory if it could or tell you to ask an admin if it needed root.
Ad icon in the package list would show eligible packages or perhaps grey out package the user lacked rights to install.
A power user/admin would get prompted whether to install system-wide or locally.6.
One last touch would be some sort of system to fix duplicate installs.
If a user added a package to their private set and the admin later added it the system would need to be smart enough to remove the local version to prevent two different versions from being visible at the same time.
It would also help recover disk space.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30172300</id>
	<title>Re:User-level package manager</title>
	<author>Anonymous</author>
	<datestamp>1258737960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Autopackage can do that. It you can find a package for whatever you want to install.</p></htmltext>
<tokenext>Autopackage can do that .
It you can find a package for whatever you want to install .</tokentext>
<sentencetext>Autopackage can do that.
It you can find a package for whatever you want to install.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149228</id>
	<title>SCREW THAT</title>
	<author>Anonymous</author>
	<datestamp>1257072840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm going back to Slack!!!</p><p>oh wait.</p><p>I never left.<nobr> <wbr></nobr>/me smugly picks up tobacco pipe, and takes a few puffs...</p></htmltext>
<tokenext>I 'm going back to Slack ! !
! oh wait.I never left .
/me smugly picks up tobacco pipe , and takes a few puffs.. .</tokentext>
<sentencetext>I'm going back to Slack!!
!oh wait.I never left.
/me smugly picks up tobacco pipe, and takes a few puffs...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152280</id>
	<title>I am a fedora user and I liked all through F11</title>
	<author>Anonymous</author>
	<datestamp>1257089160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I will not be downloading another fedora until this is fixed.<br>This is utterly wrong.</p></htmltext>
<tokenext>I will not be downloading another fedora until this is fixed.This is utterly wrong .</tokentext>
<sentencetext>I will not be downloading another fedora until this is fixed.This is utterly wrong.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30157284
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154102
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30189728
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151142
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149250
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153170
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150050
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158362
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152074
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152954
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151380
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152638
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150416
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150194
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30172300
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149926
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149236
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151738
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30156918
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150268
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149784
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149330
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155088
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152774
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150520
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150796
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149342
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150322
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154322
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149090
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150440
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154684
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152982
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149810
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154066
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149754
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149264
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150632
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150134
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149488
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149540
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154090
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149492
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150084
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150082
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30159866
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153512
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155870
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150612
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149638
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30164682
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149584
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152478
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151882
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154890
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154424
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155344
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150818
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150358
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151508
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30282192
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151176
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149428
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149390
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152834
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150808
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154196
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151734
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150250
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158188
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151510
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154014
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_18_2039229_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154986
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148966
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149772
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161644
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158362
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149092
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149850
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30164682
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149488
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149618
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150134
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30282192
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154066
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149784
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30172300
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149264
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152258
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30159866
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154322
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151714
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149236
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151738
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154890
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151696
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154014
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151892
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153408
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154102
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150440
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149390
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30189728
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149584
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154716
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151544
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148992
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152954
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149892
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151142
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153888
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149140
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151508
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30157284
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155344
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150612
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149492
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150084
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149250
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30148974
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153256
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149664
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149066
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149144
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152774
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150632
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150194
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150050
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149338
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149012
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154090
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149330
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149778
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149498
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149810
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30161624
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151510
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30156918
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150808
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149926
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150416
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150818
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149754
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151526
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30158188
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154424
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151476
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149032
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149238
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150082
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149326
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150250
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149540
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150122
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149132
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152982
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149428
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151698
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151176
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150358
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152638
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150268
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151734
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149000
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154684
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149090
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149038
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149342
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152666
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149210
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150520
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150796
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152834
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153170
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150012
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30154986
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30151882
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30153512
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155870
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30155088
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150322
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152696
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_18_2039229.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149150
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30149638
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30150760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152478
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_18_2039229.30152074
</commentlist>
</conversation>
