[Bug 286017] and Gentoo developer's *behavior*

[Earthwings]

Looks like you can't read.
Do you understand what are we speaking about?
You can find the information you are not aware about here:
http://www.rootshell.be/~spinal/gentoo_ ... 86017.html

Specially for you, running "sudo visudo" is something different from running visudo being root...

Calm down and stop being rude, please. [topic=525]Forum Guidelines[/topic].

[desultory]

Did you visit the link? It's obviously seen there, just next to button "Commit"
http://www.rootshell.be/~spinal/gentoo_ ... 86017.html

I read the bug and checked the activity log for it.

[argin]

I attentively read all thread, and I think that changing default behavior of well known important application like visudo without any noticing is really bad decision. And it bad decision even with noticing, because the leave the important variable unseted in case of someone remove the nano from system.
In fact we have two different editor - one is configured with EDITORS variable, and another with "default editor" . It is sense, that in stage 3 both have the same value, but it two essentially different case, and have to be a interface like
eselect set visudo bla-bla-bla
to set this IMPORTANT security related editor when we deploy gentoo on computer. All editor's ebuilds in it postinastall phase should check the value of both variable and suggest decision.

This bug obviously related to Diego, but not only him. It is gentoo system level bug, IMO.

[ulm]

A copy of the bug's activity log is here: http://dev.gentoo.org/~ulm/misc/bug-286 ... ivity.html

[Voltago]

Is it fair to restrict community from discuss bugs and it's solution???

You want it one way, Diego wants it another way. You insist, Diego doesn't budge. You are user, Diego is a developer. You loose. Welcome to reality. As for discussion, I guess the forums are a better place for that, bugzilla is for bug resolution. Haranguing a developer doesn't really resolve anything, it only wastes time.

[ewphillips]

Since sudo hard codes a default editor during compile(which for security reasons it should), when you change the default in /etc/env.d(for openrc) or /etc/conf.d/rc(for non openrc users) you must the env-update and emerge sudo again for the change to have any effect(ie when running sudo visudo or sudoedit foo). I did this, adding: /etc/env.d/99editor(I use openrc) containing

Code: Select all

EDITOR=/usr/bin/emacs

running env-update and then emerge sudo, sudo visudo gave the expected result of opening /etc/sudoers in emacs, also sudoedit foo opened foo in emacs.
[/post]

[energyman76b]

hard coding an editor during compile is idiotic from a security POV.

[comprookie2000]

Hi Everyone,
Diego wanted me to post a link to his blog where he explains his reasoning. He would have posted it himself but he has misplaced his forum credentials
http://blog.flameeyes.eu/2009/10/04/exp ... o-crapfest

being kind is more important than being right

[Anon-E-moose]

Hi Everyone,
Diego wanted me to post a link to his blog where he explains his reasoning. He would have posted it himself but he has misplaced his forum credentials
http://blog.flameeyes.eu/2009/10/04/exp ... o-crapfest

being kind is more important than being right

Thanks for that read.

I agree with Diego.

And a final thought on the original whine/complaint about sudo.
If someone really, really, really doesn't like the default way gentoo has compiled sudo,
or any package for that matter, they can certainly get the original source and compile it
themselves. Problem solved.

[yngwin]

Don't play reopen-close wars on bugzilla. It's highly annoying and you will loose. As you have seen.

Also, and more importantly, it distracts the attention away from the real issue and makes it about your behaviour. And saying "you're wrong, this is not the Gentoo Way" to a developer who commits a lot of time to Gentoo year after year, achieves the same thing.

[rrbrussell]

Sudo should probably depend on nano directly and not virtual/editor. I would also add some einfo documentation to the ebuild saying that the <2MB of storage nano requires when built with normal use flags probably is only worth worrying about if you are using an embed system.

I quit using sudo when I noticed subversion creating a root owned .svn directory under my users ~/ directory, when layman updated some overlays using subversion. I figured that if subversion or sudo was going to leave root owned configuration files under my personal ~/ tree I might as well su - to root.

[Flameeyes]

Sudo should probably depend on nano directly and not virtual/editor. I would also add some einfo documentation to the ebuild saying that the <2MB of storage nano requires when built with normal use flags probably is only worth worrying about if you are using an embed system.

Given I'm the first person who _removes_ nano from a system upon install, I would never do that to beginw ith.

I quit using sudo when I noticed subversion creating a root owned .svn directory under my users ~/ directory, when layman updated some overlays using subversion. I figured that if subversion or sudo was going to leave root owned configuration files under my personal ~/ tree I might as well su - to root.

I would have suggested to read the manual about stuff like, say,

Code: Select all

sudo -i

.

[rrbrussell]

Sudo should probably depend on nano directly and not virtual/editor. I would also add some einfo documentation to the ebuild saying that the <2MB of storage nano requires when built with normal use flags probably is only worth worrying about if you are using an embed system.

Given I'm the first person who _removes_ nano from a system upon install, I would never do that to beginw ith.

I understand not wanting to keep unused stuff around on the system, but, since sudo has a compiled in link to nano it should correctly depend on nano.
If someone overrides the choice for compiled in editor sudo should then sudo should depend on virtual/editor. The patch for the vanilla use flag attached to bug report seems to do this.

My other recommendation would be to add to sudo one use flag per editor and which editor sudo depends upon and has compiled in is determined by the use flags. I am willing to modify the sudo ebuilds to make support the single use flag per editor aproach, with some help from a developer.

I quit using sudo when I noticed subversion creating a root owned .svn directory under my users ~/ directory, when layman updated some overlays using subversion. I figured that if subversion or sudo was going to leave root owned configuration files under my personal ~/ tree I might as well su - to root.

I would have suggested to read the manual about stuff like, say,

Code: Select all

sudo -i

.

The sudo man page does not seem as dense as I remember it being.

[Flameeyes]

I understand not wanting to keep unused stuff around on the system, but, since sudo has a compiled in link to nano it should correctly depend on nano.
If someone overrides the choice for compiled in editor sudo should then sudo should depend on virtual/editor. The patch for the vanilla use flag attached to bug report seems to do this.

My other recommendation would be to add to sudo one use flag per editor and which editor sudo depends upon and has compiled in is determined by the use flags. I am willing to modify the sudo ebuilds to make support the single use flag per editor aproach, with some help from a developer.

No, see, you probably haven't read my post with all the explanation of the thing, or you wouldn't be going on about this after I gave a definitive answer to this.

Please drop it. You also said you don't use sudo, so stop caring, and stop keeping on wasting others' time.

[kernelOfTruth]

I would have suggested to read the manual about stuff like, say,

Code: Select all

sudo -i

.

thanks Diego !

I've been looking for this kind of behavior since years !

(and have always neglected to read man )


I'm not really using sudo on a regular basis but good to know how it works / how to initiate

[gentoo_lan]

Reported and this thread needs to be locked.

[desultory]

Reported and this thread needs to be locked.

While the [post=6000473]post[/post] you [post=6000570]reported[/post] is arguably argumentative, I do not consider it to be cause to lock this topic, much less ban Flameeyes, though that is best argued [topic=795975]elsewhere[/topic].

[rrbrussell]

I understand not wanting to keep unused stuff around on the system, but, since sudo has a compiled in link to nano it should correctly depend on nano.
If someone overrides the choice for compiled in editor sudo should then sudo should depend on virtual/editor. The patch for the vanilla use flag attached to bug report seems to do this.

My other recommendation would be to add to sudo one use flag per editor and which editor sudo depends upon and has compiled in is determined by the use flags. I am willing to modify the sudo ebuilds to make support the single use flag per editor aproach, with some help from a developer.

No, see, you probably haven't read my post with all the explanation of the thing, or you wouldn't be going on about this after I gave a definitive answer to this.

Please drop it. You also said you don't use sudo, so stop caring, and stop keeping on wasting others' time.

What I got from your post was

• People really need to offer to help fix things when they make bug reports. I completely agree with this one.
• The default editor is nano because it is assumed to be there. Again, I agree.
• Sudo is told to respect the EDITOR and VISUAL environmental editors and I managed to miss an obvious point in the sudo man page.
• The default editor can be changed, but, not by the usual means of changing a compiled in feature in Gentoo.
• Fixing the default editor would require more work than you have time available right now.

The current setup does work well for most people. However, some people would like to remove nano from their system or systems. But, sudo currently has a hidden dependency on nano. This dependency can sometimes bite those who remove nano, through either a misunderstanding of how sudo works or a misconfiguration of sudo.

I have seen five methods suggested for solving the bug of sudo trying to call a non existant nano.

• Change the sudo ebuilds to depend on nano directly. This solves only the hidden dependency and does not allow the user to remove nano. This also unnecessarily limits the freedoms of users.
• Change the sudo ebuilds to import an external environmental variable during build time. A hack pure and simple.
• Change the sudo ebuilds to install a configuration file that always keeps the EDITOR variable set. This only guarantees that sudo will not call nano unless the default EDITOR variable is in effect or the user resets their EDITOR variable back to nano.
• Change the sudo ebuilds to build with nano as the default editor and depend on nano. Then add use flags for each command line editor in portage to the sudo ebuild. If one of these new use flags is set then sudo will use that editor as its default and depend on that editor. I would also install a configuration file set to preserve the EDITOR variable.
• Implement the /usr/libexec/gentoo-editor script Flameeyes suggested.

I suggest either methods 5, 4, or 3 because I think they would solve or come the closest to solving the problem. I am also willing to work with any developer to implement these changes or changes that might be required after more eyes look at this. I also will have to start using sudo here in the next couple of weeks so I do have an interest in solving this.

I am also so an optimist who thinks a reasonable solution/compromise can be found. If someone has a technical reason, not just lack of man power, that any of these solutions might not work please make a mention of it with details.

[SamuliSuominen]

You guys don't seem to realize that without Diego you would be using vulnerable sudo from 2006 and by forcing his hand on such a ridicilous issue he's not intrested it maintaining it anymore.

Thanks for ruining it for everyone.

[Flameeyes]

• …
• Implement the /usr/libexec/gentoo-editor script Flameeyes suggested.

This is exactly what we're doing already, ulm went ahead and started working on such a script.

As I said, I really have no intention on forcing any particular editor upon users; the reason why sudo could (and should!) use nano without an explicit depend is that it's the Gentoo “default” editor (read the link for further details, and if something is still not clear feel free to ask there).

The main lesson to be learned here (for more than a couple of people it seems) is: “developers don't usually ignore users unless they have a reason to; and they tend to be more productive when they are not forced into repeating, or defending, themselves”. And if you don't understand the reason for something, rather than insisting you know the best way, the most common way to get actual results is to ask.

[Anon-E-moose]

You guys don't seem to realize that without Diego you would be using vulnerable sudo from 2006 and by forcing his hand on such a ridicilous issue he's not intrested it maintaining it anymore.

I can't say that I blame him.
I wouldn't put up with what he did.
It's not like he's being paid to do it.

Anyway, there are those of us out here who do appreciate what you do and have done Diego

[kernelOfTruth]

You guys don't seem to realize that without Diego you would be using vulnerable sudo from 2006 and by forcing his hand on such a ridicilous issue he's not intrested it maintaining it anymore.

I can't say that I blame him.
I wouldn't put up with what he did.
It's not like he's being paid to do it.

Anyway, there are those of us out here who do appreciate what you do and have done Diego

++

[baaann]

You guys don't seem to realize that without Diego you would be using vulnerable sudo from 2006 and by forcing his hand on such a ridicilous issue he's not intrested it maintaining it anymore.

I can't say that I blame him.
I wouldn't put up with what he did.
It's not like he's being paid to do it.

Anyway, there are those of us out here who do appreciate what you do and have done Diego

++

[Sadako]

I don't know if this has been suggested in this thread already, but what about modifying the sudo ebuild to hardcode the value of something like "${SUDO_EDITOR}" if defined, otherwise default to nano, so if a user doesn't want it to default to nano they can set something like SUDO_EDITOR="/bin/vi" in make.conf?

Then you could even add an ewarn or einfo if SUDO_EDITOR isn't defined but nano isn't installed.

More and more ebuilds seem to using something like this, ie optional variables in make.conf specific to the one package...

And tbh, I do think rrbrussell has a point wrt nano being a dependency of sudo with the current ebuilds, and it would be trivial for anyone to add nano to package.provided if they really doesn't want it installed.

Just my worthless 2¢ is all...

[Flameeyes]

Okay, now, please, everybody stop proposing changes that have no reason to be considered at all.

My blog post explain everything and no further change will happen. The editor script will cover everything and you can finally stop proposing solutions that have no use at all beside increasing complexity and thus waste the time of the maintainer (i.e.: most likely, still me).

If I really have to put up with so many suggestion (tons of variables, no-defaulting at build-time even though the runtime behaviour is already customizable to the detail, or absurd dependencies), then yeah, of course I'm going to drop the package and leave whoever wants to pick it up to pick it up. Given that nobody beside me stepped up after Tavis left, I'm curious who's going to be at that point. Especially taking into consideration this sheer amount of pointless commentaries.

Because yes, this is just pointless. No I'm not going to add a new variable, there's no need for that, three at runtime are already quite enough; no I'm not going to add a dependency over nano, there's no more dependency over nano in sudo than there is already in baselayout/openrc; no I'm not going to add a truckload of USE flags just because you like to set them; there is no need for that; no I'm not going to do anything beside completing the gentoo-editor script that Ulrich already started and using that.

Given that, as some other people have reminded here, I'm not paid by anybody to do this I could really have just ignored all requests from the beginning; what I'm trying to do instead is, for goodwill, trying to explain slowly to everybody that there is no compelling reason to do anything beside the fact that I don't like the change that was forced on sudo against my (the maintainer's) will.

So if you still think my post explaining the sudo non-issue doesn't cover something, feel free to ask, not go around proposing overcomplex solutions to problems that don't exist; and if you think that nano should be a dependency please re-read the other post. If you still cannot formulate a question of a non-covered note, but you still would make a suggestion, re-read and repeat until you can first come up with a question. Either this or I should start charging for every commit I make…